RE: Issue 64, @method

Jonathan,

Are you suggesting that WSDL WG would define that interface?  I think BEA is interested in WSDL providing a standardized interface definition of the HTTP operations.  

I think we are seeing 2 interesting market forces:
1) Customers are interested in deploying apps that have some interfaces that use HTTP as a transfer protocol.  They want to be able to use WSDL to describe both the HTTP as transport and HTTP as transfer styles.  
2) We've seen some interesting and obvious Web services protocols make use of HTTP directly.  A good example is Atom [1] which uses HTTP as the application protocol.  They have a binding of these verbs to SOAP.  In this particular case, a WSDL 2.0 definition of the HTTP interface would be usable by Atom.  

I do realize that Atom could model HTTP as an Atom interface.  However, creating the web service definition for the HTTP interface seems somewhat orthogonal  to what Atom is interested in doing, which is describing the message contents under the constrained interface.  I also think that they are doing some interesting work on mapping the HTTP interface exchanging SOAP content onto HTTP as a transport (ie via POST). [2]

I think that an application may have either a custom interface or the HTTP interface and there is a binding to the underlying protocols interface, the table of relationships is roughly:

1. App protocol (custom) + HTTP as Transport = POST
2. App protocol (custom) + HTTP as Transfer = various HTTP methods
3. App protocol (HTTP) + HTTP as Transfer = direct mapping to HTTP.  Seems like this could be really straight forward to describe in WSDL.
4. App protocol (HTTP) + Some other protocol like IIOP as transport = custom binding to protocol.

I'd like to state that I think that an important reason for doing this is to enable applications to mix and match their application style to the protocol style with the fidelity they want.

Right now, WSDL optimizes for case #1, and we'll need to allow for case #2 given the SOAP web method feature.  I think I've argued earlier in this message that cases 3 and 4 are also quite interesting.   I don't think they will take much time to model either.  There might even be some re-use for case #2.  

FWIW, I would rather actually describe the HTTP interface as a REST or constrained interface because HTTP is simply one realization of a RESTful interaction.  There are many potential applications that may want a constrained interface for doing state transfer that don't always (and maybe even never) use HTTP.  It seems a bit wierd to talk about "the HTTP operation" when it might get bound to IIOP.  But there seems to be a rather strong (cough) reaction to any proposal that has "REST" in it.  I figure that talking about a real world scenario of using HTTP as the interface illustrates the point better than talking about "what-ifs".

Cheers,
Dave

[1] http://bitworking.org/projects/atom/draft-gregorio-09.html
[2] http://www.intertwingly.net/wiki/pie/PacePutDelete


> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Jonathan Marsh
> Sent: Monday, April 05, 2004 2:30 PM
> To: Mark Baker
> Cc: WS Description List
> Subject: RE: Issue 64, @method
> 
> 
> 
> The context of those comments (IIRC) was why we need something
> special-purpose to enable description of HTTP.  The normal 
> way you would
> describe an operation in WSDL is using the <wsdl:operation> element.
> What's wrong with just using this to describe HTTP?  One could derive
> their own interfaces from it to constrain the structure of messages...
> 
> <wsdl:definitions 
>     targetNamespace="http://example.org/HTTP" 
>     xmlns:http="http://example.org/HTTP" 
>     xmlns:wsdl="http://www.w3.org/2004/03/wsdl" 
>     
>     <wsdl:interface name="HTTP">
>         <wsdl:operation name="GET">
>             <wsdl:input element="#any"/>
>             <wsdl:output element="#any"/>
>         </wsdl:operation>
>                 
>         <wsdl:operation name="POST">
>             <wsdl:input element="#any"/>
>             <wsdl:output element="#any"/>
>         </wsdl:operation>
>     </wsdl:interface>
> 
>     ...
> 
>     <wsdl:binding name="http:HTTP">
>       <http:binding>
>         <operation name="http:GET">
>           <http:operation location="..." method="GET" />
>         </operation>
>         <operation name="http:POST">
>           <http:operation location="..." method="POST" />
>         </operation>
>         ...
>       </http:binding>
>     </wsdl:binding>
> 
> </wsdl:definitions>
> 
> > -----Original Message-----
> > From: Mark Baker [mailto:mbaker@markbaker.ca] On Behalf Of 
> Mark Baker
> > Sent: Saturday, April 03, 2004 9:10 PM
> > To: Jonathan Marsh
> > Cc: WS Description List
> > Subject: Issue 64, @method
> > 
> > On Thu, Apr 01, 2004 at 04:29:23PM -0800, Jonathan Marsh wrote:
> > > Marsh:   issue is can one get away without operation names when
> > >          using HTTP.
> > > Sanjiva: drop issue
> > > DaveO:   is he just proposing that the HTTP operations be 
> described
> > >          as wsdl operations?
> > > ACTION:  Marsh to contact Mark Baker and see if @method satisfies
> > >          him.
> > 
> > While @method and the whole HTTP binding are welcome 
> progress, I don't
> > believe they address issue 64.  But yours and DaveO's comment there
> hit
> > the nail on the head, IMO.  I think there's some useful ideas in my
> > earlier proposal, which was to do exactly what DaveO is suggesting
> (and
> > not just for HTTP, but for all application protocols).
> > 
> > Perhaps you guys could give it a re-read-over and let me know if you
> > think any of the options described there are do-able, or alternately
> > if you have some other ideas for how it might be done ...
> > 
> > http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0103.html
> > 
> > Mark.
> > --
> > Mark Baker.   Ottawa, Ontario, CANADA.        
http://www.markbaker.ca

Received on Monday, 5 April 2004 19:04:51 UTC