Paul Prescod wrote:

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 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?

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