Many major IT players, including IBM, Microsoft, Ariba, and Sun, are proclaiming Web services to be "the next big thing." Web services are essentially software resources made available for consumption over the Internet, but they extend the basic Internet person-to-program interactions (i.e., individuals accessing programs on Web servers via browsers) to support program-to-program interactions. Data from one Web site can be integrated with data from another site, but it involves tricky HTML parsing or manually cutting and pasting elements together. The new technologies that enable Web services allow automating this integration.

Web services are concerned primarily with the program-to-program interactions. For example, Web services can connect the back end of an enterprise system to markets and other industrial partners, or you can use Web services for internal processes such as order fulfillment and employee management. They can also provide service offerings between a business and its customers, just as in the browser-based Internet model. Web services let businesses deal with daily tasks or deliver services programmatically. In many cases, the selection of which Web service to use is dynamic.

Figure 1 shows the three pieces of the Web services puzzle and their interactions. First, a service provider develops a new Web service application and publishes information about the service (the interface) with a service broker. Then, a service requestor (a program) uses the broker to find services. The service requestor applies various criteria to choose which service(s) to select, or the service requestor displays a list and lets the user decide.

After selecting a service provider, the service requestor retrieves the stored information from the broker, including how to connect to the service provider. Then the requestor binds to the provider and uses the service.

This process is analogous to a business (a service provider) publishing information about itself in the local phone directory (with a broker). A customer (a service requestor) finds the business and its advertised service in the phone book and calls the business to utilize those services.

Enabling Web Services

Several new technologies enable Web services. These technologies include Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and the Universal Description, Discovery, and Integration (UDDI) specification.

XML is an extensible tag language that can describe complicated structures in ways that are easy for programs to understand. Web services depend heavily on XML, which uses text data rather than binary data. Of course, binary data is generally faster, but after decades of attempts to develop a standard, there is little agreement about how binary data should be exchanged.

It takes fractions of a second of CPU time to create and parse XML data, which adds up to far less processing time than the necessary programmer man-months to convert gobs of software to a new binary format. If XML parsing time bothers you, you're focused on the wrong thing. The more important point is that businesses' programs are talking to each other, and XML enables the conversation. For more information, see "Generation XML," December 1999, and "XML: The Future Language of e-Commerce," January 2000.

SOAP is the protocol for XML remote procedure calls (RPCs) over HTTP. The remote procedure call that travels over the HTTP protocol contains a set of XML tags called the SOAP envelope. Procedures have parameters and return values that must be passed, and XML tags within the SOAP envelope describe each of the parameters and the return value. All publish, find, and bind operations are sent using SOAP. Note that the SOAP specification, as written, covers only HTTP. However, the spec makes it clear that SOAP can be extended to other protocols, as well. For example, you can send SOAP envelopes as e-mail via Simple Mail Transfer Protocol (SMTP) and messaging products such as MQSeries.

SOAP is language- and platform-independent; it lets you talk to any service provider's Web server that understands HTTP and XML (i.e, a Web service provider's application can be written in almost any language and run on any platform). Service applications can be built easily with Java servlets, and the current SOAP toolkit has a flexible architecture so it can call services written with JavaBeans, Enterprise JavaBeans (EJBs), or Component Object Model (COM). Servlets can bridge HTTP SOAP calls to your existing legacy applications (even those written in RPG and Cobol) and convert them into Web services. If you don't want to dive into the deep end of Web services just yet, you can use SOAP in a simpler approach that skips the broker (i.e., the publish and find steps). In this approach, the service requestor is bound to a predetermined service provider via SOAP. See http://xml.apache.org/soap for examples.

So why do Web services require SOAP? Existing binary standards would probably be faster, so why not just use an existing RPC mechanism such as Java's Remote Method Invocation (RMI) or CORBA's Internet Inter-ORB Protocol (IIOP)? The problem with this strategy is that binary protocols use TCP/IP ports that security-conscious administrators block in their firewalls. You could launch a huge "free our IIOP packets" campaign, but it's doubtful that already beleaguered administrators would quickly open their firewalls to binary data they can't easily examine and understand. By contrast, SOAP is text data that travels over HTTP, which passes through firewalls (unless their administrators are completely paranoid).

Note that the current implementation of SOAP also supports message encryption between client and server using Secure Sockets Layer (SSL) and digital signatures.

WSDL is the language used in an XML document that describes a Web service interface and specifies how to call it. (WSDL is similar in function to CORBA's Interface Definition Language, or IDL.) When a Web service application is published to a broker, the application includes WSDL to describe what parameters must be passed on the SOAP request and what return values come back. IBM's Web Services Toolkit includes tools to create WSDL from existing programs and to convert WSDL for a Web service into a Java class that can call the service using SOAP.

UDDI provides SOAP APIs that enable the implementation of a service broker. You can search a UDDI-enabled registry for a provider by company. Or, you can search for all providers of a certain type of service (because services may be classified using standard industrial taxonomies). You can even get the technical specifications for calling the provider's Web service (i.e., how to talk (or bind) to the service).

As software resources, Web services need to be incorporated into centralized repositories so they can be found. Prior to UDDI, there was no easy way to get information about the different standards that companies support. There was no single point of access to let you target all possible trading partners and their respective services. Without UDDI, service requestors and/or providers would have to support multiple repository types.

In addition to this standardized broker functionality, the UDDI.org founding companies have launched the publicly accessible, jointly operated, multisite UDDI Business Registry. When you publish to any one of the participating companies' registries, your information is automatically propagated to all other registries. For more information, see the "UDDI Executive White Paper" at http://www.uddi.org. So why do we need these new technologies to support Web services rather than augmenting existing Web technologies and protocols? Augmenting HTML won't work because even minor changes in the HTML format can confuse programs trying to parse it.

Why not generate Web pages that return XML? That's basically what SOAP does, but you also need XML in the HTTP request because Web services need to do more than simply retrieve a page of data. Web services are remote procedure calls, and their input parameters can be XML, which is more complex than HTTP's GET and POST form commands can handle.

SOAP prescribes standard ways to identify which method to call and the structured parameter data being passed. The SOAP envelope can also contain a header section that includes additional information about the call (e.g., security and transaction information).

Pulling It All Together

Becoming a service provider is a relatively straightforward process. First, you write a service implementation. You can accomplish this entirely in Java, or you write a servlet to call an existing legacy application from an application server. Then, using the appropriate tool from the toolkit, you generate and edit the WSDL that describes your interface. Finally, you publish your interface to a UDDI public or private broker and wait for the service requests to start pouring in.

Depending on your service's function, you may need to write a SOAP-enabled client to access your service. Hopefully, some Web service interfaces will become common (i.e., published in UDDI separate from specific service applications), which would let you write your Web service to support such a common interface (or perhaps a range of common interfaces). Client programs could then be written to specified service interfaces and work for all service providers.

But let's look closer at SOAP's mechanism. In Apache SOAP, the SOAP server is implemented as a Java servlet (called rpcrouter) that runs in an application server such as WebSphere. The servlet parses the incoming SOAP envelope; then, it uses data in the envelope to select which Java class and which method to call.

The servlet also handles converting parameters and return values between XML and Java data types. So, writing a Web service is usually just a matter of writing a Java class. A HelloWorld Web service is merely a class that returns the string to the SOAP servlet. That's all there is to it. More interesting Web services require more interesting code. See "Examples of Web Services," for a list of Web service possibilities.

One reason the Web service concept is getting so much attention, including from iSeries shops, is that Web services provide a handy way to Web-enable existing legacy code such as RPG. The SOAP servlet can call a Java class that uses JDBC or the AS/400 Toolbox for Java (e.g., CommandCall, ProgramCall, ServiceProgramCall) to access legacy code and data.

I recommend getting started with Web services in a "tightly coupled" arrangement in which you control both requestors and providers. This means first deploying Web services inside your business or between a well-defined set of business partners. This strategy will ease the impact of change as you learn and experiment.

Start by using SOAP. Later, you can set up an internal UDDI registry. Of course, if you want the "first-mover advantage," you can register your Web service with a public UDDI registry today and set up shop.

Substance Behind the Hype

Many of the dot-bombs that we've seen come and go promoted new technologies or services that were supposedly "the next big thing." Are Web services just another good idea that will come and go with little impact? In this rapid-fire IT world, no one can make many guarantees. But we can make an informed evaluation, and there are many reasons to believe Web services will be a part of our future.

First, Web services specifications fill an existing need. Prior to SOAP, WSDL, and UDDI, e-commerce applications took many different approaches to connect buyers, suppliers, marketplaces, and service providers. These new Web technologies enable programs to find and communicate with each other on a global scale without large investments in technology infrastructure.

Second, Web services are built on, or are similar to, numerous proven architectures and technologies. All major distributed architectures include a distributed or remote procedure call mechanism (such as SOAP), an interface description language (such as WSDL), and a central naming service (such as UDDI). Web services themselves are built on standard technologies including TCP/IP, HTTP, SSL, and XML.

Third, some of the biggest players in IT are behind the Web services initiative. IBM and Microsoft cooperated on the SOAP spec by merging new technologies that each company was developing. IBM, Microsoft, and Ariba were the founding members of UDDI.org, which has now grown to more than 220 supporting organizations. At JavaOne 2001, Sun promoted Web services as a major theme. The e-business XML (ebXML) organization recently dropped its own XML-based RPC protocol and adopted SOAP (see http://ebxml.org for more information).

If this many disparate companies and consortiums are in agreement, there's a good chance Web services will succeed. Regardless of whether SOAP, WSDL, and UDDI are the best solutions in technical terms, what matters is that the major IT players agree upon standards that facilitate communication, interoperability, and integration.

Fourth, there's a lot of code behind Web services, which represents a large developer investment. Apache has its SOAP open-source group, and IBM and Microsoft offer free Web services toolkits for download (see "Web Services Resources," for more information on available tools). And the public UDDI Business Registry is up and running.

Finally, Web services have a low barrier to entry. If you use one of the free toolkits, your first Web service can be up and running in no time. Remember that a low barrier to entry is one of the reasons the original HTML-based Web took off so quickly.

Admittedly, the Web service architecture isn't complete, fully implemented, or shrink-wrapped. It's an emerging set of technologies and protocols, and some of the higher-level functions aren't yet sufficiently evolved (see the ebXML work from OASIS at http://www.oasis.com for a peek at some of the innovations in the works). But the functionality is available to put Web services to work for your organization today.

Scott Gerard is a senior software engineer in the iSeries Custom Technology Center at IBM Rochester. He has two decades of experience with Rochester's mid-range with the last decade, working on distributed OO, C++, Java, and Web technologies. You can reach him at sgerard@us.ibm.com.