[TBTF] Binding Architecture, draft

The following is being posted on behalf of Highland Mary Mountain
(highland.m.mountain@intel.com).
It is a draft of the wording around the diagram sent by Noah Mendelsohn
[1], and represents the
beginning of a description of a Transport Binding Architecture for SOAP 1.2
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0033.html
===============================================================================

The information needed to send a message and the information available when
receiving a message is modeled abstractly as a set of named properties,
some of which may be represented as standard XML infoset entries.


Application - A SOAP node can bind to an underlying protocol for the
purpose of sending or receiving a SOAP message.


Set of Properties - Exchanging information between two or more peers often
involve agreeing on a set of properties that characterize a message
exchange and context in which the exchange is taking place. Examples of
such properties include message exchange pattern used, message role,
quality of service supported, protocol used, means of correlation,
application end point, transport end point, message encoding and
fault/error definition. Each of these properties has associated data
elements which may be defined in several ways:


1) within the underlying protocol


2) within the underlying protocol's extensibility mechanism


3) within the SOAP envelope using the SOAP extensibility mechanism


Note that it is not a requirement for a particular binding to support all
properties. Properties can be left undefined for a given named binding and
the binding specification would not reference that property in any way
shape or form. Some properties are likely to be supported by most bindings
(the core properties concept).


The Set of Properties, referenced above, is intended to indicate the
open-ended set of properties used to describe message exchange in SOAP
based protocols. Of these properties, there are some properties that are
expected to be specified by most bindings. It is strongly recommended that
a binding considers how these core properties may be supported.


Specifications for particular bindings and message exchange patterns can
require additional such properties and can provide additionally for
properties that are optional. This specification does not define any formal
framework for defining new properties.


Placement of property related information is at the discretion of the Named
Binding Author and Named Binding Customer. A Named Binding could include
flexibility as to where property information is placed over the wire for a
given property. One property could be defined as data in the protocol
header and in the SOAP envelope. It would be up to the Binding user to
implement in a way best suited to his or her application.


SOAP Envelope - This could contain Transport Binding related blocks, as
defined in the Named Binding.


Transport, e.g. HTTP - Transport Protocol header content may be derived
from the Named Binding definition.


On the wire representation - The Named Binding can specify information
included in the protocol header and in the SOAP envelop. The sending SOAP
node will be directed by the Named Binding to create the appropriate "on
the wire" representation of this bound message.

(See attached file: bindingstack.pdf)
............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com