UDDI - A Foundation for Web Services

1. What Is UDDI?

Universal Description, Discovery and Integration (UDDI) is a project to encourage interoperability and adoption of web services. It consists of a standards-based set of specifications which allow service description and discovery. The project was initiated by Ariba, IBM and Microsoft. It has now grown to a partnership of over 300 community members who collaborate to develop the specification. UDDI is not just a specification though. As part of its charter, it is also backed with a set of publicly available internet-based implementations. A UDDI registry is a set of one or more implementations which comply with the UDDI specification. The "UDDI Business Registry" is the name of a special set of UDDI implementations which member companies have provided for public access. Each implementation interoperates to share registrations.

UDDI addresses a number of business problems. For the mid-sized manufacturer which interacts with numerous on-line customers, each of whom has differing interfaces, each with their own set of standards and protocols, UDDI provides a way to broaden and simplify the use of B2B through web Service Description. For the flower shop in Australia which desires to be "plugged in" to every marketplace in the world but doesn't know how, UDDI offers a simple one-stop location for Service Discovery. For the B2B marketplace which needs to get catalog data for relevant suppliers in its industry, along with connections to shippers, insurers, etc., UDDI offers Easy Integration. Because UDDI provides a standards-based profile for all electronic services, it Enhances Accessibility.

The vision of the UDDI organization has been a three stage process. First, to build the specification on a set of recognized standards, such as XML and SOAP, and a shared vision of open protocols. Next, UDDI has been expanded into a common web services “stack.” Inter-operating implementations compliant with the UDDI specification avoid confusing customers. The specifications are public and are developed in an inclusive process. The final part of the vision is to transition the work to a standards body after completion of three cycles of implementation backed specification development. UDDI is currently in development of this third version of the specification.

Version 1 of the UDDI Specification was published in September, 2000. Public registry site implementations of the UDDI Business Registry have been in continuous operation ever since. Both IBM and Microsoft currently operate "nodes" (implementations) which make up the registry. The UDDI Version 2 Specification was published in June of 2001. Availability of Beta implementations is imminent. Both Hewlett Packard and SAP have announced their intention to operate public registry implementations as part of the UDDI Business Registry in the version 2 time frame as well. Version 3 of the UDDI Specification is currently under development.

2. How UDDI Works

A UDDI registry contains programmatic descriptions of businesses and the services they support. It also contains references to specifications (called Technical Models, or "tModels") which describe how web services work. It is built upon a programming model and schema which are platform and language agnostic.

Business and standards organizations are the primary source of registry information. Populating the registry has several steps. Software companies, standards bodies and programmers populate the registry with descriptions of various tModels which describe specifications common to an industry vertical or business. Businesses populate the registry with descriptions of the services they support. UDDI assigns a programmatically unique universal identifier (UUID) to each tModel and business registration and stores them in the registry. Marketplaces, search engines, and business applications then query the registry to discover services of other companies. Businesses then use this data to facilitate easier integration with each other over the web. This can then be a dynamic process where search and discovery automatically adapts to available services.

Business and service data in the registry can be thought of in three categories: "white pages," "yellow pages," and "green pages." White pages contain information about a business, such as its name, a set of multi-language text descriptions, and contact information such as addresses, phone numbers, fax numbers, web sites, etc. It also consists of a set of optional Identifiers by which a business may be known, such a Dun & Bradstreet D-U-N-S® number, etc. Yellow pages consist of business categorizations. UDDI supports three built-in standard taxonomies in version 1. The NAICS taxonomy of industry codes; the UN/SPSC taxonomy of products & services; and a geographical taxonomy of location codes based on ISO 3166. Taxonomies are implemented as name-value pairs. Any valid taxonomy data can be attached to the business white page, or business service. Finally, Green pages specify how to bind to a service provider. They contain technical information about how to invoke a businesses service, including references to specifications for web services and support for pointers to various file and URL based discovery mechanisms, if required. UDDI uses a nested data model of Businesses, their Services and related Service Binding information.

3. UDDI Business Registry Operation

Implementations participating in the UDDI Business Registry operate as peer nodes (websites). Companies may register with any operator in the registry. Registrations are replicated on a daily basis. Each registry node operator maintains a complete set of “registered” records. The same information is available at all operator nodes. The UDDI Specification defines a common set of SOAP APIs which is supported by all operators. Compliance is enforced by business contract.

The current implementations in the UDDI Business Registry are operated by Microsoft and IBM. The IBM site may be found at: http://www.ibm.com/services/uddi and the Microsoft site is located at http://uddi.microsoft.com. Both also offer test sites which may be used to experiment or test out registry entries. These test sites do not replicate with each other. The IBM Test Registry may be found at: http://www.ibm.com/services/uddi/testregistry and the Microsoft test registry is located at: http://test.uddi.microsoft.com. Each supports both SOAP & Web Page access.

