Re: Protocol Bindings

Have thinking about what a binding is, and discussing it with Henrik. So
far, this is the definition I'm most comfortable with (with some concepts
stolen from an earlier message by H):

--8<--

A binding provides a means of encapsulating a SOAP message, with the
following guarantees;

* messages will be encapsulated completely, so that they are not
fragmented at the SOAP layer.

* messages will be passed ot the SOAP layer intact, without reordering,
encoding or other transformations imposed by the binding.

Binding definitions must satisfy these requirements.

Some bindings impose restrictions upon the SOAP layer, such as
   - possible message exchange patterns
   - endpoint identification URIs

Binding definitions must describe these restrictions, if present.

Some bindings also provide additional services to the SOAP layer, such as
   - implied message correlation
   - caching
   - authentication, authorization and encryption mechanisms
   - state management
   - routing
   - quality of service

These services are available, but their use is not required, and they may be
supplanted by in-message mechanisms.

Binding definitions should describe these services for use by SOAP
applications.

--8<--

A few things;

* notice that I'm specifically avoiding the phrase 'protocol binding' -- the
term 'protocol' implies some things that aren't necessarily true (for
example, MIME or DIME can be bindings, but don't provide any protocol
semantics, just encapsulation). I propose that we change all references
appropriately.

The variety of mechanisms that will shift SOAP messages around really
precludes one from generically saying that all things underneath are
protocols; it doesn't add any useful information, and misleads about the
nature of SOAP's relationship with what carries it.

* The mechanisms that underlying protocols provide (e.g., HTTP provides a
MEP, implicit correlation, endpoint identification, auth, encryption through
SSL, caching) should not be reflected in the message.

* I am of the belief that it's folly to try to normalise or characterise
transports to support making them transparently interchangeable (switching
BEEP for UDP, for example) or invisible to the message (HTTP messages being
magically composed to form arbitrary application MEPs, for example). While
these are interesting and tempting problems to tackle, they're out of scope
for this WG, and will take years, not months to complete, IMHO.

* That having been said, it's a good thing to incorporate as much
information as practical about what characteristics bindings have into their
definitions, for the benefit of developers who need to be able to choose the
optimal binding. This would be guidance only.

* Such descriptions may find it beneficial to subclass bindings into
'encapsulation' and 'protocol' bindings, to aid in the identification of
their capabilities. It also may be the case that guidance can be given as to
the way that bindings can be usefully combined.

Received on Thursday, 5 July 2001 02:05:54 UTC