What Is SOAP?

The original objective behind the design of SOAP was reflected in its name, Simple Object Access Protocol. (As of the latest version, 1.2, SOAP is no longer considered an acronym but is a word in its own right.) The word simple encapsulates everything SOAP was meant to stand for. A SOAP message was intended to be a well-formed XML document—in other words, pure text. SOAP has outgrown its original name because it is now considered not a protocol but a framework for exchanging messages between a Web client and a Web service.

You can see the difference between a protocol and a framework by considering the HTTP protocol, which revolutionized the exchange of data between browsers and Web servers. HTTP keeps millions of people connected to the Web via browsers, but it doesn’t provide a platform for the free exchange of data. SOAP addresses this problem by leveraging existing protocols to allow SOAP messages to be sent as part of a message in an existing protocol.

The hitches involved in exchanging data between applications over the Web are well documented. For starters, because of HTTP’s omnipresence, many business networks have geared up with a multitude of firewalls, proxies, and other assorted security paraphernalia to exclude anything other than HTTP data.

SOAP solves this problem by sending the SOAP message as part of the HTTP data in a process known as layering SOAP over HTTP. HTTP can send instructions such as “get me this resource,” “get me this resource if it hasn’t expired yet,” “get me this bit of this resource,” “tell me about this resource,” “process this data with this resource,” and so on. All SOAP needs to do is provide a way of using the “process this data with this resource” instruction in HTTP. With other protocols, SOAP uses other message types. For example, over SMTP, SOAP uses the SMTP “send this data to this entity” message.

SOAP data packets, once they’ve reached their destination via SMTP or HTTP or whatever, contain messages that normally say things along the lines of “give me the result of running this procedure with this data as an input,” but they might say something like “process this data and forward the results to this entity.”

SOAP adds a new vocabulary to HTTP, allowing an HTTP message to contain more instructions than it typically could otherwise. The interesting thing is that you can render most common types of SOAP messages (such as “give me the result of running this procedure with this data as an input”) using simple HTTP messages (“process this data with this resource”).

As we’ve mentioned, SOAP can be combined with HTTP or SMTP, but it doesn’t stop there: SOAP can also be combined with File Transfer Protocol (FTP) and Microsoft Message Queuing (MSMQ) technology to send its data, as well as countless other more esoteric formats. However, these latter solutions don’t have as much to do with Web services, so we’ll concentrate on binding SOAP to HTTP.

SOAP’s raison d’etre was far removed from Web services. Tim Ewald, the program manager for XML Web services at Microsoft, said in a conference speech that an original aim of SOAP was “to usher Java or CORBA messages through firewalls to do remote method calls.” So although SOAP mirrors RPCs, it doesn’t always provide all the functionality you might imagine. However, the process of sending XML documents rather than RPCs has proven to dovetail naturally with SOAP’s abilities.

In fact, SOAP is concerned totally with the process of sending messages from the client to the Web service. It assumes that the applications involved will deal with how to interpret any accompanying metadata and how to check the validity of the XML that houses the SOAP message (although this isn’t always true with Web services). Because the route from client to Web service might require the intervention of other applications, it is possible to transfer SOAP between other applications or portals on the route, such as security portals. These points are known as intermediaries, and they are distinguished simply by their ability to receive and forward SOAP messages, possibly acting on information contained in the header of the SOAP message. SOAP is made easily extensible by this process.

To ensure that this message exchange process is standardized across platforms and applications, the W3C consortium is presiding over the standardization of SOAP. Unlike other standards (such as HTML), the most recent draft version of the SOAP standard is intended to be the final revision. In a recent keynote speech, the architect on the Microsoft XML Web services team, Don Box, said he envisaged SOAP 1.2 as the end of the line because the development team is very happy with it.

SOAP and WSDL

SOAP’s links to WSDL are important, too, because a SOAP message means nothing on its own to the Web service that receives it. To make sense of it, the Web service requires a document in WSDL that describes the function of the Web service. The WSDL document describes the parameters the Web service expects—in other words, what data the Web service should receive. The WSDL document also completely describes the contents of the SOAP message. Many of the data type representations come straight from this, and these can be tied into the XML Schema specification. WSDL doesn’t apply only to SOAP—it can also be used with many other protocols. In fact, the WSDL document specifies a binding that details how each operation described in the document can be accessed in a protocol-specific way.

We’ll look at WSDL in the next chapter and describe SOAP’s relationship to it more fully, but bear in mind that SOAP is concerned only with carrying the message to and from the Web service. The content of SOAP messages is an application-level concern, and you’ll see more about how this content is structured in Chapter 6.

Now that we’ve discussed SOAP at a fairly abstract level, let’s look at the elements that comprise a SOAP message.