The irony of the Web Services stack is that its core specification—SOAP—is lightweight and devoid of much of the bloat that its adversaries detest. All it describes is an XML envelope and a processing model for transferring messages across a network. It also provides some guidance for SOAP implementers on how underlying transport protocols can be used to transfer SOAP messages.
SOAP doesn’t try to solve larger problems such as security or transactions and it doesn’t try to impose application-level semantics or messaging patterns on SOAP messages. In fact, it’s a whole lot lighter than the HTTP specification in that respect.
Much like the HTTP envelope, the SOAP envelope consists of a placeholder for headers that contain metadata for setting processing context (e.g., security context, routing) for the message. Headers can also be used to convey information specific to a higher-level protocol (e.g., transactions). At runtime, SOAP envelopes are transferred across arbitrary transport protocols, with bindings defined by the various SOAP binding specifications, of which SOAP over HTTP is the only widely accepted binding to date.
SOAP treats all protocols that it binds to as transport protocols, including HTTP, much to the annoyance of the web community. WS-Addressing introduces SOAP headers that, when included in a message, capture binding information. In a sense, SOAP and WS-Addressing together provide the complete transport-independent, ...