This is a write-up of a description of the SOAP transport binding framework based on discussions within the XML Protocol WG TBTF and feedback from the Working Group and the <xml-dist-app@w3.org> mailing list. The document has no status whatsoever nor does it necessarily represent consensus within the TBTF or within the XML Protocol WG as a whole.
SOAP provides a simple messaging framework with a core set of functionality which primarily evolves around providing extensibility. The SOAP processing model in Part 1, section 2 describes the behavior of a single SOAP node with respect to the processing of an individual message.
The sending and receiving of SOAP messages by a SOAP node is mediated by a binding to an underlying protocol. A SOAP underlying protocol binding operates between adjacent SOAP nodes along a SOAP message path. There is no requirement that the same underlying protocol is used for all hops along a SOAP message path.
As part of communicating between SOAP nodes it may be necessary to introduce a variety of abstract features generally associated with the exchange of messages in a protocol environment. Although SOAP poses no constraints on the potential scope of such features, typical examples include "reliability", "security", "correlation", and "routing". In addition, the communication may require message exchange patterns (MEPs) beyond the one-way MEP that SOAP provides.
In some cases, underlying protocols are equipped, either directly or through extension, with mechanisms for providing certain features and MEPs, in whole or in part. The SOAP binding framework provides a framework for describing these features and MEPs and how they relate to SOAP nodes.
The definition of a SOAP binding to an underlying protocol declares the features and MEPs provided by a binding and the requirements for building a conformant implementation of that binding. A binding does not provide a separate processing model and does not constitute a SOAP node by itself. Rather a SOAP binding is an integral part of a SOAP node.
Features and MEPs are the modular components from which the contract between SOAP nodes and the bindings they support are formed. A binding specification details how the services of the underlying protocol are used to honor the contract formed by the declaration of features and MEPs supported by the binding being specified.
The combination of the SOAP extensibility model and the SOAP binding framework provides some flexibility in the way that particular features and MEPs can be expressed: They can be expressed entirely within the SOAP envelope (as blocks), outside the envelope (typically in a manner that is specific to the underlying protocol), or as a combination of such expressions.
It is up to the communicating nodes to decide how best to express particular features and MEPs; often when a binding-level implementation for a particular feature is available, utilizing it when appropriate will provide for optimized processing.
As described above, SOAP messages can be transported using a variety of underlying protocols. SOAP Version 1.2 Part 2: Adjuncts includes the specification for a binding to HTTP. Additional bindings can be created by specifications that conform to the binding framework introduced in this chapter. The goals of the binding framework are:
1. To set out the requirements and concepts that are common to all binding specifications
2. To facilitate homogenous description of bindings that support common features and MEPs
3. To enable SOAP and optional features built on SOAP to take advantage of the native features and MEPs of the underlying protocols
Note, that the second and third goals above are related: two or more bindings may offer a given optional feature, such as reliable delivery, with one operating using an underlying protocol that directly facilitates the feature (the protocol is reliable), and the other providing the logic (logging and retransmission) in the binding. The feature can be made available to applications in a consistent manner, regardless of which binding is used.
The creation, transmission, and processing of a SOAP message, possibly through one or more intermediaries, is specified in terms of a distributed state machine. The state consists of information known to a SOAP node at a given point in time, including but not limited to the contents of messages being assembled for transmission or received for processing. The state at each node can be updated either by local processing, or by information received from an adjacent node.
Chapter 2 of this specification describes the processing that is common to all SOAP nodes when receiving a message. The purpose of a binding specification is to augment those core SOAP rules with any additional processing that may be particular to the binding, and to specify the manner in which the underlying protocol is used to transmit information between adjacent nodes in the message path.
Thus, the distributed state machine that manages the transmission of a given SOAP message through its message path is the combination of the core SOAP processing (chapter 2) operating at each node, in conjunction with the binding specifications connecting each pair of nodes.
As described above, SOAP can be augmented with optional features (such as reliable message delivery) and with new Message Exchange Patterns (request/response, multicast, etc.). The specification of each such MEP or feature MUST include the following:
1. The information (state) required at each node to implement the MEP or feature.
2. The processing required at each node in order to fulfill the obligations of the MEP or feature.
3. The information transmitted from node to node, and in the case of MEPs, any requirements to generate additional messages (such as responses to requests in a request/response MEP).
Every binding specification MUST support the transmission and processing of one-way messages as described in this specification. A binding specification MAY state that it supports additional MEPs and/or features, in which case the binding specification MUST provide for maintaining state, performing processing, and transmitting information in a manner consistent with the specification for those MEPs and features.
In cases where multiple features are supported by a binding specification, possibly in conjunction with an MEP, the specifications for those features (and MEP) must provide any information necessary for their successful use in combination; this binding framework does not provide any explicit mechanism for ensuring such compatibility of multiple features and MEPs.
The binding framework provides no fixed means of naming or typing the information comprising the state at a given node. Individual features, MEPs and binding specifications are free to adopt their own conventions for specifying state. Note, however, that consistency across bindings and features is likely to be enhanced in situations where multiple MEP and feature specifications adopt consistent conventions for representing state. For example, multiple features may benefit from a consistent specification for an authentication credential, the transaction ID, etc. The HTTP binding in SOAP Version 1.2 Part 2: Adjuncts illustrates one such convention.
As described in (..reference to chapter on SOAP envelopes…), each SOAP message is modeled as an XML Infoset with root element <SOAPENV;Envelope> (Editors: please fix this). Therefore, the minimum responsibility of a binding in transmitting a message is to specify the means by which the Envelope Infoset is assembled (the binding MAY add header entries to those provided by invoking software or in a relayed message), and to specify the manner in which the transmission of the envelope is effected using the facilities of the underlying protocol. The binding framework does NOT require that every binding use the XML 1.0 serialization as the "on the wire" representation of the Infoset; compressed, encrypted, fragmented representations and so on can be used if appropriate.
Bindings MAY depend on state that is modeled as being outside of the Envelope (e.g. retry counts), and MAY transmit such information to adjacent nodes. For example, some bindings take a message delivery address (typically URI) that is not within the envelope; the HTTP binding in SOAP Version 1.2 Part 2: Adjuncts transmits an HTTP field named "SOAPAction" that is not contained within the envelope infoset.