UDDI 101

The Universal Description, Discovery, and Integration (UDDI) protocol is an approved OASIS Standard and 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 advanced by the OASIS UDDI Specification 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. UDDI 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, UDDI describes 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.

Learn More

Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure.  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

Milestones

Making the business case

Today's IT organizations must identify and plan for an architecture that can not only provide for scalability, but also agility, the ability to add new offerings or reorient existing functions in a flexible, minimally disruptive fashion. This agility requires that we think of IT in terms of services, not physical assets. Web services and service-oriented architecture are a practical way to meet these needs.

UDDI is an important element of the Web services infrastructure. By enabling policy-based distribution and management of enterprise Web services, a UDDI registry delivers significant business value. It helps ensure that the functional and practical needs of developers, the operational and scalability requirements of enterprise architects, and the underlying business policies are not in opposition; in fact, it brings all of these needs into closer alignment by increasing software flexibility, reuse, and control.

UDDI helps to increase code re-use and to improve infrastructure management by implementing a standardized means of:

• Publishing information about web services
• Finding web services
• Determining a service's invocation, security, transport protocols and parameters
• Providing a means to insulate applications from failures or changes in invoked services

Functions like these help address important business questions for both developers building service-enabled applications and for IT organizations managing enterprise SOA infrastructure.

UDDI’s role in Web services development

Benefits such as standards-based interoperability that are provided to programmers by Web services are clear. Nonetheless, when development teams begin to build Web services interfaces into their applications, they soon face issues all too familiar to developers who work in any programming environment: code reuse, ongoing maintenance, and documentation. Moreover, as the number of Web services created within an IT organization grows, the need to manage these services can increase exponentially.

For development teams, registries based upon UDDI help answer needs such as:

• How can development managers systematically organize and manage Web services across multiple systems and development teams?
• How can developers systematically manage the process of moving services through each phase of development: from coding to testing to public deployment?
• How can programmers document interface specifications, message transports, and authentication mechanisms with other developer groups? As the services change over time, how can external applications accommodate the changes?

When developing and deploying Web services applications, UDDI registries help drive better code reuse and developer productivity. A UDDI registry provides an interoperable, standards-based approach for systematically documenting and publishing Web services, regardless of development environment or platform. It can help developers—even across functional groups—find a shared service and use that service within their own applications.

UDDI’s role in service-oriented infrastructure

Issues of services development point to the larger question of how to design an IT infrastructure that supports Web services development efforts. Although questions such as how best to conceive shared services, to design identity management and authentication mechanisms, and so on are beyond the scope of the UDDI OASIS Standard, UDDI registries represent an important element of this overall question. In a service-oriented environment, enterprise software architects must consider questions such as:

• How can critical applications be insulated from changes—or failures—in back-end shared services?
• How can an organization share information about services in a controlled way that reflects its own business rules and policies?

Registries based upon UDDI provide IT administrators with a formal layer of indirection necessary for service-oriented application development and management. By providing a sort of firewall between a service and the applications that call it, system administrators more easily can accommodate changes in the life cycle of specific components—such as for version updates, for policy considerations, or even for service termination.

In addition to the fundamental benefits of run-time binding provided by the registry in a service-oriented architecture, administrators often require control of the publication and distribution of information about deployed Web services, so that software deployment follows business policy. To facilitate these operational and governance needs, the current version of UDDI adds support for features such as client authentication and publish/subscribe for peer registries.

This understanding of how Web services are most often used today is reflected as the UDDI OASIS Standard has evolved. Its current implementation recognizes the need for federated control in real-world operational environments and further integrates the standard with other elements of service-oriented infrastructure. It provides key capabilities for enterprise-level deployment and is a mature, well-supported standard.

Learning More

Please explore this site to learn more about UDDI and its role in enabling SOA infrastructure.  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

Specification

The current list of specifications advanced by the OASIS UDDI Specification Technical Committee includes:

• UDDI Version 2 OASIS Standard
• UDDI Version 3 OASIS Standard
• Schema Centric XML Canonicalization Specification

The UDDI Version 2 specifications, UDDI Version 3 specification and the Schema Centric XML Canonicalization Specification represent contributed material. Notes and Disclaimers are provided on each of these specification documents.

UDDI Version History

Since UDDI was proposed in 2000, it has evolved to reflect the need for manageability and federated control in enterprise operating scenarios, as well as to integrate more fully with other elements of service-oriented infrastructure.

