The Universal Description, Discovery, and Integration (UDDI) protocol is a key member of the Web services stack. It defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). UDDI is managed by the OASIS UDDI Technical Committee.

UDDI in a Web Services World

The specification defines a group of Web services and programmatic interfaces for publishing, retrieving, and managing information about services. (In true SOA fashion, a UDDI registry is itself composed of web services!) UDDI builds upon several other established industry standards, including HTTP, XML, XML Schema (XSD), SOAP, and WSDL. The conceptual relationship between UDDI and other protocols in the web services stack is illustrated in the following figure:

Key Functional Concepts in UDDI

A UDDI registry's functional purpose is the representation of data and metadata about Web services. A registry, either for use on a public network or within an organization's internal infrastructure, offers a standards-based mechanism to classify, catalog, and manage Web services, so that they can be discovered and consumed by other applications.

Accordingly, the standard specifies protocols for accessing a registry for Web services, methods for controlling access to the registry, and a mechanism for distributing or delegating records to other registries. In other words, the standard provides a means to locate a software service, to invoke that service, and to manage metadata about that service.

To these ends, key functional concepts for working with UDDI include:

• The UDDI Data Model. The UDDI specification defines core data types that include a description of the service's business function, information about the service's publisher, the service's technical details and API, and other metadata. These data types are defined in several XML schemas, which together form a base information model and interaction framework of UDDI registries. They include:

• A description of a service’s business function (called the businessService)
• Information about the organization that published the service (businessEntity)
• The service’s technical details (bindingTemplate), including a reference to the service’s programmatic interface or API, and
• Various other attributes or metadata such as taxonomy, transports, digital signatures, etc. (tModels)
• Relationships among entities in the registry (publisherAssertion)
• Standing requests to track changes to a list of entities (subscription)

• Defining UDDI Nodes and Registries. The UDDI specification includes a specific definition of the hierarchical relationship between a single instance of a UDDI implementation and others to which it is related. Technically, there are three major classifications of UDDI servers:

• A node is a UDDI server that supports at least the minimum set of functionality defined in the specification. It may perform one or more functions on the UDDI data to which it has access. It is a member of exactly one UDDI registry.
• A registry is composed of one or more nodes. A registry performs the complete set of functionality as defined in the specification.
• Affiliated registries are individual UDDI registries that implement policy-based sharing of information among them. The affiliated registries share a common namespace for UDDI keys that uniquely identify data records.

• Essential Programmatic Interfaces. A UDDI registry provides several key functions that include:

• Publishing information about a service to a registry
• Searching a UDDI registry for information about a service

These inquiry and publishing functions represent the core data management tools of a UDDI registry. Additionally, we have described how multiple registries may form a group, known as an affiliation, to permit policy-based copying of core data structures among them. Some of the most important concepts that support registry interaction include:

• Replicating and transferring custody of data about a service
• Registration key generation and management
• Registration subscription API set
• Security and authorization

The UDDI specification divides these functions into “Node API Sets” that are supported by a UDDI server and “Client API Sets” that are supported (naturally enough) by a UDDI client.

History of UDDI

UDDI first was proposed in 2000; it currently stands at its third major revision. Over this time, it has evolvoed to reflect the need for manageability and federated control in enterprise operating scenarios, as well as to further integrate the standard with other elements of service-oriented infrastructure. Highlights of the standard's progess include:

History of the UDDI Specification UDDI VERSION YEAR RELEASED KEY OBJECTIVE 1.0 2000 Create foundation for registry of Internet-based business services 2.0 2001 Align specification with emerging Web services standards and provide flexible service taxonomy. Formally released under OASIS aegis in 2003 3.0 2004 Support secure interaction of private and public implementations as major element of service-oriented infrastructure. Fully ratified by OASIS in 2005

Learning More

Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure. The left-hand navigation bar links to various in-depth resources. In particular, good next steps include:

• Introduction to UDDI: Important Features and Functional Concepts (White Paper)
• UDDI Executive Overview: Enabling Service-Oriented Architecture (White Paper)
• UDDI Version 3 Specification