Re: HTTP binding options

Glen Daniels wrote:

>Hi Jeff, David:
>
>I'm just going to pop in here and make a quick comment on this.
>
>In general, I feel a little queasy about the idea that you would express a
>GED and then have a WSDL binding chop that element up and put various pieces
>of it in various places (URL parts, headers...).  I thought that one of the
>
Fact is that for some cases, it might be really simpler to do so.
One example would be an image-upload mechanism where you need to give a 
string (an image name) and a binary stream (the image data). In WSDL1.1, 
we would model this message as a two-parts message (a string and a 
binary data). In WSDL2.0, we will model this as one GED, with two 
elements, one for the image name and the other for the image data. In 
most WSDL cases, the message contains only one unbreakable piece of data 
and this is really fine to enforce the "do-not-break-this-xml-data" 
rule. But in the previous example, it seems not to be the case. The 
desire to break this particular GED is that, in the first place, this 
GED is somehow artificial. The "wsdl11:part" element had this benefit 
that it was drawing the line between atomic and splitable data.

Let's use the message example in an upload operation scenario.
There would be two ways to map this upload operation with an http post 
request. One is to serialize the whole GED in the http body, hence do 
some Base64 (en|de)coding, xml (de)serialization and so on. This would 
be SOAP's way.
Another approach is simply to put the image binary stream as the http 
body, and put the name of the image somewhere else, for instance in the 
uri. Compared to the first approach, this solution seems simpler and 
more efficient.
For most cases, the GED is one atomic data and should be unbreakable, 
but for some cases, the GED is just a WSDL artifact and does not really 
match the wire representation and/or the data as viewed by the application.

What do you think?
    Youenn

>reasons we wanted to get rid of message and use schema in the first place
>was to be able to have schema-verifiable descriptions of messages... also,
>this kind of usage reminds me a lot of the soap-encoding trick we used to do
>(well, sure, it's a schema, but it doesn't *really* look like that on the
>wire).  This queasy feeling is the same reason I'm against the
><wsoap:header> idea in the SOAP binding.
>
>I don't think the use case of defining a single service where some uses
>serialize the entire GED in the message, and other uses serialize parts of
>the GED as URL-construction-blocks seems very realistic.  Can someone
>present a use-case for such a thing?
>
>Note that I'm not in any way against parameterizable URLs for REST-type
>services.  I just think there's got to be a better way to do it than ripping
>apart the described message contents.
>
>Thanks,
>--Glen
>
>----- Original Message ----- 
>From: "Jeffrey Schlimmer" <jeffsch@windows.microsoft.com>
>To: "David Orchard" <dorchard@bea.com>; <www-ws-desc@w3.org>
>Sent: Wednesday, November 12, 2003 1:17 PM
>Subject: RE: HTTP binding options
>
>
>
>David, 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
>
>  
>
>>-----Original Message-----
>>From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]
>>    
>>
>On
>  
>
>>Behalf Of David Orchard
>>Sent: Wednesday, November 12, 2003 9:57 AM
>>To: www-ws-desc@w3.org
>>Subject: RE: HTTP binding options
>>
>>
>>I'm strongly in favour of option 5.  I really don't see how we could
>>seriously call this a "Web" service description language if there's no
>>support for describing URLs.  We see a significant number of customers
>>wanting to have better integration between URL parts and message parts
>>    
>>
>in
>  
>
>>WSDL.  Y'all know how much I have argued against certain zealotry so I
>>don't
>>say this from that pov.
>>
>>Dave
>>
>>    
>>
>>>-----Original Message-----
>>>From: www-ws-desc-request@w3.org
>>>      
>>>
>[mailto:www-ws-desc-request@w3.org]On
>  
>
>>>Behalf Of Sanjiva Weerawarana
>>>Sent: Thursday, November 06, 2003 8:57 AM
>>>To: www-ws-desc@w3.org
>>>Subject: HTTP binding options
>>>
>>>
>>>
>>>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 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).
>>>
>>>Sanjiva.
>>>
>>>
>>>      
>>>
>
>
>  
>