- 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