Universal Description, Discovery and Integration (UDDI)

The Universal Description, Discovery and Integration ( UDDI ) specification offers a way to help companies locate trading partners and discover their capabilities for conducting electronic business. A consortium led by Microsoft, IBM, and Ariba announced UDDI in September 2000.[16]

The basic laws of economics and business assume that suppliers and customers already know of each other's existence and abilities to meet the needs of the marketplace . One of the main reasons for companies engaging in electronic business is to open new markets and find new sources of supply more easily than before.

To achieve this desired state, however, companies need a common way of identifying potential trading partners and cataloging their e-business characteristics. Otherwise, they can miss entire communities of potential trading partners, only because they didn't show up on the searching company's radar screen.

The problem here is not with the trading partners, but (figuratively) with the type of radar used. UDDI proposes a specification for defining a registry to identify and describe e-business services, query other companies, and share information. In other words, it proposes a common radar for spotting and describing the trading partner communities in which companies operate .[17]

Using a UDDI registry, companies can discover the existence of potential trading partners and basic information about them, find companies in specific classifications, and uncover the kinds of e-business services offered to interact with these companies.

UDDI describes the services that companies offer over the web, defined as functions that companies offer to other businesses, using the Internet as connective tissue .This idea of services goes beyond the simple exchange of messages. For example, a company can offer the ability to look up and report its product line by UPC/EAN code (the number represented in retail bar codes) for use in purchase orders or other electronic documents.This kind of function helps trading partners interact with the company electronically but is not strictly speaking a form of message exchange. It does, however, represent the type of service that UDDI can describe.

UDDI proposes three ways of listing companies in a registry, using the familiar telephone directory as an analogy:

• White pages, or basic identification: name , address, and key points of contact

• Yellow pages, or classification by a standard index of business and industries

• Green pages, or technical capabilities and services related to the conduct of electronic business

Using a UDDI registry, companies can discover the existence of potential trading partners and basic information about them (white pages), find companies in specific classifications (yellow pages), and uncover the kinds of e-business services offered to interact with these companies (green pages).[18]

UDDI Information Types

UDDI relies on features of the XML Schema specification, because of its abilities to support many types of data (see a similar discussion of SOAP, earlier in this chapter, as evidence of this feature) and to construct data in many different structures and models. (See Chapter 4 for a description of these features of XML Schema.)

UDDI defines four types of information for providing the white/yellow/green pages functions just described.The basic business information such as company name and contacts (white page listings) is contained in an XML element called businessEntity . This element also contains identifiers, such as D-U-N-S numbers or UCC company codes, as well as classifications or categories under which the company falls , which correspond to the yellow-pages functions.

Two XML elements provide descriptions of services, or green-pages information: businessService and bindingTemplate . The businessService element describes collections of related activities and functions, somewhat like the business process models defined in ebXML, but specifically for enabling machine-to-machine connections and interactions. Included under businessService are web addresses and details of hosted services such as digital market-places. It also covers any other additional technical data, such as software settings, that the trading partner's system needs to connect and exchange data.

The bindingTemplate provides references to details about the data formats and requirements of the trading partners. A key part of the bindingTemplate is the tModel that acts as a reference to the specifications that contain the metadata (data about data) with these critical details.[19]

These various elements have a hierarchical relationship, in which each businessEntity can contain one or more businessServices , which in turn can have one or more bindingTemplates (one-to-many relationships). However, a tModel can have any number of bindingTemplates referencing any number of tModels (many-to-many relationship); thus they are not unique to bindingTemplates .

For example, a company ( businessEntity in UDDI-speak) advertises that it can accept orders, shipping notices, and invoices electronically, and provide online inventory searches for regular customers. These various services ( businessService ) can support several protocols or specifications (XML vocabularies, EDI standards, and so on), each having a separate bindingTemplate . The bindingTemplate can reference each specification or protocol with a tModel .

Each element has a key with a unique identifier, with the names businessKey , serviceKey , bindingKey , and tModelKey . Each of these items is represented as an attribute of its respective element in the schema. The uniquely identified keys are vital for UDDI to offer global registries of these e-business services.[20]

Programmer's API

The UDDI documents include specifications for an application programming interface (API) for automated interactions with a UDDI-registered site. All of these interactions use a request-response model, in which each message requesting service from the site generates some kind of response, even if nothing more than a simple acknowledgment.The specifications define two types of exchanges with UDDI-registered sites: inquiries and publishing.

Inquiries, as the name implies, enable parties to find businesses, services, or bindings (technical characteristics) meeting certain criteria.The party can then get the corresponding businessEntity , businessService , or bindingTemplate information matching the search factors. The inquiries support three kinds of query patterns: browse, drill-down, and invocation.

The browse and drill-down patterns work together and are common database access functions.The searcher uses broad criteria to find the entities, services, or technical characteristics meeting general requirements and then drills down to find the more specific features.

The invocation pattern returns new bindingTemplate information, and is used particularly when these technical details may change because of failure of the operator site or changes in the site's configuration. Normally, the requestor will store the bindingTemplate data and use the details for routine accesses . If for any reason those normal exchanges don't work, the requestor needs to query the target site for an updated bindingTemplate . The invocation method performs this specific query and returns the new information.

UDDI sites use the publishing functions to manage the information provided to requestors. These operations give the site operators power to delete the current data and provide updates as needed. Of course, these functions require prior authentication. UDDI doesn't specify authentication procedures, but leaves them up to the operator site. An appendix to the document spells out the publishing security requirements in more detail.[21]