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:
- Provide a means to describe a Web service and make the description meaningful enough to be useful during searches.
- 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 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.
An Abstract-Namespace Reference
In Example 1, notice that a tModelKey is being referenced in the categoryBag structure of the credit-check tModel. This depicts the other usage of tModel, as an abstract namespace or taxonomy. The keyedReference structure holds a tModelKey, which contains a keyName and a keyValue. This refers to a value in a given namespace defined by the tModel, which is represented by its key. Think of it as referring to a node in a classification-scheme tree.
In Example 1, the credit-reporting service type is classified as a “wsdlSpec” type in the uddi-org:types (UUID:C1ACF26D…) taxonomy, as well as a credit-reporting service in a custom taxonomy. The uddi-org:types is defined as a pre-registered (canonical) tModel in the UDDI programmers specification. Therefore, it is always present in any UDDI registry and uses the same key. Also, the specification defines the valid values in the uddi-org:types taxonomy. The “wsdlSpec” type means that it has a WSDL document describing its protocol.
The various kinds of taxonomies could be used for identification or classification of all the data types in UDDI, as mentioned in the UDDI data model. The information about identification resides in a identifierBag structure, whereas the classification information resides in the categoryBag structure.
You have the flexibility to register and use new UDDI taxonomies based on your needs and according to the marketplace in which you operate. It is advisable to use standard, emerging taxonomies in your industry segment for classification, as more people become aware of these standard and use them to search for your service. Where one uses UDDI in a controlled company intranet, a new, internal taxonomy scheme is a helpful concept.
Identification
One of the features of UDDI registration data is to mark information with identifiers. The purpose of this is to allow others to find the published information using more formal identifiers, such as D-U-N-S® numbers, tax identifiers, or any other kind of organizational identifiers, regardless of whether these are private or shared.
For example, this concept is achieved for a businessEntity using a keyedReference structure referencing a tModel for the DUNS number, and storing the identifier in the keyValue. Example 3 shows a Organization using DUNS number for identification and offering Credit Check Service.
<businessEntity
businessKey="BBBBBBBB-BBBB-BBBB-BBBB-BBBBBBBBBBBB">
<name>Conso Finance Services</name>
<description xml_lang="en">Corporate Finance</description>
<businessServices>
<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>
<businessServices>
<identifierBag>
<keyedReference
tModelKey="uuid:8609C81E-EE1F-4D5A-B202-3EB13AD01823"
keyName="HPCU Credit Check company"
keyValue="DNB:34455 "/>
</identifierBag>
<categoryBag>
<keyedReference
tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"
keyName=" Credit Check agency in ntis-gov:naics:1997 "
keyValue=" 5223"/>
<keyedReference
tModelKey="UUID:CD153257-086A-4237-B336-6BDCBDCC6635"
keyName="Consumer credit gathering or reporting services"
keyValue="84.14.16.01.00"/>
</categoryBag>
</businessEntity>
Example 3: A businessEntity offering credit-checking services using Identification and Classification schemes.
Categorization
The UDDI registry is expected to grow in data size to millions of entities in its database. With such a large data set used for searches, it is likely that “simple” search mechanisms (with few criteria) would result in a large result set. For example, searching for all the retail merchants (using an industry code), would return a prohibitively large number of retailers. More likely, searching for all the retail merchants in a city and with a specific product code would help achieve a manageable data set.
Furthermore, name-based searches may not be advisable because naming conventions differ widely. To compound this problem, names can be registered in a different native languages.
This highlights the requirement to classify UDDI data. Various standard and custom categorizations schemes are present in the UDDI registry for this purpose. For example, schemes such as the Geo (uddi-org:iso-ch:3166:1999 tModel) taxonomy help a retailer specify its location, so that next time a search is done for a retailer in a specific town, you see this shop too. The other standard classification schemes present are the North American Industry Classification System (NAICS or ntis-gov:naics:1997 tModel) and the Universal Standard Products and Services Classification (UNSPSC unspsc-org:unspsc:3-1 tModel).
In Example 3 you see NAICS taxonomy being used to classify Conso Finance Services as a credit-check agency.
Putting It All Together
Taxonomies provide the most important mechanism in UDDI to help achieve more search-result occurrences for a service or business. When more classification is applied to a business or service, better search results will occur. This is much like having more keywords in an HTML page for the search engine to find. In fact, there is a pre-registered uddi-org:general_keyWords taxonomy, which is used to help register keywords associated with a structure in UDDI.
The standard taxonomies available in UDDI, like UNSPSC, Geo, and NAICS, help classify businesses and services in a standard, universally-known way. Because the UUID reserved for the standard tModels are same across all instances of a UDDI-compliant registry, a client program can use them uniformly across the various registries. The list of such standard tModels is mentioned in the UDDI Programmers Specification.
The standard identification schemes, like the D-U-N-S number, or Thomas Register Suppliers, are available as a standard tModel for self identification. Its usage helps Web-service applications find clients that know about company details such as the identification number in DUNS.
By understanding the details of how tModel structures are used throughout the hierarchy of UDDI data structures, a software developer can more effectively describe and categorize a company. In the end, this should help the company and its Web services become better utilized by client Web-service applications.
About the Author
Ravi Trivedi holds a Masters degree in Computer Science from the Indian Institute of Science, Bangalore. He is a Team Leader for the UDDI4j and UDDI team at Hewlett-Packard, Bangalore. He is an expert group member for HP in JAXR (JSR 93) and a committer for the UDDI4j project at www.uddi4j.org. He has been involved in developing core Web services infrastructures, such as UDDI and e-speak. He has been responsible for architecting and implementing some of the very first solutions in production using Web services. He can be reached at ravi_trivedi@hp.com.
