UDDI

The Universal Description, Discovery, and Integration (UDDI) specifications provide a standardized way for businesses to discover each other over the Internet and find details of services provided. UDDI is a combination of White Pages (contacts, addresses, telephone numbers), Yellow Pages (listing by industry classification), and Green Pages (technical details of services offered). UDDI is indeed universal in scope, in that the services offered can be anything from a telephone number to a SOAP endpoint for a Web service.

Businesses that want to publish their details on the Internet can use either a Web interface provided by one of the public UDDI operators (currently IBM and Microsoft), or a programmatic interface from within their IT systems. Information published to one public UDDI repository becomes replicated to the other public repositories automatically.

UDDI also has great value behind the firewall in intranet environments. There are advantages to using Web services to connect internal systems, rather than implementation-specific protocols, such as RMI, CORBA, or DCOM. Web services are truly independent of vendor, platform, and language, and can minimize the pain of integration issues. An internal, private UDDI repository can then be used as a logically centralized database of these systems. This repository can be replicated across sites within the company using the same techniques as public UDDI repositories.

Web Services Fundamentals
Before we go into the details behind UDDI, it's important to have an understanding of two other standards - SOAP and WSDL.

The Simple Object Access Protocol (SOAP) specification provides an XML-based dialect for invoking Web services across Internet or intranet environments. The specification details a particular XML structure for making a request, including detailed rules on encoding different data types to ensure that SOAP implementations from different vendors are compatible. SOAP defines the structure of the message but, contrary to its name, isn't really a protocol. Instead, SOAP is usable with existing Internet protocols, such as HTTP and SMTP.

The Web Service Description Language (WSDL) is another XML-based specification that provides a format for describing the interface to a Web service. The WSDL file lists the operations, parameters and data types used by that service and is all a developer needs to write a client application that can use that Web service.

Although WSDL documents describe a programmatic interface to a Web service, they're not enough to enable Web services to be published or discovered over the Internet. UDDI is roughly equivalent to a DNS for Web services, allowing companies to change details about where services are hosted. Applications connecting to those services should always locate the service through UDDI first.

UDDI Basics
The UDDI specification provides four core XML data structures to describe a business and the services it offers:

• businessEntity
• businessService
• bindingTemplate
• tModel

The first three data structures are simple to understand. A businessEntity structure provides information about a business, such as the head office address. Each business entity can have multiple businessService structures associated with it - one for each service offered by that business. Each business service can have multiple bindingTemplate entries. The binding template represents the way that the business service is accessed. For instance, a binding template can represent a telephone number, a Web site, or a Web service.

Introducing tModels
All three of these data structures can have relationships with tModels, but the meaning of the tModel differs in each context. tModels are an abstract concept representing standards, specifications, and docu-ments. They're designed to be very general purpose so perhaps this is why they appear so confusing at first.

A tModel could be used to represent a taxonomy system such as the North American Industry Classification System (NAICS), which allows companies to be classified depending on the nature of their business activities.

Another use of a tModel is to represent a "service type" offered, such as a Stock Quote service. Table 1 shows the meaning of a tModel in different contexts.

What Is a Taxonomy?
A taxonomy is simply a classification system with a finite set of values. For instance, a geo graphic taxonomy such as ISO3166 allows classification of a business by its location.

Each taxonomy system is represented by a tModel and the classification of a particular entity within that taxonomy system is represented through use of the categoryBag structure, defined by UDDI. A categoryBag is a collection of keyedReference structures. Each keyedReference provides a name-value pair within the scope of the taxonomy system referred to by its tModelKey.

The XML fragment shown in Listing 1 demonstrates the use of the cate-goryBag and keyedReference structures within a businessEntity.

In this example, Cape Clear Software is categorized as "Software Publishers" within the NAICS taxonomy and "US" within the ISO3166 taxonomy. These taxonomies are referred to by their tModelKey references. When new tModels are registered, they're automatically given tModelKeys, which are guaranteed to be a Universally Unique Identifier (UUID).

tModel Categorization and Identification
In the previous section, we saw how business entities and business services can be identified and categorized according to taxonomies described by tModel structures. We've also seen how binding templates refer to a technical specification described in a tModel structure. We'll now look at how tModels themselves are identified and classified.

The UDDI specification provides some core tModels that must be supported in all UDDI repositories. These include standard industry classification and identification taxonomies, such as NAICS, UNSPC, and D-U-N-S. Another key tModel is one representing the "UDDI Types Taxonomy."

The purpose of the UDDI Types Taxonomy is to allow tModels to be classified according to their purpose. For instance, the NAICS taxonomy tModel is classified as a "categorization taxonomy" within the UDDI Types Taxonomy. Other valid values within the UDDI Types Taxonomy are "identifier" and "namespace." Table 2 shows the valid classifications within the UDDI Types Taxonomy.

Registering a Web Service
Now that we've covered the main structures within a UDDI entry, we'll look at a real-world example of publishing a Web service within UDDI. The example is that of an Airport Weather service that can provide weather information for international airports. As a starting point, assume the Web service has already been developed and there's a valid WSDL document to describe the interface to the service.

The first step is to create a "Service Type" tModel to represent the Airport Weather service. This tModel is the generic specification of the Airport Weather service and this allows for the creation of actual Web services (business service entries) that are classified as being of type "Airport Weather." This is the equivalent of the separation of interface and implementation in object-oriented languages, such as Java. Any business entity may register business services referring to this service type.

Because this Web service is based on WSDL, this tModel should be classified within the UDDI Types Taxonomy (uddi-org:types) as being of type "wsdlSpec." This implies that the overviewDoc within the tModel contains a URL pointing to the WSDL document describing the interface to the Web service. Without this classification, there would be no standardized way for consumers of the service to know where to find a definition of the interface.

Listing 2 is the resulting tModel for the Airport Weather service. It's listed in the public UDDI operator cloud and can be queried from either the IBM or the Microsoft Web site.

The next step is to list a business service to implement this tModel. The business service uses the bindingTemplate structure to reference the Service Type tModel (see Listing 3).

Software applications can make use of the UDDI Types Taxonomy to limit searches to Web services that are based on WSDL, as shown in this sample UDDI request:

<find_tModel xmlns="urn:uddi-org:api" generic="1.0" maxRows="1000">
<categoryBag>
<keyedReference
keyName="Specification for a web service described in WSDL"
keyValue="wsdlSpec"
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
</categoryBag>
</find_tModel>

Conclusion
UDDI provides a technical infrastructure for publishing details of Web services on the Internet for use by other companies, or on the intranet for use by other depart xments. UDDI will become the key integration point for products supporting Web services. Runtime products will expose their capabilities through UDDI and developer tools will use UDDI to find those services.

There are still many business issues to be addressed around the use of UDDI on the Internet, such as how to ensure the validity or usefulness of data registered and how businesses will agree on contractual terms for the use of these services. It's unlikely that technology alone will be able to solve these problems but UDDI does provide a good framework for enabling both human and programmatic interaction between organizations. In the short term, the use of private UDDI repositories within intranets is likely to play a bigger role in the proliferation of the Web services paradigm.

References

• UDDI specifications: www.uddi.org
• CapeScience UDDI repository (Web interface): www.capescience.com/uddi
• Cape Clear's public UDDI entry: http://uddi.microsoft.com/discovery?businessKey=5E4B4CDA-3448-4B88-ACE1-8584D43B7703