• Version 1.0, released in 2000, created a foundation for the registry of Internet-based business services.
• Version 2.0, released in 2001 and ratified as an OASIS Standard in 2003, aligned the specification with emerging Web services standards and provided a flexible service taxonomy.
  
• Version 3.0, released in 2004 and ratified as an OASIS Standard in 2005, supports secure interaction of private and public implementations as major element of service-oriented infrastructure.
  

UDDI Version 3 Specification

• UDDI Version 3.0 Features List 
• UDDI Version 3.0.2 OASIS Standard. This represents the second errata to the UDDI v3 specification. UDDI  v3.0.2, OASIS UDDI Specification Technical Committee Draft, Dated 20041019: HTML / PDF
• UDDI Version 3.0.2 XML Schema. UDDI uses the XML Schema Language to formally describe its data structures. UDDI Version 3.0.2 XML Schema is provided by these files:
  • UDDI API Schema: uddi_v3.xsd
  • UDDI Custody Schema: uddi_v3custody.xsd
  • UDDI Subscription Schema: uddi_v3subscription.xsd
  • UDDI Subscription Listener Schema: uddi_v3subscriptionListener.xsd
  • UDDI Replication Schema: uddi_v3replication.xsd
  • UDDI Value Set Validation Schema: uddi_v3valueset.xsd
  • UDDI Value Set Caching: uddi_v3valuesetcaching.xsd
  • UDDI Policy: uddi_v3policy.xsd
  • UDDI Policy Instance Parameters: uddi_v3policy_instanceParms.xsd
• UDDI Version 3.0.2 WSDL Service Interface Descriptions. The complete set of UDDI Version 3.0.2 WSDL definitions is provided by these files:
  • UDDI API Binding: uddi_api_v3_binding.wsdl
  • UDDI API Port Type: uddi_api_v3_portType.wsdl
  • UDDI Custody Binding: uddi_custody_v3_binding.wsdl
  • UDDI Custody Port Type: uddi_custody_v3_portType.wsdl
  • UDDI Replication Binding: uddi_repl_v3_binding.wsdl
  • UDDI Replication Port Type: uddi_repl_v3_portType.wsdl
  • UDDI Subscription Binding: uddi_sub_v3_binding.wsdl
  • UDDI Subscription Port Type: uddi_sub_v3_portType.wsdl
  • UDDI Subscription Listener Binding: uddi_subr_v3_binding.wsdl
  • UDDI Subscription Listener Port Type: uddi_subr_v3_portType.wsdl
  • UDDI Value Set Validation Binding: uddi_vs_v3_binding.wsdl
  • UDDI Value Set Validation Port Type: uddi_vs_v3_portType.wsdl
  • UDDI Value Set Caching Binding: uddi_vscache_v3_binding.wsdl
  • UDDI Value Set Caching Port Type: uddi_vscache_v3_portType.wsdl

UDDI Version 2 Specifications

The UDDI v2 OASIS Standard set of specifications consists of the following documents:

• UDDI Version 2 API Specification. This document describes the programming interface that is exposed by all instances of the Universal Description, Discovery & Integration (UDDI) registry. UDDI Version 2.04 API, Published Specification, Dated 19 July 2002: HTML /  PDF (492 KB)
• UDDI Version 2 Data Structure. This document outlines the details of each of the XML structures associated with these messages. The UDDI Programmers API Specification defines approximately 30 SOAP messages that are used to perform inquiry and publishing functions against any UDDI compliant service registry. Also see the UDDI XML schema, below. UDDI Version 2.03, Data Structure Reference, Published Specification, Dated 19 July 2002: HTML / PDF (349 KB)
• UDDI Version 2 XML Schema. Readers should consult the UDDI Data Structure Reference (preceding) before reading this document. Version 2.0 UDDI XML Schema 2001: uddi_v2.xsd
• UDDI Version 2 Replication Specification. This document describes the data replication process and programmatic interface required to achieve complete data replication between UDDI Operators. UDDI Version 2.03, Replication Specification, Published Specification, Dated 19 July 2002: HTML / PDF (251 KB)
• UDDI Version 2 XML Replication Schema Version 2.03 Replication XML Schema 2001: uddi_v2replication.xsd
• UDDI Version 2 XML Custody Schema UDDI XML Custody Schema: uddi_v2custody.xsd
• UDDI Version 2 Operator's Specification. This document describes the behavior and operational parameters required of the UDDI Node Operators. UDDI Version 2.01, Operator's Specification, Published Specification, Dated 19 July 2002: HTML / PDF (205 KB)
• UDDI Version 2 WSDL Service Interface Descriptions.  The WSDL service interface description for a UDDI registry is defined in two WSDL documents. One document contains the UDDI inquiry interface description, and the other document contains the UDDI publish interface description. Both of these service interface descriptions are based the UDDI V2 specification. They also adhere to the WSDL service interface definition described in the Using WSDL in a UDDI Registry, version 1.08 document.
  • UDDI Inquire API: inquire_v2.wsdl
  • UDDI Publish API: publish_v2.wsdl
