Rediscover the web with UDDI

Avijeet Dash and Satyabrata Dash

One of the key challenges in web services is to programmatically find all services available on the web. Web services will loose the charm if one can’t discover the other’s service dynamically on the web. It soon became a necessity in Web services world to find a standard for distributed services registration and discovery. XML being a platform neutral language was a natural choice. UDDI is the first truly cross-industry effort driven by all major platform and software providers to provide a standard distributed registry in XML language.

UDDI consists of two parts.

The core component of the UDDI project is the UDDI business registration, an XML file used to describe a business entity and its web services. The information provided in a UDDI business registration consists of three components:

It includes services exposed by the business. Green pages include references to specifications for web services, as well as support for pointers to various file and URL based discovery mechanisms if required.

SOAP and UDDI

From XML and SOAP, one can observe that the integration and interoperability problem has been simplified in layers. XML provides a cross-platform approach to data encoding and formatting. SOAP, which is built on XML, defines a simple way to package information for exchange across system boundaries. SOAP bindings for HTTP are built on this packaging protocol and define a way to make remote procedure calls between systems in a manner that is independent of the programming language or operating system choices made by individual companies.

Prior approaches involved complex distributed object standards or technology bridging software. Neither of these approaches has proven to be cost effective in the long run. Using XML and SOAP, this cross-language, cross-platform approach simplifies the problem of making systems at two companies compatible with each other.

Even when one considers XML and SOAP, though, there are still vast gaps through which any two companies can fall in implementing a communications infrastructure. As any industry pundit will tell you: "What is required is a full end-to-end solution, based on standards that are universally supported on every computing platform." Clearly, there is more work to do to achieve this goal.

The UDDI specifications borrow the lesson learned from XML and SOAP to define a next-layer-up that lets two companies share a way to query each other’s capabilities and to describe their own capabilities.

UDDI is a "next layer" in an emerging stack enabling rich Web services. UDDI uses standards-based technologies such as TCP/IP, HTTP, XML and SOAP to create a uniform service description format and service discovery protocol.

UDDI technical overview

Basic UDDI architecture consists of following elements.

UDDI Data

Here is a sample UDDI XML document.

The four key elements of UDDI information model are:

You can see that businessEntity is a root level element in the XML example.

The businessEntity entity element includes information about actual business, which includes business name, description, address and contact information. Each businessEntity element contains one or more businessService elements. Each business receives a unique businessKey value after registration.

Each businessService includes information about a single web service or a logical group of web services. It is the child of a single businessEntity.   

Each businessService contains descriptive information to outline the purpose of individual Web services found within it.  For example, a businessService structure could contain a set of Stock Trading Web services provided by a Stock Exchange. businessService element includes an optional list of bindingTemplates in it.

Each bindingTemplate includes information about a specific Web service. It tells where the Web Service can be accessed. In the above example, the web service can be accessed here.

The bindingTemplate provides the technical information needed by applications to bind and interact with the Web service being described.  It must contain either the access point for a given service or an indirection mechanism that will lead one to the access point. Each binding Template is the child of a single businessService. 

Technical Models, or tModels for short, are used in UDDI to represent pointers to external technical specifications.  tModels represent unique constructs that can be used as a standard in a software framework. So tModels exist outside the parent-child containment relationships between the businessEntity, businessService and bindingTemplate structures.

The UDDI specifications include interfaces to allow programmatic access to the UDDI registry information. The API is divided into two logical parts.

1. Inquiry API
   
   
   
   This provides search and retrieval functionality.



2. Publisher API
   
   
   
   This providers insert and update functionality.

The Inquiry API

Inquiry API allows the users to programmatically query the details on the UDDI registry. Currently three distinct patterns of inquiry are supported.

1. Browse pattern
   
   
   
   Browse pattern supports broad level search on large quantity of data. API includes "find_xx" operations that return overview information. For example find_binding searches for bindings associated with a specific service.



2. Drill-down pattern
   
   
   
   Drill-down pattern drills down to more specific information about a service. These operations are represented by "get_xx" signature. For example, get_bindingDetail will return a complete bindingTemplate record.



3. Invocation Pattern

Applications that access the UDDI registry using Browse and Drill-down patterns do cache the result for future access. If one of the operations based on cached result fail in future, then the application must access the UDDI registry to get the results fresh again and then invoke the operations on those results and upon success, must update it’s cache with the latest values.

Publication API is used to publish and update information contained in a UDDI registry.  The publisher must select a UDDI node where it will publish the information.  UDDI provides no automated means to reconcile multiple or registrations that are published at different nodes of the same registry.

API calls in this section MUST all be implemented as synchronous and "atomic" form that is, each call MUST either succeed completely or fail completely.

Publication API is used to publish and update information contained in a UDDI registry.  The publisher must select a UDDI node where it will publish the information.  UDDI provides no automated means to reconcile multiple or registrations that are published at different nodes of the same registry.

API calls in this section MUST all be implemented as synchronous and "atomic" form that is, each call MUST either succeed completely or fail completely. When a publisher does not provide keys for new entities, the UDDI node will assign keys in accordance with registry policy. If the publisher does not propose a key for an entity, the registry MUST assign one.

Some of the UDDI implementations for java are:

UDDI4J

jUDDI

References:

UDDI 3.0 Specification

UDDI White papers

XML Schema tutorial

UDDI Information and news

Sample UDDI XML document

(Authors can be reached at