11. Chapter 11 UDDI: A Web Service

"Discovery consists in seeing what everyone else has seen and thinking what no one else has thought." -- Albert Szent-Gyorgi

In a world full of Web services, Universal Description Discovery and Integration, UDDI, becomes an extremely valuable component. As a service built into Windows .NET server, UDDI is also likely to become the de-facto standard Web services catalog within the enterprise. Therefore, to complete the Web services story, I will explain what UDDI is and the scenarios where applications can benefit from private as well as public UDDI implementations. I will focus on writing UDDI-enabled applications that communicate with UDDI as a SOAP-based Web service.

What is UDDI

On the surface, UDDI is a directory where businesses can register and search for Web services. However, digging a little deeper, you’ll find that there’s more to UDDI than simply directory information. UDDI is centered around the concept of a Web service interface which is typically described by a WSDL document.

As Web services become popular, it is likely that industries will define standard Web service interfaces that businesses can implement. The travel industry might publish standard interfaces for hotel rate checking and reservation then register those interfaces with UDDI. Hotels would then expose Web services that implement those interfaces and register their services with UDDI as shown in figure 11-1. A travel agency can then search UDDI to see whether Hilton Hotels exposes a Web service that implements the standard room reservation interface. When the travel agency finds the desired Web service in UDDI, it can begin communicating with that service immediately because the service implements a well-known hotel reservation interface. Hence business applications can be more easily integrated through implementing and programming against well-known standard interfaces.

Figure 11‑1

Organizations expose Web services that implement an industry-standard interface.

Ideally, a business application would find the Web services it needs and begin using. This would not require intervention from the end user except possibly for defining some criteria, such as business name or geographic location, that the Web services must meet. For this to happen, applications must be able to programmatically search a directory such as UDDI. In fact, UDDI is not designed to be searched by end users at runtime. Instead, UDDI exposes its data through a set of operations known as the inquiry API. UDDI also exposes the publishing API which can be used to register businesses and services with UDDI.

To ensure maximum interoperability, UDDI exposes its APIs as Web service operations. Therefore, you can think of the UDDI API as a live, production Web service that you can program against for publishing to and searching UDDI’s registry.

To summarize, there are two distinct features of UDDI that differentiate it from ordinary Web directories such as Yahoo!. First, every Web service registered with UDDI implements an interface that is also registered with UDDI. The interface might be defined by the same developer who built the Web service or by a standards organization. Second, not only can people (specifically developers) use UDDI at design time to find Web services and publish their services, applications can also use UDDI at runtime to programmatically locate and publish Web services.

What UDDI Is Made Of

Most people think of UDDI as a Web site or a Web service end point but there are several things that make up UDDI. This section breaks down UDDI into distinct parts and explains the role of each part.

UDDI Specifications

UDDI is a set of specifications with private and public implementations. UDDI provides two Web services: Inquiry and publishing. The inquiry Web service provides operations such as find_business and get_businessDetail. Similarly, the publishing Web service provides operations like save_business and delete_business. The operations provided by the inquiry and publishing Web services all use document/literal SOAP messages. These messages are documented and explained in the UDDI Programmer’s API Specification. The UDDI Data Structure Specification explains the input and output XML data structures used by the UDDI Web service operations. These data structures are also defined in the UDDI XML Schema.

UDDI Operators

UDDI operators are organizations that implement a UDDI registry and expose it via Web services according to the UDDI specifications. At the time of this writing, four organizations provide public UDDI V2 implementations: Hewlett-Packard, IBM, Microsoft, and SAP.

Each operator implements their own UDDI registry store which is replicated with other operator nodes so that the information you enter at one operator’s site can be queried from any other site. Each operator also exposes one or more Web service end points that provide the standard UDDI APIs as documented in the Programmer’s Specification. For example, Microsoft’s beta implementation of UDDI V2 inquiry APIs is exposed at http://uddi.rte.microsoft.com/inquire and the corresponding UDDI publishing APIs implementation is at https://uddi.rte.microsoft.com/publish.

