UDDI Specification Index Page

 

The Universal Description, Discovery, and Integration (UDDI) specification defines a SOAP-based Web service for locating WSDL-formatted protocol descriptions of Web services. UDDI provides a foundation for developers and administrators to readily share information about internal Web services across the enterprise and public Web services across the Internet. UDDI.org specifications can be found at http://uddi.org/specification.html.

UDDI Version 1

Specification

UDDI Programmer's API 1.0: http://uddi.org/pubs/ProgrammersAPI-V1.01-Published-20020628.pdf

UDDI Data Structure Reference v1.0: http://uddi.org/pubs/DataStructure-V1.00-Published-20020628.pdf

Schema

UDDI Version 1.0 Schema: http://uddi.org/schema/uddi_v1.xsd

UDDI Version 2

Specification

UDDI Version 2.0 API Specification: http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.pdf

UDDI Version 2.0 Data Structure: http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.pdf

UDDI Version 2.0 Replication: http://uddi.org/pubs/Replication-V2.03-Published-20020719.pdf

UDDI Version 2.0 Operator's Specification: http://uddi.org/pubs/Operators-V2.01-Published-20020719.pdf

Schema

UDDI Version 2.0 Schema: http://uddi.org/schema/uddi_v2.xsd

Version 2.03 Replication Schema:http://uddi.org/schema/uddi_v2replication.xsd

UDDI Custody Transfer Schema:http://uddi.org/schema/uddi_v2custody.xsd

UDDI Version 3

Feature List

UDDI Version 3.0 Features List: http://uddi.org/pubs/uddi_v3_features.htm

Specification

UDDI V3 Specification: http://uddi.org/pubs/uddi_v3.htm

Schema

UDDI API Schema: http://uddi.org/schema/uddi_v3.xsd

UDDI Custody Schema: http://uddi.org/schema/uddi_v3custody.xsd

UDDI Subscription Schema: http://uddi.org/schema/uddi_v3subscription.xsd

UDDI Subscription Listener Schema: http://uddi.org/schema/uddi_v3subscriptionListener.xsd

UDDI Replication Schema: http://uddi.org/schema/uddi_v3replication.xsd

UDDI Value Set Validation Schema: http://uddi.org/schema/uddi_v3valueset.xsd

UDDI Value Set Caching: http://uddi.org/schema/uddi_v3valuesetcaching.xsd

UDDI Policy: http://uddi.org/schema/uddi_v3policy.xsd

UDDI Policy Instance Parameters: http://uddi.org/schema/uddi_v3policy_instanceParms.xsd

Status

UDDI is a project that was founded by Microsoft, IBM, and Ariba in the second quarter of 2000. The project and the publication of the first (version 1.0) release of the specifications were announced publicly in September 2000 with the broad backing of all the major players in the industry. Since then, UDDI has become an industry-wide standard for Web service discovery. Version 2 of the specifications was published in June 2001 and was rolled out by the UDDI Business Registry (UBR) in May 2002; you can find the UBR Operator node access points at http://uddi.org/find.html. Version 3 specification development was completed July 2002. Stewardship of the UDDI specifications has been transferred to OASIS, where the specifications will continue to evolve within the context of an OASIS Member Section dedicated to UDDI. The UDDI Member Section will to continue work on the Web services registry foundations developed and published by UDDI.org.

ApNotes

Introduction

The UDDI specifications form the necessary technical foundation for publication and discovery of Web services implementations both within and between enterprises. Included in the specification are structures supporting the formal description of abstract service protocols and existing services. A rich set of metadata can be associated with this information, enabling efficient discovery of Web service information through precise search criteria. UDDI is itself a Web service for managing and locating other services from a logically centralized resource.

Goals and Non-Goals

UDDI was designed to provide a simple mechanism to support the discovery of Web services and their specifications. The design supports development tools, automation, and provides a simple categorization structure for adding searchable attributes to Web service and protocol listings.

The specification does not attempt to define the description language itself, nor does it attempt to store the supporting XML elements directly. UDDI consists of a set of links to resources and rich descriptions and remains completely neutral regarding the particulars of a service or description language. This neutrality allows non-XML services to be described within UDDI.

Details

Two types of information are registered within UDDI. The first is the set of abstract service protocols, called tModels (technical models) in UDDI terminology, which are used to describe the behavior of a particular Web service. The second type of information in UDDI is the service implementation, currently referred to as a businessEntity. These entries refer to multiple tModels and provide descriptions about their behavior and specifications.

Abstract Protocols: tModels

