RE: HTTP binding options

Youenn, how do you feel about having only part of the GED indicated by
/definitions/interface/operation/{input,output}/@message be serialized
in /Envelope/Body/* ?

 

--Jeff

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of FABLET Youenn
Sent: Monday, November 10, 2003 5:37 AM
To: Philippe Le Hegaret
Cc: Sanjiva Weerawarana; Web Services Description
Subject: Re: HTTP binding options

 

I do not remember that there was a "pretty strong sentiment against
doing 5", i.e. URL replacement.
Maybe I do not recall the entire discussion. Anyway, I would also favor
option 5, which seems to be equivalent to today's http binding
functionnality.

Personly, I would even go beyond and ask to generalize the access
mechanism (used by the url replacement) to work not only with the http
binding but also with the soap binding, for instance to directly set
property values with abstract data.

    Youenn

Philippe Le Hegaret wrote:



On Thu, 2003-11-06 at 11:57, Sanjiva Weerawarana wrote:
  

	The "HTTP binding table" at the post-meeting lunch came up
	with the following possible options for the HTTP binding:
	 
	option 1:
	    drop HTTP binding completely
	 
	option 2:
	    define a POST binding only with the natural binding
possible:
	    input becomes POST body and output must be POST response
	 
	option 3:
	    define option 2 +
	    define GET binding for operations with MEP=in-out and with
no
	    input body (i.e., GET goes to http:address <http://address>
URL) and the output
	    must be the GET response
	 
	option 4:
	    define option 3 + 
	    define GET binding for operations with MEP=in-out and
@style=rpc
	    ala the WSDL 1.1 binding, but with rules to move all
parameters 
	    into query parameters. (That is, no URL rewriting ala WSDL
1.1.)
	 
	option 5:
	    define option 4 +
	    add URL replacement to allow different parts to go in the
URL
	    itself vs. as query params
	 
	There was pretty strong sentiment against doing (5). (4) has the
	negative that the value of operation/@style is bleeding into the
	binding - which would be unfortunate. (3) is interesting and can
	be generalized a bit for other MEPs if needed. An interesting
twist
	on (3) could be to allow appending a relative URL to the adresss
	on a per-operation  basis. That's not without price
(inconsistent
	use of xml:base for relative URLs for one).
	 
	My current preference is that we do option (2).
	    

 
I currently favor option 5. SOAP 1.2 includes a SOAP response-only MEP
and we ought to support it reasonably, which not the case of option 1,
2, and 3. It is also a matter of enabling Web applications to take
advantage of Web Services, without requiring a SOAP stack. True enough,
this has to be done with limitations, because of the limitations of HTTP
itself. Option (4) can require to use the RPC style at the interface
level if necessary. Regarding option 5, the idea of not being able to
expose a database of images where each image has its own uri, without
using parameters, is simply absurd. HTTP is out there and we better take
advantage of it. Finally, I would note that enabling option 5 does
affect at all our abstract model. It does affect the way applications
can define interfaces since the RPC style must be required in the case
of HTTP GET.
 
Philippe