This section discusses the different specifications that make up the UDDI initiative and the options available to developers writing Java programs that interact with a UDDI registry.
The UDDI project also defines a set of XML Schema definitions that describe the data formats used by the various specification APIs. These documents are all available for download at http://www.uddi.org. The UDDI project releases their specifications in unison. The current version of all specification groups is Version 2.0. The specifications include:
- UDDI replication
This document describes the data replication processes and interfaces to which a registry operator must conform to achieve data replication between sites. This specification is not a programmer’s API; it defines the replication mechanism used among UBR nodes.
- UDDI operators
This document outlines the behavior and operational parameters required by UDDI node operators. This specification defines data management requirements to which operators must adhere. For example, node operators are responsible for durable recording and backup of all data, ensuring that each business registration has a valid email address associated with it, and the integrity of the data during deletions (e.g., deleting a business means that all of its service entries must also be deleted). This document is not a programmer’s API and private registries are not required to support it.
- UDDI Programmer’s API
This specification defines a set of functions that all UDDI registries support for inquiring about services hosted in a registry and for publishing information about a business or a service to a registry. This specification defines a series of SOAP messages containing XML documents that a UDDI registry accepts, parses, and responds to. This specification, along with the UDDI XML API schema and the UDDI Data Structure specification, makes up a complete programming interface to a UDDI registry.
- UDDI data structures
This specification covers the specifics of the XML structures contained within the SOAP messages defined by the UDDI Programmer’s API. This specification defines five core data structures and their relationships to one another.
The UDDI XML API schema is not contained in a specification; rather, it is stored as an XML Schema document that defines the structure and datatypes of the UDDI data structures.
The UDDI specifications do not directly define a Java-based API for accessing a UDDI registry. The Programmer’s API specification only defines a series of SOAP messages that a UDDI registry can accept. Thus, a Java developer who wishes to access a UDDI registry can do so in a number of ways:
- Using a Java-based SOAP API
A Java programmer can use an API that creates SOAP messages containing a UDDI XML document. The Java programmer would be have to create each XML document by hand and insert this document into the body of each SOAP message. This approach would require that a developer understand the ordering of the SOAP messages that a UDDI registry accepts and format each SOAP message properly.
- Using a custom Java-based UDDI client API
Some companies, such as Systinet, have created client APIs for accessing a UDDI registry. These APIs have classes and constructs that represent the data structures and messages supported by UDDI. These APIs also allow you to interact with a UDDI registry without knowing the specifics of SOAP or the XML messages and data structures that UDDI interacts with. These custom libraries work with any UDDI registry, so you can use Systinet’s library to access Microsoft’s UBR node.
- Using JAXR
The JAXR specification defines a standardized way for Java programs to access a registry. JAXR allows developers to write code that can access several different registries, including UDDI and the ebXML Registry/Repository. JAXR’s programming constructs don’t mimic those used by UDDI, but this API gives you a common way to access a variety of different registry types, whereas a custom Java-based UDDI client API can access only a UDDI registry. The trade-off for portability is dealing with the additional layer of abstraction required by JAXR. JAXR is currently in an early preview release
To get you up to speed with UDDI, this chapter presents a simple UDDI example implemented three times—one time for each technique. Apache SOAP is used to develop a client that uses a Java-based SOAP API, Systinet WASP UDDI Client Package demonstrates a custom Java-based UDDI client API, and a JAXR client shows how JAXR’s abstract approach looks to the developer. However, as more details of UDDI are explained, the examples use the Apache SOAP implementation because it allows us to focus on the details of XML and UDDI.