An example of a simple tModel entry is shown here. This is a UDDI entry for a credit check protocol entry.

<businessEntity xmlns="urn:uddi-org:api"  
 businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"> 
 <name>Contoso Finance Services</name> 
 <description xml:lang="en">Corporate Finance</description> 
 <businessServices> 
  <businessService  
   businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"  
   serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC"> 
  <name>Credit Check</name> 
   <bindingTemplates> 
    <bindingTemplate  
     serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC"  
     bindingKey="DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD"> 
    <accessPoint                  URLType="https">https://contoso.com/credit.aspx</accessPoint> 
     <tModelInstanceDetails> 
      <tModelInstanceInfo 
       tModelKey="UUID:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA"/> 
     </tModelInstanceDetails> 
    </bindingTemplate> 
   </bindingTemplates> 
  </businessService> 
 </businessServices> 
 <categoryBag> 
  <keyedReference 
   tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634"  
   keyName="Consumer credit gathering or reporting services"  
   keyValue="84.14.16.01.00"/>  
 </categoryBag> 
</businessEntity>

This example tModel entry demonstrates four of the more important characteristics of typical UDDI entries. First, a human-friendly name and description is a part of each entry. Second, a unique key, in the form of a GUID, is assigned to the entry. Third, the entry for the credit check service definition is the URL to its WSDL file. This file is not stored in UDDI, but on an external resource where it can be managed and secured separately.

Finally, the tModel includes a set of categorizations that provide additional information about the entry. In this example, the credit check is categorized within a business taxonomy for credit reporting and within a development taxonomy to indicate that the specification is provided in WSDL.

Service Providers

The second type of information published within UDDI is the set of service providers, or the locations where Web services are implemented. These entries reference one or more tModels to formally describe their behavior. The name 'businessEntity' is a bit of a misnomer. UDDI entries describe service providers of any sort, whether they are a business, individual application, or a smart handheld device.

An example entry is shown here. For simplicity and clarity, contrived GUIDs have been included to show how key values are reused and references are maintained.

<businessEntity xmlns="urn:uddi-org:api" 
 businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB">
 <name>Contoso Finance Services</name>
 <description xml:lang="en">Corporate Finance</description>
 <businessServices>
  <businessService 
   businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB" 
   serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC">
   <name>Credit Check</name>
   <bindingTemplates>
    <bindingTemplate 
     serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC" 
     bindingKey="DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD">
     <accessPoint URLType="https">https://contoso.com/credit.aspx</accessPoint>
     <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey="UUID:AAAAAAAA-AAAA-AAAA-AAAA-
AAAAAAAAAAAA"/>
     <tModelInstanceDetails>
   </bindingTemplate>
  </bindingTemplates
 </businessService>
 <businessServices>
 <categoryBag>
  <keyedReference
    tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6634" 
    keyName="Consumer credit gathering or reporting services" 
    keyValue="84.14.16.01.00"/> 
 </categoryBag>
</businessEntity>

The structure of the UDDI "businessEntity" entry is nested at three levels.

• The businessEntity contains general information about the service provider, and a collection of services (the businessServices element). In this example, Contoso's Corporate Finance organization is hosting services. This level of the entry also includes categorizations similar to that of the tModel described above.
• The businessServices collection contains the set of functional groupings of related Web services. This example shows only one for Credit Check services. Any number of functional areas may be included.
• Within each of these functional groups is the collection of bindings to the access points for the services. These are contained within the bindingTemplates element. Included is the URL to used invoke the Web service, and references to the tModels describing the protocol implemented.

Each of the main UDDI structures (tModel, businessEntity, businessService, the bindingTemplace) is assigned a unique key, in the format of a GUID. It should also be noted that the businessEntity structure may be updated at a finer granularity than is shown in this sample. Also, note that parent or enclosing element keys (businessKey, serviceKey, and bindingKey) chain related structures together. This is used to facilitate fine-grained updates in the API as shown below.

UDDI Interfaces

Inquiry Messages

UDDI defines a set of messages for search and inquiry. These messages are used to discover entries based on a set of criteria, and to request detailed information about a specific entry.

Publication Messages

UDDI also defines a set of messages for the publication and management of information. Updates to UDDI require the client to use authorization tokens. Each type of information in UDDI can be listed or deleted independently through a series of SOAP calls.

Related Specifications

UDDI is itself a Web service, based on SOAP and XML. Interaction with UDDI is through the set of SOAP interfaces that have been specified. The protocol is formally described in WSDL.

See Also

UDDI Specifications: http://uddi.org/specification.html