Chapter 5: SOAP

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

”Samuel Goldwyn


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, would look like:

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

The response to this call will be returned in another SOAP message. At this juncture it is best to actually look at the overall structure of a representative but relatively simple, SOAP-based transaction. To this end let s consider a hypothetical online book ordering scenario between a book retailer and a publisher realized via an eOrder SOAP request.

The SOAP request sent from the book retailer to the publisher will contain retailer identification, PO details, and information about the book. To achieve this, the customer sends the following orderItem SOAP request to the supplier, which includes pertinent information such as the customer identification (i.e., RetailID), the item number, item name , item description, quantity ordered, wholesale price, and so forth ”in this case using HTTP as the transport mechanism:

 POST /Orders HTTP/1.1  Host:  Content-Type: application/soap+xml; charset="utf-8"  Content-Length: nnnn  <?xml version='1.0' ?>  <soap:Envelope xmlns:soap="  soap-envelope">   <soap:Header>    <o:eOrder        xmlns:o=        soap:encodingStyle=  encoding        soap:mustUnderstand="true">    </o:eOrder>   </soap:Header>   <soap:Body>   <m:onlineOrder>     soap:encodingStyle= encoding       xmlns:m="http://">    <m:eOrder xmlns:m="http://  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> 

This SOAP request, delivered to the book publisher (i.e., via HTTP, will result in the eOrder method to be invoked at SOAP itself does not specify or care how this method was implemented. It also does not get involved in how this request is processed . Its express goal is to deliver the request, in the form of an invocation, to the intended remote method ”along with the enclosed input data. The receiver, in this case the HTTP server at, could use a standard CGI script, invoke a Java servlet or .NET process to process this order, and return an appropriate acknowledgment (e.g., order confirmation number and an estimated delivery date).

Even a cursory examination of this SOAP example will indicate that it consists of four distinct parts . The first four lines, starting with POST, talk about HTTP, identify the (remote) host, and specify a content type for this message. These four SOAP transport-related lines are known as the SOAP binding ”in this instance, the SOAP-HTTP binding, given that the transport is HTTP. Within this, the first two lines, which are HTTP specific, are understandably known as the HTTP request. Straight after the XML declaration, which comes next , you can find the start of a SOAP envelope. This envelope, which in essence subsumes the entire SOAP message, is in turn made up of two parts: the SOAP header and the SOAP body. All SOAP messages will conform to this overall structure, as will be discussed later in this chapter.

In addition, the abundance of colons in the previous example, since each element name is prefixed, as well as the four occurrences of the keyword xmlns, should indicate that XML namespaces are an integral concept within SOAP. XML namespaces, as discussed in Section 2.3.4, are the standard XML mechanism to ensure that the meaning and intent of XML elements relative to a given XML document are not mistaken or misinterpreted. The prefixed element names , relative to a specific XML namespace, ensure the uniqueness of XML elements within a particular context.

This explains the significance of XML namespaces vis--vis SOAP. Since SOAP is a messaging scheme, the underlying implication is that the XML document transported by using SOAP will be read and interpreted at a site different from where the original XML document was originally conceived. Also, a recipient could receive XML documents from different sources that contain the same elements ”but each with a slightly different nuance. The use of XML namespaces eliminates such ambiguity and makes sure that a recipient of an XML document has the means to unequivocally validate the intent of the elements contained in that document.

This preamble as to what SOAP is about can be concluded with the following summary of the salient SOAP attributes.

  • SOAP is an XML-based messaging scheme.

  • SOAP works between applications.

  • SOAP can be readily used between disparate platforms.

  • SOAP supports the encapsulation and remote delivery of RPCs.

  • SOAP is programming language agnostic.

  • SOAP enables XML to be communicated over HTTP.

  • SOAP, however, is not restricted to HTTP.

  • SOAP relies heavily on XML namespaces.

  • SOAP is used by Web services for their I/O operations.

  • SOAP is also considered to be what remotely invokes Web services.

Web Services[c] Theory and Practice
Web Services[c] Theory and Practice
ISBN: 1555582826
Year: 2006
Pages: 113 © 2008-2017.
If you may any questions please contact us: