Re: Protocol Bindings

On Wed, Jul 11, 2001 at 05:56:03PM -0400, christopher ferris wrote:
> > * 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?

Yes, but that transformation isn't apparent to the message sender or
receiver; the binding takes the responsibility to 'hand off' what was
sent to the receiver in the same form.


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

That's not my reading of his position at all, and would be interested
to see his response.


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

I agree that these are different things. However, from the SOAP
message's point of view, none of this is apparent; there is only
something underneath it that is moving it around (perhaps; 'moving it
around' could be things like IPC or even writing to and reading from
a filesystem). Bindings are only charged with layering SOAP into
another format; not with mapping that format's semantics into the
envelope, IMHO.

OTOH, I think it would be very useful to disambiguate between 'those
bindings that just provide encapsulation' and 'those which provide
encapsulation, and also make services available to the application
using SOAP', for the benefit of developers making choices.


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

Of course. I think the current debate surrounds this question; is the
message (the representation send between the sender and the receiver)
the appropriate place for this context? Do we want to effectively
attempt to reflect the whole world (context, state, protocol
services going down n layers, etc.) in the application-level SOAP
message?

> 	- the transport binding software may be inaccessible to the 
>       application software which processes the message by virtue of
> 	some intervening or abstracting API.

True, but I don't see how this leads to a requirement for mapping
between transport functions and Modules.


> 	- 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 agree that we should enable this with what we do; just not support
it (back to that debate). Supporting it is a significant undertaking.
I don't believe this mapping doesn't need to be standardized by this
group (or indeed standardized at all) for a vendor to provide this
functionality.


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

I disagree. The different semantics of SASL authentication and HTTP
authentication preclude a single 'transport authentication' module,
and authentication is a fairly simple example. IMHO this approach
will evolve to either a) transport-specific modules for every
function provided or b) transport 'package' modules which imply all
of them, gaining no net functionality.

The operational semantics of HTTP are very subtle. While it's
tempting to try to characterize them, I fear that we'll end up
regurgitating substantial parts of RFC2616 and RFC2617 as well as a
considerable body of implementation detail to do so correctly or
usefully.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 12 July 2001 13:15:59 UTC