Re: SOAP Binding Framework Concerns

Hi Stuart;

Thanks for your reply.  In general, I think we disagree on the need of a
contract between SOAP and the underlying protocol.

Stuart wrote:

So there is nothing that SOAP can rely on the underlying protocol to do for
it (no contract)! I think there is and the TBTF is trying to make it modular
in chunks called transport message exchange patterns and features.

SOAP processor relies  on the underlying protocol for the delivery/receipt oif
its messages.  It is unclear to me why we need to specify it for implementors of
SOAP.  A SOAP vendor needs to correctly implements the use of HTTP, TCP, etc for
it to work.

Let us consider the example of the "simple request-response" MEP feature of the
TBTF document.

Scenario 1 concludes that the binding knows that the feature is supported by the
underlying protocol.

I am thinking that it is the application programmers who makes that
determination and binds this service to the correct protocol.  He does that by
writing a correct WSDL.

Scenario2 stipulates that the underlying protocol does not support the MEP in
question.  So you are proposing  that a SOAP processor insert the appropriate
headers to make it possible.

Again, I don't understand why this is the function of  the binding.  Shouldn';t
this be a SOAP module?   And then again shouldn't this contract be between the
sender and receiver?

Stuart wrote:
So explain to me how you would describe the services of a particular
protocol (or a protocol plus a binding). How would you describe its
characteristics?

The services and characteristics of a particular protocol are well documented in
their respective RFCs etc.  The SOAP implementors know them already

Thanks for the engaging conversation.
Marwan




"Williams, Stuart" wrote:

> Marwan,
>
> > -----Original Message-----
> > From: Marwan Sabbouh [mailto:ms@mitre.org]
> > Sent: 19 October 2001 14:03
> > To: xml-dist-app@w3.org
> > Subject: SOAP Binding Framework Concerns
> >
> >
> >
> > David;
> >
> > I thought I run this by you before I forward it to the
> > mailing list. Please comment.
>
> Me thinks you may have targetted xml-dist-app by mistake... but no matter.
>
> >
> > I am very concerned with the work taken place on the binding framework.
> > It seems as if we are creating a layer that sits between the
> > transport/transfer protocol and the SOAP layer.  In my mind, there isn't
> > a physical layer that is called the binding layer.  There isn't a
> > boundary between SOAP and the delivery protocol.
>
> I think that you will find a spectrum of view points here.
>
> > More importantly, there isn;'t "a contract between SOAP and the
> > bindings/underlying protocols that SOAP uses", as described
> > in Stuart's email to Glyn Normington.
>
> So there is nothing that SOAP can rely on the underlying protocol to do for
> it (no contract)! I think there is and the TBTF is trying to make it modular
> in chunks called transport message exchange patterns and features.
>
> > In my mind the contract is between the SOAP sender and
> > receiver.  WSDL is a good example of such a contract.  I
> > invite the TBTF workingb group to examine it.
>
> I am reasonably familiar with WSDL... that describes a contract between
> peers. The contract the TBTF is examining is the contract be SOAP and the
> thing(s) that sit beneath it.
>
> > Instead, a Web service that binds itself to a particular protocol,
> > is then able to receive messages using that protocol.  In this context,
> aSOAP
> > processor uses the delivery mechanism specified by this service.
>
> So explain to me how you would describe the services of a particular
> protocol (or a protocol plus a binding). How would you describe its
> characteristics?
>
> > I am afraid we are making it far more difficult than it needs to be.
> > What am I missing?
> >
> > Marwan
>
> Cheers,
>
> Stuart

Received on Friday, 19 October 2001 14:03:42 UTC