SOAP Transport Binding Framework
Status
This isan attempt of
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. This version has a
draft of a
new intro and motivation writeup based on the
compromise discussed on the 11/15/01 conference call.
Introduction to the SOAP Binding Framework
(I moved the Intro ahead of the Goals, as this
seems to make more sense)
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 Section1, section
2 describes the behaviour of a single SOAP node with respect
to the processing of an individual message. message.
The sending and receiving of SOAP messages by a SOAP node
is mediated by a binding to an underlying protocol.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 featuresAs 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.
"routing", and "message exchange
patterns". The SOAP Binding Framework provides a mechanismIn
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 howthey
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 message exchange
patternMEPs 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 oftransport message
exchange patternsand 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.
Goals of the Binding Framework
As described above, SOAP messages can be
transported using a variety of “underlying
protocols”. underlying
protocols. SOAP Version 1.2 Part 2: Adjuncts includes the
specification for onea
binding to HTTP. Additional bindings can be created by specifications that
conform to the binding framework introduced in this chapter.
·chapter.
The goals of the binding framework are:
1. are:To set
out the requirements and concepts that are common to all binding specifications
·2.To
facilitate transparent application access to multiplehomogenous
description of bindings that support common features and message
exchange patternsMEPs
·3.To enable SOAP and optional features built on SOAP to take advantage
of the native features and MEPs of the underlying protocols
available to it.
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 on a transportusing
an underlying protocol that directly facilitates the feature (the transportprotocol
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.
[EdNote: Would be
nice to have a longer list]
[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 :-)]
Binding Framework
General Principles of the Binding
Framework
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 thea
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 in section below,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. etc.) Each such feature or MEP must have its own
specification, indicating whatThe
information (state)is required at each node to implement
the MEP or feature.
2. feature, whatThe
processingis required at each node
in order to fulfill the obligations of the MEP or feature.
3.
node, whatThe
informationmust be 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. 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 feature, MEPnode. 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”"on
the wire" representation of the Infoset; compressed,
encrypted, fragemented 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”"SOAPAction"
that is not contained within the envelope infoset.
>>>NOTHING CHANGED BELOW HERE: WE SHOULD PROBABLY CHECK THE MEP AND FEATURE
DESCRIPTIONS FOR CONSISTENCY WITH THE TEXT ABOVE, AND ELIMINATE THE DISCUSSION
OF PROPERTIES (Noah) <<<
MEPs,
Features and Properties
[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.]
Message Exchange Patterns
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.
Features
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
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.
Property Containers
[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.