Chapter: XML and Web Services : Building XML-Based Applications : Web Services Building Blocks: WSDL and UDDI

Introduction to UDDI

Universal Description, Discovery, and Integration (UDDI) is a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet as well as public registries of Web Services designed to store information about businesses and the services they offer.

Introduction to UDDI

If WSDL is The Empire Strikes Back, then UDDI is The Return of the Jedi, concluding the chapters on Web Services. Universal Description, Discovery, and Integration (UDDI) is a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet as well as public registries of Web Services designed to store information about businesses and the services they offer. UDDI is also a specification for building such registries as well as an application pro-gramming interface (API) that exposes the functionality of the registries. Fundamentally, UDDI provides for the publication and discovery of Web Services, which are the key functional components of the Service-Oriented Architecture explained in Chapter 14, “Architecting Web Services.”

The UDDI Consortium, established by hundreds of companies, emerged in response to a series of challenges posed by the new Web Services model. These challenges included the following:

How do you discover Web Services?

How should information about Web Services be categorized?

How do you handle the global nature of Web Services? How do you provide for localization?

How can interoperability be provided, both in the discovery and invocation mechanisms?

How can you interact with the discovery and invocation mechanisms at runtime?

For UDDI to provide the foundation for Web Services registries, therefore, it had to serve two primary roles within the Web Services model: Service publication and service dis-covery (shown in Figure 14.2 in Chapter 14). The rest of this chapter addresses how UDDI’s publication and discovery capabilities operate as well as how UDDI addresses the listed challenges.

UDDI Basics

Public UDDI registries are hosted by operator nodes, which are companies such as Microsoft and IBM that have committed to running public UDDI nodes. The public reg-istry system is loosely modeled after the Domain Name Service (DNS) system, in that there are multiple registries responsible for synchronizing their data with each other. Currently, each public UDDI node synchronizes with the others daily, but a more fre-quent schedule is in the works.

Likewise, as is the case with the DNS system, UDDI registries are not repositories of data; rather, in their roles as registries, they simply provide information on how to find and invoke Web Services. Just as the DNS system provides for unique domain names, UDDI relies on globally unique identifiers (GUIDs), which are URNs that uniquely iden-tify the resources in each registry.

There are three levels of information available in each UDDI registry, which correspond roughly to the features of a phone book:

White pages. These pages provide listings of companies that can be queried by name, text description, contact information, and known identifiers (like Dun and Bradstreet’s DUNS numbers).

Yellow pages. These pages allow for the looking up of companies by the kind of services they offer, organized into established business categories (industry codes, location, and products and services). These categories are organized into taxonomies.

Green pages. These pages provide information about how to interact with compa-nies’ Web Services by exposing service descriptions and binding information.

By accessing the appropriate “pages,” a service requester can obtain answers to the fol-lowing questions:

For a given industry, what Web Services interfaces have been published?

Which of those interfaces are based on WSDL?

Which companies have created implementations based on one of those interfaces?

Which Web Services in a particular category are available?

How does one contact a company about accessing the Web Services it publishes?

What are the specifics of binding to and invoking a given Web Service?

The Structure of UDDI

The XML schema that provides the structure of UDDI defines four core types of infor-mation in a UDDI registry, as shown in Figure 16.7:

Business information. Provided by the businessEntity element. The businessEntity element supports the “white pages” and “yellow pages” taxonomies, allowing for structured information about companies. This element is the top-level information manager for the information in the registry about a particular business.

Service information. Provided by the businessService element. This element supports the “green pages” functionality. The businessService structure contains a group of Web Services related to a category of services or possibly a business process. Each businessService element contains one or more technical Web Services descriptions, which describe how to find and bind to each of the Web Services.

Binding information. Provided by the bindingTemplate element, which is the ele-ment contained within the businessService element that provides the information needed to bind to and invoke a Web Service.”

Specifications for services. Enclosed within each bindingTemplate element are special elements that list references to information about specifications for ser-vices. These elements, called tModel elements (from “technical models”), are metadata about each specification, providing information on a specification’s name, publishing organizations, and URLs to the specifications themselves. tModel ele-ments have several uses within a UDDI registry, in particular, representing techni-cal specifications for wire protocols (such as SOAP), interchange formats (WSDL), and sequencing rules. Each specification registered as a tModel in a UDDI registry receives a unique GUID.

It is important to point out that UDDI actually has no direct support for WSDL—or any other service description mechanism, for that matter. Instead, UDDI uses tModel ele-ments to allow the specification of the service description mechanism to be flexible and independent of any single description language. At this time, however, WSDL is cur-rently the preferred description language for UDDI registries.

tModel Structure

Understanding tModel elements is critical to understanding how UDDI works, because they form the basis of how UDDI deals with the meaning of the various specifications it deals with. The concept of a tModel is necessarily somewhat nebulous, because tModel elements consist of metadata (data about data). tModel elements provide a reference sys-tem for UDDI registries that is based on abstraction (in other words, a tModel can define just about anything).

The primary use for tModel elements within UDDI is to represent a technical specifica-tion—for example, wire protocols (such as SOAP), interchange formats, and the like. When two parties wish to communicate using a particular specification, they must share a mutually agreed on technical identity for the specification they share. This technical identity can be registered in a tModel. Once such a specification is uniquely defined in this way, other parties can refer to it by referring to its unique tModel identifier, which is called a tModelKey. tModelKey elements act as “technical fingerprints” that uniquely designate individual specifications.”.

