Exactly What Are Web Services?
In a nutshell, Web services are computer-processing services made available over HTTP (hence the "Web" in the name) using a handful of independent protocols to perform the discovery (where the service is located), invocation (calling the service), and passing of data items to and fro. The universal example of a Web service shows an application sending a server located at a remote site a ZIP code via HTTP and receiving back the current temperature in that ZIP code.

On the surface, this action might not seem like a big deal, but in fact, the ability to have remote servers provide computational services or content without having to be concerned that programs or data formats are compatible ushers in a raft of new applications.

What is it?

In a nutshell, Web services are computer processing services made available over HTTP (hence the 'Web' in the name) using a handful of independent protocols to perform the discovery (where the service is located), invocation (calling the service), and passing of data items to and fro. The universal example of a Web service shows an application sending a server located at a remote site a ZIP code via HTTP and receiving back the current temperature in that ZIP code.

The first aspect of this benefit is the absence of concern about data formats. Web services use several standards, SOAP (simple object access protocol) and WSDL (Web services definition language) to define what's being passed in and what will be returned. In addition, using XML as an extended data format means that applications that rely on different operating systems and different data formats can interact seamlessly with a server that exposes Web services. The differences in data and operating platform are dissolved by the protocols.

A second benefit is the ease with which Web services enable the distribution of content. A content provider—let us say one providing digital images—can expose a set of Web services for image delivery. Any application can now send requests for specific images and quickly receive them. To help the application find these images, a universal way of locating the available content is specified in the universal description, discovery, and integration (UDDI) protocol, which is the third of the three central Web services standards.

A third aspect of Web services makes them attractive to IT: Converting existing code into Web services is not difficult. Web services can encapsulate objects and code fragments written in different languages and deployed on different servers and make them available for use by other programs regardless of what platforms those programs are running on.

So, in theory, a Python routine running on a Macintosh can seamlessly hand off some computing function to a Visual Basic function running on Windows XP box which in turn invokes an EJB on a Solaris server. Initially, this may appear like the EAI argument again, but the integration is the secondary benefit in this case; what is important is that legacy code need no longer be rewritten to be integrated into the enterprise. Any platform it runs on can now be integrated into the computing fabric through Web services.

Other analysts project that Web services will thrive in B2B and supply-chain applications. Whereas today vendors in the supply chain must open confidential data to partners and provide access mechanisms for data conversions, Web services can handle the data issues as well as limit the visibility of confidential data without restricting access to the needed information. The outside company uses the Web-services interface to send requests and receive the data in its own native format.

Undoubtedly, as Web services are deployed, new ideas for tapping their utility will emerge and provide new, unforeseen opportunities for deployment (see sidebar "Where They Are Deployed").

Writing Web Services—The Developers' Challenge
In the second installment of this series, we'll show you how to write both a simple and complex Web service in Java. As you'll see, the work involved is not great. It requires some familiarity with the prerequisite standards, which are not terribly difficult to understand. It is certainly easier to write Web services than to learn a new programming language. And with the advent of new tools from leading vendors, writing Web services may soon be downright easy.

The major players are poised to make an impact in this way are Microsoft with its .NET initiative, Sun (with its SunONE package), IBM (with its new Eclipse tools), and Oracle. A raft of other vendors are trying to elbow their way in as well: notably, BEA, Sybase, and IONA. Meanwhile, pure-play Web services companies such as CapeClear, have been unveiling impressive tools. Let's try to put some order into this market.

A year and a half ago, when Microsoft announced C#, developers scoffed. Six months ago, when Microsoft first pulled the covers back on J#, developers jeered. No one is scoffing or jeering now.

Microsoft .NET
For the uninitiated, .NET is a set of technologies that form Microsoft's computing platform of the future. It includes recent releases of existing technologies (for example, future releases of the Windows operating system will be part of the .NET family; SQL Server 2000 is already considered part of .NET) as well as some completely new technologies. The most interesting of the latter is the .NET common language runtime (CLR), which allows all languages to share a common execution environment on Windows. Complementary technologies include the Passport identification and authentication mechanism, ADO.NET to provide database access, and ASP.NET to improve and accelerate Web interaction. These technologies are designed to work as natively as possible with XML.

When viewed as a whole, .NET is Microsoft's attempt to put together a comprehensive execution environment with everything a company would need to implement Web services on Windows with the minimum of effort. In this regard, one could say that but for the Windows attachment, .NET is Microsoft's response to the Java enterprise solution, J2EE.

This view is furthered by the development tools Microsoft shipped in February as Visual Studio .NET (VS.NET). This huge product (the zipped file weighs in at 1.8GB and expands to more than 24,000 files) is an update to Visual Studio 6 that directly supports the new languages Microsoft is promoting for developing Web services: C#, which is a new language that looks a lot like Java; J#, an even closer implementation of Java syntax and libraries; and VB.NET a substantially modified update to Visual Basic.

A year and a half ago, when Microsoft announced C#, developers scoffed. Six months ago, when Microsoft first pulled the covers back on J#, developers jeered. No one is scoffing or jeering now. Over the last few months it has become apparent that Microsoft has done a remarkable job developing new products and getting them standardized.

Consider that Microsoft—a company known for imposing its own standards and disregarding those of others—developed SOAP, which the Web services community adopted voluntarily, not to say eagerly. Microsoft also won ECMA certification for its C#. Alan Zeichick of SD Times correctly described this as "clearing a low hurdle," but that hurdle was too high for Java. It's clear that Microsoft recognizes that some of the old hardball business tactics won't work with the Web and IT communities as it did on the desktops. As such, the company is working much more cooperatively (and thus, wisely) than ever before. Whether this is a real conversion or a temporary expedient remains unclear.

