This is an attempt of a write-up of a framework for SOAP bindings based on discussions within the XML Protocol WG TBTF. 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 has been designed to be carried within or on top of a variety of other protocols that as a group are called "underlying protocols". The boundary between SOAP and the underlying protocol is called a protocol binding. A binding has two purposes:
The relationship between SOAP, bindings, and underlying protocols is illustrated below. Note that is not a requirement that implementations are layered in this manner. The purpose of this diagram is strictly to illustrate the abstract relationship between SOAP, bindings, and the underlying protocol.
In the diagram above, properties are modeled as name and value spaces, property containers are environment and contexts and the operational model - message exchange patterns are templates for message exchanges. Message exchange context acts as a container for all the contextual info specific to a single message exchange which may involve the exchange of multiple messages according to a pattern.
SOAP has the following two requirements to a binding in order to enable passing of data between SOAP and the underlying protocol:
The interactions between the binding and the underlying protocol can be in any format supported by the underlying protocol. SOAP has nothing to say about this interaction.
Within this framework these interactions are modeled as an exchange of message exchange contexts between SOAP and a binding, however it is outside the scope of this specification to describe how an implementation realizes such interaction.
In addition to defining the format of the data passed between the binding and the underlying protocol, a binding must define the rules for how the data is exchanged using that underlying protocol.
Exchanging information may require additional information from higher layers not expressed directly within the SOAP message. It is outside the scope of this framework to describe how such information is communicated within a SOAP node.
A binding may provide any number of properties that the SOAP layer may
choose to take advantage of if so desired. It is outside the scope of this
specification to describe how these properties are named or how they are
described. However, the default HTTP binding [ref] offers one possible,
non-normative, approach. Properties defined in support of a given feature,
message exchange pattern or binding
are named with XML QNames. Property values are determined by the Schema type
of the property, as defined in the specification which introduces the
property.
SOAP provides a simple messaging framework with a core set of functionality. 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 some cases, underlying protocols are equipped with native mechanisms for providing certain features, in whole or in part (for example, message queuing systems typically provide a degree of reliability).
The SOAP Transport Binding Framework provides some flexibility in the way that particular features can be expressed: Features 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; often when a binding-level implementation for a particular feature is available, utilizing it when appropriate will provide for optimized processing.
[ Ed note : the following text describes a simple example in a bit of detail. There is some feeling within the group that although an example may be a good way to demonstrate the concepts, such text does not perhaps belong in the normative specification, and might be better suited for a primer or tutorial section. There is also some concern that an example dealing with Message Exchange Patterns may not be the right choice. ]
An example might be illustrative:
The "simple request-response" MEP feature, which has been specified by some author, is somehow indicated (in an implementation-specific manner) to be in use for a request. The feature describes a semantic for correlating requests with Faults or responses for particular types of short-lived exchanges. It also describes an optional "canonical" implementation of this semantic using SOAP header blocks to carry information.
We consider two scenarios:
[Note that this example does not address certain issues which would be crucial in real-world versions of features like this one, such as processing order and potential interactions with other features/modules/bindings.]
- The software on the sending node knows that the default HTTP binding is in use. As the specification for this binding indicates that the "simple request-response" MEP feature is supported implicitly by the binding, no further work is necessary to ensure correctly correlating requests and responses.
- The software on the sending node knows that no binding-specific code will handle the "simple request-response" semantics (perhaps a UDP binding is in use). Therefore the canonical header-based implementation is used, and appropriate headers are inserted into the message envelope before sending,
A binding specification SHOULD identify the supported message exchange patterns (MEPs) by reference to their specification and provide a binding specific expression(s) of the identified MEP feature properties either as identified SOAP header blocks or as protocol specific elements or extensions.
A binding specification SHOULD describe the properties it expects to be present in a transport message exchange context when control of that context is passed between the local SOAP Node and a binding instance and vice versa in terms that are clear and unambiguous. At a minimum, the set of defined properties MUST include the XML Infoset of the SOAP envelope being exchanged.
A binding specification SHOULD define binding specific expression of all supported features either as identified SOAP header blocks or as protocol specific elements or extensions.
Note: it is expected that "feature specifications" are defined in terms of an expression of SOAP blocks such that they are binding independent. It then becomes the responsibility of the binding specification to define binding specific or "outside the envelope" expression of any supported feature s.
[ED Note: does this belong in the Features section above?]
A binding specification MUST address any and all security considerations that are known to the author. See [RFC 2119].