Chapter 5: SOAP

Pictures are for entertainment; messages should be delivered by Western Union.

”Samuel Goldwyn

Overview

SOAP is currently a fundamental, prerequisite building block for XML Web services. SOAP is used to send input to and receive output from conventional XML Web services. Thus, it is the underlying communications mechanism for today s Web services. Since a Web service requires input parameters in order to be activated, SOAP is also considered to be what invokes a Web service ”because it delivers the input parameters.

The role and scope of SOAP, however, are not limited to Web services. SOAP is the latest in a long line of distributed computing initiatives, which in this context include CORBA and Microsoft s COM/DCOM, though it is not meant to totally displace either of these powerful, object-oriented methodologies. SOAP sets out to be a simpler alternative that does not provide all the high-end bells and whistles (e.g., automatic garbage collection).

SOAP is totally XML-centric. SOAP is a messaging scheme that works by exchanging XML documents. It is formally characterized as a lightweight communications protocol for exchanging XML-based information between applications in a decentralized, distributed environment like the Web. In the interests of putting a stake in the ground, think of SOAP, to begin with, as an XML datagram.

XML, as should now be abundantly clear, is a mechanism for describing the meaning and context of data ”albeit based on both sides (i.e., creator and subsequent reader or consumer) being privy to some common intelligence (e.g., XML schema or DTD). XML s initial focus, understandably, was all about being flexible and extensible and having the necessary industry- and application-specific vocabularies (or dialects) to facilitate b2b e-business, but the real scope of XML is limited to that of XML documents (i.e., plain text files containing data annotated with XML notation). XML does not deal with how XML documents can be exchanged between interested parties, which is where SOAP comes in.

Let s take a look at an obvious supply chain management (SCM) scenario, that of a supplier wishing to notify some of its customer base programmatically, with new pricing data, to appreciate the rationale for SOAP in the context of XML. With today s expertise in XML and the ready availability of the appropriate industry-specific vocabularies, it would not be difficult to create the necessary price update XML document. The challenge now becomes that of conveying this document to all the intended recipients ”in an automated, program-to-program manner.

Obviously, sending the XML document over HTTP as an e-mail attachment or sending it via FTP to each of the recipients is not adequate. This does not address the fundamental, program-to-program criteria ”nor does it offer XML-oriented, application-level transaction coordination, payload security, or guaranteed delivery. SOAP sets out to address all of these distributed computing- related message delivery requirements. SOAP can sustain any type of XML messaging application need, including those for one-way messaging, multicasting (or broadcasting), request-response interactions, and coordinated, sequential workflow progressions. It also includes the option for a simple but powerful RPC-type mechanism.

With SOAP one can conduct XML-based, program-to-program, request/response-oriented, RPC-like transactions that can be visualized in the form:

• placeOrder()

• getCreditRating()

• findCurrentWeather()

• getStockPrice()

• updatePurchaseOrder()

• obtainShipDate()

One can now see the relationship between XML documents, SOAP, and Web services because each of the procedure calls shown above could be to a Web service that performs that function. Though SOAP is invariably associated with this type of RPC mode operation, it is important to note that this is only one of the messaging modes that can be used with SOAP. In reality, RPC mode representation is an optional SOAP capability.

What SOAP really does when it comes to RPCs is provide a generalized mechanism for representing and encapsulating them within SOAP messages. The SOAP approach is programming language and protocol agnostic . In theory, any of the schemes used by today s programming languages to define and invoke procedures or object-oriented methods can be mapped and represented by a SOAP message ”which would typically be delivered to the remote server via an HTTP POST command.

Let s take, for example, the findCurrentWeather Web service, which when given a zip code returns an XML document that contains the current temperature, anticipated temperature range, current disposition (e.g., cloudy), and so forth. A SOAP-based call to this service, which is hypothetically assumed to be available as a method at www.your-weather.com, would look like:

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

<w:findCurrentWeather xmlns:w=http://www.your-
weather.com/> 
  <w:sZipCode xsi:type=xsd:string>03249</w:sZipCode> 
</w: findCurrentWeather>

POST /Orders HTTP/1.1 
Host: www.megapublisher.com 
Content-Type: application/soap+xml; charset="utf-8" 
Content-Length: nnnn 

<?xml version='1.0' ?> 
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/ 
soap-envelope"> 
 <soap:Header> 
  <o:eOrder 
      xmlns:o=http://www.megapublisher.com/orders 
      soap:encodingStyle=http://megapublisher.com/ 
encoding 
      soap:mustUnderstand="true"> 
  </o:eOrder> 
 </soap:Header> 
 <soap:Body> 
 <m:onlineOrder> 
   soap:encodingStyle=http://www.w3.org/2003/05/soap-
encoding 
     xmlns:m="http:// www.megapublisher.com/orders/"> 
  <m:eOrder xmlns:m="http:// www.megapublisher.com/ 
orders"> 
  <m:retailerCode>UK0216987</m:code> 
  <m:retailerName>TechBooks</m:retailerName> 
  <m:invoiceNumber>MgTec533</m:invoiceNumber> 
  <m:isbnNumber>1-55558-280-X</m:isbnNumber> 
  <m:author>Guruge</m:author> 
  <m:title>Corporate Portals</m:title> 
  <m:quantity>100</m:quantity> 
  <m:shipping>standard</m:shipping> 
 </m:onlineOrder> 
 </soap:Body> 
</soap:Envelope>

Similar products