- From: David Orchard <dorchard@bea.com>
- Date: Wed, 21 Apr 2004 20:35:57 -0700
- To: "Roberto Chinnici" <Roberto.Chinnici@Sun.COM>
- Cc: <www-ws-desc@w3.org>
Let me see if I understand your objection clearly. To do so, I'll follow Rogerian philosophy and say back to you what I think you are saying. The problem with defining a generic HTTP interface is that it will naturally result in the desire to constrain/extend/refine the contents of the input and output messages. This is because a GET/etc. method will need description of what it accepts as input and output. Attempting to provide this solution (constraining inputs and outputs) will naturally lead to a very difficult sub-typing discussion. Further, it will not be possible to agree on a single "extension" mechanism that refines an open content model to something constrained, ie only 1 level of refinement is allowed. Therefore it is better to avoid defining an HTTP interface and an HTTP binding in WSDL. The solution is that each vocabulary define it's acceptable inputs and outputs for the HTTP verbs it supports, ie atom:get, atom:delete, etc. Further, because in reality each use of an HTTP verb will want to define the input and output, there is very little re-use that can be gained by providing a WSDL interface for HTTP operations. Is that roughly right? Cheers, Dave > >>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 23:37:22 UTC