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. MEPs are considered
to be a type of feature; unless otherwise stated, references to the term
"feature" apply also to MEPs.
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 andMEPs and
how they relate to SOAP nodes.
The definition of a SOAP binding to an underlying protocol
declares the featuresand 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.
Featuresand 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 featuresand 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
featuresand 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.
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.
Editors
note: there is still some disagreement as to how best to represent the balance
of responsibility between binding specifications in particular, vs. other
software at the SOAP node, when dealing with features that are represented
entirely within the SOAP envelope. The paragraph above may need some additional
work to clarify.
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.
3.2.To
facilitate homogenous description of bindings that support common features
and MEPsfeatures.
3. To enable SOAP and optional features built on SOAP to take advantage
of the native featuresand MEPs ofthe
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,delivery,
request/response MEPs, multicast MEPs, etc.). The specification of
each suchMEP or feature MUST include the
following:
2.1.The
information (state) required at each node to implement theMEP
or feature.
2. The processing required at each node in order to fulfill the
obligations of theMEP 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 additionalMEPs
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 thoseMEPs
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 multipleMEP
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><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.