Download (direct link):
SOAP used to stand for "Simple Object Access Protocol," but with the release of SOAP 1.2, its acronym status is now revoked. After the original specification was developed by Microsoft and DevelopMentor in SOAP 1.0, IBM and Lotus contributed to the specification for SOAP 1.1. Some believed that it would later be renamed "the XML Protocol" Others thought it should stand for "Service-Oriented Architecture Protocol" But instead, because developers associated the term "SOAP" with Web services, they kept the name and just dropped the acronym. This is a good decision because SOAP has nothing to do with object-oriented programming. You can very nicely create a C or Pascal SOAP-based Web service.
SOAP has been adopted as the standard for Web services, and applications from major vendors have developed SOAP APIs for their products, thus making software systems integration easier. The syntax of SOAP, in its basic form, is fairly simple, as shown in Figure 4.4. A SOAP message contains the following elements:
■■ A SOAP envelope that wraps the message ■■ A description of how data is encoded
■■ A SOAP body that contains the application-specific message that the backend application will understand
Application-Specific Message Data
Figure 4.4 Structure of a Web-based SOAP message.
Understanding Web Services
Let's look at an example of a simple SOAP message, taken from the first example in the SOAP 1.1 specification. The listing that follows shows a simple SOAP message for getting the last trade price of the "DIS" ticker symbol. The SOAP envelope wraps everything in the message. On line 3, an attribute of the SOAP envelope, encodingStyle, shows how the message is encoded, so that the Web service can read it. Finally, lines 4 to 7 are the SOAP body of the message that wraps the application-specific information (the call to GetLast-TradePrice in the SOAP body). A Web service receives this information, processes the request in the SOAP body, and can return a SOAP response.
The SOAP response for our example stock price request is shown in the listing that follows. Just like the request, the message is syntactically the same: It consists of an envelope that wraps the message, it describes its encoding style in line 3, and it wraps the content of the message in the SOAP body in lines 4 to 9. The message inside the body is different. On lines 5 to 7, we see that the message is wrapped in the GetLastTradePriceResponse tag, with the result price shown in line 6.
<m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>34.5</Price>
SOAP messages may look simple, but they can get complicated. Luckily, your developers don't necessarily have to understand the details of SOAP. Many tools, such as those that come with Microsoft's .NET and the Java tools for Sun's JAX-RPC, create the SOAP handlers automatically. The developer simply creates objects with methods to be invoked and transforms the object into a Web service with his or her vendor's toolkit.
Now that you've seen what a SOAP request and response look like, you may be thinking, "How will my applications know the application-specific details for talking to a Web service?" In our example, it is easy to see that the common
language is SOAP, but how would your application know how to call Get-LastTradePrice, or be able to understand the result GetLastTradePriceRe-sponse? The answer lies in the next section—describing Web services.
How to Describe Basic Web Services
Whereas SOAP is the communication language of Web services, Web Service Definition Language (WSDL) is the way we describe the communication details and the application-specific messages that can be sent in SOAP. WSDL, like SOAP, is an XML grammar. The W3C defines WSDL as "an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information." To know how to send messages to a particular Web service, an application can look at the WSDL and dynamically construct SOAP messages.
WSDL describes the operational information—where the service is located, what the service does, and how to talk to (or invoke) the service. It can be thought of as an XML form of CORBA's Interface Definition Language (IDL). The format of WSDL can look pretty scary, but it isn't really intended to be human-readable.
Developers and integrators do not have to understand WSDL and SOAP to create Web services. When you create a Web service from your enterprise applications, most toolkits create WSDL for you. Figure 4.5 shows an example of how this process works.