4. The UDDI Specification

The UDDI Specification consists of several parts:

• XML schemas for the UDDI API data model and replication

• Programmers API - containing API definitions for performing discovery and publishing; API syntax, request/response structure semantics, error handling, and XML & SOAP details.

• Operators specification (available only in V2) Information on operation of a UDDI Registry node

4.1. The UDDI Data Model

The UDDI data model is composed of four primary "top-level" entities: the businessEntity, businessService, bindingTemplate and tModel. All top-level entities in UDDI are given a UUID. A businessEntity contains information about the business specifications, including the businessKey (UUID), business name, the authorizedName (relating to the publisher's credentials), the custodial operator (the registry node on which the business is maintained), and the business description(s). A businessEntity also can contain references to any businessService it owns, as well as a categoryBag (which contains a set of keyedReferences, each of which provide a reference to a particular taxonomy name/value pair). Similarly it can contain an identifierBag, which contains keyedReferences to specific identifiers for the business. The businessEntity also can contain contacts and always has one or more discoveryURLs, which allow one to make an http request which will recover the businessEntity contents. Operators assign a discoveryURL specific to their node when a business is saved.

A businessService contains the businessKey (UUID) of the business which owns it. , as well as its own serviceKey (UUID), name and description(s). A service may also contain a bindingTemplate (which provides invocation information for using the service), and a categoryBag.

The bindingTemplate provides a mechanism for associating tModels (references to specifications) with a service, and for identifying where and how to invoke that service. It also contains a reference to the serviceKey of the service which owns the binding as well as its own bindingKey (UUID) and may also contain description(s) of the binding. A bindingTemplate contains something called a tModelInstanceDetails (which is a container for tModelInstanceInfos which describe information on compatible specifications via tModel references & optional settings); as well as either an accessPoint or hostingRedirector, which point to the actual location where the service can be invoked, or a remote host for that service, respectively.

The tModel identifies information about specifications. It contains a tModelKey (UUID), a name, an authorizedName, operator, and description(s). The tModel is a somewhat overloaded entity in UDDI, as it is also used to fill the role of defining taxonomies and identifier sets.

4.2. The UDDI APIs

There are a number of APIs defined in UDDI which assist with either inquiry or publishing. Most are self-exclamatory, but we'll discuss a few:

Inquiry APIs:	Publishing APIs
find_business	save_business
find_service	save_service
find_binding	save_binding
find_tModel	save_tModel
get_businessDetail	delete_business
get_serviceDetail	delete_service
get_bindingDetail	delete_binding
get_tModelDetail	delete_tModel
get_registeredInfo	get_authToken
	discard_authToken

The UDDI inquiry APIs support three types of query patterns. The browse pattern allows a broad search using the "find_xxx" APIs. The "find_xxx" APIs allow one to look for registry entries based on a set of search criteria. The drill-down pattern is supported by the "get_xxx" APIs, which obtain complete details on a specific entry. The invocation pattern assumes users of the registry cache binding information for services they use and only return to the registry when updates are needed.

The "save_xxx" and "delete_xxx" APIs allow creation and destruction of any of the top-level entities, within the context of their nested ownership. The "get_authToken" and "discard_authToken" APIs are used to identify one's publishing credentials with the operator in preparation for publishing entities.

4.3. Web Service Descriptions

Web service descriptions describe how a web service works. While UDDI is extremely flexible and mandates no particular standardization here, selecting a common grammar for describing web services is extremely valuable because it affords tool makers a means of automating the creation and use of web services. Web Services Description Language (WSDL) is an XML Vocabulary (similar in purpose to IDL). It describes the interfaces for web services and how to invoke those services. WSDL was created by combining IBM's NASSL and Microsoft's SDL/SCL. WSDL has been submitted to the W3C, where it will develop into an open specification.

WSDL contains operational information about the web service it describes. It supports service interface implementation details and access protocol contact endpoints. This allows one to have a machine-readable service description, and provides a unifying way of describing new and existing services. It also provides the basis for a web services component composition framework. WSDL is also extensible to allow new protocol bindings. See WSDL “Best Practices” document http://uddi.org/pubs/wsdlbestpractices-V1.04- Open-20010420.doc for more information on using WSDL with UDDI.

4.4. Case Study: Chili Dip Golf

To see how all this fits together, we'll take as an example a fictitious business known as Chili Dip Golf. Enthusiasts of the game will appreciate the irony. Chili Dip is a golf supply wholesaler of bulk products to retailers and offers a number of custom web services to the public, including an Automated Product Browsing service, an Automated Ordering service; an Automated Shipping service; a Custom Golf Club Building service; and a Handicapping Service.

We will create registry entries in UDDI which will allow others to discover and use Chili Dip's services:

4.4.1. Creating Chili Dip's White Page

We can use the UDDI SOAP APIs to publish Chili Dip's white page. First we need to obtain an authorization token so we can publish the entry:

<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">

<Body>

<get_authToken generic="1.0" xmlns="urn:uddi-org:api" userID="myUserId" cred="myPassword" />

</Body>

</Envelope>

which returns

<authToken generic="1.0" operator="www.ibm.com/services/uddi" xmlns="urn:uddi-org:api">

<authInfo>myAuthToken</authInfo>

</authToken>

The "myAuthToken" value returned is used on all subsequent publishing requests. Next we save the business entity for Chili Dip. The SOAP wrapper is omitted for brevity:

<save_business generic="1.0" xmlns="urn:uddi-org:api">

<authInfo>myAuthToken</authInfo>

<businessEntity businessKey="">

<name>Chili Dip Discount Golf</name>

<description xml:lang="en">Discount golf supply wholesaler</description>

<contacts>

<contact useType="CEO">

<description xml:lang="en">Chief Executive Officer</description>

<personName>John Doe</personName>

<phone useType="Contact the CEO">512-555-1212</phone>

<email useType="email the CEO">ceo@chilidip.com</email>

<address useType="Snail Mail the CEO">

<addressLine>123 Chili Dip Rd.</addressLine>

<addressLine>Austin, TX, 78758</addressLine>

</address>

</contact>

</contacts>

<categoryBag>

<keyedReference tModelKey="UUID:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88" keyName="Texas" keyValue="US-TX"/>

<keyedReference tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2" keyName="Sporting Goods Stores" keyValue="45111"/>

</categoryBag>

</businessEntity>

</saveBusiness>

After saving, UDDI will assign our new business a UUID key, and a discoveryURL. Note that the categoryBag included two taxonomy references, the first to the geographical taxonomy indicating this business operates in Texas, and the second to the NAICS taxonomy identifying the business as a Sporting Goods Store. Categorizing one's business and its services is extremely important. It allows others the means by which to find your offering without explicitely knowing the name of your business. Accurate and explicit categorization is key to UDDI.

4.5. Creating tModels for Chili Dip

We need a tModel for each unique interface exposed by Chili Dip’s web services. Each points to an overviewURL of the specification describing the interface. Chili Dip’s services are all WSDL compliant, so we'll also add a categoryBag reference to each of our tModels to identify them as WSDL spec compliant For purposes of example, we'll only describe the tModel for Chili Dip's Product Browsing Service. We'll also show the result of having saved the tModel, which provides us with its returned UUID:

<tModel authorizedName="5U0000000C2" operator="www.ibm.com/services/uddi" tModelKey="UUID:43EB9E10-59E7-11D5-A560-BC9419402B90">

<name>Automated Product Browsing</name>

<description xml:lang="en">Automated Product Browsing</description>

<overviewDoc>

<description xml:lang="en">WSDL Source Document</description>

<overviewURL>http://www.chilidip.com/ProductBrowsing.wsdl</overviewURL>

</overviewDoc>

<categoryBag>

<keyedReference tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="uddi-org:types" keyValue="wsdlSpec"/>

</categoryBag>

</tModel>

The categoryBag above illustrates how one can identify the tModel it is in as being WSDL compliant, by using the wsdlSpec value in the uddi-org:types canonical tModel. This allows one to search the registry for WSDL compliant tModels, and for the services which support them.

4.6. The Automated Product Browsing Service

Our service supports dynamic query of Chili Dip’s product line and is targeted to retailers. We create the service below (SOAP Envelope not shown):

<save_service generic="1.0" xmlns="urn:uddi-org:api">

<authinfo>myAuthToken</authInfo>

<businessService businessKey="same key we got upon saving...." serviceKey="">

<name>Product Browsing</name>

<description xml:lang="en">Automated browsing of Chili Dip's product line</description>

<bindingTemplates>

<bindingTemplate bindingKey="">

<description xml:lang="en">Automated Product Browing</description>

<accessPoint URLType="http">http://www.chilidip.com/ProductBrowser</accessPoint>

<tModelInstanceDetails>

<tModelInstanceInfo tModelKey="the key of our tModel above...">

<description xml:lang="en">Automated Product Browsing</description>

<instanceDetails>

<description xml:lang="en">How to call the Automated Product Browsing web service</description>

<overviewDoc>

<description xml:lang="en">Automated Product Browsing interface description</description>

<overviewURL>http://www.chilidip.com/ProductBrowser.html</overviewURL>

</overviewDoc>

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

<categoryBag>

<keyedReference ... we include the same geographical location and NAICS Sporting Good's taxonomies here as with the business above...>

</categoryBag>

</businessService>

Note that whenever a new entity is saved in UDDI, one specifies "" for its key, which is a signal to UDDI that it is a new entity, rather than a replacement for an existing one, and the registry assigns a new UUID key to it.

4.7. What's new in UDDI Version 2?

Version 2 of the UDDI specification adds significant functionality. One of the major weaknesses in version 1 was the difficulty which large organizations had creating business entries in the registry and relating them to one another. Version 2 adds support for the description of complex organizations. It also adds new categorization and identifier schemes, richer options for inquiry, and improved support for internationalization. Another major improvement is peer based replication for improved scaling of multiple replicating nodes in a registry

The new support for business relationships allows creation of publisher assertion pairs between businesses identifying a relationship. Each assertion is represented by two businesses and a keyedReference which describes the specific relationship. A new built-in canonical tModel (uddi-org:relationships) supports parent-child, peer-to-peer and identity type relationships. One can only create a relationship if he owns at least one of the two businesses making up the relationship. Business relationships must be mutually confirmed to be publicly visible. The publisher's of both companies must assert an identical relationship to make this happen. Several new messages have been added for Publication & Inquiry.

Inquiry APIs:	Publication APIs:
set_publisherAssertions	find_relatedBusinesses
add_publisherAssertions	get_publisherAssertions
delete_publisherAssertions	get_assertionStatusReport

With the business assertions feature, one can model a large company as several separate businesses, each related to the other via a pair of assertions. Another useful scenario which can be modeled are cases of business partnerships or holding companies, etc. Customers can discover which businesses are related via the new inquiry APIs.

Another important feature which helps with modeling of a large company's organization is called Service Projections. An enhancement to the save_business API allows one business to save another’s service and binding templates as if they were its own. Projections essentially allow a reference to another businesses service. The creator of the projection cannot alter the actual service being referenced, but this feature is useful for cases where a common service of a company is offered by a number of different businesses.

Version 2 adds new support for publishing of categorization and identifier sets whose use can be controlled by the provider. This allows the provider to require use of its codes to be validated prior to allowing any business to save a reference to it in the registry. Operators use the validate_values API callout which providers of externally checked taxonomies must implement. Setting up an taxonomy for external validation requires mutual agreement between the validation service provider and the operator, but once in place, all operators honor the callout. It is also possible for operators to cache taxonomy values in order to accomplish validation without using the validate_values callout if both parties agree. The external validation capabilities offered by this scheme are flexible. External validation providers can use any criteria they choose to determine whether or not to approve a requested use of their taxonomy. Validators can do anything from simple checking that the code chosen is indeed valid, all the way to any sort of contextual check they desire, since the entire entity with which the taxonomy code is being associated is sent as part of the validation request.

A number of new search qualifiers have also been added in version 2:

orLikeKeys is particularly useful, because it enables pseudo complex queries. For example, one can find businesses located in the US, Mexico, or Canada which offer Cold Storage Shipping services or Generic Shipping services. This enables one to search for businesses that are categorized with different levels of specificity, while at the same time allowing a single inquiry to reference multiple different taxonomies.

orAllKeys reverses the default AND behavior of searches

combineCategoryBags effectively combines categoryBags of a business and all of its services.

serviceSubset is used with find_business to apply category search elements only to services within (or referenced by) the business.

andAllKeys provides default behavior in searches.

soundex supports an English only “sounds like” search on businesses, services or tModels

Some additional features for internationalization have also been added in version 2. The accommodation of multiple languages by adding support for multiple language-typed name elements has been added to both businessEntity and businessService entities. Internationalization of the address structure by referencing address type tModels is new as well. This provides flexible support for structured postal addresses.

5. Pulling it all Together - the Web Services Stack

UDDI fits into an overall Web Services stack and is a key component of its foundation, enabling the creation, specification, discovery, and invocation of web services:

UDDI builds on a network transport layer and a SOAP based XML messaging layer. Service Description languages, such as “Web Services Description Language” (WSDL) provide a uniform XML vocabulary for use in describing web services and their interfaces . One can then build upon this overall foundation by adding layered capabilities such as web service work flow descriptions using “Web Services Flow Language”, Security, Management and Quality of Service frameworks.

Design and Development by deepX Ltd.