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 <email@example.com> 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.
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
The combination of the SOAP extensibility model and the
SOAP binding framework provides some flexibility in the way that particular
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
To facilitate homogenous description of bindings that support common
features and MEPs
To enable SOAP and optional features
built on SOAP to take advantage of the native features
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.
1.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
The information (state) required at each node to implement the
The processing required at each node
in order to fulfill the obligations of the
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
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
In cases where multiple features are supported by a binding
, 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 feature
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
As described in (..reference to chapter on SOAP
envelopes…), each SOAP message is modeled as an XML Infoset with root element
(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
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.