UDDI, the specification from hell
Hi, Uche!

I was there nearly at the birth of UDDI, when it was announced as a new concept out of a "consortium" that consisted primarily of Microsoft. I thought the idea was lame at the time, that it was, as you said, a ridiculously complex (and heavily jargoned) way, of creating a resource directory, and that it was anticipating a market which I figured would not really exist for at least five years - the world of publicly exposed web services. It's 2005, the number of useful UDDI declared services still number in the low double digits, and the number of active UDDI servers numbers in the single digits. I've often suspected the real role of UDDI was to provide a web services-based excuse to better sell the concept of Active Directory, which outside of Microsoft windows administration itself has had remarkably few success stories.

Given that, I too am rather astonished that UDDI has reached a 3.0 point. I've had occasional call to use WSDL, though I'm always leary of binding heavily to WSDL enabled services, but I think the only UDDI repositories I've encountered have been "graveyards", whole tracts of dead services no longer offered because Timmy decided there were better uses of his cable internet connection than providing yet another lame service.

-- Kurt Cagle

Agree
I totally agree. Haven't these people ever heard of LDAP?

Comments on Article - Luc Clement, Systinet, Co-chair OASIS UDDI TC
I think that some still may be unwittingly equating UDDI (the spec) with the UDDI Business Registry (an implementation and deployed a UDDI registry).

UDDI (the spec) represents today the standard (UDDI v2 is an OASIS Standard and v3 will be by the end of Jan 05) for implementing the business services registries that enterprises are deploying today to meet their needs for governance and lifecycle management through the abilities that this standards provides them: visibility, reusability, adaptability and manageability of an enterprise's SOA and its artifacts. Now in its 3rd revision, UDDI has broad vendor support and proven interoperability - see http://www.oasis-open.org/news/oasis_news_11_17_04.php.

The fact that UDDI is the Web services registry standard has also not gone unnoticed by the user, vendor and standards communities. There are a number of specs that are now or in the process of leveraging UDDI: 1) Policy - WS-PolicyAttachment - mapping of WS-policy onto UDDI, 2) Orchestration - BPEL - publication and discovery of BPEL4WS abstract processes, 3) Remote Portlets - WSRP - publication and discovery of WSRP Producer and Portlet services, 4) Management - WSDM - publication and discovery of metrics and manageability provider information. Please also note that the UDDI TC has also mapped ebXML components onto UDDI for the publication and discovery of ebXML components.

Luc Clement
Senior Program Manager, Systinet
Co-Chair OASIS UDDI Technical Committee

Agree - surely you're kidding
LDAP – surely you’re kidding. Using directory as an application platform is not a winning proposition. First came DEN (Directory Enabled Computing) - it failed. Cisco (others and Microsoft to some extent) where pushing the idea of directory-enable-everything thing. Microsoft took the bite (though they never really “got it”) and invented Active Directory Service Publication which is a means of publishing services in Active Directory from where one can discover presence of “services”. MS SQL and other MS product components used it as a means of registering product components and endpoints. It never went much further than this - I explain why below.

Other mechanisms such as JNDI (which is perfectly good technology) also came to be though it fails at being inclusive. WS-Discovery (nothing more than UPnP re-factored for Web services) is being proposed and implemented by the device-focused community. Then, there is ebXML Reg/Rep. I could go on and on with “discovery” mechanisms as well as you could.

The bottom line is that these discovery mechanisms are purpose-specific; so is UDDI for that matter, however it is designed and optimized specifically to be "the" Web services registry. The only one that is trying to contend (as far as I’m concerned in order to expand its reach) is directory. “Directory” is not an alternative for many reasons. Here are some thoughts on this:

• It’s a data model issue

I’ve heard of UDDI referred to as a stubborn child that isn’t malleable enough. To me the fact that the data model and the APIs are pinned down is its strength. It is not trying to be everything to everyone like directory and ebXML Reg/Rep for example. Let me explain. The problem with ebXML Reg/Rep is that the data model is wide open just as one that which you can conjure up with directory. The problem with this is that you end up with a wide-open field – it is just that, and it leads to paralysis-analysis. In fact, Fujitsu – an ebXML proponent – gave up on ebXML Reg/Rep because customers became catatonic when faced with having to define their data model. Nothing got done. Fujitsu very pragmatically abandoned ebXML Reg/Rep in favour of UDDI and even authored the “Using UDDI as the Registry of ebXML Components” [1].

