April 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

The Role of Taxonomies in UDDI: tModels Demystified

  • June 18, 2002
  • By Ravi Trivedi
  • Send Email »
  • More Articles »

Introduction

The Universal Description Discovery and Integration (UDDI) specification provides a platform-independent way of describing services, discovering businesses, and integrating business services using the Internet. UDDI is the building block which will enable businesses to quickly, easily, and dynamically find and transact with one another via their preferred applications.

The UDDI registry is to Web services what a search engine is to Internet data. The power of a search engine comes from associated keywords described in a Web page. Similarly, a fine-grain search for a particular type of Web service is possible only if the service is classified properly. Classification and identification taxonomies present in UDDI constitute a starting point for describing Web services. Just as important to software developers is a means to efficiently classify their businesses in a registry.

Taxonomies and identifier systems are crucial to UDDI. It is through categorization and identification that businesses are able to find each other and their appropriate services. UDDI Versions 1 and 2 cite three common categorization schemes to encourage registrants to categorize their businesses, services, and service descriptions. There are many newer taxonomies that are targeted at specific constituencies.

The UDDI data structure used to describe taxonomies is called a tModel. Although the tModel structure is a very important abstraction in UDDI, it is a concept that takes considerable time to understand for developers new to UDDI programming. This is because a tModel is used both to define a service's technical interface and as a taxonomy, or namespace, which specifies the categorization or identification scheme. This is also because tModel structures are referenced, unlike other structures which hold containment relationships, amongst themselves. This article will show the various uses of the tModel structure.

The UDDI Data Model

The basic information model used by UDDI consists of hierarchy of five basic data types. They are: publisherAssertion, businessEntity, businessService, bindingTemplate, and tModel. Figure 1 shows the relationship among these data structures.

Figure 1: The UDDI DataModel

As can be seen from the structure relationship, there is a containment relationship between the businessService and bindingTemplate structures, as well between as the businessEntity and businessService structures. This means that only one specific businessEntity structure, identified by its unique key value, will be used to express information about a specific instance of a businessService structure (also identified by its own unique key value). A businessEntity can have multiple businessService structures, but a businessService structure can only have one owner businessEntity.

On the other hand, the tModel structure is referenced from all the other structures. The tModel structure is referenced in various different roles from each of the data structures. This article will delve in depth into these roles. The businessEntity, businessService, tModel, and publisherAssertion refer to a tModel as a namespace, whereas the bindingTemplate refers to it as a service type. The interesting thing to notice is the use of tModel to refer to itself like a namespace for classification, or taxonomy.

The tModel Data Structure

The two important goals of UDDI are to:

  1. Provide a means to describe a Web service and make the description meaningful enough to be useful during searches.
  2. Provide a facility to make these descriptions useful enough to learn how to interact with a service that you don't know much about.

To do this, there needs to be a way to mark a description with information that designates how it behaves, what conventions it follows, or with what specifications or standards the service is compliant. Providing the ability to describe compliance with a specification, concept, or even a shared design is one of the roles that the tModel structure fills.

The first goal is met by using tModel as a namespace or taxonomy, while the second goal is met by its usage as the technical fingerprint.

The Technical Fingerprint or Service Type

When describing how a Web service is to interact with its clients, the specification information is stored in the tModel structure. The tModel is used as a service type in this role. An example might be a specification that outlines wire protocols, interchange formats, and interchange sequencing rules, as in RosettaNet Partner Interface Processes (PIP) and various Electronic Document Interchange (EDI) efforts. After standard protocol definitions such as these are registered as a tModel, services can express their compliance with them by referring to them in the bindingTemplate.

A common use of the technical fingerprint is referring to a Web service WSDL (Web Service Description Language) in the bindingTemplate. The Web Services Description Language (WSDL) is a general-purpose XML language for describing the interface, protocol bindings, and the deployment details of network services. In this case, the WSDL is the contract to which the service adheres.

For instance, in Example 1, a tModel is registered for a credit-check protocol. Notice that the tModel refers to a WSDL document, in the overviewURL, to describe the details of the protocol, or service type. Note that in UDDI, only the metadata is stored about businesses, services, and taxonomies, but never the actual data. In this case, the tModel points to the WSDL, rather than storing the WSDL itself.

Also note that the UDDI registry assigns a unique UUID (Universally Unique Identifier) to a tModel stored and shown as tModelKey. The UUID of the credit check report tModel appears as a attribute to the tModel node (UUID:AAAAAAA....).

<tModel xmlns="urn:uddi-org:api" tModelKey="UUID:AAAAAAAA-AAAA-AAAA-
AAAA-AAAAAAAAAAAA">
  <name>hp-com:creditcheck</name>
  <description xml:lang="en">Check limit reporter</description>
  <overviewDoc>
    <overviewURL>http://schema.com/creditcheck.wsdl</overviewURL>
  </overviewDoc>
  <categoryBag>
    <keyedReference
      tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6635"
      keyName="Consumer credit gathering or reporting services"
      keyValue="84.14.16.01.00"/>
    <keyedReference
      tModelKey="UUID:C1ACF26D-9672-4404-9D70-39B756E62AB4"
      keyName="types"
      keyValue="wsdlSpec"/>
  </categoryBag>
</tModel>

Example 1: A credit-check reporting service type specification.

If a service adheres to this service type, or WSDL, it can state this by referring this tModel in its bindingTemplate, as follows in Example 2.

<businessService
   businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB"
   serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC">
   <name>HPCU Credit Check</name>
   <bindingTemplates>
    <bindingTemplate
     serviceKey="CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC"
     bindingKey="DDDDDDDD-DDDD-DDDD-DDDD-DDDDDDDDDDDD">
     <accessPoint URLType="https">https://hpcu.com/creditcheck</accessPoint>
     <tModelInstanceDetails>
      <tModelInstanceInfo tModelKey="UUID:AAAAAAAA-AAAA-AAAA-AAAA-
AAAAAAAAAAAA"/>
     <tModelInstanceDetails>
   </bindingTemplate>
  </bindingTemplates
 </businessService>

Example 2: A credit-check reporting service implementation.

The service registered in Example 2 shows its compliance by referring to the tModelKey of the credit-check service (as in UUID:AAAAAAAAAA-... ...) in the tModelInstanceDetails structure. It also includes the accessPoint, which refers to the end point of the service, or the location where it can be accessed.





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel