Re: Protocol Bindings

Mark,

Some questions/comments on this proposal/write-up follow.

Cheers,

Chris

Mark Nottingham wrote:
> 
> 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.

This part I think is key... e.g. what precisely is the SOAP layer
or more correctly, what are its boundaries. This is what I believe
that Stuart, Marc et al were attempting to describe/define in the AM
and subsequently, in Stuart's comprehensive write-up.

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

Wouldn't a message that has undergone say compression be considered
to have been transformed by the binding, even if the transformation
(in this case compression/decompression) were effectively an
identity transformation?

Secondly, if I correctly understand Henrik's position a binding
MAY actually transform the message by inserting headers which
relate information that is not contained within the message,
but is available to the software that effects the binding.
e.g. the "binding" may actually perform as an actor in the SOAP 
sense. Conversely, a binding may consume header blocks that
are targetted to it, thus effectively transforming the message.

> 
> 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.

I'm not convinced that 'encapsulation' == 'binding'. I believe that they
are very different things. A protocol binding may use an encapsulation mechanism. 
It may be capable of supporting multiple encapsulation mechanisms for
that matter. 

> 
> 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.

Why not? I can think of a lot of very good reasons why carrying this seemingly
redundant information within the SOAP envelope:
	- a SOAP message may need to be considered outside the context
	of the runtime software in which it was sent/received. (e.g. I might
	have a requirement to preserve SOAP messages on disk for such things
	as audit or nonrepudiation) Without the runtime context, the unadorned
	SOAP message is meaningless. Where did it come from? Was the source
	authenticated? What message was this a response to?
	- the transport binding software may be inaccessible to the application
	software which processes the message by virtue of some intervening
	or abstracting API.
	- a message may cross a number of transport protocol boundaries
	between its original source and its ultimate destination. Providing
	a consistent means of sharing (and carrying) this information between
	different protocols could be seen as a good thing, providing for
	increased interoperability.

> 
> * 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.

BEEP and UDP are at different levels of the stack. BEEP and HTTP
would be at the same (or nearly so) level and in that case, the
interchangability is much more obvious and practical, 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.