SOAP

XML saves the world <?>

No transfer mechanism

SOAP

There are roughly 3 parts to the SOAP specification

(a) the envelope structure

(b) the encoding rules

[15] SOAP Version 1.2 Part 0: Primer, Nilo Mitra, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part0 .

[16] SOAP Version 1.2 Part 1: Messaging Framework, Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part1 .

[17] SOAP Version 1.2 Part 2: Adjuncts, Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part2 .

Envelope
Encoding
Message exchange

Envelope

The soap envelope is a simple XML structure for encapsulating XML-encoded payload data and associated metadata that may affect the processing of payload data.

SOAP makes no assumptions about the flow of messages: in particular, a message may pass directly from sender to receiver, or it may pass via a number of intermediate message handlers. Additional information may be directed to any (or all) of the handlers by means of SOAP envelope header blocks. The intended target (or targets) for a SOAP header is identified by a role identifier in the form of a URI.

The SOAP core specification provides a detailed XML syntax and processing rules for this envelope structure.

This is covered in the SOAP Messaging Framework specification [16].

Encoding

SOAP can be used to transfer any payload formatted as a fragment of XML.

SOAP also defines some rules for encoding fairly arbitrary application data as XML for this purpose. Other encodings may also be used. If an encoding is used, it is identified by an encodingStyle attribute in the SOAP envelope structure, where the attribute value is a URI identifying the particular encoding style.

Where the application data is already presented as XML, no further encoding is required, and the encodingStyle attribute is omitted. This is sometimes called "document messaging" and is the preferred implementation style for some SOAP-based product developers.

Encoding is covered in the SOAP Adjuncts specification [17].

[17] SOAP Version 1.2 Part 2: Adjuncts, Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part2 .

Message exchange

SOAP specifies two frameworks for defining message exchange

message exchange patterns, which provides the basis for describing alternative styles of transaction (request/response, asynchronous send, etc.)
protocol bindings, providing a basis for conveying specified SOAP message exchange patterns with a given underlying transfer protocol.

These are covered in the SOAP Adjuncts specification [17].

[17] SOAP Version 1.2 Part 2: Adjuncts, Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau, Henrik Frystyk Nielsen, W3C Working Draft 26 June 2002, http://www.w3.org/TR/soap12-part2 .

Exchange Patterns
Message exchange patterns provides the basis for describing alternatives like request/response (e.g. RPC), fire-and-forget (e.g. notification), etc. Two specific patterns are defined by the SOAP 1.2 specification:
- request/response, and
- response-only (the specification uses a different term).
The former corresponds to an HTTP request, with SOAP used to encapsulate the request and the response bodies.

The latter corresponds to a simple HTTP GET operation, the response to which is a SOAP envelope; this allows certain kinds of simple information retrieval performed using SOAP to mesh cleanly with certain Web architectural ideas. Effectively, the request is encoded entirely in a request-URI.
Protocol Bindings
The SOAP 1.2 material on protocol binding I found to be rather confusing, though one can see the general idea OK. The intent is that SOAP can be bound to any underlying transfer protocol; the binding needs to indicate what message exchange patterns are supported and how they map to underlying protocol operations. I guess the idea is to select a protocol that matches the applications underlying patterns of operation. But in practice, I think most implementations have focused on using HTTP as their substrate. Specifications have been drawn up for SOAP-over-BEEP and (I believe) SOAP-over-SMTP, but these are not part of the SOAP WG effort (I believe the HTTP binding *is* part of that effort).

Which I think takes us into the HTTP-substrate issue, for which we already have an RFC.

Maybe there's a case for promoting SOAP-over-BEEP? Because BEEP is pretty much agnostic w.r.t. supported message exchange patterns, and avoids the problems of HTTP-as-the-universal-transport-protocol (or "you can use any port you want, sir, as long as it's 80").