RE: SOAP Binding Framework Concerns

> -----Original Message-----
> From: Marwan Sabbouh [mailto:ms@mitre.org]
> Sent: 19 October 2001 18:59
> To: Williams, Stuart
> Cc: 'xml-dist-app@w3.org'
> Subject: 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.

No... I am (or the TBTF is) proposing that a binding does not claim to
support MEPs that it doesn't support.
I (we) are not proposing that every binding support every available MEP or
feature, but that where it does (claim to) support a given MEP or feature
that semantics of that claim be well understood.

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

Where do sender and receiver start? Are messages singular in nature or are
there (temporal) relationships between messages - eg. request and response?
If there are... are those relationships evident in the SOAP message
themselves, are they evident in the operation of the underlying protocol
(and not explicit in the message) or are the evident elsewhere?

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

So... maybe you could explain how to do SOAP over TCP... (perhaps unfair,
because you would probably prefer that the TBTF provided such an
explaination).
SOAP is message oriented, TCP is bytestream; There are perhaps no natural
message exchange patterns for TCP just a bidirectional pipe that is open for
a while and then closed. It seems to me that knowing TCP and the core SOAP
message processing model of Section 2 is not enough for interop. I think
that there is something missing.

> 
> Thanks for the engaging conversation.
> Marwan

Thank you to...

best regards

Stuart

> 
> 
> 
> 
> "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 Monday, 22 October 2001 14:08:09 UTC