Contents

• Summary
• Bibliographic Information
  • UDDI Version 3.0.2 Specification
  • UDDI Version 3.0.2 Schemas
  • UDDI Version 3.0.2 WSDLs
• UDDI Version 3 Features
• From the OASIS Announcement
• Principal References

Version 3 of the Universal Description, Discovery, and Integration (UDDI) specification, in development since mid-2002, has been ratified as an OASIS Standard.

The UDDI Version 3.0.2 Specification describes the Web services, data structures, and behaviors of all instances of a UDDI registry. It "describes a registry of Web services and programmatic interfaces for publishing, retrieving, and managing information about services described therein."

Prior to balloting the UDDI 3.0.2 specification for approval as a standard, seven OASIS organizational members provided attestations with respect to successful use of UDDI Version 3, as required by the OASIS TC Process. These companies include Computer Associates, IBM, Microsoft, Oracle, SAP AG, Systinet, and UnitSpace.

According to the UDDI specification Introduction, Web services are meaningful "only if potential users may find information sufficient to permit their execution. The focus of Universal Description Discovery & Integration (UDDI) is the definition of a set of services supporting the description and discovery of (1) businesses, organizations, and other Web services providers, (2) the Web services they make available, and (3) the technical interfaces which may be used to access those services. Based on a common set of industry standards, including HTTP, XML, XML Schema, and SOAP, UDDI provides an interoperable, foundational infrastructure for a Web services-based software environment for both publicly available services and services only exposed internally within an organization."

The UDDI protocol is a "central element of the group of related standards that comprise the Web services stack. The Version 3 specification defines a standard method for publishing and discovering the network-based software components of a service-oriented architecture (SOA). The key objective in UDDI Version 3 is to support secure interaction of private and public implementations as major element of service-oriented infrastructure."

In the development of UDDI Versions 1 and 2, "much of the attention was focused on the UDDI Business Registry (UBR), a public implementation of the UDDI standard that represents a directory of publicly available e-commerce services. Although the UBR remains an important part of the UDDI project, it represents only one aspect of the overall effort. Just as the overwhelming majority of DNS activity occurs within the confines of a company's own network, so too do most UDDI implementations support a business' internal Web services infrastructure.' The implementation in UDDI version 3.0.2 "recognizes the need for federated control in real-world operational environments and further integrates the standard with other elements of service-oriented infrastructure."

Several registry features supported by the UDDI specification "have matured in the version 3 release, but the chief architectural change is the concept of 'registry affiliation'. This shift reflects the increasing recognition that UDDI is one element of a larger set of Web services technologies that support the design and operations of myriad software applications within and among business organizations."

In UDDI Version 3.0.2, affiliation refers to "using UDDI to support a variety of network/infrastructure topologies. The possibilities have expanded from a standalone, single-registry approach to include hierarchical, peer-based, delegated, and others. In short, the structure of a UDDI registry (or registries) can now reflect the realities and relationships of the underlying business processes that it supports."

Several models of registry interaction are thus enabled by Version 3 of the UDDI specification. "Through mechanisms like publish/subscribe and replication among peer nodes of a registry, the information in UDDI servers can be fully public (like the UBR), semi-private (such as with affiliated registries), or even fully private and isolated from the public network."

