UDDI has been around for almost three years now. It has gone from an initial proposal by three companies (Ariba, IBM, and Microsoft), to a consortium effort (www.uddi.org) with a community of hundreds, and finally into the hands of the OASIS standards body. Along the way, the original specification has gone through two additional revisions. Perhaps more important, with each new revision the business value of UDDI has shifted from being a registry of public services to a central fixture in private EAI and partner-integration efforts.

The most recent version of UDDI, V3, continues this trend by making UDDI more usable as a common service registry inside an extended enterprise and between partners. Thus this technology, originally designed for publishing and discovering Web services, can today be leveraged by enterprises to provide a complete solution for managing access to Web services including subscription control and endpoint indirection.

Is UDDI Only for the Public Internet?
Along with SOAP and WSDL, UDDI is considered one of the three "pillars" of Web services technologies. Unfortunately, it is probably the least understood, at least initially. At the root of the various misconceptions about UDDI is the schizophrenic nature of the specification. The UDDI idea initially (and to this day) encompasses two very distinct concepts. The first one is the concept of a universal, online business registry, the Universal Business Registry (UBR), maintained and operated by a set of impartial operators along the lines of the DNS infrastructure. It is hoped that this UBR will act as some form of universal, multilayered "phone book" for registering businesses and the services they provide across the world, (for good or bad, this "universality" is baked into the UDDI name). This is the concept most people know about, and the one that is the most discussed, at least by the various UDDI naysayers. It is also perhaps the one least relevant to business, and just one incarnation of the more important concept behind UDDI: that of a generic services registry based on a set of open, standards-based, data structures and a set of SOAP-based APIs to programmatically register, organize, and find services and their descriptions.

Where UDDI is seeing its greatest adoption and showing greatest value is inside the enterprise. There, with some minor enhancements, it can bring security and flexibility to the process of publishing, discovering, and subscribing to internal services. The alternative is a disorganized soup of services that are published by local teams without any central organization, security, or management. With UDDI V3, the necessary functionality now exists for UDDI to take its place as core enterprise integration infrastructure.

UDDI Basics
When UDDI was first released, the concept of registries was by no means new. Corporate IT departments had been using naming and directory services for some time and several vendors had commercial registries on the market. The difference was that UDDI proposed an open collaborative effort to produce a standards-based registry that was not controlled by any vendor. Requirements for a registry are well understood: a data model for the metadata and a set of CRUD operations on these structures. The data model has to enforce ownership and containment requirements; a logical, consistent referencing system for the containment relationships; and a classification taxonomy to simplify searching. The CRUD API has to enforce security or authentication for operations that change data, and provide a query language for searching and retrieving data. The requirements that went into designing UDDI are no different.

UDDI has been described in detail in many articles and books but it would be helpful for us as a baseline to go over its structures and API. The UDDI data model has four main elements: businessEntity, businessService, bindingTemplate, and tModel. Use of the word "business" in two of the elements is unfortunate, but it should not be a deterrent since the pattern of registering and querying entities and the services they provide is useful, regardless of the name of the elements. Actually, with the proper XML transformations, the UDDI data model can be reused for a variety of purposes by changing the names of the elements.

The containment model is very simple: business entities can contain a set of business services; business services have binding templates that provide implementation details for the various implementation flavors of the business service (e.g., Web browser-based or e-mail- based implementation of the same basic service); and finally tModels provide the reference or namespace mechanism used in the description of how to access these services.

The tModel concept is extremely important in understanding UDDI. You can think of it as a set of technical signatures that are assigned to services to facilitate searching and categorization. A set of tModels has already been established to represent some of the more important technical concepts such as HTTP or SOAP. As an example of how they are used, consider a service that is accessible through SOAP over SMTP: it would be labeled, among other tModels, with the SOAP and SMTP tModels. When searching for a particular service to access through SOAP over SMTP, the search can be restricted to entries labeled with those two tModels.

Another important use of the tModel is as a namespace. An industry group, for example, can create their own tModels to designate business processes and services that are provided by their members; in this case, searches can be restricted to services within that namespace by using the appropriate tModel as a qualifier.

The UDDI API has two subsets: an authenticated Publishers' API to save, update, delete, and manage entries with security token management; and an open Inquiry API to find entries and get detailed content from them. In addition to the data model and the API, the UDDI specification allows the use of taxonomies for organizing the entries space and searching through it. Three taxonomies, for businesses, products and services, and geographic location, were originally specified.

UDDI V2: Becoming Enterprise Friendly
The UDDI v2 specification provided some additional flexibility in the UDDI usage model, mainly in providing the capability to add third-party taxonomies to the three that were already part of the specification. This provides enormous flexibility for organizations, whether private companies or consortia, for example, to define their own taxonomies and overlay them over other taxonomies. Another important concept introduced in v2 is that of business relationships through so-called publisher assertions. This allowed businesses (or organizations) to indicate that they are related through a partnership or other affiliation. Along with the additions to the data model, V2 introduced some changes to the API to handle the new data structures and relationships.

UDDI V3: Built for the Enterprise
The original UDDI specification was mainly concerned with enabling a set of central universal registries and some of the constraints reflect these concerns. For example, the original specification required operators to issue unique identifiers for every registry entry. These identifiers took the form of UUIDs, and could only be generated by the operators, in order to avoid clashes and inconsistencies in the identifier namespace. This is a perfectly acceptable restriction in the case of one universal registry, but becomes unworkable when several independent registries need to share information as is common inside the extended enterprise.

An example enterprise scenario facilitated by UDDI V3 but not its predecessors occurs when Web services are being developed internally and published to a test registry. Once these services become operational, they have to be migrated to one or more operational registries, whether internal or external. Once propagated, the integrity of these registry entries needs to be ensured against tampering, since the single UBR, with its trusted operators, is not being used. This scenario touches on several important requirements that were taken into account for V3, namely the ability to share entries between registries, while maintaining the referential integrity of the assigned keys; and the ability to sign and certify registry entries.

The V3 specification provides many new features, but the significant ones are geared towards making UDDI registries into more of an enterprise-class IT infrastructure by addressing some of the issues above. These improvements can be grouped under three main categories:

General extensions: