This is an attempt of providing a simple model for a framework for SOAP bindings. The document has no status whatsoever.
In this section we introduce a binding framework model within which bindings can be named and described. The binding model provides support for creating new bindings from scratch or by nesting existing bindings and allows properties defined by bindings to be reused by other bindings in an open-ended and decentralized manner. Each binding is characterized by three things which we will describe in the following sections.
Identifying a binding is important in order to specify which binding is used in places like WSDL etc. One could assume that the binding always can be deduced based on the URI scheme but in many cases, this is not true. Therefore, this model provides the following naming model:
The name of the binding is a globally unique name in the form of a URI
A binding can define certain properties that describe the services provided by the binding (or the underlying protocol through the binding).
A binding may define a set of properties that exposes the services provided by that binding. Properties may be named using the normal XML namespace conventions so that they can be reused by other bindings. Properties may be reused by other bindings in an open and decentralized manner. If a binding contains nested bindings then properties defined by nested bindings may also be exposed to the SOAP application.
Bindings may be nested with other bindings to leverage already existing semantics and services provided by these bindings. This can be used to effectively produce bindings that exhibit combination of services provided by different layers.
A binding may provide a description of how that binding can be nested with other bindings. Each combination of nested bindings is a binding in its own right and has a name in the form of a URI like any other binding.
Following is an example of how this can play out (The FOO: notation is used to indicate where the properties are defined - think of it as namespace prefixes)
SMTP: a one-way message exchange pattern with certain expectations about reliability etc.
SMTP: message correlation but no particular message exchange pattern
We expect that the SMTP binding will be at the bottom and not nested downwards with any other bindings
ATTACHMENT: an attachment property that allows data to be carried with the SOAP message but outside the SOAP message itself
The SOAP attachment binding can be nested with the SMTP binding in which case we give it a name
Which exposes the following properties:
SMTP: a one-way message exchange pattern with certain expectations about reliability etc.
SMTP: message correlation but no particular message exchange pattern
ATTACHMENT: an attachment property that allows data to be carried with the SOAP message but outside the SOAP message itself
RPC: a request message type and a response message type
RPC: request/response message exchange pattern with certain expectations about timing etc.
RPC: message correlation between a request and a response
The RPC binding can be nested with the SMTP binding as well as the SOAP attachment binding. In the former case we get a nested binding with a name like:
and it has the following properties
SMTP: a one-way message exchange pattern with certain expectations about reliability etc.
SMTP: message correlation but no particular message exchange pattern
RPC: a request message type and a response message type
RPC: request/response message exchange pattern with certain expectations about timing etc.
RPC: message correlation between a request and a response
Because some of the properties overlap (correlation is an example), we will have explain how they interact. In the latter case, we get another nested binding with a name like
and with this set of properties:
SMTP: a one-way message exchange pattern with certain expectations about reliability etc.
SMTP: message correlation but no particular message exchange pattern
ATTACHMENT: an attachment property that allows data to be carried with the SOAP message but outside the SOAP message itself
RPC: a request message type and a response message type
RPC: request/response message exchange pattern with certain expectations about timing etc.
RPC: message correlation between a request and a response