- From: David Orchard <dorchard@bea.com>
- Date: Wed, 30 Jun 2004 13:46:32 -0700
- 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 UTC