The Role of Taxonomies in UDDI: tModels Demystified, Page 2
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.
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 xmlns="urn:uddi-org:api" 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.
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 firstname.lastname@example.org.