Re: HTTP binding options

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
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.
> >
> >

Received on Wednesday, 12 November 2003 13:31:23 UTC