SOAP, based on its XML pedigree, is
SOAP is meant to be used on top of standard transport protocols. The layering of SOAP on top of the transport layer is clearly shown in the Web services stack diagram in Figure 4.14. SOAP can be used across HTTP, TCP, SMTP, FTP, message queuing (e.g., IBM s WebSphere MQ), BEEP, or other RPC mechanisms. However, HTTP is the preferred and most widely used transport scheme for SOAP ”in the context of Web services as well as other scenarios.
HTML over HTTP is what the Web is all about, but with SOAP, you can have XML over HTTP. The SOAP specifications
Given that SOAP is a messaging scheme that has structures known as envelopes and payloads, it has become de rigueur to use a postal analogy to describe SOAP, though the analogy is somewhat limited. Nonetheless it would be remiss not to mention it in passing, given its widespread usage within the industry. SOAP is all about the item that is to be mailed. It describes how the item to be mailed (i.e., the payload) is to be packaged, in a modular manner. That is where the SOAP envelope comes in.
However, SOAP does not
When used on top of HTTP, SOAP messages can typically traverse corporate firewalls and evade standard packet-filtering policies, since HTTP, as the basis for interacting with Web servers, is given carte blanche access. Ironically, one of the motivations for developing SOAP was the fact that when used with HTTP it could indeed be a powerful remote procedure call mechanism that would not be blocked by a corporate firewall. CORBA and the DCOM-based distributed computing approaches needed specific ports to be opened in the firewall for them to get through. Since network administrators are invariably hesitant to
However, this firewall traversal capability is not an overt security exposure, the reason being that getting one or more SOAP messages through a firewall by itself is
Figure 5.1: SOAP s modus operandi. It is transport and network independent and always works application to application, application to Web service, Web service to Web service in sender-receiver mode, where a SOAP node can act as both a sender and a receiver since most SOAP interactions work via some form of
SOAP predates the
Following XML-RPC, Microsoft and DevelopMentor went on to investigate transport-independent, XML-based messaging schemes that could be used for distributed computing. They were striving for a mechanism that was simpler to deploy and use than either DCOM or CORBA ”which were
The 1.1 specification was submitted to W3C on May 8, 2000. Collaborating on SOAP provided IBM and Microsoft with the inspiration and impetus to flesh out the concept of XML Web services that would use this new XML-based messaging scheme as their I/O mechanism. IBM, Microsoft, and Ariba thus went on to create the specifications for WSDL and UDDI, which were made public 6 months after the unveiling of SOAP.
In addition to the four companies that authored it (keeping in mind that Lotus is a division of IBM), the submission of the SOAP 1.1 specification to W3C was further endorsed by other then-big names in the industry, including Ariba, Compaq, H-P, SAP, IONA Technologies, and CommerceOne. Given this wide and influential industry backing, W3C did not subject this specification to the
SOAP 1.1 was not as precise as some would have wished, and there were some interoperability issues between different implementations of the 1.1 specification. This led to the W3C s XML Protocol Working Group initiating work on a SOAP 1.2 specification that attempted to address the nearly 400 technical and editorial issues cited against the original specification. This working
Develop an envelope-oriented encapsulation scheme for XML data so that it could be transferred in an interoperable manner between disparate systems, allowing for future extensibility and evolution in terms of distributed systems ”particularly in terms of possible intermediary nodes that may occur between the transmitter and the receiver where these intermediaries could be in the form of gateways, caches, or application-level proxies.
Ensure, with the cooperation of the IETF, an operating system (and programming language) “independent means for representing the contents of the SOAP envelope when SOAP is used for RCP-related operations.
Define a mechanism based on XML schema data types (e.g., xsd:string, xsd:integer, xsd:decimal, and xsd:Boolean) to represent necessary data (where such a process for representing data so that it can be correctly interpreted at the remote end is referred to as data serialization ).
To define, yet again with the cooperation of the IETF, a nonexclusive transport mechanism that could be layered on top of HTTP.
The SOAP 1.2 specification, sanctioned as an official W3C recommendation, was made available on June 24, 2003. This W3C recommendation status makes SOAP 1.2 a bona fide standard. The 1.2 specification consists of two
SOAP Version 1.2 Part 1: Messaging Framework
SOAP Version 1.2 Part 2: Adjuncts
These two parts, which
The goal of the
Assertions and Test Collection
is to foster interoperability between diverse 1.2 implementations. Given that interoperability was an issue with 1.1, it is easy to appreciate the motivation for this specification-validating suite of tests. This document captures assertions found in the
SOAP Version 1.2 Part 1
specifications and provides a set of tests that
These tests are meant to help SOAP implementors ensure that their creations
However, the successful completion of this test suite does not
In a somewhat related vein, the 1.2 specification also strives to be as unambiguous as possible,
The goal of XML InfoSet is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-
Other than the use of InfoSet, with its emphasis on namespaces, much of the other changes between 1.1 and 1.2 tend to be in the realm of technical refinement ”and are somewhat esoteric. For example, with 1.1 it was possible to have other elements, known as
SOAP, to be as flexible and extensible as possible, advocates a message transfer model in which there can be a chain of SOAP-cognizant nodes between the originator and receiver of a message. Each node in such a chain may process a part of the overall SOAP message. Nodes that perform some level of processing on a SOAP message are known as SOAP endpoints. The processing performed by intermediary endpoints typically
Figure 5.2: Some of the possible SOAP node/endpoint configurations. The terms endpoint and node are essentially interchangeable when it comes to SOAP. The former was popular in the early days of SOAP, though SOAP 1.2 tends to
SOAP 1.2 renames the actor= attribute to a more meaningful role= attribute while keeping its purpose and meaning the same as that for actor= ”discussed further in Section 5.2.1. The other changes in 1.2 are similarly arcane and are
However, there is one subtle but significant change regarding SOAP 1.2 that
SOAP is a message transfer protocol rather than an object access mechanism. There is nothing that relates to object orientation when it comes to SOAP. SOAP does not even assume that any objects exist at the sending or receiving ends, so the object part is inappropriate. Furthermore, exactly how simple SOAP is, particularly as it evolves with 1.2, is also open to debate. In the early days of SOAP, people would claim that a SOAP implementation could be realized in a weekend, given that it was such bare-bones protocol. However, the consensus today is that it really would take a rather long