Web Services Demystified

How Do They Work?

Web service technology has evolved around a stack of five technologies: Network, Transport, Packaging, Description, and Discovery. Each of these technologies sits on top of the ones before it (e.g. without a Network to build on, there could be no Transport).

Fig. 2: The Web services technology stack

Fig. 2 shows this stack of technologies on the left along with the most common choices for each of these layers on the right. Allow me to explain each of these layers from the top down to help you understand how together they make Web services as described in the previous section possible:

• Discovery: For a program to use a Web service, it must first be able to find it. A linked network of servers that provide a global directory of Web services, the Universal Description, Discovery, and Integration (UDDI) project is the current standard means for Web service discovery.
• Description: Before you can create a directory of Web services, there must be a way to describe a single service. The Web Service Description Language (WSDL) is an XML-based language that describes the various functions that a Web service is capable of (its public interface). Once it has a WSDL description of a Web service, a program has everything it needs to make use of it.
• Packaging: Since Web services must permit access from any program written in any language on any operating system, requests (such as "spell check this document") and responses (like "the 3rd word is misspelled") must have a standard format that is platform-independent. The Simple Object Access Protocol (SOAP) is an XML-based language that lets you package up function calls and documents as Web service requests.
• Transport: Once a request is packaged up (for example, as a SOAP message) you need a way to send it to the Web service. In turn, the Web service needs a way to send its response back to you. Web service technology is flexible enough to use almost any protocol -- Microsoft is introducing a number of services over instant messaging, and even email is conceivable as a transport mechanism -- but Hypertext Transport Protocol (HTTP), the protocol used by Web browsers to request and receive Web pages, is by far the most common.
• Network: And finally, to send and receive requests and responses between computers, a network of some kind must be available. In the vast majority of cases, the Internet is that network -- or some other internal network based on TCP/IP (Transmission Control Protocol/Internet Protocol).

So with this structure in mind, let's think about how our spell checking Web service might work. For simplicity's sake, we'll assume the client program has already found a particular Web service to use to perform the spell check.

Fig. 3: A program using a Web service to perform a spell check

The steps (illustrated in Fig. 3) are as follows:

1. The client program bundles up the document to be spell checked into a SOAP message.
2. This SOAP message is sent to the Web service by sending it as the body of an HTTP POST request.
3. The Web service unpacks the SOAP request and converts it into a command that the application can understand. The application checks the spelling of the document, producing a list of mistakes in the document.
4. Next, the Web service packages up that response into another SOAP message, which it sends back to the client program in response to its HTTP request.
5. The client program unpacks the SOAP message to obtain the results of the spell check.

Now this may all sound well and good in theory, but how difficult is it to get working in practice?