• UDDI Version 2 tModels:
  • UDDI Registry tModels
  • UDDI Other Core tModel
  • Replication tModels
  • Taxonomy tModels

Schema Centric XML Canonicalization Specification

Existing XML Canonicalization algorithms such as Canonical XML and Exclusive XML Canonicalization suffer from several limitations and design artifacts (enumerated herein) which significantly limit their utility in many XML applications, particularly those which validate and process XML data according to the rules of and flexibilities afforded by XML Schema. The Schema Centric Canonicalization algorithm addresses these concerns.

• Schema Centric XML Canonicalization, Version 1.0, Published 20020710
  

Technical notes

The technical notes listed below are non-normative documents which accompany the UDDI specification and provide guidance on how to use UDDI registries. While technical notes represent the view of the OASIS UDDI Specification Technical Commitee on a UDDI-related topic, they may be prospective in nature and need not document existing practice.

Generating a JAX-RPC Client for UDDI 3.0.2

There are several incompatible Java clients for UDDI V2 which prevents portability of UDDI applications and tools written in Java. This Technical Note aims to avoid a repetition of this for UDDI V3 by encouraging the use of a single JAX-RPC programming model for UDDI V3. This technical note describes how to generate a Java client for UDDI 3.0.2 using only the mandatory mappings from WSDL and XML Schema to Java in the JAX-RPC 1.1 Specification. HTML / PDF Schema Files  / WSDL File

Handling of anyURI datatypes

Non-ASCII characters are supported by the XML Schema anyURI datatype but are not always supported in Web service tooling. This technical note describes the interoperability considerations when using anyURI-based data types in UDDI V3 API calls. HTML / PDF

Providing a Taxonomy for Use in UDDI Version 2

Taxonomies and identifier systems play an important role within UDDI. It is through categorization and identification that businesses are able to find each other and the services that meet their needs. Versions 1 and 2 of UDDI cite three common categorization schemes to encourage registrants to categorize their businesses, services and service descriptions. There are dozens of other taxonomies available that are newer, gaining in popularity, or targeted at specific constituencies. While UDDI does not mandate use of these taxonomies, it is imperative that they be made available to those who would benefit from using them. This paper guides the providers of taxonomies and identifier systems in the registration of their taxonomies and through the process of providing a validation service. Since taxonomies and identifier systems are handled in the same way, for conciseness this paper refers to both as "taxonomies".   HTML / PDF

Providing A Value Set For Use In UDDI Version 3.

In UDDI, a value set represents a set of values that can be used to provide meaning or context to a UDDI entity. Category, identifier, and relationship type systems are all value sets. Value sets play an important role within UDDI, because it is through their use that businesses are able to find each other and the services that meet their needs. Through the use of value sets in UDDI registries, businesses are able to find each other and the services that meet their needs. This document provides guidelines for providers of value sets on how to model, register, and validate their value sets for use in UDDI Version 3. HTML / PDF

UDDI as the registry for ebXML Components

  This UDDI Spec Technical Committee Technical Note (TN) provides technical guidance on how to use UDDI registries within the ebXML framework of B2B services. Specifically, it addresses the issues related to enabling automated discovery of ebXML framework components, such as Collaboration Protocol Profile and Business Process Specification Schema, using UDDI. By adopting the technical guidance of this TN, users will enable trading partners and their Web services and ebXML infrastructures to interact using UDDI as a common registry.   HTML / PDF  

Using BPEL4WS in a UDDI registry

