W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

RE: Protocol Bindings

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Thu, 5 Jul 2001 12:48:45 +0100
Message-ID: <5E13A1874524D411A876006008CD059F192511@0-mail-1.hpl.hp.com>
To: "'Mark Nottingham'" <mnot@mnot.net>
Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, xml-dist-app@w3.org
Mark,

some comments in line...

Regards

Stuart

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 05 July 2001 15:05
> To: Henrik Frystyk Nielsen; Williams, Stuart; xml-dist-app@w3.org
> Subject: 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, 

Agreed...

> with the following guarantees;
> 
> * messages will be encapsulated completely, so that they are not
> fragmented at the SOAP layer.

Don't know what this means... to me a binding operates underneath the "SOAP
Layer" so I don't see how the message could then become "fragmented at the
SOAP layer."

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

So I think that you're saying that you believe that the operation bindings
and underlying protocols collectively are (or should be) order preserving at
least on a hop-by-hop basis?

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

Ok...

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

I am of the belief that it would be folly for every SOAP/XMLP application to
have to be aware of particular capabilities of the SOAP stack to which it is
bound - some of these choices mak get made at deployment time rather than at
application development time. I believe that SOAP/XMLP needs to provide a
clear and consistent messaging abstraction to the things (application
entities) that use it.

I think that initially SOAP will be bound to a relatively small set of
underlying protocols - and given what SOAP is or aspires to be it may not
make sense to bind it to every protocol under the sun. So... we need a
binding abstraction that is a 'reasonable' pivot point around which we can
partition the definition of the core of SOAP from the definition of bindings
to underlying protocols drawn from the set of protocols to which SOAP might
reasonably be bound.

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

So I'm curious... how much do developers care or want to care about what
SOAP is bound to. I would have imagined that they would like to able to say
this is a SOAP application, rather than this is a SOAP/HTTP application or
this is a SOAP/BEEP application... or this application supports these
flavors of SOAP/xxx. I'd also expect that there might be a separation of
concerns between development and deployment of a SOAP application such that
the configuration of the underlying communication profile be largely a
deployment issue.

Maybe this is just fantasy on my part... I'd be interested to understand
what SOAP application developers would expect.

> * 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 07:48:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:02 GMT