The same thing typically happens in directory. Just like ebXML Reg/Rep data-modeling committees who argue whether to use an attribute versus an element, the directory folks will argue whether to use an attribute versus an object. At the end of the day, most come up with a data-model that is company-specific that has little chance of wide vendor support. The team is then left with the unsavory task of selling and adapting everything to this internal data model.

• It isn’t a store issue

I’ve heard a lot of arguments in favour of collecting “service data” with identity information (i.e. directory) in the same store. At the end of the day, the value-proposition has no substance and leads to too many compromises. Directory has its place, and so does registry – they serve different functions and are optimized to different needs. The reality is that directory has been relegated to the identity space – period. Don’t tell this to your directory friends as this is going to engage you in a never-ending tirade; just point out the fact that all vendors are positioning it so.

• It’s about purpose-specific and optimized Web service registration and discovery

Having locked down the data model, UDDI provides the necessary hooks to service Web service publication and discovery needs. It provides for:
a. A rich metadata framework that you can extend via tModel and categorization schemes you define – the extensibility concepts are built in. Try to do this in directory forces you in the end to argue whether an attribute is multi-valued or not, and whether to index it or not (if it hasn’t come up yet, it will)
b. subscription and notification
c. many other Web scenario focused functionality – a good source of features can be found at [2]
d. … I could go on and on…

Bottom line: UDDI is built to service these needs and the OASIS UDDI technical committee (which I’m part of) is evolving UDDI to improve it. No one is doing so for directory-enabled discovery for example.

• It’s about building a Web services infrastructure

Adopting a non-Web services based registry is akin to implementing your infrastructure outside of the Web services framework: your services maybe based on Web services but the plumbing isn’t. Using LDAP for example for publication and discovery calls on you to use LDAP SASL authentication mechanisms rather than to leverage Web services aligned mechanisms (e.g. WS-Security which UDDI is in the process to aligning with); and using directory calls for you to load and distribute non-Web services protocol stacks (with all of the development, deployment and infrastructure costs associated with them).

The reality is that vendors have started to put Web services façades on everything they can. Authentication mechanisms are being exposed via SAML, WS-Security, etc. Directory has long been XML’ized via DSML – though the result is not really compelling. A similar level of support is unlikely outside of the Web services framework.

You also need to consider the alignment that is happening in the Web services world around policy, security, federation, reliability, management, etc.; none of these are being retrofit to legacy (i.e. directory). This is important because the Web services wave is affecting vendor product plans and thus what you can procure as solutions. I doubt that advancements in Web services (i.e. metadata/policy/security driven approaches) are likely to be available from vendors for legacy. The implication of this is that if you want to benefit from these outside of the Web services framework (i.e. UDDI registry) you are going to have to build it yourself.

All of this makes moving to an SOA much more difficult.

• Other factors: I could touch on other factors such as performance etc but I'll dispense with this at the moment.

Comments on Article - Luc Clement, Systinet, Co-chair OASIS UDDI TC
I'm sorry, but I suspect you and I are both preaching to our respective chiors, and I'd say your comment probably put off people who are befuddled by UDDI, just as mine probably makes UDDI proponents roll their eyes.

I do note with some amusement that the only examples you gave of UDDI influence are within the Web Services "stack", which is exactly the over-elaborated layer cake that people of my mind think should be thrown in the dumpster in favor of lightweight building blocks such as REST, and maybe even LDAP.

UDDI = A Rube Goldberg machine?
Hi Uche,

I generally agree with your assesment of UDDI 3.0 standard. However, I caution readers not to assume that a standards-based registry-repository is in itself a bad idea.

There has been some interesting discussion on this subject that I contributed to at uddi-dev list in defense of ebXML Registry-Repository standard. The thread begins at:
http://lists.oasis-open.org/archives/uddi-dev/200506/msg00005.html

It had a somewhat funny climax summarize here as follows:

-UDDI does too little

-What little is does do, it does with too much complexity