This is an attempt of a write-up of a description of the SOAP transport binding framework 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.
[EdNote: Would be nice to have a longer list]
The SOAP processing model in Part 1 Section 2 describes the behaviour 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.
Different underlying protocols may have different characteristics with respect to the features that it provides. Examples of features include "reliability", "security", "correlation", "routing", and "message exchange patterns". The SOAP Binding Framework provides a mechanism for describing these features and how they they relate to SOAP.
The definition of a SOAP binding to an underlying protocol declares the features 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 message exchange pattern 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 transport message exchange patterns and features supported by the binding being specified.
[EdNote: This is literally the paragraphs from Henrik's version of the Intro... typo's correct and I'm sorely tempted to spell honor, honour which is of course the correct spelling :-)]
[EdNote: Noah suggested that we needed a bit more setup here and that it needed to be more balanced between bottom-up and top-down view. I've had a go... the second paragraph (beginning "For example...") may be too much.]
Underlying/transport protocols have different natural characteristics. The binding framework abstracts these different characteristics into common features and common transport message exchange patterns. Binding specifications can then draw upon the repertoire of available transport message exchange patterns and features as a means to describe the contract between a SOAP Processor and the locally available SOAP transport bindings. In some cases the message exchange patterns and features supported by a given binding will match the natural characteristics of the underlying protocol, in other cases the binding specification will need to introduce additional mechanism to provide the abstractions defined by some combination of features and transport message exchange patterns.
For example, consider the binding of SOAP to a bi-directional connection-oriented byte-stream protocol, such as TCP/IP [RFCxxxx]. Unlike SOAP TCP/IP is not message oriented and unlike HTTP , TCP/IP has no natural transport message exchange pattern. The specification of a binding to TCP/IP would describe a mechanism for framing messages over a byte-stream channel and it would to describe how to make use of the services of TCP/IP to provide the semantics associated with the range of transport message exchange patterns and features supported by that binding specification.
Within the binding framework the interaction between a SOAP processor and underlying/transport protocol binding is modelled as an exchange of properties between the SOAP processor and the binding, illustrated in the following diagram:
[The Disclaimer] This is a non-normative, non-prescriptive model intended soley to support the description and specification of message exchange patterns, features and there interaction, and the operation of bindings. It is *NOT* intended to be prescriptive or even suggestive of a particular approach to implementation. There is NO requirement that implementations follow the pattern of property container described here-in, nor that implementations literally use the property names and value ranges described. The only requirement is that all externally visible behaviour should be as described.
[EdNote: Noah expressed particular concern over the wording of
this disclaimer with respect to the non-normative nature of properties. The
intent here was to indicate that implementations are not required to model their
implementation as some sort of circulation of property containers capable of
carrying arbitrary properties named literally with qnames and whose values are
stored as instances of XML data-types (whatever that would mean!). I think it is
more normative that other specs. that might arise that make use of this
framework, and other artifacts such as meps and features defined using this
framework do make normative reference to these properties - The last sentence
really is targetted at implementation. I guess there is a degree of normative
use of the framework wrt to spec. writers rather than implementors. Maybe
someone else can have a crack at sharpening up the disclaimer.
Also, might want to think about how high up in the document to place a (revised)
disclaimer.]
The binding framework defines the concept of a transport message exchange pattern which characterise the message exchange behaviour supported by the combination of an underlying/transport protocol and its SOAP binding. Part 2 of the SOAP 1.2 specification provides concrete descriptions of the abstract transport message exchange patterns supported by the concrete transport/underlying protocol bindings also defined in Part 2.
The transport message exchange patterns defined in Part 2 are a non-exhaustive set. It is anticipated that additional transport message exchange patterns will be defined either in future revisions of the SOAP specification or in separate specifications to meet the needs of new binding specifications.
Different underlying/transport protocols provide direct support for different combinations of features such as "reliability", "security", "correlation", and "routing".
A goal of this framework is to enable a SOAP node to take advantage of the native features of the underlying protocols available to it.
A feature is modelled by a set of named properties defined in a feature specification. Within the framework model a feature is activated for use with a particular binding by the inclusion of the relevant properties in a property container that represents the current transport message exchange context. In addition the operation of a particular feature may make reference to properties associated with the local environment of the SOAP Node.
[EdNote: Some concerns expressed about the previous paragraph, specifically the words/phrases 'activate' and 'transport message exchange context'. Some feel that this cross the line to feeling too implementation oriented]
A feature specification will normally contain a description of the properties associated with the feature, a description of the abstract operation of the feature in terms of those properties in conjunction with the operation of the transport message exchange patterns for which the feature is defined.
Features are similar to SOAP Modules. By extension over multiple hops, some features may operate on an end-to-end basis in which case the feature definition MUST describe the operation of relaying the semantics of the feature across multiple hops.
A SOAP Node may choose to express the operation of a feature as SOAP blocks which are processed upon reception according to the general SOAP message processing model, or to delegate the provision of a feature on a hop-by-hop basis to an underlying protocol binding.
[EdNote: Features that operate end-to-end by extension of hop-by-hop behaviour. If expressed within the envelope will be targetted at .../next and probably have mU=1. At the recipient they will be processed according to section 2 which in the abstract also amounts to the reconstruction of the relevant properties in the associated message exchange context. If the message is then relayed, there is a local decision to make again as to whether the properties are re-expressed in the envelope for the next hop, or delegated to the binding for the next hop. I think this may be a way of thinking about one of Glen's concerns and also a way of thinking about the extended operation of features across a chain of bindings to different underlying protocols].
Properties are simply named and typed values that support the operation of features. Some properties may represent local state associated with the feature, others may represent values that become manifest in the expression of a feature either as SOAP block within a SOAP Envelope or as fields within the operation of the underlying/transport protocol.
Within this framework model, Properties are named with qnames and property value types are expressed as far as is possible using XML Schema datatypes.
[Ednote: Glen said that he might have a different way of presenting this...]
The Binding Framework model recognises two types of property containers.
Message exchange contexts where the container represents the operation of a particular instance of a message exchange and the properties in the container represent the state of the message exchange including current messages and feature state.
Environment properties that relate to the local configuration rather than to a specific instance of a message exchange.