What is clear is that the technology is impressive. Early users of C# like the language: it's C++ and Java without a lot of the baggage, and—surprise—it runs fast. J# enables developers to run Java programs natively on Windows without excessive difficulty. Only the VB crowd will face serious obstacles to porting their code. It's not a far-fetched theory to say that Microsoft views Visual Basic developers as solidly Microsoft-committed and are therefore unlikely to leave the fold in great numbers over porting difficulties. This is the most sensible explanation for why the company has been least responsive to their needs.

Microsoft has publicly staked its future on XML, so delivery of high-quality .NET products is key to its success. The first generation of products looks good. In fact, Microsoft has made creating Web services about as simple as possible: see the sidebar "Writing a Web Service in .NET."

SunONE
At the time this article was commissioned, it was outlined as a .NET vs. Sun ONE comparison, because the editors—like the Java community—expected a serious well-articulated response from Sun to .NET. ONE—the Open Net Environment—you will recall, was unveiled in February 2001 as Sun's Web services strategy. At that time, analysts dismissed it as a bunch of old products being repositioned. Most of them expected that as the .NET release drew nearer, Sun would formulate its usual well-articulated vision to counter Microsoft's marketing machine.

To the disappointment of many, Sun announced only some XML interfaces to Java and little else. No overarching vision, no clever sound bites. Nothing. As can be seen from the companion interview with Marge Breya , the vice-president in charge of Sun ONE , there is still no vision beyond promoting Solaris, the iPlanet application server, and the Liberty Alliance.

While many magazines have reacted with surprise at Sun's lack of formulated response (Information Week ran this as its cover story recently; even consumer publications such as the Economist weighed in), Sun has several factors on its side. Most of all, it has time. .NET has only just started shipping and even though it shows promise, Microsoft generally takes several product releases to get its technology right. The current security issues with Microsoft Passport are consistent with this history.

In addition, there is no way to tell how interested developers will be in using C# or J#. On both counts, Sun has a huge lead with Java: Java works well and developers like it. Sun's problem is to hang on to Java sites, so that they don't become Java and .NET hybrids. And to do this, the company must soon start painting a vision that developers and IT shops can support.

Other Major Players
Sun's ability to shape an interesting Web services story for Java normally would depend on the participation of other key players in the Java community. However, two key players have no particular desire to help Sun out of its predicament. These are IBM and Oracle—both companies have tools that compete with Sun's iPlanet server. IBM was actually the first major vendor to have Web services ready to demo, doing so in the first half of 2001. Since then, it has filled out its product line considerably, and has done it with the help of the open-source community. Read our sidebar "IBM's Open-Source Approach to Building Web Services."

Oracle is trying to elbow its way into the fray. The company believes its database expertise, its application server, and longstanding commitment to Java give it the credentials to be a major player in Web services. Such a role, though, seems unlikely. In its current incarnation, Oracle's app server is barely a year old; its Java tools, arguably, have only recently become interesting; and the link between Web services and databases presents no problem that Oracle is uniquely qualified to solve. Consequently, Oracle's role will be secondary; it won't be on the vanguard of Web services. Read our sidebar "Oracle's Businesslike Take on Web Services Development."

Pure-play Web Services Vendors
In terms of software development, the pure-play Web services companies actually are among the most interesting. For example, Cape Clear is a company with impressive development tools, whose CapeStudio product handles pretty much any task necessary for the conversion of code to Web services including XML and WSDL generation, UDDI creation, and SOAP-XML interoperability. The company's CapeConnect product enables Java, C++, C#, COM, and CORBA objects to talk to each other through Web services without difficulty.

Other companies with products in this space include Avinon and Bowstreet, both of whom have products for converting business processes into Web services.

Issues that Need to Be Addressed
The deployment of Web services will proceed apace only if certain key issues are addressed quickly by the principal players (Microsoft, IBM, Sun, Oracle, and others). Given their remarkable cooperation so far in quickly adopting the standards discussed earlier, there is reason for optimism. The three central issues are management, security, and uniformity of standards implementation. Taking them in reverse order:

• Uniform implementation of standards. Web services require universal adherence to standards. Early pilots projects have shown, however, that different parties read the standards documents differently. As a result, in February, more than 50 companies (notably absent was Sun) formed the Web Services Interoperability Organization to iron out differences in implementations. This group will be meeting for the first time in March 2002, as this article is published.
• Security. This issue currently dominates the dialogue about Web services. It is unfortunately cast into just one problem: authentication. That is, how does the provider of Web services know the requesting party is entitled to access the services? Microsoft's Passport and Sun's Liberty Alliance are two initiatives that attempt to define authentication mechanisms. But Microsoft's Passport has shown security weaknesses of its own, namely in the form of allowing inappropriate access to personal data that is shipped to the service vendor. The Liberty Alliance, which might be more secure, is less widely deployed at present. Undoubtedly, security standards will need to be formulated. (Read the related article "Software Engineers Put .NET and Enterprise Java Security to the Test".)
• Management. Little attention has yet been paid to the management of services—specifically, on guaranteeing their delivery. For example, if an application relies on Web services to provide weather telemetry or ZIP code look-ups, what happens when the services are not working? By building Web services directly into applications, sites are dependent on the integrity of servers and data at locations over which they can exert no control. Is there a scenario in which a company would have a component of a mission-critical application be dependent on a Web service? Only once redundant providers of services can be instituted. Today, time servers using Simple Network Time Protocol (SNTP) to provide highly accurate time when polled are the only thing that comes close to redundancy in Web services. This time data is frequently used in time stamps and clock synchronization of remote systems. To guarantee reliable access to accurate clocks, there are more than 250 continuously running SNTP servers available for polling. (For more information, see http://www.oneguycoding.com/automachron/).