Operators might also expose a Web user interface for humans to register with and search UDDI. Such operators Web UI’s are simply HTML front ends for a subset of the UDDI APIs and typically add no features beyond what’s available through the API.

You can see two examples of search user interfaces at Microsoft’s UDDI site (http://uddi.rte.microsoft.com/search/frames.aspx) and IBM’s site (https://www-3.ibm.com/services/uddi/v2beta/protect/find). All sites require registration in order to publish your business and Web services.

To register your business and services with UDDI, you pick an operator site, such as Microsoft and register with that operator to obtain user credentials in the form of a user id and password. These credentials apply only to the particular operator site with which you registered; credentials are not shared or replicated across operator sites. You then use these credentials to register your business and Web services. You can later edit your business and service registration at the same operator site where you registered. The changes you make will be replicated to other sites so that applications and users querying UDDI at any of the operator sites can view your information.

UDDI Registrars

Using UDDI’s publishing APIs, companies can set up public Web sites for registering with UDDI. These Web sites are known as UDDI registrars and typically add some value over the standard operator sites. For example, a registrar might specialize in registering businesses within a specific industry. A list of UDDI registrars can be found at http://www.uddi.org/solutions.html#registrars.

Private Implementations

Perhaps the most interesting aspect of UDDI is the availability of implementations that you can download and install for use within your intranet. A typical large organization with dozens of departments might have tens or hundreds of Web services scattered in various locations. Such an organization can benefit from a private, internal directory of Web services. Instead of reinventing the wheel, the organization might install a private version of UDDI. For example, IBM provides a private UDDI implementation that you can download and install while Windows .NET Server will include a built-in UDDI registry that organizations can use on their intranets. Whether you program against a private UDDI implementation or the public UDDI registry, the APIs (in the form of SOAP messages) you use are the same.

UDDI Usage Scenarios

This section explains at a high level some of the common UDDI usage scenarios. The objective is to give you the big picture of how and when UDDI can be used. Once you conceptually understand these scenarios, the next sections explain the details of programming UDDI. Please note that the diagrams in this section are not proper UML sequence diagrams. Instead of objects and operations, they show the interaction between client application, UDDI, and a third party Web service.

Finding closest business

I occasionally go to the local Kinko’s store to reproduce course manuals or other documents. When I first moved to my current house, I went to Kinko’s Web site and used their store locator to find the nearest store by zip code. Most people in the U.S. use the Web or their Yellow Pages to find the closest branch of a business. In many cases, the business itself is already known to the user, e.g. I used Kinko’s for many years before I moved to my current house, they just want to find the nearest branch.

In the world of connected applications, you might start seeing Windows applications that let you print directly to the nearest printing/copying store (call it Printers R Us) by sending the print file to the store’s Web service.

One of the issues posed by this scenario is that of finding the closest Printers R Us store. This is where UDDI can be useful. A client application can send a message to UDDI asking for a list of the closest Printers R Us businesses as shown in figure 11-2.

Figure 11‑2

Finding businesses that match some search criteria.

UDDI sends back a list of businesses and Web services that satisfy the client’s search criteria. The client application can then show this list to the end user and ask him or her to choose the specific branch to which they want to print. Once a branch is chosen, the client can begin interacting with that branch’s Web service and sending it the print file.

In this context, UDDI is acting as a smart Yellow Pages directory that can be used by applications rather than directly by end users. Notice that this scenario applies to Windows, Web, and any other types of client applications that can invoke a Web service. Applications on hand held devices, e.g. PocketPC, can also benefit from this smart Yellow Pages scenario.

The Invocation Pattern

This powerful usage scenario is straight out from the UDDI V2.0 API Specification. Here UDDI is used to solve the problem of invoking a relocated Web service. Commercial Web services could potentially have thousands of client applications that rely on the service being available. If the service’s end point were to move, all clients would have to be notified ahead of time to make sure they point to the new endpoint location when it’s ready. Coordinating such a move can be a logistical nightmare and things are likely to go wrong.

Alternatively, the Web service operator might create a locator Web service just to tell clients about the location of the real Web service. Client applications would then query this locator service at runtime to get the end point URL of the real service. However, this solution won’t work because now you have to worry about the locator Web service and what happens if you need to move it. What you need is a highly-available directory such as UDDI that can be used as a locator for your Web services.

Before moving your Web service, you edit the service’s UDDI registration to point to the new end point URL. At run time, a client application calls your Web service which might have been relocated. After receiving an error (e.g. 404 not found), the client sends a message to UDDI asking for the current service location as shown in figure 11-3.

Figure 11‑3

The UDDI Invocation Pattern.

UDDI responds with the new end point URL which the client then uses to invoke the Web service. Assuming the invocation works and the service responds, the client can cache the new URL locally (e.g. in a config file) for future use.

In this scenario UDDI acts as a readily-accessible, highly-available directory that can save you from a potential logistical nightmare.

Finding Trading Partners’ Services

Let’s say your company purchases a new business accounting application that supports electronic invoicing. The application is designed to send XML invoice documents to Web services that implement a hypothetical standard invoicing interface called Xinvoice. After installing the application, an accountant begins entering a list of current customers including each customer’s name and contact information. When entering a customer called Acme Autos, the accountant sees a button labeled “Send electronic invoices” and clicks it. The application then initiates a UDDI query asking for a business named Acme Autos that implements the standard Xinvoice interface as shown in figure 11-4.

Figure 11‑4

Finding trading partners’ services.

Assuming Acme Autos has registered a service that implements Xinvoice, UDDI responds with some information about the business and the service. The accounting application then issues another message asking for the details of the invoicing service (e.g. the end point URL) and UDDI responds with those details. The accounting application stores Acme Autos invoicing Web service’s end point URL in its local database for future use. At this point, the accounting application is ready to begin sending electronic invoices to Acme Autos.

Although the accountant could have obtained Acme Auto’s end point URL through other means (e.g. calling them or getting it from their Web site), UDDI does make it more convenient and takes away some of the friction involved in setting up ecommerce. Note that for this scenario to work, the accounting application must be programmed to invoke the Xinvoice interface and Acme Autos must implement this interface. The area of industry standard e-commerce messages and interfaces is still evolving and has a long way to go. On the short term, the above scenario is more likely to work if both trading partners install the same accounting package or compatible packages.

Registering Services

Going back to the electronic invoicing scenario, let’s examine how Acme Autos might have registered their services with UDDI. Acme Autos purchases and installs a commercial accounting application and proceeds to configure it. One of the configuration options is to receive invoices electronically. When the user chooses this option, the accounting application configures a Web service that implements the hypothetical Xinvoice interface. The client application then asks whether this service should be known to the public. Assuming the user answers “yes”, the application sends a message to UDDI asking to register Acme Autos as a business (assuming it was not already registered). The invoicing service can be registered as part of the same request message or can be registered in a subsequent request as shown in figure 11-5.

Figure 11‑5

Registering a business and a service with UDDI.

A common objection to this model that I frequently hear from my students is that of publicly exposing business services. The objection centers on the security threat that this might pose. Personally, I don’t believe that security by obscurity is a good long term strategy. Instead, we must think about security risks and address those via a combination of technologies and proedures. Today, the Web is routinely used for sensitive transactions such as e-commerce and bank account management. As recently as 1996, most people did not feel the Web would ever be sufficiently secure for banks to post customer’s account statements or stores to accept credit card numbers. A lot has changed since then and its likely the same will happen with Web services.

Publish/Subscribe Pattern

When you think of a typical Web service, you think of one Web service and many clients invoking it. This is certainly the most common scenario, but turning this scenario on its head makes for an interesting model that is useful in many applications[1]. Consider a retail company that has many stores spread across the country and possibly the world. The company’s headquarters would like to send current merchandise prices daily to each store location. In a real-world scenario, the stores might have different applications (perhaps some stores were acquired in a business merger) and some might have different versions of the same application. In most cases communicating with all stores, including new ones as they are opened is not an easy task.

Web services can help by easing the application integration aspect of the problem. Headquarters defines a Web service interface called RetailPricing. Each store then exposes a Web service that implements this interface. To push information out to stores, headquarters writes a client application that invokes each store’s Web service sending it current pricing information as shown in figure 11-6.

Figure 11‑6

The publish-subscribe Web services scenario. Branches subscribe by exposing a Web service that implements a pre-defined interface.

For the client application to find all store Web services, it consults UDDI. At runtime, the client asks UDDI for a list of services that implement the RetailPricing interface (assuming HQ already registered this interface with UDDI). As each new store comes online, it simply registers its interface with UDDI and the next time the client runs it will automatically find the new store and push pricing information to it as shown in figure 11-7.

Figure 11‑7

UDDI and the publish/subscribe scenario.

This pattern can be effective in many scenarios where an application needs to push content to many “subscribing” applications. Instead of managing subscribtions yourself, you rely on UDDI to manage them for you.

Main Data Structures

Information registered with UDDI is represented by XML documents containing structures described in UDDI’s XML Schema[2]. There are four key data structured core to most UDDI usage scenarios. Figure 11-8 shows these four structures and two additional structures and the relations between them.

Figure 11‑8

The main UDDI data structures.

The businessEntity data structure is used to represent a business or, more generally, a service provider. Each businessEntity may contain services represented by businessService structures. A businessService contains bindingTemplates which point to tModel structures (more on this later). Businesses might be related (e.g. a parent-child business relation) using publisherAssertion structure. Listing 11-1 shows part of the UDDI XML Schema which contains the formal definitions of the above XML structures.

Listing 11‑1 XML Schema types and element declarations for the main UDDI data structures. (VBWSClientCode\Chapter11\UDDISchemas\uddi_v2.xsd).

<element ref="uddi:description"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

<attribute name="businessKey"

use="required" type="uddi:businessKey"/>

</complexType>

<element ref="uddi:description" minOccurs="0"

maxOccurs="unbounded"/>

</sequence>

<attribute name="serviceKey"

use="required" type="uddi:serviceKey"/>

<attribute name="businessKey"

use="optional" type="uddi:businessKey"/>

</complexType>

<element ref="uddi:description" minOccurs="0"

maxOccurs="unbounded"/>

</choice>

</sequence>

<attribute name="serviceKey" use="optional"

type="uddi:serviceKey"/>

<attribute name="bindingKey" use="required"

type="uddi:bindingKey"/>

</complexType>

<element ref="uddi:description" minOccurs="0"

maxOccurs="unbounded"/>

</sequence>

</complexType>

businessEntity

Each business registered with UDDI is represented via a businessEntity data structure. Think of this entity as the starting point for your relationship with UDDI: When you publish your services to UDDI, you start by publishing a new businessEntity. Similarly, when searching UDDI, many of the inquiry APIs search a specific businessEntity.

Figure 11-8 shows the businessEntity structure and its contents and listing 11-1 shows the corresponding XML Schema complex type definition. Listing 11-2 shows an example businessEntity structure from Microsoft’s UDDI v2 implementation.

Listing 11‑2 An example businessEntity structure.

<businessEntity

businessKey="677cfa1a-2717-4620-be39-6631bb74b6e1"

operator="Microsoft Corporation" authorizedName=" Yasser Shohoud : 86">

http://uddi.rte.microsoft.com/discovery?businessKey=677cfa1a-2717-4620-be39-6631bb74b6e1

</discoveryURL>

</discoveryURLs>

<name xml:lang="en">LearnXmlWS: The Resource for Web Service Developers</name>

<description xml:lang="en">An online community for developers of Web services and Web service applications. Read articles, download code, and ask questions pertaining to Web services. Created by Yasser Shohoud.

</description>

<businessService

serviceKey="d8091de4-0a4a-4061-9979-5d19131aece5"

businessKey="677cfa1a-2717-4620-be39-6631bb74b6e1">

<name xml:lang="en">The Weather service</name>

Returns the current weather conditions for a given zip code

</description>

<bindingTemplate

bindingKey="942595d7-0311-48b7-9c65-995748a3a8af"

serviceKey="d8091de4-0a4a-4061-9979-5d19131aece5">

http://www.LearnXmlWS.com/services/weatherRetriever.asmx

</accessPoint>

<tModelInstanceInfo

tModelKey="uuid:42fab02f-300a-4315-aa4a-f97242ff6953">

http://www.learnxmlws.com/services/weatherretriever.asmx?WSDL

</overviewURL>

</overviewDoc>

</instanceDetails>

</tModelInstanceInfo>

</tModelInstanceDetails>

</bindingTemplate>

</bindingTemplates>

</businessService>

</businessServices>

</businessEntity>

Each businessEntity is uniquely identified by a UUID (Universally Unique Identifier) called a businessKey. The operator assigns this businessKey to the businessEntity when it’s published. The publisher also optionally saves the name of the person who published the businessEntity in the authorizedName attribute.

A businessEntity may have one or more discoveryURL elements which contain URLs that point to discovery documents. In this context, the name “discovery document” has nothing to do with Web services, it is simply a document that provides information about the business itself. When you register a new business, the operator will automatically add to it a discoveryURL that points to the businessEntity information on that operator’s node. For example, if you open Internet Explorer and navigate to the discoveryURL from listing 11-2, http://uddi.rte.microsoft.com/discovery?businessKey=677...e1 [3], you will get back an XML document that contains the LearnXmlWS businessEntity definition like the one in listing 11-2. You can also add your own discovery URLs, perhaps a link to your company’s home page or some other document that provides more information about the business. To help differentiate the types of URLs, the useType attribute can be set to a value that identifies the type of document returned by the discovery URL. UDDI defines only two useType values: businessEntity and businessEntityEx. When useType is businessEntity, it means that navigating to the discovery URL will get you an XML document that contains a UDDI businessEntity structure. Similarly, when useType is businessEntityEx, the discovery URL will get you an XML document that contains a UDDI businessEntityEx structure. businessEntityEx is similar to businessEntity but allows third parties to extend it by adding their own XML elements to the structure.

Each businessEntity will also have one or more name and zero or more descriptions. Multiple names and descriptions are allowed to support multiple languages. If multiple names are specified, each must have an xml:lang attribute indicating the language used and each must be in a unique language, i.e you cannot specify two names in the same language. The same language rules apply to description. Note that businessEntity names need not be unique across all businessEntities, so its likely that some businesses registered with UDDI will have the same name. businessKey is considered the only unique identifier for a businessEntity.

A businessEntity may optionally contain a contacts structure used to hold contact information such as mailing address, phone, and email[4]. A contacts structure can contain multiple contact structures for different uses such as technical support, sales, investors, etc.

identifierBag and categoryBag are two data structures used to add identification and categorization information to a businessEntity. I will explain these structures in more detail later in this chapter. for now, keep in mind that identifierBag is a structure used to add identification information such as a Federal Tax Id or a D-U-N-S number to the business. Similarly, categoryBag is used to categorize or classify the business for example, a categoryBag might categorize the business as being a retail or travel business. Both identifierBag and categoryBag are optional, e.g. the example in listing 11-2 does not have either.

businessService

A businessEntity may contain zero or more businessService structures which are used to describe services provided by the businessEntity. In this context, the word service does not necessarily mean Web service, it could be anything. If you browse UDDI, you’ll find services ranging from SOAP-based Web services, to HTML Web pages to fax and telephone numbers. Although UDDI does not stipulate that a businessService has to be a Web service, for the purpose of this chapter I will focus only on businessServices that are SOAP-based Web services.

A businessService is uniquely identified by a serviceKey which is an auto-assigned UUID. Each businessService also has one or more names and zero or more descriptions that work in the same way as the businessEntity’s name and description. An optional categoryBag may be included to categorize the businessService.

bindingTemplate

To describe the technical aspects of the Web service, each businessService contains zero or more bindingTemplate structures. A bindingTemplate defines such technical information as the service’s interface and end point URL. Each bindingTemplate is uniquely identified by an auto-generated UUID stored in bindingKey. The optional description elements work in the same way as description elements in other UDDI structures.

Each bindingTemplate must contain either an accessPoint or a hostingRedirector element as indicated by the <choice> element in listing 11-1. An accessPoint element contains the URL where the service can be accessed with the type of URL indicated by the URLType attribute. URLType values can be mailto, http, https, ftp, fax, phone, or other. For SOAP-over-HTTP services, you only care about http and https. Note that you must include the protocol prefix (e.g. http:// ) in the URL contained in accessPoint. Omitting the http:// prefix is a common error when registering services with UDDI.

If a bindingTemplate does not contain an accessPoint element, it must contain a hostingRedirector element which points to another bindingTemplate. For example:

A bindingTemplate that contains a hostingRedirector is essentially saying “don’t use me, rather go find the bindingTemplate identified by this bindingKey and use that instead”. This feature is useful when you want the technical information of one service to be utilized by other services that “link” to it via the hostingRedirector. The name hostingRedirector indicates one scenario where this feature might be useful: If the service is hosted for you by some other organization you might want to allow that organization to control the bindingTemplate information such as accessPoint. So when you register your service you add to it a bindingTemplate with a hostingRedirector that contains the bindingKey for the appropriate bindingTemplate maintained by your host.

tModel

UDDI’s tModel reminds me of XML namespaces: Both are equally simple and equally confusing to many developers. It is not clear what the word tModel stands for, could be technical model or type model. But that’s not important, what’s important is what tModel is and how it’s used.

A tModel is a general purpose data structure for linking to metadata outside of UDDI. The most important content of a tModel structure is a URL to a document that provides more information on this metadata. This document can be anything, maybe an HTML page, a Word document, or a WSDL document, depending on what exactly the tModel describes. I know this is not a concrete definition, but this abstract nature of the tModel is what makes it so versatile that it is used in various places in UDDI today and is extensible to meet future needs.

tModels as Service Types

Making tModels concrete always helps people understand them better so I will explain the specific use of tModels for defining service types. Listing 11-3 shows an example tModel I registered with UDDI to describe the interface of my WeatherRetriever Web service.

Listing 11‑3 An example tModel that represents the WeatherRetriever service type (i.e. service interface)

<tModel

tModelKey="uuid:42fab02f-300a-4315-aa4a-f97242ff6953"

operator="Microsoft Corporation"

authorizedName=" Yasser Shohoud : 86">

<name>Weather Service Interface</name>

Standard interface for Web services providing current weather information

</description>

The Weather service's WSDL document

</description>

http://www.learnxmlws.com/services/ifaces/weatherretriever.wsdl

</overviewURL>

</overviewDoc>

<keyedReference

tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"

keyName="Specification for a web service described in WSDL"

keyValue="wsdlSpec"/>

<keyedReference

tModelKey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2"

keyName="On-Line Information Services"

keyValue="514191"/>

</categoryBag>

</tModel>

tModels are top-level data structures in UDDI meaning they are not contained in a businessEntity. Each tModel is uniquely identified by its tModelKey which is an auto-assigned UUID. A tModel also has a name and zero or more description elements with different languages. The overviewURL element contains a URL pointing to a document that describes the Web service’s interface. When I registered this tModel, I entered the URL to a WSDL document that describes the WeatherRetriever’s service interface. overviewURLs don’t have to point to WSDL documents, anything that describes the Web service interface is allowed. Practically, however, you should point to a WSDL document since WSDL is becoming increasingly popular and many development tools, including Visual Studio .NET, rely on WSDL documents to create Web service proxies. Note that the WSDL document you point to here does not need to have a <service> or <port> definition. That is, it is only used to define an interface, not to specify where implementations of that interface are located. The bindingTemplate’s accessPoint can be used to specify the actual service location.

The tModel in listing 11-3 contains a categoryBag which is used to categorize the tModel. I’ll defer explanation of this categoryBag contents until after the section on categorization later in this chapter.

Ignoring the categoryBag for now, the tModel in listing 11-3 becomes just a way to point to the WeatherRetriever’s WSDL document which describes the service interface. Again, please note that the weatherretriever.wsdl document does not need to contain the Web service location, only the interface definition.

tModel as meta data

Besides their use as service types, tModels are also used to hold meta data about business and services registered with UDDI. Imagine you were designing a relational database to store business information. You might create a business table with name, description, and other columns. If you wanted the database to be extensible so that any other business properties could be stored, you might create a table called keyedReference with two columns called keyName and keyValue as shown in figure 11-9. Database users could then use this table to store additional information about their businesses. For example, to store the business’s Federal Tax Id, I could add a row in keyedReference with the following values:

keyName=Federal Tax Id

keyValue=999-99999

Figure 11‑9

An example keyedReference table in a relational database.

This approach allows flexibility but has a serious issue. It relies on all persons or applications entering data to use consistent names. For example, another user might enter their business’s Federal Tax Id like this:

keyName=Id

keyValue =8811-888888

Looking at this record you’d have no idea that this was a Federal Tax Id. To solve this problem, you might create a table called tModel with columns called name, description, overviewDoc and tModelKey which is a unique identifier (the primary key). This table would hold a record for each unique property type that users want to add to the database. For example, it would hold a record for the Federal Tax Id property type:

name = Federal Tax Id

description=The business’s federal tax identifier

tModelKey=4771063B-2499-41f0-BE59-786DCE3E42F4

overviewDoc=link to the IRS web site where they explain tax ids

To describe records in the keyedReference table as holding Federal Tax Ids, you would add a foreign key to keyedReference and point to the above tModel record. Figure 11-10 shows the resulting keyedReference and tModel tables.

Figure 11‑10

A tModel table and a keyedReference table with a one-to-many relation.

In this context, the tModel table is used to hold meta data about records in the keyedReference table. This is exactly how UDDI uses tModels for meta data. To ensure UDDI can be extended to hold information beyond what’s defined in the standard data structures, UDDI uses a data structure called keyedReference. This structure contains a keyName, keyValue and tModelKey attributes exactly like the keyedReference table in figure 11-10. keyedReference is used in places where extensibility is needed for example in publisherAssertions, categoryBag, and identifierBag all of which will be covered in later sections.

This usage of tModels is similar to how XML namespaces are used in XML documents: A tModel provides context to a piece of information and an XML namespace provides context to an XML element or attribute. Since UDDI information is exposes as XML, the question then is: Why not provide context by using XML namespaces as qualifiers for the key names? tModels are better for this application because they can contain rich information such as name, description, and a link to an overview document that provides the reader with more information on what that tModel describes. In addition, because each tModel has an auto-assigned tModelKey, it is easier to ensure that tModelKeys are unique than trying to ensure that user-entered XML namespaces are unique.

tModelInstanceInfo

Going back to the diagram in figure 11-8, you’ll see that each bindingTemplate may be associated with zero or more tModels and a tModel may be associated with zero or more bindingTemplate. To manage this many-to-many relation, a data structure called tModelInstanceInfo is used. Listing 11-4 shows the XML Schema for tModelInstanceInfo and instanceDetails.

Listing 11‑4 tModelInstanceInfo and instanceDetails schema. (VBWSClientCode\Chapter11\UDDISchemas\uddi_v2.xsd).

<element ref="uddi:description"

minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>