|
|
One of the main purposes for using a registry is to maintain information about services and make it easy for clients to search for services. Having a registry without the proper taxonomic classification of data in it would not be ideal. If a client cannot quickly and efficiently discover appropriate services, UDDI becomes cumbersome to use.
Taxonomies can be used to categorize a service or other entities registered in a UDDI registry. Entities can be classified based on D-U-N-S, UN/SPC, SIC codes, or other schemes used to categorize businesses, industries, and their respective product categories. Additional classification schemes exist to specify geographic information or membership information for a specified organization.
 |
Taxonomies are structured vocabularies that embody a relationship among terms and provide orderly classification of information. Simply, it provides a list of allowable terms or phrases.
|
UDDI will allow a classification system to be used on every entity contained in the registry. It is generally recommended that all services be classified before being made publicly available. Whether you decide to use standard classification schemes or create your own taxonomy, it is vital that all UDDI data, such as businessEntity, businessService, bindingTemplate, and tModels, be given the appropriate classification.
UDDI inquiry APIs permit searching with different classification schemes. A query could contain criteria that use multiple classifications, such as industry codes, geographic codes, and business identification codes. This query will become an entry point to value-added search engines, such as AltaVista and Google. UDDI can also use the classification schemes optionally as validation checks. As an example, UDDI can make sure you specify a valid country code.
As part of the base specification, UDDI supports three canonical taxonomies that can be used for broad classification of businesses and the services they offer:
ISO 3166: geographic
NAICS: industry
UN/SPSC: products and services
UDDI registries can also provide their own additional classification schemes. Sometimes it may be necessary to define additional classification schemes for businesses and the services they offer. If you are classifying businesses for internal registries, you should create a new taxonomy that groups services by cost, quality of service, or other factors. In the Flute Bank scenario, they have decided to group all service providers into four classifications: platinum, gold, silver and regular. Flute Bank's policy is that all services offered by platinum providers must be used during market business hours. Platinum providers make their services available during business hours but also support after-business hours usage on a prioritized basis.
Many organizations have created their own internal classification schemes. This could include a preferred vendors list, preferred shipping providers, or a listing by criteria such as credit rating.
Consider the following scenario: Flute Bank decides to create a taxonomy for specifying quality of service for partners listed in its private UDDI registry. The bank determines it will use four domain values for quality of service: better, good, fair, and poor. Whenever the bank needs a particular quality of service, it will perform a taxonomy-based find operation and retrieve all business service entries that meet the requirement. To support the quality of service, Flute Bank creates a tModel and registers it in the UDDI registry. Listing 6.3 shows the XML message used to create the tModel.
|
<save_tmodel generic="2.0" xmlns="urn:uddi-org:api_v2">
<authInfo> ... </authInfo>
<tModel tModelKey="">
<name>Flute Bank Quality of Service Taxonomy</name>
<description xml:lang="en">Flute Bank classification quality of service
</description>
<overviewDoc>
<overviewURL>
http://www.flutebank.com/qos/browseQOS
</overviewURL>
</overviewDoc>
<categoryBag>
<keyReference
keyName="Flute Bank categorization type"
keyValue="categorization"
tModelKey="UUID:B2CAF44D-2322-4333-9EF8-22D338F82AB1"/>
</categoryBag>
</tModel>
</save_tModel>
|
In Listing 6.3, suppliers can retrieve the tModel and use it to classify the businessServices they offer. Additionally, the registry can ensure that only specified values are used to indicate the quality of service offered. UDDI provides support for this through the validate_values API. By using a validated taxonomy, a supplier can assure that calls to the save_business, save_service, or save_tModel use only allowable values. If the validate_values API returns an error, the save_xxx API will fail.
The UDDI registry that needs to validate the quality of service values would send a validate_values message to the service registered to provide validation. The validate_values message would look similar to this:
<validate_values generic="2.0" xmlns="urn:uddi-org:api_v2"> <businessService/> ... | <tModel/> ... <validate_values>
Flute Bank and its validate_values service takes this message and looks for key values contained in the keyedReference element and obtains a reference to its tModelKey. It then does a lookup against all valid quality of service values to ensure validity. The Flute Bank validate_values service will ignore other information in the message.
Whenever an organization decides to create its own classification scheme, it may also decide that relationships exist between single categories. In Listing 6.3, we used categoryBags to classify quality of service. Flute Bank might want to indicate that it sells insurance products only in the United States. The categoryBags can be extended to contain keyedReferenceGroups that can contain a list of keyedReferences. Let us look at how Flute Bank can indicate its insurance products are available only in the United States:
Listing 6.4 shows a key of "uddi:ubr.uddi.org:categorizationGroup:unspsc_geo3166" that corresponds to category systems for UNSPSC and ISO 3166. The keyedReferenceGroup uses a tModel that describes the countries in which the product category is sold. As we can see, categorization can happen based on predefined classification systems or internal schemes. Classification can also be extended to support specific geographic coordinates of where the business is located and/or the services offered. Let us look at one final example of how Flute Bank can indicate where it is located, based on the World Geodetic System:
|
The world geodetic system is a classification system that specifies the longitude and latitude for a given location.
|
|
<businessEntity businessKey="uddi:flutebank.example">
...
<keyReferenceGroup
tModelKey=
"uddi:ubr.uddi.org:categorizationGroup:unspsc_geo3166">
<keyedReference
tModelKey="uddi:ubr.uddi.org:categorization:unspsc"
keyName="UNSPSC: Insurance Products"
keyValue="22.00.00.00.00"/>
<keyedReference
tModelKey="uddi:ubr.uddi.org:categorization:geo3166-2"
keyName="GEO:United States"
keyValue="US"/>
</keyedReferenceGroup>
...
</businessEntity>
|
Listing 6.5 shows that Flute Bank is physically located at latitude 41.831647 and longitude 72.72493, with its position calculated based on the center of the street on which it is located.
|
<businessKey businessKey="uddi:flutebank.example">
<categoryBag>
<keyedReferenceGroup
tModelKey="uddi:ubr.uddi.org:categorizationGroup:wgs84">
<keyedReference
tModelKey=
"uddi:ubr.uddi.org:categorization:wgs84:latitude"
keyName="WGS 84 Latitude"
keyValue="+41.831647"/>
<keyedReference
tModelKey=
"uddi:ubr.uddi.org:categorization:wgs84:longitude"
keyName="WGS 84 Longitude"
keyValue="+72.72493"/>
<KeyedReference
tModelKey=
"uddi:ubr.uddi.org:categorization:geo_precision"
keyName="Center of Street"
keyValue="0900"/>
</keyedReferenceGroup>
</categoryBag>
</businessEntity>
|
|
|