W3C home > Mailing lists > Public > www-ws-desc@w3.org > June 2004

RE: Issue 169: Propose http method in the operation interface to simplify http binding.

From: David Orchard <dorchard@bea.com>
Date: Wed, 30 Jun 2004 13:46:32 -0700
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF08A321C9@ussjex01.amer.bea.com>
To: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <paul.downey@bt.com>, "Mark Nottingham" <markn@bea.com>, <alewis@tibco.com>
Cc: <www-ws-desc@w3.org>



> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
> Sent: Wednesday, June 30, 2004 11:33 AM
> To: paul.downey@bt.com; Mark Nottingham; alewis@tibco.com
> Cc: www-ws-desc@w3.org; David Orchard
> Subject: Re: Issue 169: Propose http method in the operation interface
> to simplify http binding.
> 
> 
> I am not at all willing to accept that "webmethod" is an abstract
> protocol independent concept.

There's 2 separate concepts: Constrained or Generic interface (ie REST)
and the actual protocol verbs (GET/PUT/POST/DELETE) on the wire.  The
use of "GET" can apply to many protocols, and even many bindings.

For example, might model an operation as a "GET" and then use the
soap-response MEP by default in the soap binding.

> 
> Can someone explain what that means in SOAP and for RMI/IIOP?

Sure.  In the case of SOAP, as we see in Atom, they can bind a
"GET" operation to either HTTP GET or to SOAP.  In the case of SOAP,
they set the soapaction to "GET".  They can bind a "DELETE" operation 
to: HTTP DELETE, HTTP POST with a DELETE body, or HTTP POST with a 
SOAP body of DELETE.

The concept of "DELETE" maps to SOAP and HTTP.

Now the Java community could come up with a GET/PUT/POST/DELETE RMI/IIOP
class that would be a natural mapping of constrained interface to
RMI/IIOP.  I wouldn't expect the WSDL WG to do that, but maybe 
JAX-RPC xyz.  And MSFT could do the same for .NET remoting.

> 
> I don't at all agree the @style info is in the same category - that's
> not saying *anything* about the semantics of the operation .. just
> a bit of info about the syntax of the data being sent back and
> forth. (In the case of @style="rpc" it means that the schemas
> follow a style which permit extracting a method signature .. when
> augmented with Roberto's clever signature syntax.)
> 

So let's see: We can design our schemas in the abstract to say that the
method is in the body in a certain format, but yet we can't say that the
method is a particular named method?  If you *know* you are sending over HTTP
natively, you probably won't use rpc style because you'd know the method
is in the protocol.  Atom is a good example, they use an rpc style encoding
when they have to bury(tunnel) the method inside the body.

Saying in the interface "the input to GetStockQuote is the GetStockQuote
Schema which follows the RPC style encoding" is *the same* as saying in 
the interface "the input to GetStockQuote is the GetStockQuote Schema which
is a document/literal encoding and the method is GET".  In both cases the
abstract interface defines the method.

Cheers,
Dave
Received on Wednesday, 30 June 2004 16:46:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:31 GMT