RE: Protocol Bindings

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: 06 July 2001 03:51
> To: Williams, Stuart
> Cc: Henrik Frystyk Nielsen; xml-dist-app@w3.org
> Subject: Re: Protocol Bindings
> 
> 
> 
> > > * 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."
> 
> I think we're saying the same thing... I'm stating that a binding delivers
a
> whole message.

Seems like we are... good.

> What does 'underneath' mean?

Do you really want me to answer that? :-)

> > > * 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?
> 
> My intent was 'internal reordering' - will have to go away and think about
> that interpretation.

Ok... "internal" to what? 

The local end of a binding? 
The binding as a layer? 

Within what context? 
The context of a flow of message between a given pair (set for multicast...
no don't go there) of SOAP endpoints? 
The context of a total ordering of message passing between the local "SOAP
Layer" and the wire?

> > > * 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 don't think we should obstruct SOAP applications from using different
> protocols interchangeably, but enabling them in the Core SOAP protocol
would
> involve abstracting out a taxonomy of the services provided by whatever
> protocols we wish to support (and making sure that it is well-aligned with
> future protocols we may support), and then providing modules for all of
> those services to make them available when run across a protocol that
> doesn't provide them.

I think that there will be clear mis-matches, that while not impossible,
will yield an efficient or effective means transfer SOAP messages - eg. I
can't conceive of what SOAP bound to LDAP or DNS would mean.

> This may eventually happen, and it would be a valuable capability. I just
> don't think this group has the scope in its charter, nor the time, to do
> this.
>
> > > * 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.
> 
> It would be interesting to hear. My intuition (and experience, FWIW) is
> that applications will be designed to take advantage of the most
appropriate
> transport, and specify which binding is in use.

So is SOAP really a protocol or is it yet another packaging/encapsulation
format?

Thanks,

Stuart

Received on Friday, 6 July 2001 06:52:44 UTC