- From: Anne Thomas Manes <anne@manes.net>
- Date: Mon, 22 Apr 2002 23:17:50 -0400
- To: "Paul Prescod" <paul@prescod.net>
- Cc: "David Orchard" <dorchard@bea.com>, <www-ws-arch@w3.org>, <xml-dist-app@w3.org>, <www-tag@w3.org>
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:26 UTC