In the Corporate/Private registry type (such as an Enterprise Web Service Registry, there is an internal registry, behind a firewall that is isolated from the public network; access to both administrative features and registry data is restricted, and data is not shared with other registries.

In the Affliated UDDI registry type (such as a Trading Partner Network), a UDDI registry is deployed within a controlled environment, but with limited access by authorized clients. Administrative features may be delegated to trusted parties, and data may be shared with other registries in a controlled manner.

In the Public UDDI registry type (such as a UDDI Business Registry - UBR), a public registry appears to be a service in a cloud — from an end-user's perspective. "Although administrative functions may be secured, access to the registry data itself is essentially open and public. Data may be shared or transferred among other registries, and content may or may not be moderated."

Bibliographic Information

• UDDI Version 3.0.2. Technical Committee Draft Approved as an OASIS Standard. Edited by Luc Clément (Systinet), Andrew Hately (IBM), Claus von Riegen (SAP AG), and Tony Rogers (Computer Associates). Produced by members of the OASIS UDDI Specification Technical Committee. Date: 2004-10-19. Document identifier: 'uddi_v3'. 420 pages. Current version URL: http://uddi.org/pubs/uddi-v3.0.2-20041019.htm [HTML]. Latest version URL: http://uddi.org/pubs/uddi_v3.htm. Previous version URL: http://uddi.org/pubs/uddi-v3.0.1-20031014.htm.

  Contributors: Tom Bellwood (IBM), Steve Capell, Luc Clément (Systinet), John Colgrave (IBM), Matthew J. Dovey, Daniel Feygin (UnitSpace), Andrew Hately (IBM), Rob Kochman (Microsoft), Paul Macias (LMI), Mirek Novotny (Systinet), Massimo Paolucci, Claus von Riegen (SAP AG), Tony Rogers (Computer Associates), Katia Sycara, Pete Wenzel (SeeBeyond Technology), Zhe Wu (Oracle). See also the Acknowledgements in Appendix M.

• 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 Custody Schema
  • UDDI Subscription Schema
  • UDDI Subscription Listener Schema
  • UDDI Replication Schema
  • UDDI Value Set Validation Schema
  • UDDI Value Set Caching
  • UDDI Policy
  • UDDI Policy Instance Parameters

• WSDL. UDDI Version 3.0.2 WSDL Service Interface Descriptions:

  • UDDI API Binding
  • UDDI API Port Type
  • UDDI Custody Binding
  • UDDI Custody Port Type
  • UDDI Replication Binding
  • UDDI Replication Port Type
  • UDDI Subscription Binding
  • UDDI Subscription Port Type
  • UDDI Subscription Listener Binding
  • UDDI Subscription Listener Port Type
  • UDDI Value Set Validation Binding
  • UDDI Value Set Validation Port Type
  • UDDI Value Set Caching Binding
  • UDDI Value Set Caching Port Type

UDDI Version 3 Features

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. As part of a generalized strategy of indirection among servicesbased applications, UDDI offers several benefits to IT managers at both design-time and run-time, including increasing code re-use and improving infrastructure management by:

• Publishing information about Web services and categorization rules specific to an organization
• Finding Web services (within an organization or across organizational boundaries) that meet given criteria
• Determining the security and transport protocols supported by a given Web service and the parameters necessary to invoke the service
• Providing a means to insulate applications (and providing fail-over and intelligent routing) from failures or changes in invoked services

The UDDI Data Model: The core information model used by a UDDI registry is defined in several XML schemas. XML was chosen because it offers a platform-neutral view of data and allows hierarchical relationships to be described in a natural way. XSD [W3C XML Schema] was chosen because of its support for rich data types and its ability to easily describe and validate information based on information models represented in schemas. The UDDI XSDs define several core types of information that provide the kinds of information that that users and applications would need to know in order to use a particular Web service. Together, these form a base information model and interaction framework of UDDI registries. They are:

• 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
• Various other attributes or metadata such as taxonomy, transports, digital signatures, etc. (tModels)

UDDI Version 2 and Version 3 each add an additional data type to facilitate registry affiliation. Respectively, these are:

• Relationships among entities in the registry (publisherAssertion)
• Standing requests to track changes to a list of entities (subscription)

These [data types], like all UDDI data types, are expressed in XML and are stored persistently by a UDDI registry. Within a UDDI registry, each core data structure is assigned a unique identifier according to a standard scheme. This identifier is referred to as a UDDI key.

UDDI Nodes, Registries, and Affiliated 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 UDDI 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.

Taxonomic Classification of UDDI Entities: An important part of UDDI is providing a foundation and best practices that help provide semantic structure to the information about Web services contained in a registry. UDDI allows users to define multiple taxonomies that can be used in a registry. In such a way, users are not tied to a single system, but can rather employ an unlimited number of appropriate classification systems simultaneously. UDDI also defines a consistent way for a publisher to add new classification schemes to their registrations... [excerpted from the Technical White Paper "Introduction to UDDI: Important Features and Functional Concepts."]

From the OASIS Announcement

Excerpts from the OASIS announcement of 2005-02-03: "UDDI v3.0 Ratified as OASIS Standard. Computer Associates, IBM, Microsoft, Oracle, SAP, SeeBeyond Technology, Systinet, and Others Produce Open Standard for SOA Registries."

"The UDDI registry model is one of the central elements of an interoperable framework that ensures the effective interaction of services in a service oriented architecture." said Frank Kenney, analyst at Gartner. "By enabling policy-based distribution and management of enterprise Web services, a UDDI registry can deliver significant business value. It can help ensure that the convenience of developers, the 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, centralization and control; allowing enforcement and ultimately governance."

The UDDI OASIS Standard specifies protocols for creating a registry for Web services, methods for controlling access to the registry, and a mechanism for distributing or delegating records to other registries. Version 3.0.2 adds the ability to affiliate registries in keeping with SOA's emphasis on supporting a variety of infrastructural variations and providing a means to define relationships among a variety of UDDI registries. Although from its inception, the specification included concepts such as delegation and distribution among server peers, earlier UDDI definitions relied upon proprietary means of interaction. By contrast, UDDI v3.0.2 provides an open, standardized approach to ensure widely interoperable communication.

"The v3.0.2 OASIS Standard represents another significant milestone in UDDI's evolution," noted Luc Clement of Systinet, co-chair of the OASIS UDDI Specification Technical Committee. "It delivers key capabilities for enterprise-level deployment, providing different responses depending upon the security, transport, or quality of service as defined by business rules or taxonomies."

"One of the most significant enhancements of UDDI v3.0.2 is that it allows well-known identifiers for service descriptions to be created, facilitating reuse of service descriptions among registries," added Tony Rogers of Computer Associates, co-chair of the OASIS UDDI Specification Technical Committee. "This makes it much easier for developers and architects to communicate."

Other v3.0.2 features include support for digital signatures, allowing UDDI to deliver a higher degree of data integrity and authenticity. Extended discovery features can combine previous, multi-step queries into a single-step, complex query. UDDI now also provides the ability to nest sub-queries within a single query, letting clients narrow their searches much more efficiently.

Patrick Gannon, president and CEO of OASIS, applauded the thorough approach taken by the UDDI developers, pointing to the large body of use cases and technical notes that supplement the specification. "The technical committee has taken the time to precisely articulate the business case for UDDI. They've also actively consulted and collaborated with related standards efforts, such as the OASIS Web Services for Remote Portlets (WSRP) Technical Committee, UN/CEFACT's ebXML Core Components Working Group, and the OASIS Web Services for Business Process Execution Language (WSBPEL) Technical Committee."

Two new technical notes were released simultaneously with UDDI 3.0.2. The first provides advice on using UDDI and WSBPEL together. The second explains the process using JAX-RPC for a UDDI client. These technical notes are part of the on-going effort by the OASIS UDDI Specification Technical Committee to facilitate and promote the use of UDDI in a wide variety of contexts.