SOAP Messaging Example

• In the previous section we looked at sending XML-RPC over HTTP to execute specific procedures on our ZwiftBooks server. With SOAP we may still use XML-RPC to trigger specific methods on the server, or we may simply define XML elements that get processed by our SOAP server.


• To understand how SOAP works, let's continue our ZwiftBooks example and look at how SOAP may be used to expand business functionality by opening our server up to collectors who wish to notify ZwiftBooks about books they have for sale. ZwiftBooks will then add the providers and their books to the ZwiftBooks database.


• To make this happen, several things must be done by ZwiftBooks:


• Define a top-level element and related subelements that will trigger processing of the book availability data by the SOAP server.


• Define a schema (DTD or XML Schema) that dictates the form of the XML that will arrive from collectors and book providers.


• Specify a namespace that is unique to ZwiftBooks. This may be the ZwiftBooks Web site or any URI.


• Configure the server to return a fault if the incoming SOAP message is not one of the special elements defined in step 1.


• Figure 4.12 illustrates a SOAP request for the ZwiftBooks guaranteed delivery time for a specific book, specified by ISBN number. Note that the SOAP Envelope element is the top-level element in the body of the SOAP message and within the SOAP body element is found the request for GetGuaranteedDeliveryTime, packaged as an element including the ISBN number.


Figure 4.12. A SOAP request sent to the ZwiftBooks server.




• A SOAP response takes the form illustrated in Figure 4.13. Here the XML response indicating the best delivery time is packaged in a SOAP message that is delivered using the standard HTTP response protocol. As far as HTTP is concerned, it's just data being returned to the client that initiated the request. However, for a client that understands SOAP, the data becomes useful information.

Figure 4.13. A SOAP response to a request to the ZwiftBooks server.





Message Paths

• An important aspect of SOAP is the provision for message paths. Independent of the transport protocol used to send SOAP messages, messages may be routed from server to server along a so-called message path. As we saw in Figure 4.11, message paths support message processing at one or more intermediate nodes in addition to the ultimate destination.

SOAP Intermediaries

• SOAP intermediaries are an essential aspect of building scalable Web-based distributed systems. Intermediaries can act in different roles, including proxies, caches, store-and-forward hops, and gateways. Again, experience with HTTP has shown that intermediaries cannot be implicitly defined but must be provided as an explicit part of the messaging path model. Thus, one of the key motivations of the Working Group is to ensure that an XML protocol supports composability between peers.


• A SOAP-compliant server must be able to act as a SOAP intermediary capable of processing and forwarding a SOAP message on a path from its origin to a final destination. SOAP intermediaries may be explicitly specified by providing their URIs as the value of the SOAP actor attribute within a SOAP header, for example:


• Alternatively, a SOAP message can specify that the header should be processed by the first SOAP application that processes the message, as in this example: