RE: FW: draft findings on Unsafe Methods (whenToUseGet-7)

See inline ...

> -----Original Message-----
> From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
> Behalf Of Paul Prescod
> Sent: Monday, April 22, 2002 7:02 PM
> To: Anne Thomas Manes
> Cc: David Orchard; www-ws-arch@w3.org; xml-dist-app@w3.org;
> www-tag@w3.org
> Subject: Re: FW: draft findings on Unsafe Methods (whenToUseGet-7)
>
>
> Anne Thomas Manes wrote:
> >
> >...
> >
> > In reference to Paul comments (see below), it's not true that
> "every bit of
> > information on the Web should have a URI address". There's lots
> of discrete
> > information on any random Web page that doesn't have a unique URI.
>
> If the resource is XML, it is addressable through XPointer. If it is in
> another syntax then there may be (should be) another query fragment
> syntax that can address it.

Not all Web resources are XML. Are you now attempting to specify that the
Web architecture requires that all Web content by available and accessible
as XML?

> > ... It is
> > true that every Web *resource* has a URI. I view a Web service as a Web
> > resource, and hence every Web service should have a URI. (I
> think we've made
> > this association in our Web service definition statement.) If
> you attempt to
> > perform a GET on most Web service URIs, you usually get a WSDL
> description
> > back. Doesn't this qualify as "a clear statement of how to dereference
> > addresses to retrieve information"?
>
> There is nothing in the SOAP specification that requires this
> convention.

Perhaps, but we can certainly establish this convention as the norm or
required. Many SOAP implementations adhere to this convention already. I
don't view this as a requirement of the SOAP spec, but as a requirement of
the Web services architecture.

> And nevertheless it seems to me to be just a rhetorical
> game. I think you know what I mean. In UDDI terms (I know you are
> familiar with UDDI), every UDDI binding, business, relatedBusiness,
> service, tModel, bindingDetail, businessDetail, businessDetailExt,
> serviceDetail and tModelDetail should be URI-addressable in its native
> XML. I've discussed this here:
>
>  * http://www.xml.com/pub/a/2002/02/06/rest.html
>
> Nobody has yet demonstrated to me how the current UDDI API is better.
> The same goes for the new Google API. In fact this goes for every
> deployed SOAP API I've encountered. If SOAP advocates are truly
> interested in getting the best technology adopted then at some point
> they need to discuss this issue.

I've never made the claim that the current UDDI API is better than other
approaches. (I can think of many better mechanisms to perform discovery.)
But at the moment, UDDI/discovery isn't under discussion. We're trying to
work out basic call semantics and perhaps also description semantics. And
I'm also not about to make the claim that SOAP is the best technology. I'm
just saying that it works today, and people are using it today, and the XML
Protocol working group was chartered to develop an XML Protocol based on
SOAP 1.1, and it would behoove us to complete our charter as soon as
possible. As I said, starting a new charter to explore a REST-based service
invocation mechanism would be a really interesting thing. Trying to change
the XML Protocol charter at this late date would be very detremental.

>
> > .... More to the point -- how do I specify a
> > purchase order (which is a pretty common example of a SOAP
> input message) in
> > a URL?
>
> When would you submit a purchase order in a safe, side-effect-free
> operation?

I don't think you get the point. People want to submit a Purchase Order over
the Web, and they aren't overly concerned with whether or not it's done
using a "safe, side-effect-free operation", they just want to submit the PO.
What's the best way to do it? I don't think it's appropriate to do it via
GET. You might be able to do it via PUT, but you aren't trying to publish
the PO, only submit it. POST seems like the safest, side-effect-free
approach.

> >...
> > If W3C follows a path that defines the "Web architecture" as
> being equal to
> > the REST architecture, it will force the W3C working groups to
> abandon use
> > of SOAP over HTTP POST. This will cause an unacceptable delay in the
> > standardization of SOAP. Next we'll find that very few vendors
> will adopt
> > the new standards, and customers will be very happy to use
> products based on
> > SOAP 1.1 and WSDL 1.1. This path will lead W3C into obscurity,
> and WS-I will
> > become the de facto Web services standardization group.
>
> So I guess what you're saying is that any time large software vendors
> agree on a spec before they submit it to the W3C, it is the W3C's job to
> rubber stamp it rather than slow it down.

Please review the charter of the XML Protocol working group. It explicitly
says that the XML Protocol should be based on SOAP 1.1 This isn't a request
to rubber stamp SOAP 1.1. We want and need to improve SOAP, but we don't
want to make a complete change to its architecture. I'm also pointing out
some basic realities. W3C is, at heart, an academic organization. And its
perfectly reasonable for W3C to pursue its academic goals (REST and the
Semantic Web). But if W3C wants to play a major role in business systems,
and if W3C wants to continue receiving funding from the big software
vendors, then the W3C TAG must be willing to accomodate the requirements of
big business. If the REST faction continues to try to undermine the existing
Web services architecture, it will alienate big business.

My suggestion is that W3C explore REST in a separate working group. Just
don't undermine current business objectives (SOAP-based Web services).

Anne

Received on Monday, 22 April 2002 23:16:25 UTC