UDDI: Straw Man or Ugly Duckling?

The Universal Description, Discovery, and Integration (UDDI) standard is the least understood and often the most maligned of the core Web Services standards. Unlike its now well-understood cousins SOAP and WSDL, UDDI has experienced limited and sporadic adoption by companies implementing Web Services-based SOAs. This lukewarm reception is particularly surprising, considering that discovery is a core feature of Service-Oriented Architecture (SOA), and SOAs are all the buzz in IT shops around the world today. So, what’s the problem with UDDI, anyway? Why is it so misunderstood? And most important, what will the future bring for UDDI adoption?

Off to a Poor Start: the UDDI Straw Man
UDDI was originally the brainchild of a consortium of vendors led by IBM, Microsoft, and Ariba in 2000. SOA proponents primarily at IBM promoted the “publish-find-bind” SOA triangle, and sketched out the core of UDDI to provide a standard way of handling the discovery aspects (publish and find) of this triangle. The broader UDDI consortium and early press coverage, however, saw Web Services more as providing a way for companies to conduct business with each other, where Web Service discovery applied more to finding a third-party company to do business with than solving a particular integration problem.

As a result, the consortium defined three distinct parts of the UDDI specification: White Pages, where a Service consumer could discover companies’ basic contact information, Yellow Pages, where users can search for information about the types of business services a company offers, and Green Pages that provide the technical information about how to interface with a company’s publicly available Web Services. The consortium building the UDDI spec quickly built public test registries, in the hopes that businesses around the world would populate them with rich information about how to conduct business with each other, and a new era of automated, business-to-business eCommerce would be born.

However, this vision of automated business-to-business interaction simply didn’t pan out, because business just doesn’t work that way. Here’s an example of the problem. Let’s say your shipping software wants to look in a public UDDI registry for an overnight carrier that offers the lowest cost for shipping a particular package. Finding the right company is easy, but now what? If you don’t already have an account with the shipping company, than simply finding information about it is insufficient for conducting business with the firm. The missing element is the human relationship. After all, technology doesn’t change the fact that business requires some kind of human handshake.

From Straw Man to Ugly Duckling
In the four years since the original proposal of the UDDI spec, then, the White, Yellow, and Green Pages idea of UDDI has dogged the standard, creating a straw man that has impeded widespread adoption. This idea is a straw man because it fundamentally mischaracterizes the UDDI value proposition as discovering new companies to do business with. On the contrary, the power of UDDI lies in its role within an operating SOA as a key standard that helps companies realize loose coupling by guiding the location independence of Services, and hence implementing the abstraction layer that the Services represent in an SOA.

To understand UDDI’s true value to an SOA, it’s important to distinguish between two basically different senses of the concept of the discovery of Web Services. The first sense of discovery is essentially a manual, design time activity, where developers or other people who want to find a particular Web Service search for it with some kind of Service discovery tool. The second sense of the concept of Service discovery is basically an automatic, runtime activity, where a Service consumer (which is a piece of software) has an indirect reference to the Service it requires, and looks up that reference in a runtime registry in order to find the Service contract (WSDL file) that tells the consumer where to find the Service and how to bind to it, similar to how the Domain Name Service (DNS) binds names of Internet addresses to the physical IP address of the requested server.

This manual, design time sense of Service discovery is best handled by an asset management or metadata management tool. Such tools may support UDDI as part of how they provide for the discovery of Services, but the information that might be contained in a UDDI-enabled registry is only part of the metadata that asset management tools must deal with. In other words, asset management tools are metadata management tools that may or may not support the UDDI standard, but in any case, must offer users far more information than what would normally be included in a UDDI registry, including metadata about Service levels, support for Service consumers, security and policy requirements, and information about what Services are for and how to use them. Asset management is essential to how people use an SOA to build loosely-coupled, coarse-grained systems that are composed of reusable Service assets, but is only tangentially related to the runtime operation of the architecture.

In contrast, the automatic, runtime sense of Service discovery is essential to the proper operation of an SOA. To understand why runtime discovery is so important, consider that a Service consumer should query the registry every time a particular Service is requested, and the registry might conceivably return a different Service contract from one request to the next. For example, a Service-Oriented (SO) Management application that incorporates a UDDI-based Service registry might route a request to a different server to provide better scalability or availability, support different Service versions or service levels, handle protocol translation, or maybe convert a synchronous request to an asynchronous one.

In addition, Service consumers might not be aware of security or policy changes that might require a change in the way that they access a given Service. In these cases, there might be a Service negotiation where Service consumers communicate first with a registry to determine how best to access particular functionality. Regardless, all of this management activity takes place behind the scenes, in that the user of the Service need be none the wiser that the Service contract or the underlying Service provider is different from one request to the next.

In other words, UDDI is an essential part of abstracting the Service interface. As faithful ZapThink readers know, an SOA is an abstraction layer that provides agile business Services to the user while hiding the underlying complexity of the technology. UDDI is a critical element in the magic that makes this abstraction work.

The ZapThink Take
As the old story goes, the ugly duckling got nothing but scorn from his nest-mates, but had the last laugh in the end, since after all, he was a swan all along. Just so with UDDI — scorned in its youth, but now in the process of growing its adult feathers. Now that the attention of the industry is focused on SOA, technologists are working through the elements of this new architectural approach, and as a result, are gaining a newfound respect for, and understanding of UDDI.

Even as UDDI takes flight, however, it’s important to realize that it’s just one part of the whole Service discovery picture. On the one hand, asset management tools provide a broader set of discovery capabilities to the business or technical user than a UDDI registry would offer, and on the other hand, UDDI-based Service registries are frequently an integral part of an SO management application. After all, UDDI is a standard, not a product — but among the core Web Services standards, it’s the one most essential to maintaining the abstraction layer in an enterprise SOA.