W3C home > Mailing lists > Public > www-tag@w3.org > May 2002

RE: TAG document: SOAP HTTP GET binding available

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 8 May 2002 12:13:05 -0400
To: "David Orchard" <dorchard@bea.com>
Cc: "'Sam Ruby'" <rubys@us.ibm.com>, www-tag@w3.org
Message-ID: <OF6572EF0A.B04679C0-ON85256BB3.0059A492@lotus.com>
David:  with respect, I think you're missing the point.  Saying the 
mapping to URI-space can be done in WSDL is another way of saying:  "SOAP 
has never told anyone how to build the URI for SOAP destinations.  One 
obvious way to do it is under the control of WSDL, if that's the 
technology you choose.  You can also do it dynamically in your programming 
system, or you can use a variety of other techniques beyond the scope of 
SOAP itself."

So, the differences in approach are:

A) The goal is to carry the SOAP body in the URI...we should do a mapping.
B) The purpose of the URI is to identify the resource.  As with non-RPC 
SOAP, we don't (in general) model the identity of the resource as being in 
the SOAP body in the first place.  In other words, we bring SOAP RPC on 
the wire closer into line with non-RPC SOAP.  I.e.: identifying the 
resource is done outside the SOAP body.

I think both approaches are coherent, if done carefully.  I do have a 
fairly strong feeling that the purpose of the URI is to identify the 
resource and not to carry other control informatoin such as transaction 
ids (except if my bank account in one transaction is truly a different 
resource than my bank account in another.)  By the way, note that a 
transacted GET is not in general safe.  Transactions typically involve 
serializability, in which case you really do need to go the server, set 
locks, etc., to get the semantics you want.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

"David Orchard" <dorchard@bea.com>
Sent by: www-tag-request@w3.org
05/07/2002 03:20 PM

        To:     <www-tag@w3.org>, "'Sam Ruby'" <rubys@us.ibm.com>
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: TAG document: SOAP HTTP GET binding available


Thanks for your considered comments.

1. It is certainly possible that a web service accessed via GET and URI 
be exposed as an entry in a wsdl file, and I expect that many would.  But 
is also certainly possible and probable that web services using URI 
or HTTP POST binding without being defined using WSDL.  A key point of 
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

2. I feel extremely comfortable with the WSDL group looking at the issue 
defining mechanism for expressing which port-types are "safe".  This would
be very useful for taking advantage of the proposal.  The TAG would be
interested in having a discussion with the WSD working group on this.

3. I agree with you, clearly the URI binding should be only used for 
methods.  In fact, the TAG is in a process of issuing a finding on use of
GET.  This proposal is targetted at SOAP HTTP POST bindings that should be
expressed in URI space.  One interesting approach would be to label things
as "safe" in wsdl space, and then use this proposal for providing access 
URI space.  I purposefully did not include text on using GET for safe
methods because this text will be in the web architecture document, in
production.  Perhaps it should be included even though it is duplicating

What do you think?


> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Sam Ruby
> Sent: Tuesday, May 07, 2002 5:35 AM
> To: www-tag@w3.org
> Subject: Re: TAG document: SOAP HTTP GET binding available
> If you will permit me, I have a few comments on the document.  For the
> moment, I'll limit myself to section 1 and section 1.1.
> Depending on the
> reception of these comments, I may have more.
> Section 1. Introduction
>    If the desire is to bind a web service to HTTP GET, then
> arguably this
>    is a web service binding not a SOAP binding.  In fact, the
> Web Service
>    Description Language already includes a number of bindings
> including
>    HTTP GET & POST Binding defined in section 4
>    <http://www.w3.org/TR/wsdl#_http>.  Section 3 of this
> document describes
>    the SOAP binding, and section 5 describes a MIME binding.
>    Perhaps this input could be reformulated as a delta to the
> existing WSDL
>    document?
> Section 1.1 Requirements
>    "The mapping from SOAP HTTP POST Binding to HTTP GET and
> back shall be
>    automatable.".  This concerns me a bit as HTTP GET is
> supposed to be
>    limited to "safe" operations - see
>    http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1.  In
>    general, this determination is not automatable.  Also, the
> WSDL bindings
>    for the various protocols contain a number of protocol
> specific elements
>    that influence the mapping between the abstract definition
> of the sevice
>    and the formulation of bits that flow across the wire.
> - Sam Ruby
Received on Wednesday, 8 May 2002 12:29:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:51 UTC