Why UDDI Is Important
Attempting to create a Service Oriented Enterprise without a Service Registry is destined for trouble; here is how UDDI can help
Web Services are a great advance in our quest for the Service Oriented Enterprise, but most enterprises overlook the importance of a Service Registry (UDDI). This article outlines reasons why UDDI is critical to successful SOA initiatives and reviews recent enhancements to the UDDI standard.
What is a Service Registry?
A service registry is a central repository that allows for the cataloging of services throughout the enterprise. This catalog provides service consumers a place to search for details about service providers, the functional areas (taxonomies) these services address and binding details (location, contract, transport, etc.) for services.
The analogy often used is that of the telephone directory, but I think DNS (Domain Name System) is also a good fit. DNS is something we all understand at least at some level. DNS helps us as humans find computers which only know each other as IP Addresses (numbers). There is a similar parallel with a service registry. Service registries help us as service consumers (people) find services in a simple and centralized manner. They go one step further, however, and help consumers (programs) know how specifically to communicate with them as well.
UDDI
Universal Description Discovery and Integration (UDDI) is the accepted standard for service registries in the SOA context. It is now in its third version and has added important features that really make it the only practical choice for service registry. There are many UDDI servers (i.e. products) available; every large software vendor produces one. There are also many open source servers available as well. The good news is that they mostly implement the entire specification; even the free ones.
Continuing the telephone directory analogy, UDDI consists of three types of directories:
• White Pages – which identify organizations (companies, or more likely departments)
• Yellow Pages – which categorize services (like AP, Purchase Order, etc)
• Green Pages – bindings or details for specific services
The three pages represent a hierarchy--presented above from top down. One organization may (and should) have multiple categories of services, each with multiple service binding options.
Why use the Registry?
The registry really addresses many problems inherent in the enterprise: namely communication and responsibility (ownership). The existence of a registry allows others in the enterprise to see who (person or department) owns a service and who can be contacted for further details as well as where this service exists and how to communicate with it on a technical level (more on this last part later).
The ownership part is critical and it starts off by making the service landscape more open and transparent. I have worked with clients large and small that inadvertently created duplicate services (or worse yet skipped the service that existed and went directly to the data source) because they were unaware of services existing to perform tasks they needed. This is not only a major lapse in communication, but also in governance.
In addition to existence, ownership can be easily and clearly established. Services are like middleware in that they don’t have a User Interface that management sees and is reminded about. Being autonomous by nature it is possible for services to simply run for years without anyone really being responsible for them. This is a mistake because when there are problems consumers won’t know where to turn for help. Ownership in the registry removes this ambiguity and helps keep a clean line

