Over year ago Ed Gibbs asked the same question. Well it wasn't question maybe, however point is that UDDI may not be such dead yet. Some time ago I dug out that and I think it still can be useful. There are some conclusions.
A bit of history
For sure it's one of many forgotten technologies that were abandoned some time ago and no one talks about them. Well, almost no one. Specification for UDDI 2.0 has been published by OASIS on April 2003. On February 2005 the version 3.0.2 has been proposed but this document was published as a draft and didn't change till today. So looks like this bit is totally dead by now. In fact it isn't, rather went down to background and is living there. You can find some decent information on the uddi.xml.org, living and working site focused on UDDI. Let me quote Karla Norsworthy, Vice President of Software Standards, IBM quote (from NARZE blog post, 2007):
UDDI continues to serve an important role in the deployment of Services Oriented
Architectures. IBM will extend support for UDDI Version 3 in the WebSphere Application Server. The security enhancements in UDDI combined with the industry leading enterprise capabilities in WebSphere will be especially important for customers using UDDI to improve reuse and simplify discovery of Web services across their IT infrastructure.
There was big amount or criticism against UDDI in the past that is probably reason why this technology was abandoned. Difficult management and implementation were one of the major objectives. As a response, IBM and Microsoft designed WS-Inspection specification which was intended to replace UDDI. I have no idea what is the current WS-I status, but it seems to be as dead as UDDI.
Truth is that discovery mechanism is very useful and sometimes can be required. I think UDDI is not quite dead yet and maybe will raise back again soon, maybe in different shape.
What the UDDI is?
So what the UDDI is? Let me quote UDDI 2.0 specification as the answer:
Universal Description, Discovery and Integration, or UDDI, is the name of a group of web-based registries that expose information about a business or other entity and its technical interfaces (or API's). These registries are run by multiple Operator Sites, and can be used by anyone who wants to make information available about one or more businesses or entities, as well as anyone that wants to find that information. There is no charge for using the basic services of these operator sites.
By accessing any of the public UDDI Operator Sites, anyone can search for information about web services that are made available by or on behalf of a business. The benefit of having access to this information is to provide a mechanism that allows others to discover what technical programming interfaces are provided for interacting with a business for such purposes as electronic commerce, etc. The benefit to the individual business is increased exposure in an electronic commerce enabled world.
The information that a business can register includes several kinds of simple data that help others determine the answers to the questions "who, what, where and how". Simple information about a business – information such as name, business identifiers (D&B D-U-N-S Number®, etc.), and contact information answers the question "Who?" "What?" involves classification information that includes industry codes and product classifications, as well as descriptive information about the services that the business makes available. Answering the question "Where?" involves registering information about the URL or email address (or other address) through which each type of service is accessed. Finally, the question "How?" is answered by registering references to information about interfaces and other properties of a given service. These service properties describe how a particular software package or technical interface functions. These references are called tModels in the UDDI documentation.
Why I need UDDI for?
Question should be rather "do I need UDDI at all?". Answer is not easy however. If you have just few services in your business you probably don't need UDDI. Discovery like that becomes very useful when you have larger number of services and you want to store them in central location along with all technical data. Does that mean that business with as little as two services should not use UDDI? Not at all. You should learn what you can do with UDDI before decision will be made. So what are possible usage scenarios?
- Service directory. UDDI offers single point where information about all services is stored. It's easy to use via web interface (or other) or by web services that allows search, browsing and publishing. Directory can be published for anyone in the business and even published for potential partners or customers so everyone can get information without asking around. Well created directory will contact business taxonomy and dependencies, contact information etc. Because UDDI was designed to store information about web services you can publish endpoints, interface wsdl file locations, transport and protocol information, documentation, version info and many more. tModel schema is very flexible and powerful. With tModel you can store any information you like - wsdl location, protocol, authentication requirements, dependencies etc. It allows also you to create your own hierarchical categorisation schemas. Using tModel you can categorise services by it's location, functionality, business departments and so on. Search mechanism based on tModel allows you easily search through directory for services that have references to specific tModels, i.e. "find services implementing following interface", "find services located in UK office and related to finance department".
- Development support. Visual Studio .NET supports UDDI Services so a developer can locate services and create references. Having multiple teams working on various parts of business services can make that work easier. Using UDDI all teams will be ensured that are using correct services in development environment. Moreover, during a build process information can be published into test directory so test team will be able to work with correct version without any concerns. Support for partners or customers that are using your business services is worth to be mention. With UDDI they can easily locate services they want to use with information required to create proxies.
- Run-time discovery and dynamic configuration. That's my favorite case. Having all services published in UDDI it's very easy to create service that will connect to the directory at run-time and will collect information about endpoints and protocols it should expose for clients. In the same way client applications can locate required service in UDDI and configure proxy dynamically. That allows implementing total endpoint transparency. None of addresses except UDDI are hardcoded and whole system is very flexible to changes.
There is much more things you can possibly do with UDDI. In implementation I'm working on right now I have information such as service and interface versioning, technology compatibility (WSE2, 3 and WCF), relationships between service endpoints, authentication requirements and physical location (from building down to server). I still see many more potential features I could use (configuration for dynamic message routing, load balancing etc.).
Where to start?
Interested? If yes, you might need some guidelines where to start using UDDI. First of all you should set up UDDI services. The easiest way is to use Enterprise UDDI Services that are included in Windows 2003 Server. If you will do that you can start working with the directory right now, however will be good to read some papers before. Here is short start list:
Conclusion
I hope that post turn your attention into UDDI. It's not such bad and dead as it seems to be. Closer look opens a lot of perspectives and options for using it. I would recommend taking a look on that for everyone who is working with web services.
If you will need any help please let me know. I will be happy to share my knowledge. Also, if you will find that interesting please let me know. I can publish some more technical content with some code samples.
HTH