UDDI Under the Covers

In the remainder of this chapter, we discuss how to add entries to a UDDI registry as well as how to search for available services and build applications that consume those services. We will also briefly touch on the major sections of the UDDI specification.

The UDDI Specification

Version 3 is the most recent incarnation of the UDDI specification. Version 3 builds on and expands the foundations laid by versions 1 and 2 of the UDDI specification, and presents a blueprint for flexible and interoperable Web services registries. Version 3 also includes a rich set of enhancements as well as additional features, including improved security and new APIs. The entire UDDI specification can be found at http://www.uddi.org.

The major documents of the UDDI Version 3 specification are listed in Table 4-3.

Table 4-3. The major documents of the UDDI Specification version 3.

UDDI Version 3 Specification Documents	Synopsis
Features List	Brief overview of the key features in version 3.
Specification	The actual specification document.
XML Schemas	A set of XML Schema files that formally describe UDDI data structures.
WSDL Service Interface Descriptions	A set of files that describe the UDDI Version 3 WSDL interface definitions.

Unlike in previous versions, UDDI Version 3 consolidates the entire specification into a single document entitled the UDDI Version 3 Published Specification. This single document contains everything related to UDDI, and also contains all information necessary for developing a UDDI node, the Web services that are called by a UDDI node, or a client application that directly interacts with a UDDI registry.

UDDI Core Data Structures

Information representation within UDDI consists of instances of persistent data structures that are expressed in XML. It is these data structures that are persistently stored and managed by UDDI nodes. The UDDI specification refers to these as entities, and defines four core entity types as listed in Table 4-4.

Table 4-4. The different entity types defined by the UDDI Information Model.

Entity Type Name	Description
businessEntity	A business that provides a Web service.
businessService	A collection of related services offered by a business.
bindingTemplate	Technical information about a particular Web service.
tModel	Technical model information about a Web service that is used to determine whether a service is compatible with the client's needs.

Whether you intend to programmatically connect to a UDDI registry or manually browse through one, it is necessary to understand these core data structures. Central to the purpose of UDDI is the representation of information about Web services so they can be easily registered and classified by publishers as well as searched and consumed by client applications. As such the data structures used by UDDI provide not only technical interface information about a service itself, but also information necessary to classify, manage, and locate services. Figure 4-4 depicts the interrelationships between the core UDDI data structures.

Figure 4-4. The interrelationship between the UDDI core data structures.

The businessEntity entity type represents information about service providers within UDDI. This information includes detailed data about the name of the provider, contact information, and some other short descriptions of the provider. This information may also be provided in multiple languages. The businessEntity structure does not necessarily have to refer to a business, but to any type of service provider, such as a department within an organization or a group.

One or more of the businessService entity types are contained within a businessEntity structure and represents information about the services offered by that businessEntity. The businessService entity type does not provide implementation or technical details, but instead is a logical grouping of Web services and provides information about the bundled purpose of a set of contained Web services.

One or more of the bindingTemplate entity types are contained within a businessService structure and provides technical information about a particular Web service. The bindingTemplate structure directly or indirectly provides descriptive technical information about an instance of a Web service, and includes a network location or endpoint of the service. The network location (access point) is usually a URL, but can be other network access points such as email addresses. The bindingTemplate structure also includes information about the type of Web service located at that access point through references to tModel entities as well as other parameters.

tModels, which are short for technical models, provide more detailed information about a Web service. tModels are reusable entities that are referenced from bindingTemplate structures and denote compliance with a shared concept or design. tModels are not contained within bindingTemplates, but instead are referenced. Distinct tModels exist for different interfaces and contracts that a Web service can comply with including specifications, transports, protocols, and namespaces. The set of tModels that a bindingTemplate refers to makes up a Web service's technical fingerprint. The actual documents and information identified by a tModel are not located within the UDDI registry itself, but instead the tModel provides pointers to the location where such documents can be found.

Two more UDDI entity types that are important are subscription and publisherAssertion. The subscription entity type describes the request to keep track of the evolution or changes to particular entities. The publisherAssertion entity type describes the relationship between one businessEntity and another businessEntity. There are many instances where multiple divisions within a large organization or a group of organizations want to make the relationship between them known in order to facilitate discovery of the services they provide. The individual divisions or organizations each have their own businessEntity, and the entity type publisherAssertion describes the relationship between two businessEntity structures. It is important to note that two organizations must assert the same relationship through the publisherAssertion for that relationship to be publicly available. This disallows the situation where one organization claims a relationship with another where in fact there is none.