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 Registry
The UDDI Registry implements the UDDI specification . UDDI is a Web-based distributed directory that enables businesses to list themselves on the Internet (or Intranet) and discover each other, similar to a traditional phone book’s yellow and white pages. The UDDI registry is both a white pages business directory and a technical specifications library. The Registry is designed to store information about Businesses and Services and it holds references to detailed documentation.

In step 1 of the above Figure, “Invocation Pattern using the UDDI Registry” it is shown how a business publishes services to the UDDI registry. In step 2, a client looks up the service in the registry and receives service binding information. Finally in step 3, the client then uses the binding information to invoke the service. The UDDI APIs are SOAP based for interoperability reasons. In this example we’ve three APIs specified in the UDDI v3 specification, Security, Publication and Inquiry. The UDDI v3 specification defines 9 APIs: UDDI_Security_PortType, defines the API to obtain a security token. With a valid security token a publisher can publish to the registry. A security token can be used for the entire session. UDDI_Publication_PortType, defines the API to publish business and service information to the UDDI registry. UDDI_Inquiry_PortType, defines the API to query the UDDI registry. Typically this API does not require a security token. UDDI_CustodyTransfer_PortType, this API can be used to transfer the custody of a business from one UDDI node to another. UDDI_Subscription_PortType, defines the API to register for updates on a particular business of service. UDDI_SubscriptionListener_PortType, defines the API a client must implement to receive subscription notifications from a UDDI node. UDDI_Replication_PortType, defines the API to replicate registry data between UDDI nodes. UDDI_ValueSetValidation_PortType, by nodes to allow external providers of value set validation. Web services to assess whether keyedReferences or keyedReferenceGroups are valid. UDDI_ValueSetCaching_PortType, UDDI nodes may perform validation of publisher references themselves using the cached values obtained from such a Web service.

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.

History of UDDI

• UDDI 1.0 was originally announced by Microsoft, IBM, and Ariba in September 2000.
• Since the initial announcement, the UDDI initiative has grown to include more than 300 companies including Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun.
• In May 2001, Microsoft and IBM launched the first UDDI operator sites and turned the UDDI registry live.
• In June 2001, UDDI announced Version 2.0.
• In 2004, UDDI released Version 3.0
• In 2005 UDDI ratified as an OASIS Standard
• Currently UDDI is sponsored by OASIS.

Structure of UDDI
A UDDI business registration consists of three components:

• White Pages — address, contact, and known identifiers;
• Yellow Pages — industrial categorizations based on standard taxonomies;
• Green Pages — technical information about services exposed by the business.

• White Pages: White pages give information about the business supplying the service. This includes the name of the business and a description of the business - potentially in multiple languages. Using this information, it is possible to find a service about which some information is already known (for example, locating a service based on the provider's name). Contact information for the business is also provided - for example the businesses address and phone number; and other information such as the Dun & Bradstreet.
• Yellow Pages: Yellow pages provide a classification of the service or business, based on standard taxonomies. These include the Standard Industrial Classification (SIC), the North American Industry Classification System (NAICS),[10] or the United Nations Standard Products and Services Code (UNSPSC) and geographic taxonomies. Because a single business may provide a number of services, there may be several Yellow Pages (each describing a service) associated with one White Page (giving general information about the business).
• Green Pages: Green pages are used to describe how to access a Web Service, with information on the service bindings. Some of the information is related to the Web Service - such as the address of the service and the parameters, and references to specifications of interfaces.[10] Other information is not related directly to the Web Service - this includes e-mail, FTP, CORBA and telephone details for the service. Because a Web Service may have multiple bindings (as defined in its WSDL description), a service may have multiple Green Pages, as each binding will need to be accessed differently.

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).

References