Re: SOAP Binding Framework Concerns

You wrote:

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.

Answer:

 I will answer the question of how to do request-reply RPC using a protocol
other than HTTP.

One way of doing it is to construct  a protocol stack using TCP/SunRPC Record
Marking/ONC RPC.  then I provide an ONC RPC binding ( which is a module-See the
stack below which is my best guess). Record Marking is necessary since ONC RPC
requires a boundaried protocol.  I am claiming that the specification of the ONC
RPC module, the specification of the Record Marking binding ( This is dependent
on the sematics of RM and may not be needed), and the specification  of the
abstract message type can be done in the WSDL file and not in the SOAP
specification.  So section 2 by itself is not enough.   This way, 2 SOAP
processors who share Contract 2, can still interoperate.  That is contract 2
determines the on-the wire representation. Note that both vendors must use the
same RM bindings.

The stack might look someyhing like this:


+-------------------+                     +-------------------+
| Application  |<--contract1-->|  Application |
+-------------------+                     +-------------------+

+-------------------+                       +-------------------+
|     ONC RPC   |<-- contract3-->|    ONC RPC      |
+-------------------+                       +-------------------+
       ^                                             ^
           | contract2              contract2 |
          v                                             v
+-------------------+                       +-------------------+
|     SOAP      |<-- contract3-->|    SOAP      |
+-------------------+                       +-------------------+
          ^                                             ^
           | contract4              contract4 |
          v                                             v

+-------------------+                      +-------------------+
Record Marking |<-- contract5-->|  Transport   |
+-------------------+                      +-------------------+
+-------------------+                      +-------------------+
TCP |                                                    TCP
+-------------------+                      +-------------------+


reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/wsdl.asp

Marwan

"Williams, Stuart" wrote:

> > -----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 19:21:56 UTC