Is the public UDDI movement dead or, was it ever alive?

Question

I am trying to find some public UDDI registries to interact with, for learning purposes. But it seems there are none available. I popped the following question on SO to see if someone knows about any public registry still hosted, but got no answers.

The IBM, Microsoft and SAP public registries were a test of the UDDI technology. I quote from here: The primary goal of the UBR was to prove the interoperability and robustness of the UDDI specifications through a public implementation. This goal was met and far exceeded.

They now continue to support the UDDI specifications in their products (so, different companies can host their UBRs for private use).

Now, I am changing my original question to this: Is the public UDDI movement dead or, was it ever alive?

What do you think? If your answer is no, can you provide an example of an existing public UDDI UBR?

Answer 1

I received an answer from John Saunders on my original question, to one of my comments, and I think he is right.

To summarize it:

The public UDDI movement is dead because the IBM, Microsoft and SAP public registries were the UDDI movement.

Answer 2

Public UDDI is indeed dead, but it managed to survive in private registries inside enterprises.

A UDDI registry's functional purpose is the representation of data and metadata about Web services. A registry, either for use on a public network or within an organization's internal infrastructure, offers a standards-based mechanism to classify, catalog, and manage Web services, so that they can be discovered and consumed by other applications.

• http://uddi.org/pubs/uddi-tech-wp.pdf

This isn't bad for a definition and purpose, unfortunately it was applied at the web level.

UDDI was supposed to be the "yellow pages" of web services. If you wanted to find a web service providing a certain functionality, you would look it up inside the UDDI.

The idea was to use a standard (universal) mechanism for online interaction between SOA businesses components. You then dynamically looked up services, connected to them and do business automatically. And the decision for choosing between similar services was supposed to happen based on the metadata found in the UBR (all of it inside a very complex model which discouraged adoption) with no way of checking if the service actually did what you were expecting it to do.

But bringing every interaction to a common ground was impossible because businesses are highly heterogeneous. And businesses still revolves around people, human activity and human decisions.

Business are conducted between partners that choose to make business with each other only after thorough analysis and negotiation, before finally striking a business deal and agree on all terms and conditions. Only then their infrastructures are connected. And at this point the UDDI definition does start to make sense, because within the enterprise UDDI allows you to:

• relocate services without any of the clients failing;
• supports load balancing;
• improves efficiency by reducing manual interventions within the infrastructure;
• manage redundancy (if one service fails the clients will search for another service providing the same functionality);
• etc

.. but all of this within a confined set of predetermined services who's functionality is well established and agreed upon.

Answer 3

Not dead.

Apache jUDDI has a public snapshot available online

http://uddi-jbossoverlord.rhcloud.com/

Answer 4

UDDI is indeed dead. Three things killed it:

1. Overambitious complexity
2. Ignoring security
3. The difficulty, still with us, of managing and collecting micropayments

If a UDDI broker dynamically chooses a service provider for me, I have no opportunity to do any due diligence on the security of the service. And how much trouble would the broker take to ensure security for me? Not a lot, I would suggest.

Web services are commonly used behind the firewall for SOA purposes, to integrate applications with business partners, and to call well-known APIs. UDDI is total overkill for these purposes. A large organisation should have a catalogue of its web services, but that could be as simple as a wiki page. A developer looking for a potentially useful web service needs a one paragraph description of what it does, a contact person, and some WSDL and technical documentation. UDDI is not necessary for any of that.