UDDI

The Universal Description, Discovery and Integration (UDDL) Business Registry is a standard for cataloging and publishing WSDL descriptions of Web services that are available over the Internet. In much the same way as people peruse common Yellow Pages for a particular service, commerce systems can search the UDDI registry and find Web services, download the parameters for interaction, and effectively interact with the discovered Web service using SOAP (see Figure 15.3).

Figure 15.3. UDDI is a standard for tracking and exposing WSDL for intercompany integration.

UDDI Business Registry is an implementation of the UDDI specification. A UDDI business registration consists of three components:

1. White pages. Address, contact, and known identifiers.

2. Yellow pages. Industrial categorizations based on standard taxonomies.

3. Green pages. The technical information about exposed services (e.g., WSDL documents).

UDDI specifications consist of an XML schema for SOAP messages and a description of the UDDI API specification the latter is actually a SOAP specification. The API defines methods for both inquiry and publishing services.

The UDDI invocation model is this:

1. A programmer uses the UDDI Business Registry (either via a Web interface or using the inquiry API) to locate the business entity information for the business partner advertising the Web service.

2. The programmer drills down to find the advertised Web service and obtains the binding templates (WSDL documents).

3. The programmer prepares the program based on the WSDL specifications.

4. At runtime, the program invokes the Web service as planned, using the binding obtained from the WSDL document.

The UDDI specification aims to define a common mechanism to both publish and discover information about Internet-accessible services that the UDDI folks call Web services. You can think of Web services as methods exposed by a company or software program that are both discoverable and accessible by other programs or organizations that are in need of a particular service; for example, purchasing a product, reserving a flight, calculating tariffs discrete business services that have value to many organizations.

Those that put UDDI together (IBM, Microsoft, and Ariba, together with 63 others) are looking to create a type of Yellow Pages for the Internet. The first generation of the specification is out now.

UDDI is really just a set of databases where businesses can register their Web services as well as locate other Web services they may be interested in leveraging. As an example, a company has a unique program for predicting breakage found in a shipment of ceramics, depending on the method of shipping, point of origin, and destination. That company may publish this information in the UDDI databases, allowing other organizations to find this Web service and understand how to access this service programmatically, as well as the interfaces employed (e.g., OAG BODs). Other examples would include the ability to create orders within a particular supplier's system through UDDI-registered Web services, as well as the ability to make payments by accessing Web services found in banking systems.

The core component of the UDDI project is the UDDI business registration database. This is really a large XML file that describes a business entity and any Web services that exist within that entity. The UDDI Business Registry can be used at a business level to determine if a particular trading partner has a specific Web service interface. You can locate companies in a given industry that provides a particular type of service. For example:

 Airlines -> XYZ Air ->  Reserve_Flight() 

The folks that wrote the UDDI specification describe UDDI as the next layer on the stack, with SOAP below it, and XML below that and above native network protocols (HTTP and TCP/IP). The UDDI spec describes a conceptual cloud of Web services, as well as an API to define a simple framework for describing any kind of Web service. The spec is made up of several documents, including an XML schema that defines a SOAP-based API for both registering and finding Web services.

Using the UDDI discovery services allows entities to register information about the Web services that are exposed for use by other Internet-connected businesses. By doing this, information is added to the UDDI Business Registry through a Web interface or through a defined registry protocol.

The UDDI Business Registry is a distributed database, which provides virtual centralization. There are multiple root nodes that synchronize data in near time, allowing businesses to register with one database, and have that information available in all UDDI databases within minutes. UDDI is taking this approach due to the large number of entities that may be using the databases at a single point in time, as well as protection against database failure.

Once the information is inside of the registry, other UDDI-enabled programs, or UDDI-aware programmers, can both discover and use Web services. Using this mechanism, the partner can determine if the service exists and is compatible with native enterprise systems. You may locate specific services through UDDI directly, or through online marketplaces and search engines that can peek into UDDI databases as a data source. As we move forward, the UDDI gang promises that this will be more of an automated process.

What UDDI looks to bring to the table is nothing new. We've been looking to create standard infrastructure to share program services, both intra- and intercompany, for some time. This was clearly the basic goal of distributed object standards, including the Object Management Group's (OMG's) CORBA specification (see www.omg.org). However, while a few B2B implementations exist, CORBA requires more time and effort than many organizations are willing to invest, and has no registry or discovery mechanisms to provide a clearinghouse for Internet-accessible methods. What's more, CORBA has a tendency to bind applications tightly together; UDDI is more loosely coupled. Loosely coupled application integration is a better fit for B2B.

Other recent attempts to create B2B method-sharing standards using a more contemporary approach include Hewlett-Packard's e-Speak. Like UDDI, e-Speak was designed specifically with B2B in mind and shares many of the same goals. However, e-Speak has not captured much interest from the B2B development community, and new standards such as UDDI will have to overcome many of the same obstacles.

UDDI will succeed, and provide value for the new real-time B2B marketplace, if it can quickly show successful implementations. Moreover, UDDI must learn to attract developers with excellent tools and support. Clearly, Microsoft will play a role in doing that. Finally, UDDI will need to stand the test of time. The simple fact is that most information technology standards don't exist in the long term, and UDDI will have to prove itself with both viability and market share. In the short term, count on a confusing battle with other B2B application integration standards that provide many of the same features as UDDI. This is the future of the IT marketplace, and there is a land grab occurring right now.