RE: TAG document: SOAP HTTP GET binding available

> -----Original Message-----
> From:
> []On Behalf Of
> Sam Ruby
> Sent: Tuesday, May 07, 2002 2:54 PM
> To:
> Subject: RE: TAG document: SOAP HTTP GET binding available
> David Orchard wrote:
> >
> > 1. It is certainly possible that a web service accessed via
> GET and URI can
> > be exposed as an entry in a wsdl file, and I expect that
> many would.  But it
> > is also certainly possible and probable that web services
> using URI binding
> > or HTTP POST binding without being defined using WSDL.  A
> key point of this
> > proposal is to create an automatable conversion, so that
> SOAP software can
> > reach into URI space.  Given that we want to deal with SOAP
> in URI space,
> > potentially without WSDL, I'm don't see how we could do
> this as a delta on
> > WSDL.
> We seem to have a semantic gap here.  Let me start by
> describing how I use
> various terms, and then perhaps we can bridge this gap.  To
> me, one does
> not bind one wire format to another.  Instead one binds of an abstract
> definition of a service to (possibly multiple) across-the-wire
> representations.

Your approach is one way to do this.  It isn't the only way.  One can bind a
wire format to another, sometimes called transcoding, mapping or
transformation.  WSDL uses the term binding to mean one thing, but there are
many different definitions of binding.  Perhaps I should call it a SOAP HTTP
POST to HTTP GET transcoding specification.  For the purposes of my
discussions with you, I will change my term from binding to transcoding.
When I used the term binding, I did not mean binding in the WSDL sense.

> WSDL can be used to describe web services abstractly in the form of
> portTypes, as well as binding from portTypes to concrete wire formats.
> While there conceptually is a linkage between WSDL and SOAP
> at design time,
> there is *NO* defined linkage from a SOAP datastream to its WSDL
> description at runtime.  This, however, does not prevents a
> an abstract
> definition from being constructed and reasoned about.  In
> opersGuideToWsdl11.html
> I describe how such a description can be provided for a pre-existing
> service.
> Pre-existing bindings are provided in the WSDL 1.1
> specification for SOAP,
> HTTP GET, HTTP POST, and MIME.  Given that these bindings
> already exist - I
> am curious as to what problem you have with these existing
> bindings, and
> how your new proposed binding addresses these problems.

We are still not speaking at the same level.  I fully and completely
understand that there are SOAP, HTTP GET/POST and MIME bindings in WSDL.  I
fully understand it is possible to describe services abstractly and then
bind to a concrete wire format.  Hopefully the clarification above will

The point that my proposal addresses is how to have a re-usable transcoding
between a SOAP HTTP POST binding and a HTTP GET binding, instead of having
each service create it's own transcoding.

A sample usage scenario that I see is that a user creates a web service and
marks it as "safe".  A tool then automatically generates a SOAP HTTP POST
binding and a GET binding in the WSDL.  Their runtime software could be
configured to automatically map the GET invokes into a POST invoke, perhaps
based upon the "safe" attribute in WSDL.  The user only had to create one
implementation (the POST) and the user did not have to define the
transcoding algorithm.


Received on Tuesday, 7 May 2002 18:27:34 UTC