车东[Blog^2]

An Illustrative Example
UDDI is an example of a web service that could be made much more robust as a resource-centric web service. I'm not discussing the philosophical issues of UDDI's role in the web services world but the very concrete issue of how to get information into and out of it. These arguments will apply to most of the web services in existence, including stock quote services, airplane reservations systems, and so forth.

UDDI has a concept of a businessEntity representing a corporation. Businesses are identified by UUIDs. The Web-centric way to do this would have been to identify them by URIs. The simplest way to do this would be to make a businessEntity an XML document addressable at a URI like"http://www.uddi.org/businessEntity/ibm.com" or perhaps "http://www.uddi.org/getbusinessEntity?ibm.com". The difference between these two is subtle and does not have many technical implications so let's not worry about it.

You can think of "http://www.uddi.org/businessEntity" as a directory with files in it or a web service pulling data from a database. A wonderful feature of the Web is that there is no way to tell which it is just from looking at the URI. That is "loose coupling" in action.

Let's consider the implications of using HTTP-based URIs instead of UUIDs for business entities:

Anybody wanting to inspect that business entity would merely point their browser at that URI and look at the businessEntity record. An HTML version could be served to legacy browsers and the XML version to newer ones.
Anybody wanting to reference the businessEntity (in another web service or a document) could just use the URI.
Anybody wanting to incorporate the referenced information into another XML document could use an XLink, XPointer or XInclude.
Anybody wanting a permanent copy of the record could use a command line tool like "wget" or do a "Save As" from the browser.
Any XSLT stylesheet could fetch the resource dynamically to combine it with others in a transformation.
Access to the businessEntity could be controlled using standard HTTP authentication and access control mechanisms
Metadata could be associated with the businessEntity using RDF
Any client-side application (whether browser-based or not) could fetch the data without special SOAP libraries.
Two business entities could represent their merger by using a standard HTTP redirect from one businessEntity to another.
Editing and analysis tools like Excel, XMetaL, Word and Emacs could import XML from the URI directly using HTTP. They could write back to it using WebDAV.
UUIDs or other forms of location-independent addresses could still be assigned as an extra level of abstraction as demonstrated at purl.org.
The current UDDI API has a method called get_businessDetail. Under an address-centric model, that method would become entirely redundant and could thus be removed from the API. UDDI has several get_ methods that operate on data objects such as tModels and business services. These data objects could all be represented by logical XML documents and the methods could be removed. Note how we have substantially simplified the user's access to UDDI information. At the same time we've elevated the importance of XML and XML modeling in the UUDI system.

Business entities are not the only things in UDDI that should be identified by URI-addressable XML resources rather than SOAP APIs. In fact all of the data in a UDDI database could be represented this way.

Summary: Resources (data objects) are like children. They need to have names if they are to participate in society.