- 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
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. vs. 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 Sam, Thanks for your considered comments. 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. 2. I feel extremely comfortable with the WSDL group looking at the issue of 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 "safe" 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 in 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 information. What do you think? Cheers, Dave > -----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