Simple Object Access Protocol (SOAP) describes the packaging, encoding, and exchange of structured, typed data as an XML document. SOAP is sufficiently general yet readily extensible enough to be used for the exchange of just about any structured data. That said, SOAP is most commonly associated with Web Services, serving as the de facto standard message envelope.

SOAP messages consist of two required components: an Envelope, which packages the data; and the Body, which is the data. A third, optional element is the Header (or Headers), which can contain additional descriptions about the message, the data itself, or other processing instructions.

In theory, there can be any number of transport mechanisms, since the upper layers of the stack don’t care how the data is transported. In practice, however, HTTP is currently and will be the dominant transport mechanism for Web Services in the foreseeable future, for several reasons: ubiquity, understandability, firewall-traversal, loose coupling, and it is a real time protocol (as opposed to the store-and-forward nature of email).

SOAP is the Web Services messaging format adopted by Microsoft, Sun, IBM, Oracle, HP, and a host of other companies. The original SOAP 1.1 specification, in fact, came not from a standards body, but was coauthored by representatives of DevelopMentor, IBM, Lotus, Microsoft, and UserLand. Only later was it submitted to the World Wide Web Consortium (W3C).

Current SOAP development is the domain of the W3C XML Protocol Working Group whose membership list reads like a who's who of Web Services players (e.g., BEA Systems, IBM, Microsoft, Sun Microsystems, and Systinet) and a cross-industry collection of interested parties (e.g., AT&T, DaimlerChrysler, Intel, and Fujitsu).

While XML is the universally agreed-upon encoding format for Web Services, it says nothing about the way complex data should be structured within an XML document. Neither does SOAP speak to the semantics of the data it conveys.

What it does provide is a thin, simple, yet extensible wrapper within which to pass messages between peers. Additionally, SOAP specifies some actions and a notion of responsibility for understanding and acting upon messages received by a SOAP processor.

While those involved in the ongoing development of SOAP or building Web Services plumbing are comfortable tinkering with the rather complex XML and associated specifications involved, the majority of developers make use of toolkits to abstract away at least some of the lower-level details.

Any Web Services application or framework worth its salt supports SOAP as a primary messaging format. SOAP toolkits (often more than one) exist for just about every conceivable platform, Web server, and programming language.

Programmers are able to manipulate the XML either directly, using an XML parser and assorted XML tools, or by translating (deserializing) the XML via a SOAP/XML processor into their preferred native data format for manipulation and later translation (serialization) back into XML/SOAP, ready for transport.

SOAP 1.1, the version of SOAP in widespread use today, was published as a W3C Note in May 2000. SOAP 1.2 is currently in working draft form, part of the W3C's XML Protocol Working Group.

The principal advantage of SOAP is that it is the de facto standard. In addition to its broad adoption (rather surprising for such a young technology), the SOAP designers have sought to avoid the problems of interoperability and upgrades seen on the Web by providing mechanisms like the mustUnderstand attribute, which prevents a Web Service message from being processed unless the receiver of the message understands a particular request, command, or piece of data.

The disadvantages of SOAP are almost all directly related to this sort of completeness. Despite the fact that SOAP is meant to be a lightweight protocol, the amount of complexity currently packaged into the SOAP specification makes it difficult for a developer to pick up casually. For SOAP to remain viable as a technology that is easy enough for individuals, small businesses, and organizations to implement (a critical design goal in order to achieve widespread adoption), the specification will have to be kept simple, with feature enhancements made optional. Or, a set of tools that can hide the complexity of SOAP messages will have to be widespread. Or both.

The only credible alternative to SOAP is XML-RPC, a precursor to SOAP designed by Dave Winer of UserLand Software, who also participated in the design of SOAP. Compared with SOAP, XML-RPC is considerably more lightweight and easier to implement, although it is less full-featured, lacks the richness of SOAP’s built-in extensibility mechanisms, and, perhaps most critically, lacks widespread support by large vendors. Nevertheless, the presence of a lightweight alternative for building simple Web Services may have the effect of lowering the barrier to entry for individuals and small groups for whom the SOAP specification is simply too complex. It may allow services to be rapidly prototyped in XML-RPC before being ported to SOAP, and it may keep the SOAP developers focused on keeping SOAP’s core as lightweight as possible.