Much like web services, the broad definition of the Simple Object Access Protocol (SOAP) means various things to different people. It’s a wire protocol. It’s an RPC mechanism. It’s an interoperability standard. It’s a document exchange protocol. It’s a universal business-to-business communications language. It’s everything you would ever need. It’s not nearly enough.
Actually, it’s all of the above. Perhaps the best way to understand what it is and what it isn’t is to break down the acronym into its parts and analyze where each one fits.
For starters, the “S” in SOAP stands for “simple.” The basic approach of expressing data as XML and transporting it across the Internet using HTTP is simple. In the SOAP protocol, everything that goes across the wire is expressed in terms of HTTP or SMTP headers, MIME encoding, and a special XML grammar for encoding application data and objects.
However, a full understanding of the details and rules of SOAP is not for the faint of heart. For instance, the idea of expressing a SOAP document with attachments using the email and MIME metaphor is simple. Is MIME simple? It is simple only because it uses a data formatting convention that is already in widespread use, is familiar to most IT people, and is conceptually understood by less technical people. Perhaps the “S” should stand for “simpler.”
Is XML simple? It can be as simple or as complex as you want it to be. XML provides a way to add semantic meaning to data shipped over the wire. Through XML-Schema, we have a way of describing a complex document such as a purchase order. But XML-Schema is far from simple. SOAP provides conventions for creating “envelopes” for your data. SOAP has explicit rules for encoding application data—even for such things as arrays of binary data—so it can be expressed in an ASCII human-readable form. It isn’t all that simple, but it is explainable.
We don’t mean to scare anybody off by representing SOAP as overly complex; we will walk you through it and explain it in detail. The good news is that tools and frameworks are already coming to the rescue. In the end, most of us will not worry about how a purchase order gets encoded or how it is sent over the wire. We will all code to a PO object and click on a “Save” button. However, for those of you who consider the best tool of trade to be vi, emacs, or Notepad, we must press on. Even those who like to take advantage of productivity tools and infrastructure need to understand what lies beneath.
Perhaps the “S” should stand for “straightforward.” In SOAP, nothing is hidden intentionally. Every aspect of a SOAP request is intended to be completely self-describing and largely based on a conglomeration of proven, well-established conventions. That’s the real beauty behind SOAP; the platforms and programming languages on both sides of a SOAP conversation are independent of one another, yet they can communicate as long as each side of the conversation can:
Send and receive data transmissions across a network using either HTTP or SMTP[1]
Understand MIME encoding rules and base the means of constructing and deconstructing binary attachments on those rules
Construct and deconstruct XML documents that conform to the enveloping and encoding rules established by SOAP
Perform the required action, if an action is indicated in the SOAP document
Also, simple doesn’t necessarily connotate “weak” or “lame.” SOAP is powerful enough to represent any datatype, object serialization, method invocation, or document exchange.
Simple does mean that SOAP is missing some important things, such as security, reliability, routing, and rules of engagement for interaction among multiple parties. These items, however, will be added eventually. Let’s just conclude that in its infancy, SOAP was “simpler” than its predecessors.
[1] Even this characterization is somewhat of a misnomer, as we will see when we talk about bindings and higher-level protocols built on top of SOAP.