- From: Roberto Chinnici <Roberto.Chinnici@Sun.COM>
- Date: Wed, 21 Apr 2004 18:02:50 -0700
- To: David Orchard <dorchard@bea.com>
- Cc: www-ws-desc@w3.org
David Orchard wrote: > > >>-----Original Message----- >>From: Roberto Chinnici [mailto:Roberto.Chinnici@Sun.COM] >>Sent: Wednesday, April 21, 2004 5:13 PM >>To: David Orchard >>Cc: www-ws-desc@w3.org >>Subject: Re: Issue 64 resolution: HTTP operations as WSDL operation >>names >> >> >>I'm not sure what concrete problem is addressed by this proposal (and >>yes, I've read issue 64). >> >>In what sense is the operation called >>QName("http://example.org/HTTP", >>GET) *the* HTTP GET "operation" (= method, I presume)? Certainly I'm >>free to bind it in a completely HTTP-free way, say to SOAP/SMTP. What >>does it mean in that case? And what if I bound it to an http:operation >>with method="PUT"? Or is the REST:GET operation what people are really >>asking for? > > > The operation is the GET operation in the same way that a spec like Atom describes it. Atom:GET then? Sure we don't prevent Atom from defining one. What's so valuable in defining it in WSDL 2.0? > Users use the operations in their application as the abstract methods. However they bind it is, well, how they bind it. They could bind a "PUT/DELETE" to POST ala Atom, but probably shouldn't bind GET to a PUT. If you want to call it REST:GET, that's fine by me. I had made an earlier suggestion to that effect because of exactly the same concern you raised. I'm glad we are in agreement about having some trouble with the name(s), but I think the bigger issue is whether WSDL 2.0 should provide a constrained interface. On that we agree. By the way, "constrained" interface in what sense? >>And wouldn't the hypothetical user of the wsdl:HTTP interface want to >>restrict the input and output messages? E.g. >> >> <wsdl:interface name="StockQuotes" extends="wsdl:http"> >> <wsdl:operation name="GET"> >> <wsdl:input element="myns:something"/> >> <wsdl:output element="myns:somethingElse"/> >> </wsdl:operation> >> </wsdl:interface> >> >>I see a big, slippery slope on the horizon. > > > A slippery slope to where? To allowing an interface to extend another and restrict (or extend) the messages that are exchanged. Then we get into the subtyping discussion, contravariant input messages, covariant output ones, etc., i.e. the usual "object-oriented languages meet type theory" stuff. >>In this case, I'd >>rather see >>a proposal that deals with the more complete functionality >>than vote it >>in piecemeal over the next several weeks. >> > > > The last time we made a single message with multiple related proposals, a bunch of people objected saying it was too confusing and wanted the proposals all separate. I'm not sure if there's a single container proposal we could make that would be of the right form for the group. I think more digestable chunks showing discrete benefit is a reasonable way to go. Well, this one piece is quite undigestible to me because it doesn't seem to help much in concrete scenarios. Or do you think people will be happy with saying "this is a GET, it accepts anything and return something" without going into more details of what's expected and what's returned? >>Additionally, I'm not too confortable introducing the concept of a >>binding extending another binding. It seems to raise more issues >>than it solves. Moreover, if it's really needed, it should find its >>way in Part 1, shouldn't it? > > > Do you have a counter-proposal for achieving the functionality of re-using a binding, ala an application binding re-using the http binding and just filling in the location? Since it's just a shortcut, I'd be satisfied not providing one. Not ideal, but acceptable. IMHO, that's less confusing to users than introducing a binding extension facility that works with just one binding and lets you override just one attribute. Roberto >>David Orchard wrote: >> >>>Proposal: WSDL 2.0 defines an interface consisting of HTTP >> >>operations, WSDL interface operations can use the HTTP >>operation QNames, a definition of an HTTP binding, and WSDL >>binding operations can use the HTTP binding. >> >>>The discrete items proposed: >>>1. A WSDL 2.0 interface consisting of the HTTP operations. >>>2. WSDL interface operations extends attribute may use the >> >>WSDL 2.0 HTTP interface qname. >> >>>3. HTTP Binding Operations contain an optional location >> >>attribute. If set, this is the default URI for any operation >>bindings done in the binding operations. This attribute is >>in soap 1.2 support proposed resolution. >> >>>4. HTTP Binding Operations contain an optional interface >> >>attribute. This indicates that the referenced interface is >>used in it's entirety. Each operation in the interface is >>bound to HTTP according to the operation qname in the >>referenced interface. The binding is that the local name >>portion of the QName is mapped to the HTTP Method. This is >>very similar to the interface attribute in SOAP 1.2 web >>method support. >> >>>5. HTTP Binding Operations contain an optional extends >> >>attribute references a binding. Typically this will allow >>the binding to define the location of the service. >> >>>This is a logical extension of a description provided by >> >>Jonathan Marsh [1] >> >>>There are 2 WSDL definitions following. The first is the >> >>WSDL definitions for HTTP operations. The 2nd WSDL >>definitions are sample definitions using the proposed >>interface operation and binding operation constructs. >> >>>WSDL definition of HTTP operations >>>======== >>> >>><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:operation name="PUT"> >>> <wsdl:input element="#any"/> >>> <wsdl:output element="#any"/> >>> </wsdl:operation> >>> >>> <wsdl:operation name="DELETE"> >>> <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 method="GET" /> >>> </operation> >>> <operation name="http:POST"> >>> <http:operation method="POST" /> >>> </operation> >>> <operation name="http:PUT"> >>> <http:operation method="PUT" /> >>> </operation> >>> <operation name="http:DELETE"> >>> <http:operation method="DELETE" /> >>> </operation> >>> ... >>> </http:binding> >>> </wsdl:binding> >>></wsdl:definitions> >>> >>>Sample third party WSDL definitions using the wsdl http >> >>operations and binding directly. >> >>>================ >>> >>><!-- An application using HTTP directly should have a very >> >>simple wsdl definitions --> >> >>> <wsdl:definitions >>> xmlns:myns="http://example.org/mystuff" >>> xmlns:wsdl="http://www.w3.org/2004/03/wsdl" >>> >>> <wsdl:import href="wsdl:http"/> >>> >>> <!-- interface is just HTTP --> >>> <wsdl:interface name="StockQuotes" extends="wsdl:http"> >>> </wsdl:interface> >>> >>> <wsdl:binding name="myns:http" extends="http:HTTP"> >>> <!-- the binding provides a location for all the operations >>> <http:binding location="..." interface="myns:StockQuotes"/> >>> </wsdl:binding> >>> >>> <wsdl:binding name="myns:httpAlt"> >>> <!-- the binding provides a location for all the operations >>> <http:binding location="..." interface="myns:StockQuotes"/> >>> <operation name="http:GET"> >>> <http:operation method="GET" /> >>> </operation> >>> <operation name="http:POST"> >>> <http:operation method="POST" /> >>> </operation> >>> <operation name="http:PUT"> >>> <http:operation method="POST" /> >>> </operation> >>> </wsdl:binding> >>> >>> </wsdl:definitions> >>> >>>Cheers, >>>Dave >>>[1] > > http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0003.html > -- Roberto Chinnici Java Web Services Sun Microsystems, Inc. roberto.chinnici@sun.com
Received on Wednesday, 21 April 2004 21:02:46 UTC