- From: Anne Thomas Manes <anne@manes.net>
- Date: Tue, 23 Apr 2002 08:36:38 -0400
- To: "Paul Prescod" <paul@prescod.net>, <www-tag@w3.org>
- Cc: <www-ws-arch@w3.org>, <xml-dist-app@w3.org>, <www-tag@w3.org>
Paul Prescod wrote: > > We're getting off into a diversion. Can we agree that every piece of > information available on the Web should be URL addressable or a PART of > a URL-addressable resource? And I don't mean part in a vague sense: I > mean you download a representation and the piece of information is in > there. In many content-types you can also directly link to > "sub-resources" of the resource (e.g. XML, PowerPoint, PDF) > Agreed. In the case of a Web service, if you perform a simple GET on the resource, you receive a service description, which tells you how to (a) how to invoke the service or (b) how to send a message to the service. > > 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.) > > No, I'm not talking about better ways to perform discovery. I'm talking > about better ways to express the *existing API*. i.e. we can improve it > with *no new ideas* just by recasting it in terms of URIs. Same for > Google. Same for any other SOAP API you can mention. If you care about > technology then it should worry you that less flexible and powerful > services are being unleashed on the world just to be "SOAP compliant". I encourage you to explore new ways to perform discovery. I would say that we haven't devised an effective discovery mechanism. Please keep in mind these basic requirements: - there as standard APIs/schemas (service types) being developed for certain types of interactions, and you want to be able to associate individual service implementations that support these standard APIs/schemas and discover service implementations based on their service type. - you want a mechanism to categorize business and services, and to search based on these categories. (think of this requirement as the ability to compose smart bookmarks that I can make available to other users) Right now the most popular form of discovery of Web resources by humans is Google, although Google doesn't particular help you discover Web services (a very specialized form of Web resource). Google (until now) hasn't been particularly available to application (non-human)clients. By building a SOAP API to Google, applications can now invoke Google searches. I would characterize the Google SOAP API as extremely flexible and powerful -- so I'm having trouble following your argument. Are you saying that it could be more flexible and powerful (i.e., support simpler discovery) if Google designed a API based on something else other than SOAP? If you spend a moment looking at the Google WSDL description, you'll realize that the input and output messages are relatively complex. The data are structured and typed, and the formats change based on the function you're performing. From a developer's point of view, it much simpler to deal with these input and output messages as application structures than as URI constructs. I'm not sure that I'm willing to sacrifice developer productivity for a simpler discovery mechanism. I'm willing to explore the concept further as part of a research project on the next generation of Web services -- but I'm not willing to disrupt our current set of technologies. If a WSDL document is by convention available thru GET from every Web service URL, why can search engines use this information for discovery? > Forget REST. Concentrate on Web architecture. One of the principles is > that as many things as reasonably possible should have URIs: > > "The essential process in webizing is to take a system which is designed > as a closed world, and then ask what happens when it is considered as > part of an open world. Practically, this effect on a computer language > is to replace the names/tokens/identifiers for URIs. Thus, where before > reference could only be made to something in the same > document/program/module one can with equal ease make reference to > something in a different one somewhere in that abstract space which is > the Web." Since Web services by definition are identified by a URI, you can easily reference a Web service. Our are you looking for more granularity -- I imagine that you're asking for a mechanism to supply a URI that provides access to a specific method within the service? There are ways to do so. You could provide a reference to a specific QName (referencing an operation within a portType) within the WSDL document. Anne
Received on Tuesday, 23 April 2002 08:35:12 UTC