BPEL4WS abstract processes describe the observable behavior of Web services. They complement abstract WSDL interfaces (port types and operations) and the UDDI model by defining dependencies between service operations in the context of a message exchange. This technical note describes the relationships between the three models and suggests how BPEL4WS abstract processes can be used in a UDDI Registry. HTML / PDF

Using WSDL in a UDDI Registry, Version 2.0.2  

The Universal Description, Discovery & Integration (UDDI) specification provides a platform-independent way of describing and discovering Web services and Web service providers. The UDDI data structures provide a framework for the description of basic service information, and an extensible mechanism to specify detailed service access information using any standard description language. Many such languages exist in specific industry domains and at different levels of the protocol stack. The Web Services Description Language (WSDL) is a general purpose XML language for describing the interface, protocol bindings, and the deployment details of network services. WSDL complements the UDDI standard by providing a uniform way of describing the abstract interface and protocol bindings of arbitrary network services. The purpose of this document is to clarify the relationship between the two and to describe a recommended approach to mapping WSDL descriptions to the UDDI data structures. This document builds on Using WSDL in a UDDI Registry, Version 1.08, providing an expanded modeling practice that encompasses the flexibility of WSDL. The primary difference between this mapping and the one described in the existing Best Practice is that this mapping provides a methodology to represent individual Web services artifacts. As a Technical Note, this document does not replace the Version 1 Best Practice. If the additional flexibility is not required, the existing Best Practice can still be used, particularly when the UDDI artifacts are published manually. The current version of this Technical Note represents errata #2. HTML / PDF  

Value Set Overview Documents

Value sets facilitate discovery of entities in UDDI registries. Value sets may consist of various types of values and hierarchies that may not always be self-explanatory, e.g. value sets consisting of codes or numbers. It is thus important that value sets be well-understood by their users and applied correctly and consistently to improve the quality of registration of entities and facilitate their discovery.   This OASIS UDDI Spec TC Technical Note provides recommendations on what Value Set Overview Documents accompanying a value set need to contain. Application of this TN will ensure consistency and completeness of Value Set Overview Documents.   HTML / PDF

Versioning Value Sets in a UDDI Registry, Version 1.12

Through the use of value sets in UDDI registries, businesses are able to find each other and the services that meet their needs. However, value set publishers often change their value sets by adding or deleting values and/or changing their meaning in order to meet the needs of a certain domain. This UDDI Spec TC Technical node provides guidelines to providers of value sets on how to register different versions of value sets for use in UDDI versions 2 and 3.   HTML / PDF

tModels

tModels are core components of UDDI. tModels represent unique concepts or constructs and are used to describe compliance with a specification, a concept, a category or identifier system, or a shared design. Each tModel should contain an overviewURL, which references a document that describes the tModel and its use in more detail.

Specification tModels are used to represent service type definitions, that is, reusable features of Web services. Web service registrations reference specification tModels in order to indicate their compliance with the service type definition..

Category systems and identifier systems tModels, together known as "value sets", represent another important use of tModels. These enable the categorization and identification of entities registered in UDDI in accordance to these value sets. The ability to attribute metadata to providers and services registered in UDDI, and then run queries based on that metadata is absolutely central to the purpose of UDDI at both design time and run time.

While these tModels can be published in a UDDI registry, promulgating their existence is also important. The OASIS UDDI Specification Technical Committee wants to encourage and promulgate common tModels promoted by standards groups and consortiums.

View a list of currently registered tModels.

Registering tModels with OASIS

The registration of tModels with OASIS is limited to tModels that represent a well-known concept and/or are owned by a well-known standards group, an industry vertical or a consortium (note that "well-known" may be limited to an industry, a geographical region or other contexts).

Technically, the tModel should follow basic recommendations and best practices for UDDI registrations. Therefore, it must contain:

• A name, formatted as a URI
• At least one description
• At least one of overviewDoc/description or overviewDoc/overviewURL that describes the tModel's meaning in more detail. In case of an overviewURL, the URL must resolve to a document in a well-known format.
• A categoryBag/keyedReference with the tModelKey of the UDDI Types category system and a keyValue that corresponds to the tModel's actual type

It should also:

• Contain as many categories and identifiers related to it
• Be referenced by a tModel if this represents its predecessor version. This is established by using the isReplacedBy identifier system.

Requesting registration with OASIS

tModel registration requests should be sent to the OASIS UDDI Specification Technical Committee comment list. The Committee will validate requests and, once accepted, will post the tModel information to this site.

FAQ