Universal Discovery with UDDI

Universal Discovery with UDDI

In the summer of 2000, Microsoft, IBM, and Ariba got together and created a new standard for discovering Web services. The result was UDDI: Universal Description, Discovery, and Integration. UDDI is several things:

• A federated and open database

• A standard SOAP interface for querying and submitting information

• A repository that includes custom metadata for querying and finding Web services

UDDI enables companies to register their electronic services—everything from an e-mail address for technical support to XML-based Web services for purchasing. They can do this from a Web page or by programmatically using the UDDI interface. The information is then replicated to IBM, Microsoft, and several other database providers that run UDDI registries. Then, anyone who needs to query for these services (again, either from a Web page or programmatically) can do so using any of these registries.

UDDI is part of Windows in the .NET Server release. You can set up your own UDDI server internally within your enterprise. Often, you may need the ability to centrally store and search for services that your company offers internally, especially if you work for a large company. UDDI within Windows allows you to do so very easily. So, what makes up UDDI? How are the parts integrated? Even more important, how do WS-Inspection and WSDL integrate with UDDI?

The Anatomy of UDDI

There are two large pieces to UDDI, and one smaller piece. The larger pieces are:

• The data format

• The API for querying and submitting

Just as important, but not as critical for everyone to know, is the replication API. UDDI registry operators need to follow a standard API for replicating their data to the other registries. Because that is a highly specialized technology, I've omitted it from this book. However, I will say that if you need to learn how to replicate data, then you still need first to learn the data format and API. For further information, refer to the UDDI API documentation at www.uddi.org.

It's important to understand some design points of UDDI. Most important is the use of relational data references using GUIDs (Globally Unique Identifiers). This makes itself apparent in the way in which information is fanned out across multiple structures, and then related using references.

More than two dozen data structures exist in the UDDI specification; therefore, covering them all would turn this book into a reference. What we should look at are the major data structures, and there are five very important ones, each with its own sub-elements:

• businessEntity— Contains information about a specific business, such as Microsoft.

• businessService— Contains information about a specific electronic service offered by a specific company.

• tModel— Categorizes a type. A service may contain multiple types.

• bindingTemplate— Collects tModels and other specific information about a service.

• categoryBag— Collects name–value pairs for a general categorization. businessEntity.

The following sections discuss businessEntity, businessService, and tModel in greater detail.

businessEntity

The businessEntity type holds information about specific businesses. Of course, there is no requirement that these documents precisely correspond to a single business entity. They could correspond to corporate entities, such as subsidiaries or corporate divisions.

This structure contains the following main pieces of information:

• businessServices— The service that this entity hosts

• categoryBag— A generic bag of names and values for properties that this entity has

• identifierBag— Similar to the category bag, a set of name–value pairs for generic information about the business entity

• contacts— A list of people to contact

• discoveryURLs— The location of documents that contain more information

businessService

The businessService document holds information about a specific service for a particular service. It contains the following data:

• serviceKey— A GUID that uniquely identifies the service

• name— A friendly, human-readable name for the service

• description— A human-readable description of the service and what it offers

• bindingTemplates— A set of properties that define the taxonomy of the service

• categoryBag— A generic name–value pair that helps to define the categories to which the service belongs

Here is an example of a businessService document:

<businessService 
     businessKey="some GUID here" serviceKey="some GUID here">
     <name>Keith's Service</name>
     <description>This service doesn't do anything</description>
     <bindingTemplate>
          ...
     </bindingTemplate>
</businessService>

tModel

The tModel is the hardest to understand and most misunderstood data structure in the UDDI Schema. It's actually very simple, but extremely powerful. A tModel is a technology model; it's a type. In other words, it's a generic keyed reference to something.

Arguably, this incredible flexibility makes tModel harder to use. But it enables us to describe all kinds of things, and then link them to all kinds of other things. (Notice that I have to use the vague word thing because of this abstraction and flexibility.)

With UDDI, tModels can have many different purposes, but one stands out in my mind: to reference Web service features in a transparent and generic fashion. I can create separate tModels for services that implement transactions, that implement reliable messaging, and that are described by WSDLs. I can then attach all of the tModels that apply to any of my individual Web services. Even better, I can search for services based on those tModels!

The tModel structure contains the following information:

• tModelKey (technical model)

• name— The friendly, human-readable name of the service

• authorizedName

• operator

• description(s)— A description of the tModel

• Idbag— A set of identifying name–value pairs

• category bag— A series of categories to which this tModel belongs, expressed as a set of name–value pairs

