First, let’s get the announcement out of the way; UDDI v3 was announced earlier this week. Now on to the shot-taking …
If you recall, Paul Prescod used UDDI as a guinea pig when he demonstrated how REST was a superior approach to a SOAP/RPC based solution. He did a wonderful job at describing how the generic HTTP GET was superior to a bunch of get_* methods. But I’m interested in criticizing UDDI not for this reason, but for merely existing.
The whole idea of any kind of any form of centralized registry (except DNS, which gets special consideration for the time-being) is an anathema to Web architecture, which is radically decentralized. If UDDI had followed Paul’s advice, and used URIs to identify the entries in their registry, they would quickly have discovered that anybody could, in effect, become a registry merely by putting these URIs in a web page someplace. Because that’s what’s really going on, on the Web; each web page is a mini registry, which includes references (hyperlinks) to other pages that can describe anything, including all the things that UDDI describes.
The secret sauce behind this profound, but apparently under-appreciated architectural feature, is the joined-at-the-hip relationship between a URI and the HTTP GET method. You can invoke GET on any HTTP URI (well, any URI actually, but that subject is best left for another time), and that knowledge turns a simple “label” (the URI) into a means to navigate between things. UDDI, by not using HTTP URIs (v3 uses URNs), in effect creates a centralization-dependancy for resolving those URI.
I think few people, even many Web services proponents, would disagree that UDDI probably doesn’t have much of a future. Hopefully this little blurb, and Paul’s article, can explain some of the technical reasons for why that might be the case.
Disclaimer; Joel Munter, “Mr. UDDI”, bought me pastries in Paris. I may have been too nice to UDDI as a result. 8-)