Staking New Territory, Breaking New Ground The Web Services marketplace is officially "in play." Though adoption of the technology itself is nearly a foregone conclusion, developers—and Java developers in particular—are left with a considerable conundrum: How shall we build them? Microsoft has staked its future on Web services; Can Sun, standards, and security keep apace with developers' demands? by Andrew Binstock

very year or so, a new fad storms through computing and offers what seems to be a miraculous solution to an intractable, age-old problem. Most such fads die away, some quickly, some too slowly; while a few—such as the Internet, the Web, and Java—develop into truly useful technologies. Web services are the latest craze; much about Web services, however, suggests they will be around long-term and develop into a mainstream technology. Web services will acquire what analysts call "traction." In fact, many analysts, including me, believe the adoption of Web services is likely to occur faster than it did even for Java. Why? Web services answer a distinct need; they are simple to understand and implement; they rely on industry standards (SOAP and WSDL); and they leverage existing code.

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").

The Developers' Challenge

In this Article
Introduction	Writing Web Services—The Developers' Challenge
Issues that Need to Be Addressed