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.
Read the complete article by Dan Rosanova in CIO Magazine.
