|
This article is based on the UDDI chapter in Building Web Services
(Sams), a book I've written with Doug Davis, Steve Graham, Yuichi
Nakamura, and Ryo Neyama from IBM, Toufic Boubez from Saffron
Technology, and Glen Daniels from Macromedia. It's scheduled for
release early next month.
Moving from the introduction to the UDDI information model and APIs in last month's XML-J
(Vol. 2, issue 10), this month we'll take a detailed look at the UDDI
categorization and classification mechanisms and the magic of UDDI tModels.
One of the main objectives of the UDDI registries is the
discovery of services, whether statically (design time) or dynamically
(runtime). This entails a form of search through a large space of
entries. In a reasonably populated registry, depending on the search
mechanism, this could return a very large set of hits. An early
requirement for UDDI therefore was a way to perform intelligent
searches. Until we get closer to a truly Semantic Web, the best
mechanism to facilitate such searches will continue to be through
property-based lookup and taxonomic categorization and classification.
Property-Based Lookup
The simplest type of search involves looking through sets of value
spaces. For example, you may want to look for "470-25-4383" in the
space of Social Security Numbers (SSNs). Or you may want to look for
02140 in the space of U.S. zip codes. In both cases the result of the
search will be a set of entities (a person with the given SSN or all
addresses in the 02140 zip code area).
Formalizing the notion of property-based search is relatively
easy to do. We need a mechanism to attach any number of properties to a
piece of data. Properties need to have names and values. So far so
good.
The only complication has to do with supporting a naming
system that allows for precision and extensibility without introducing
much complexity. Precision of naming has to do with the ability to
identify the precise meaning of a property name. Take, for example, a
property whose name is name.
Is this a company's name, a person's name, or the name of a country?
XML has addressed this problem for element names with the introduction
of namespaces. Namespaces aren't unique to XML. They're extensively
used in other areas such as programming languages to provide specific
meaning to simple names. Namespaces allow us to distinguish between the
property "name" in the company namespace and the property "name" in the
personal information namespace.
In UDDI properties are called identifiers. Most UDDI data
structures can support any number of properties inside an identifierBag
element. The properties are represented by keyedReference elements that
have three attributes:
- keyName (required): Name of property
- keyValue (required): Value of property; can be any string
- tModelKey (optional): Universally unique identifier (UUID) of property name namespace that name of property belongs to; the tModel concept will be detailed later
Following is an example of a property identifying a company's Dun & Bradstreet D-U-N-S number:
<identifierBag>
<keyedReference keyName="DUNS" keyValue=
"00-111-1111" tModelKey="UUID:8609C81E-
EE1F-4D5A-B202-3EB13AD01823"/>
</identifierBag>
In this example the key UUID:8609C81E-EE1F-4D5A-B202-3EB13AD01823 identifies the space of the D&B D-U-N-S numbers.
Simple property-based searching is easy to do, but it lacks the
power to express search constraints that have to do with subselection
and membership to multiple categories. For example, if a business
manufactures skateboards, it is a manufacturer in the general sense of
the term and a manufacturer of light equipment and of sporting goods
and of skateboards. To navigate these types of concepts we need
category-based search.
Categorization and Classification
Categorization is the process of
creating categories, while classification
is the process of assigning objects to these predefined categories.
There are many types of classification schemes. For large information
spaces such as businesses and the services they expose, the most useful
classification models are hierarchical in nature. UDDI includes in its
core specifica-tions three predefined classification schemes:
- North American Industry Classification System (NAICS) for classifying businesses by industry
- Universal Standard Products and Services Classification (UNSPSC) for product and service classifications
- ISO 3166 standard for geographic location classifications
In order to support category-based search, we need to classify items in
the search space. We can do this by associating data with the "nodes in
various categories" it conceptually belongs to. In UDDI this is done
through the categoryBag element. The structure of categoryBag is
identical to that of identifierBag: a set of keyedReference elements.
In this case, however, the attributes of keyedReference are used in a
different way:
- keyName: Name of category
- keyValue: Value of category according to categorization hierarchy
- tModelKey: UUID identifying categorization scheme
Following is an example of a categorization identifying a company as a sporting goods manufacturer in the New York area:
<categoryBag>
<keyedReference
keyName="Sporting and Athletic Goods Manufacturing" keyValue="33992"
tModelKey="UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2"/>
<keyedReference
keyName="New York" keyValue="US-NY"
tModelKey="UUID:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88"/>
</categoryBag>
In this example the key
UUID:C0B9FE13-179F-413D-8A5B-5004DB8E5BB2 identifies the NAICS
categories while the key UUID:4E49A8D6-D5A2-4FC2-93A0-0411D8D19E88
identifies ISO 3166 standard for geographic location classifications.
The UDDI tModel Concept
In the UDDI information model described in last month's XML in
Transit (see Figure 1), business entities expose a number of business
services, each of which is accessed via a number of bindings to
different protocols and at different physical locations (network
addresses). All three information structures - entities, services, and
bindings - refer to UDDI technical models (tModels). The tModel
structure is a fundamental concept that is at the root of much of the
power and flexibility that UDDI provides. As you've seen, tModels are the mechanism used to identify property namespaces and categorization schemes in UDDI.
What Is a tModel?
In order to invoke a service, it's sometimes necessary to know a
large amount of details in terms of document formats, transport
protocols, business processes, and the like. These details in general
could be supplied in the description of the service. If software
engineering has taught us one thing in the last decade, however, it is
the power of abstraction and reuse. These service specifications could
be applicable in several different places for different services, or
for different bindings for the same service. They can also be specified
by an industry consortium, a standards body, or a large corporation for
use by their suppliers. Thus conformance to a known and predefined set
of specifications becomes very important. The tModel
concept is the mechanism for such abstractions. It allows various
entities (such as businesses, standards bodies, industry groups) to
publish abstract specifications to be used by other entities in
implementing services.
The tModel Data Structure
The tModel
structure is simple and flexible; it allows you to define just about
anything. Here are some of the key pieces of information that define a tModel:
- tModelKey: Unique identifier for tModel; used in keyedReferences
- name: tModel's name
- description: Textual description of tModel
- overviewDoc: Optional URL to document describing tModel
- identifierBag: Optional properties attached to tModel; can be valuable in searching UDDI registry for particular tModel
- categoryBag: Optional classification information about tModel; allows tModels to be organized within taxonomies
Using tModels
The simplicity of the tModel
data structure makes it a powerful concept, but it can also be a
double-edged sword. On the one hand, because of the simplicity in
defining a tModel,
people can specify anything they want, even if it's not useful to or
reusable by anyone else. On the other hand, if used properly, tModels can be used to specify the standards and templates that will be used for the next generation of e-business on the Web.
Throughout the UDDI data structures, tModels are used as references. By convention, the UDDI specification suggests two main uses for them:
- They are useful in defining namespaces for identifiers and classification, as you've seen in the earlier examples.
- They're also used in defining what the UDDI documentation calls technical fingerprints. This refers to any technical specifications or prearranged agreements on how to conduct business. For example, tModels
can be created by industry groups such as RosettaNet or by companies
wishing to standardize the way they deal with suppliers. As an example,
the WSDL (Web Services Definition Language) Schema for Web services
descriptions is already defined in UDDI as a tModel. This enables WSDL to be used with UDDI.
Through the containment model of UDDI, tModels can be organized into a hierarchy. UDDI has a number of predefined tModels describing tModel types, called canonical models.
Each canonical model is a technical fingerprint, a set of well-defined
and agreed-upon concepts and rules. The canonical model hierarchy is
shown in Table 1, using the tModel's names.
An example of how these models can be put to use are the definitions of the UDDI APIs, which are referred to as tModels because they're well defined and agreed upon through the UDDI specification. These tModels are all classified in the UDDI Type tModel namespace as being of types "specification," "xmlSpec," and "soapSpec." Listing 1 shows the definition of the UDDI inquiry API.
Through the UDDI publishing API, organizations or businesses can define, create, and publish their own tModels. In fact, they can even create their own taxonomies using tModels.
Third-Party Taxonomies
Taxonomies are the primary means in UDDI of organizing and
therefore searching for entries. UDDI version 2.0 added a feature by
which third parties could specify new taxonomies and provide a service
by which UDDI registries - in particular, operator nodes within the
UDDI Business Registry - could validate categorizations asserted
against a taxonomy developed by a third party.
Why would anyone want to define a new taxonomy? UDDI provides,
by default, the three canonical taxonomies: NAICS, for industry
classifications, UN/SPSC, for product/service, and ISO 3166, for
geographic classifications. These are general-purpose taxonomies that
are quite useful for broadly classifying businesses or services.
However, a particular industry might want to define a new taxonomy to
detail product classifications according to a scheme commonly used in
their industry. A third-party quality of service (QoS) guarantor may
wish to define an identifier scheme, classifying businesses and their
services according to some new QoS metric for Web services.
Organizations may choose to convert their product codes into a taxonomy
and categorize which businessService entries are associated with
requesting, purchasing, and getting postsales support on each of their
products.
Example Taxonomy
For example, WeMakeIt Inc. decides to create a parts code scheme
for all of the parts WeMakeIt Inc. uses in its manufacturing lines.
Because WeMakeIt Inc. is a manufacturer of a wide and frequently
changing variety of goods, this list of product codes is constantly
updated. By creating this taxonomy, the company can make its private
UDDI partner catalog registry extremely useful. WeMakeIt Inc. will
require their suppliers to use Web services to interact with their
automated supply reordering system. All of the partners will be
required to categorize their UDDI businessService entries using
WeMakeIt Inc.'s custom parts code taxonomy.
In this way the businessService entries in WeMakeIt Inc.'s
partner catalog UDDI are all classified according to the parts code.
When WeMakeIt Inc. needs to reorder a part, it can issue a
taxonomy-based find operation and retrieve all the business partners
that deal in that part. WeMakeIt Inc. can then issue RFQs, purchase
orders, and the like to resupply a manufacturing line, or to
just-in-time prepare for an upcoming manufacturing run.
Let's examine the steps WeMakeIt Inc. would use to set up
their third- party taxonomy based on the existing product code scheme.
The company would create a tModel to describe their product code taxonomy and register it in the UDDI Business Registry using the save_tModel API (see Listing 2).
The UDDI registry will assign a tModelKey, say, UUID:E0AC1230-4CC1-11D5-B353-B4D70FD31643. WeMakeIt Inc. would tell all of its suppliers to get this tModel
and use it to classify their businessEntity and businessServices
according to which of these product codes the supplier provides.
The following is an example of how the parts-ordering service
of a midsized widget manufacturer would classify itself within the
WeMakeIt parts code scheme.
<categoryBag>
<keyedReference
keyName="Mid-Size Widgets" keyValue="123-17-94"
tModelKey="UUID:E0AC1230-4CC1-11D5-B353-B4D70FD31643"/>
</categoryBag>
Validating Taxonomies
Because WeMakeIt Inc. wants their suppliers properly categorized,
it would provide a validation mechanism for its taxonomy. WeMakeIt Inc.
would set up a Web service to validate any UDDI entry that is
categorized using its custom taxonomy. This Web service would conform
to the validate_values requirements specified in the UDDI version 2.0
programmer's API. WeMakeIt Inc. would register this service with the
UDDI Business Registry using the mechanism specified by the operator
node that controls WeMakeIt Inc.'s entries. It would tell all of its
suppliers to reference this validate_values Web service with their
private portal UDDI registries.
Without this effort WeMakeIt Inc.'s custom taxonomy would have
remained unchecked. The difference between a checked and an unchecked
taxonomy is fairly important. With a checked taxonomy, any
save_business, save_service, or save_tModel
that references this taxonomy will use the validate_values service
published by WeMakeIt Inc. If an entry specifies an invalid category,
or WeMakeIt Inc.'s validate_values service returns an error for some
reason, the save operation for the entry fails. If WeMakeIt Inc.
develops an unchecked taxonomy, there would be no way its suppliers
could ensure that their categorizations accurately reflected WeMakeIt
Inc.'s supplies coding scheme.
| 
