Universal Description, Discovery and Integration (UDDI)

"The Universal Description, Discovery and Integration (UDDI) specifications define a registry service for Web services and for other electronic and non-electronic services. A UDDI registry service is a Web service that manages information about service providers, service implementations, and service metadata. Service providers can use UDDI to advertise the services they offer. Service consumers can use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. The UDDI V2.0 and 3.0 specifications have been approved as OASIS Standards and are maintained by the OASIS UDDI Specification technical committee. Numerous vendors and open source communities supply products that implement the UDDI standards..."

UDDI is the Internet's equivalent of a telephone directory, where businesses register themselves and other businesses or consumers look them up.

• A UDDI registry works in the following manner:
• A service provider registers its business with the UDDI registry.
• A service provider registers, separately, each service with the UDDI registry.
• The service consumer looks up the business and services in the UDDI registry.
• The service consumer binds to the service provider and uses the service.

When UDDI was introduced in 2000, its role as a central pillar of the Web service industry looked very promising. Major players such as IBM, Microsoft and SAP had invested in UDDI and rolled out public UDDI business registries (UBRs). Only six years later, in the beginning of 2006, the three companies announced they were shutting down their public UBRs. While the technology concept was proven and UDDI versions 2.0 and 3.0 were accepted as standards by OASIS, the primary reason for the shutdown was lack of business support. Business conduct still requires human interaction in the contracting phase. The UDDI standard is still being used, mainly in the internal operations of organizations. Other standards governing the interaction with registries were introduced. The most prevalent are ebXML and Java API for XML registries.

UDDI can be thought of as two major concepts:

• The specifications. These standards describe how such repositories should work and include three major concepts: white pages, yellow pages, and green pages. These will be described further below.
• The implementations of the specifications. Microsoft and IBM are UDDI operators of two public repositories, called business registries, which are the first public implementations of the UDDI specifications. A company can register at one repository and be confident that the entry will be replicated to the other repository (currently, the entries are replicated every 24 hours). However, for security reasons, any updates must be performed at the repository where the service was first registered. Of course, like everything else that is related to Web Services, the entries in the UDDI repositories are XML data.

The UDDI specifications define:

• SOAP APIs that applications use to query and to publish information to a UDDI registry
• XML Schema schemata of the registry data model and the SOAP message formats
• WSDL definitions of the SOAP APIs
• UDDI registry definitions (technical models - tModels) of various identifier and category systems that may be used to identify and categorize UDDI registrations

The OASIS UDDI Spec TC also develops technical notes and best practice documents that aid users in deploying and using UDDI registries effectively.

UDDI Data Model
The UDDI data model includes an XML schema that provides four major elements:

• The businessEntity element represents the owner of the services and includes the business name, description, address, contact information categories, and identifiers. Upon registration, each business receives a unique businessKey value that is used to correlate with the business's published service. The categories and identifiers can be used to specify details about a business, such as its NAICS, UNSPSC, and D-U-N-S codes—values that can be useful when performing searches.
• The businessService element has information about a single Web Service or a group of related ones, including the name, description, owner (cross-referenced with a unique businessKey value of the associated businessEntity element), and a list of optional bindingTemplate elements. Each service is uniquely identified by a serviceKey value.
• The bindingTemplate element represents a single service and contains all the required information about how and where to access the service (e.g., the URL if it is a Web Service). Each binding template is uniquely identified by a bindingKey value. l The service does not have to be a Web Service; it can be based on email (SMTP), FTP, or even the fax.
• The tModel element (shortened from "technical model" and also known as the service type) is primarily used to point to the external specification of the service being provided. For a Web Service, this element (more specifically, the overviewURL child element) should ideally point to the WSDL document that provides all the information needed to unambiguously describe the service and how to invoke it. If two services have the same tModel key value, then the services can be considered equivalent (thus allowing the requester potentially to switch from one serv-ice provider to another). Here is a useful metaphor: a tModel that can be thought of as an interface for which there can be multiple implementations, presumably from different companies since it does not make sense for a firm to implement more than one service for a given tModel (just as it would not make sense for a single class to implement the same interface in different ways).