UDDI | XML, Web Services, and the Data Revolution


Team-Fly

	XML, Web Services, and the Data Revolution By Frank P. Coyle
	Table of Contents

	Chapter 5. Web Services

UDDI is the protocol for communicating with registries.

At the core of UDDI is the UDDI Business Registry, a global, public, online directory that provides businesses a uniform way to describe their services, to discover services from other companies, and to understand the details of how to connect and interact with the software that implements a service.

UDDI stems from a cooperative agreement among Microsoft, IBM, and Ariba on an XML-based specification for establishing a registry of businesses and services on the Internet. Since the initiative began in August 2000, the project has expanded to over 260 UDDI community members .

UDDI defines a layer above SOAP in an interoperability stack that builds on TCP/IP, HTTP, and XML. UDDI defines an XML-based infrastructure for software to automatically discover available services on the Web, using SOAP as the protocol to invoke services.

UDDI: Public versus Private Registries

Registries may serve different public and private functions.

A UDDI-compliant registry provides an information framework for describing the services of a Web entity or business. The Web services vision uses UDDI registries as the focal point for registering and locating services. It is expected that some registries will be public and others private. Microsoft, IBM, and HP have agreed to provide a public UDDI registry, open for search and connection across the entire Internet. But private registries will also be available either internally within companies or among a closely knit family of trusted partners and collaborators.

In Version 2 of the UDDI specification there is support for deploying both public and private Web service registries, allowing enterprises to deploy private registries to manage internal Web services using the UDDI specification. As a result many IT companies are beginning to use Web services technologies behind their firewalls for application-to-application integration. By starting small on less critical projects, managers and developers can gain the experience needed to migrate to more ambitious projects beyond their corporate boundaries.

The UDDI Family of Specifications

The UDDI framework consists of several specifications that describe how a program can interact with a registry, including the following.

The UDDI Programmer's API Specification defines approximately 30 SOAP messages that are used to perform inquiry and publishing functions against any UDDI-compliant business registry. This specification outlines the details of each of the XML structures associated with these messages.
The UDDI Data Structure Specification defines the four major data structures used by Programmer API. These include businessEntity , businessService , bindingTemplate , and tModel .

Using UDDI to Make the ZwiftBooks Connection

The following is a scenario of interaction for connecting to our ZwiftBooks server using UDDI discovery:

A company is interested in writing software that connects to several book-service providers and comparing price and delivery times for each. It needs a program that can connect to the UDDI business registry via either a Web interface or a tool that uses the Inquiry API. After a lookup based on an appropriate yellow pages listing, the company obtains a businessEntity that represents ZwiftBooks.
Using the businessEntity , the client can either drill down for more detail or request a complete businessEntity structure. In either case, the objective is to obtain a bindingTemplate that provides the information about how to connect to ZwiftBooks Web service.
Based on the details of the specification provided by the bindingTemplate , the company sets up its program to interact with the ZwiftBooks Web service. The semantics of the service may be obtained by accessing the tModel contained in the bindingTemplate for the service.
At runtime, the program invokes the Web service based on the connection details provided in the bindingTemplate .

If the remote Web services and the calling program each accurately implement the required interface conventions (as defined in the specification referenced in the tModel ), calls to the remote service will be successful. However, if there is a problem with the interaction between client and Web service, UDDI specifies details for failure and recovery.

UDDI Failure and Recovery

UDDI failure is part of the protocol.

Web businesses making use of Web services for e-commerce need to be able to detect and manage communication problems and other failures. Because distributed systems have more failure points than stand-alone systems, it is important for clients to be able to detect and/or recover from failures that occur during interaction with remote partners. UDDI addresses quality-of-service issues by defining a calling convention that involves the use of cached bindingTemplate s. When a failure occurs, the cached information is refreshed based on current information from a UDDI Web registry.

The following scenario describes how error recovery fits into Web services:

A developer prepares a program to use a Web service, caching the appropriate bindingTemplate for use at runtime.
During program execution, the program calling the remote Web service uses the cached bindingTemplate that was earlier obtained from a UDDI Web registry.
If the call fails, the program uses the bindingKey value and the get_bindingTemplate API call to acquire a new copy of a bindingTemplate for this unique Web service.
The program compares the new bindingTemplate information with the cached version and, if they are different, retries the failed call using the new bindingTemplate .
If both versions are the same, the client retries the call. This approach, called " retry on failure," is more efficient than acquiring a new copy of bindingTemplate data prior to each call. It also proves useful when a business needs to redirect traffic to a new site; it need only activate the new site and change the published location information for the affected bindingTemplate s.


Team-Fly

Top