Listing 11.1 shows a sample of what a tModel can look like.

A tModel Structure in the UDDI Schema

<tModel
     xmlns="urn:uddi-org:api"
     tModelKey="UUID:1111111-1111-1111-1111-1111111">
       <name>KeithBa.Com:PurchaseOrders</name>
       <description xml:lang="en">
             Purchase orders services
       </description>
       <overviewDoc>
              <overviewURL>http://keithba.com/po.wsdl</overviewURL>
       </overviewDoc>
       <categoryBag>
               <keyedReference
                 tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
                 keyName="types"
                 keyValue="wsdlSpec"/>
       </categoryBag>
 </tModel>

Programmer's API

In addition to defining a series of data structures, UDDI defines how to interact with those data structures—in other words, how to use them with SOAP. There are two major sets of APIs within UDDI:

• Inquiry Operations— For searching for information

• Publisher Operations— For saving, editing, and deleting information

Inquiry

The piece of UDDI used the most is the set of inquiry operations, often called the inquiry API. Inquiry operations with UDDI take two basic forms: browsing operations and retrieval operations.

Browsing operations are used to find something. You use them as broad-based queries to figure out what you want. All of these operations start with the pattern "find_XXX", where XXX is something specific, such as find_business or find_service.

Typically, you would use these operations to find something when you don't know specifically what you are looking for. For example, to find a service, you may send a string that represents part of the name. Any services that match the string pattern would be returned. These operations are like search engines.

There are only four operations in this category of UDDI operations:

• find_binding

• find_business

• find_service

• find_tModel

Once you know what you want, you can use the drill-down information retrieval operations to get all of the details you need about a specific business or service. These operations require specific UUIDs (Universally Unique Identifiers) that you probably will get via the browsing "find" operations. They all follow the pattern of "get_XXX," where XXX is the specific information you need. Using Microsoft's UDDI SDK, you can easily use these find operations:

Inquire.Url = "http://uddi.rte.microsoft.com/inquire"; 
FindBusiness findBusiness = new FindBusiness();
findBusiness.Names.Add("KeithBa");
BusinessList list = fb.Send();

There are five retrieval operations:

• get_bindingDetail

• get_businessDetail

• get_businessDetailExt

• get_serviceDetail

• get_tModelDetail

And again, the UDDI SDK from Microsoft makes it easy to call these:

Inquire.Url = "http://uddi.rte.microsoft.com/inquire"; 

FindBusiness findBusiness = new FindBusiness();
findBusiness.Names.Add("KeithBa, inc.");
BusinessList list = findBusiness.Send();

if (list.BusinessInfos.Count > 0)
{
      GetBusinessDetail gb = new GetBusinessDetail();
      gb.BusinessKeys.Add(bizList.BusinessInfos[0].BusinessKey);
      BusinessDetail bizDetail = gb.Send();
      if (bizDetail.BusinessEntities.Count > 0)
     {
          //do something interesting
     }
}

WSDL and UDDI

UDDI offers a way to store abstract WSDL documents (WSDLs that don't point to a specific service, but instead can be implemented by any number of services), as well. Actually, it provides for a specific tModel structure to which each businessService can point.

The basic idea is that it is possible to create WSDL documents that are abstract. Technically, almost any WSDL that is missing a service element and the child port pointing to a specific address is abstract. In practice, the UDDI binding is for abstract WSDLs that are described down through the binding section. Of course, nothing prevents you from using the true point of abstraction in a WSDL: the portType section.

Once you've defined this abstract WSDL (e.g., as part of a standards organization), you can then create a tModel in UDDI that references this WSDL. The important part to remember is that there must be a keyed-Reference to the tModelKey that represents abstract WSDLs.

Also, the overiewURL element should point to the WSDL file. Listing 11.2 shows an example tModel.

A tModel That References a WSDL Document

<tModel tModelKey="UUID:1111111-1111-1111-111111">
     <Name>Standard WSDL for AutoParts</Name>
     <OverviewDoc>
       <overviewURL>http://autoparts.org/autoparts.wsdl</overviewURL>
     </OverviewDoc>
     <categoryBag>
          <keyedReference
               tModelKey="uudi:C1ACF26D-9672-4404-9D70-39B756E62AB4"
               keyName="uddi-org:types"
               keyValue="wsdlSpec"
          />
     </categoryBag>
</tModel>

Now, you can reference this tModel from other tModels or (more likely) from businessService entries that represent specific implementations of this WSDL.