The other main use for tModel elements supports how UDDI handles its search capabil-ity. Searching, of course, is an essential part of UDDI’s “find” capability. Searching is provided for in UDDI with the use of two structures: identifierBag and categoryBag. The identifierBag structure defines organizational identity. It consists of name/value pairs that record and define identification numbers—for example, “DUNS number 12345” or “SS# 987-65-4321.” The categoryBag elements, on the other hand, are name/value pairs that correlate specific taxonomy information—for example, “Florists 45311” (from the NAICS taxonomy), “Massachusetts US-MA” (from the ISO 3166 Geographic Taxonomy), or “Boston 516499” (from the GeoWeb taxonomy). A particular florist in Boston, Massachusetts would possess all three of these categoryBag elements, as well as each identifier’s supercategories. The tModel, then, is used to correlate differ-ent levels of these hierarchies—for example, to express the relationship that Boston is within Massachusetts, or that florists are retailers.

tModel elements have the structure shown in Figure 16.8.

The name element is the only required element, and it’s searchable, whereas the description is not. The overviewDoc element references remote descriptions or other instructions related to the tModel. Finally, the identifierBag and categoryBag elements contain searchable name/value pairs that reference identification numbers and taxonomy information, respectively. An example of a tModel is shown in the following section).

Publishing and Finding WSDL Descriptions in a UDDI Registry

In order to understand how UDDI uses WSDL as a description language, you must be clear on how WSDL documents are mapped to the UDDI structure. As discussed earlier, WSDL documents can be organized as service implementation and service interface doc-uments. (Listing 16.2 shows a WSDL service implementation document, and Listing 16.3 shows the corresponding WSDL service interface.) The service implementation doc-ument maps to the UDDI businessService element, whereas the service interface docu-ment maps to the tModel elements, as shown in Figure 16.9.”.

The first step in publishing a WSDL description in a UDDI registry is publishing the ser-vice interface as a tModel in the registry. Here are the steps to follow to create the appro-priate tModel:

Set the name field of the tModel to the targetNamespace attribute of the definitions element in the interface document. This field is used to locate the appropriate tModel.

The description field of the tModel corresponds to the documentation element of the interface document. This field can have a maximum of 256 characters.

Set the overviewURL field of the tModel to the URL and binding specification in the interface document.

Set the categoryBag field of the tModel so that its keyed reference is uddi-org:types and its keyValue is wsdlSpec. This defines the UDDI entry as a WSDL service interface definition.

For example, if we take the interface document in Listing 16.3, we build the tModel in Listing 16.5.

LISTING 16.5 tModel.xml—A tModel Created from a WSDL Service Interface

<?xml version=”1.0”?> <tModel tModelKey=””>

<name>http://www.myclassservice.com/MyClass-interface</name>

Service interface definition for our demo Service. </description>

WSDL Service Interface Document </description>

<overviewURL> http://www.myclassservice.com/MyClass-interface#MyClass_ServiceBinding

</overviewURL>

</overviewDoc>

<keyedReference tModelKey=”UUID:DB77450D-9FA8-45D4-A7BC-9C8C7D998F8D” keyName=”Sample Web Service”

keyValue=”12345678”/>

</categoryBag>

</tModel>

Next, we must create the businessService and bindingTemplate elements that corre-spond to the WSDL service implementation document shown in Listing 16.2. The businessService has the following fields.”:

The name field of the businessService is set to the name attribute of the service element in the implementation document.

The description field of the businessService comes from the documentation element in the implementation document.

The bindingTemplate has the following fields:

The description field of the bindingTemplate comes from the first 256 charac-ters of the documentation element of the port element, if it exists.

The accessPoint field is set to the value of the location attribute of the exten-sion element that is associated with the port element, in the case of a SOAP or HTTP binding.

The bindingTemplate contains one tModelInstanceInfo field for each tModel it references.

The overviewURL field directly references the service implementation document; however, it is only used to provide human readability.

Putting these instructions together, we can build the UDDI b sponds to the WSDL interface document in Listing 16.2. The businessService appears in Listing 16.6.

LISTING 16.6 businessService.xml—businessService and bindingTemplate

Elements Created from a WSDL Service Implementation

<businessService businessKey=”...” serviceKey=”...”> <name>MyClass_Service</name>

IBM WSTK V2.4 generated service definition file </description>

<accessPoint URLType=”http”> http://localhost:8080/soap/servlet/rpcrouter

</accessPoint>

<overviewURL> http://localhost:8080/wsdl/MyClass_Service-interface.wsdl

</overviewURL>

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

<keyedReference tModelKey=”UUID:DB77450D-9FA8-45D4-A7BC-3663DA8D8CFB” keyName=”Sample Web Service”

keyValue=”84121801”/>

</categoryBag>

</businessService>

UDDI Invocation Model

Now that we can build a businessService and its various elements, let’s step through the process for using a UDDI registry to find and invoke a Web Service.”:

You use the UDDI business registry to locate the businessEntity information that was previously published by a company advertising a Web Service.

You either request more specific information about the businessService or request the entire businessEntity structure. This structure contains the relevant bindingTemplate information needed to connect to the service. You put this binding information into a cache.

You refer to the tModel key information in the bindingTemplate to obtain relevant information on the specifications needed to invoke the desired Web Service, and you use this information to write the program that will access the service.

The program invokes the Web Service using the bindingTemplate information that has been cached.

If the call to the Web Service fails, refresh the bindingTemplate information. If the new call succeeds, refresh the cache. Otherwise, keep trying.

By using cached binding information and taking a “retry on failure” approach, the UDDI registry infrastructure is not burdened by unnecessary calls but rather allows for seamless operation when binding information changes. This approach to scalability is quite similar to the way the DNS system works.”

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

XML and Web Services : Building XML-Based Applications : Web Services Building Blocks: WSDL and UDDI : Introduction to UDDI |