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 of communication between providers and consumers (the people, not the programs in this case).

From an operational standpoint the registry allows service providers to publish secondary versions of their services to be used for testing, disaster recovery, and the like. This creates more fluidity and provides better certainty in service capabilities for users. Critically, it also allows providers to change the location of their services dynamically. When used properly a service consumer does not directly reference a service address, but instead queries UDDI and uses the resulting service information to communicate with the service. It is this level of directory indirection that makes UDDI operationally so powerful.

Many companies rely on DNS, router, or client configuration updates to facilitate moving services. This last part is really the most damning. If your consumer applications need to change for something as simple as a service location change then you are clearly violating core principles of Service Orientation. Alas this is the missing link in most enterprises’ foray into Service Orientation: without UDDI most efforts simply result in point to point service calls. As the web of services grows their manual management becomes a burden too great to sustain.

IT and SOA Governance get a lot of attention today and in many ways they tie to the concepts discussed above about ownership and existence. The last critical piece of the registry trifecta comes from requiring all services to be listed in the registry, and requiring consumers to use the registry. Once that’s accomplished service governance becomes a very simple affair. In fact, subscriptions in UDDI v3 allow for governance notifications when any aspect of the registry changes. This can be details of a service binding or transport, changes to a contract, or even just changes to the human contact information.

Why do so many people hate UDDI?

In part UDDI was a victim of technology marketing hype (indeed much like SOA nearly was). The major vendors (including IBM, Microsoft and SAP) all created public registries for web services believing (or trying to mandate) that companies would make many services publically accessible and searchable. There was an effort to push UDDI as a sort of DNS and Search Engine for web services. That this did not materialize in the manner first imagined should be no surprise. When UDDI hit the world there had not yet been a standardized security approach (WS-Security). This would make a public exchange of services troublesome to say the least. Yet many successful technologies flourish in applications other than their original intention.

Hurting UDDI further were a heavy use of Universally Unique Identifiers (UUIDs) which are great for computers, but terrible for people, as well as a less flexible taxonomy (both issues which have been rectified in the newest versions). UDDI was pushed, it seems, as some sort of external service to facilitate exchange between companies. In my experience UDDI fits much better in the internal role providing registry and governance capabilities to the enterprise itself.

How can an enterprise start being successful with UDDI?

The first place enterprises can begin succeeding is by simply starting to use UDDI and to mandate its centralized use and administration. Although global adoption is the best way, even one department using it is a good start. Critically, using Web Services in a point to point manner must stop. All web service access should be performed using UDDI lookups

UDDI should be leveraged to provide visibility into service existence, ownership, and technical implementation. By searching categories (taxonomies) developers or managers will be able to plan projects knowing what services exist to aid development. When gaps are found and services must be created they should embrace the concepts of SOA and create a true reusable service rather than just a point to point solution. This service should then be entered into the registry. The beautiful thing about UDDI and SOA in general is that even if you start with one type of UDDI server you should be able to switch between vendors quite easily.

Important changes in UDDI v3

The virtue of UDDI has been made even more attractive by smart revisions to the UDDI standard. The latest version of UDDI introduces some critically important features, some of which have already been introduced.

The following features will be presented in more detail in future articles:

• Multi-Registry support (making UDDI function even more like DNS).

• Support for digital signatures to verify the validity of registry entries.

• Expanded query support.

• Subscription API.

Conclusion

We have seen what UDDI can provide us as well as how it has changed recently. We covered how existence and ownership being visible and open helps an enterprise better manage and plan its service assets. We also covered how the registry can allow the changing of service details (like address) without changes to consumers. When we think of what Service Registry/UDDI can do for our enterprise, the choice should be clear. UDDI is not a luxury, but a necessity for web services in general and Service Orientation in particular.

Source CIO.com