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. What does 'underneath' mean?


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


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

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.

Received on Thursday, 5 July 2001 14:51:44 UTC