Like every other distributed computing platform, the Web services platform has also settled on a standard, well-known protocol for communication between distributed components of a system. For CORBA, the protocol was IIOP; for RMI, first JRMP and later IIOP; in Microsoft environments, DCOM. For Web service architectures, the de facto standard for the basic protocol for communication between two parties is the Simple Object Access Protocol (SOAP). Because SOAP is the basic messaging protocol for Web services, other specifications build on top of the SOAP specification or have "bindings" to it. In this chapter, we discuss the role SOAP plays in Web services and how service nodes process SOAP messages. At the end of the chapter, you will have an understanding of a SOAP message construct and how SOAP can be extended to provide for more complex communication patterns between Web services.

The Case for SOAP

To understand the value of an XML-based protocol for information exchange, we need to understand the doors it has opened. The fundamental shift in distributed computing SOAP has introduced is the ability to communicate effectively between distributed systems that rely on heterogeneous software and hardware stacks. Before SOAP, organizations had two main options to communicate between two geographically or physically distributed points, as ScreenShot shows.

SOAP and the enterprise

The first approach takes the network for granted and concentrates on defining how parties communicate. This involved building wide-area networks and allowing the parties to plug into them. Often, these parties were valued business partners. This was the approach adopted by Electronic Data Interchange (EDI). EDI defined message constructs and how those messages were exchanged but left the network details to the parties involved. This was an acceptable solution for large corporations that had established relationships with their partners, and it was, in fact, quite successful. However, it resulted in collections of networks that were not only expensive but that also locked the parties into using proprietary products and solutions. For example, if Flute Bank decided to communicate with Pipe Bank, both would need to buy expensive software that implemented EDI's data and messaging specification and pay for a wide area network and data transfer. The second approach started with standardizing the communication protocol and involved building distributed computing infrastructures that could run on an open network. This was the route taken by CORBA, RMI, and DCOM. Each developed its own protocol (IIOP, JRMP, and ORPC, respectively) that was positioned on top of TCP/IP and allowed two distributed objects to communicate.

While this approach reduced the need for private networks, the problem still remained: CORBA implementations could communicate with CORBA, RMI with RMI (with RMI-IIOP in J2SE 1.2 RMI and CORBA), and DCOM with DCOM. Though CORBA promoted platform independence by allowing objects to be written in any language, it still required both parties to use underlying object request broker (ORB) software, which usually had to be from the same vendor, because of the fragmentation in vendor implementations when it came to interoperability. It is from this background that SOAP has been developed. SOAP decouples the data format and the underlying protocol, by leveraging a platform-independent language such as XML to describe the data and allowing for the use of well-established protocols such as HTTP to transport that data across the network. Some aspects that contribute to the simplicity of the SOAP protocol come from the fact that SOAP does not need to support features found in its predecessors, IIOP and JRMP, nor does it require the use of any broker software. For example, SOAP does not support distributed garbage collection, nor does it support the RMI/CORBA concept of servant activation. SOAP was initially designed with HTTP in mind. HTTP by itself is very simple, in that a client makes a GET/POST request with some data and gets back a file or error response. It makes no requirements on the data, the way the client processes the data, or the underlying network infrastructure. It requires only the ability to establish a TCP/IP connection between the two endpoints.

Tim Berners-Lee is credited with authoring the first HTTP-HTML implementation and a browser called "WorldWideWeb." He later founded the World Wide Web Consortium (W3C) (source: ).

SOAP is the evolution of a movement to define an XML-based RPC standard on top of HTTP that would leverage this simplicity. Userland Software initiated the process in 1998. In 1999, Microsoft and Develop Mentor joined the effort and soon thereafter jointly published the SOAP 0.9 specification, which was not readily accepted. Only with the publication of the SOAP 1.1 specification and the SOAP with Attachment capability did the industry at large move to accept SOAP as the de facto standard for a Web services communication protocol. SOAP 1.1 with Attachments is covered in this chapter.

As of this writing, SOAP 1.2 became a candidate recommendation by the W3C (). This chapter examines SOAP with respect to version 1.1, but wherever appropriate, the changes proposed in version 1.2 are noted.

By itself, SOAP addresses only the basic needs of how disparate apps in different address spaces communicate. As different industry consortiums continue to define standards for various essential aspects of a distributed system (security, transactions, messaging patterns, etc.), SOAP is capable of extending itself to accommodate such emerging and, in some cases, established standards. ScreenShot shows how different value-added services can be layered on top of SOAP and how SOAP takes advantage of lower layers in the communication stack. SOAP can be extended in two important ways:



Screenshot: The Web services communication stack