A taxonomy, or value set in the terminology of the UDDI specifications, is a tModel which can be used in categoryBags, identifier bags, or Publisher Assertions. This tModel must be in a specific form, so that BEA AquaLogic Service Registry can recognize it as a taxonomy. The tModel must be categorized with the type of taxonomy and, optionally, with information concerning whether and how to validate the values in keyedReferences.

The UDDI specification distinguishes four types of taxonomies: categorizations, categorizationGroups, identifiers, and relationships.

The publisher of a taxonomy can decide whether the values in keyedReferences within the taxonomy will be checked or not.

The creator of the taxonomy must specify types of keyValues by assigning the appropriate comparator reference (comparator tModel) of the systinet-com:isOrderedBy taxonomy to the categorization taxonomy you want to use to categorize a UDDI entity. The following types of key values types are supported:

For example, the tModel of the categorization taxonomy with numeric key values must have the following keyedReference in its category bag:

<keyedReference tModelKey="uddi:systinet.com:isOrderedBy"
   keyValue="uddi:systinet.com:comparator:numeric"/>  
        

Figure 42. Example of Numeric Categorization

Figure 42 shows how the demo:location:floor taxonomy from Demo data can be assigned numeric key values.

Important

If you change type of keyValues of the taxonomy and there are entities in the BEA AquaLogic Service Registry that were already categorized with the taxonomy, the BEA AquaLogic Service Registry administrator must execute the task Transform keyed references. The button for executing this task is located in the Registry Console under the Manage tab, Registry Management link. See Administrator's Guide, Accessing Registry Management

Custom Ordinal Types  ^Locate

You can define your custom ordinal types. To demonstrate possible extensions, BEA AquaLogic Service Registry contains two demo comparators:

• systinet-com:comparator:date

• systinet-com:comparator:stringToLowerCase

Let's assume you want to create a taxonomy with date values in keyValues. You must mark the taxonomy tModel (that is, add the following keyedReference into its categoryBag) by <keyedReference tModelKey="uddi:systinet.com:isOrderedBy" keyValue="uddi:systinet.com:comparator:date"/>. It is quite easy because there is a demo comparator for date in the registry. Imagine the date comparator is not present. Take the following steps to create it in the registry:

1. Create a transformer service that transforms the date value into a string or numeric value. The transformer service must implement TransformerKeyedReferenceApi and add this class to the BEA AquaLogic Service Registry class path.

2. Create a new comparator tModel for date. The tModel must be categorized as a comparator using the systinet-com:comparator taxonomy. The comparator must refer to the transformer service. This reference is specified by the taxonomy IsTransformedBy (where "uddi:cba104c0-fb5c-11d8-8761-eb2505508761" is the key of the bindingTemplate with the specification of the transformer service.

Important

If you change implementation of the of the transformer service of the taxonomy and there are entities in the BEA AquaLogic Service Registry that were already categorized with the taxonomy, the BEA AquaLogic Service Registry administrator must execute the task Transform keyed references. The button for executing this task is located in the Registry Console under the Manage tab, Registry Management link. See Administrator's Guide, Accessing Registry Management

Figure 43 shows the tModel references for date categorization ordering. It describes a purchase order document that has been mapped to BEA AquaLogic Service Registry via XML-to-UDDI functionality, and then categorized by the acceptancedate taxonomy. The categorization taxonomy must refer to the comparator tModel uddi:systinet.com:comparator:date that references a bindingTemplate with the location of the date transformation service.

Figure 43. Example of Custom Categorization (date)

The transformer service is called whenever the appropriate keyedReference is processed. If any entity contains the keyedReference with a taxonomy tModel whose type is custom then the transformer service is called to discover the correct (that is, transformed) keyValue of the keyedReference. Such transformed values are stored into the database. If you want to find entities by this keyedReference (the keyedReference with the same taxonomy tModel), the service is called again to get the transformed value. Transformed values are used for the saving and searching of keyedReferences.

See Administrator's Guide , Editing Taxonomies how to edit taxonomy type.

This section demonstrates the basics of taxonomy API and taxonomy persistence format. A comprehensive description of the Taxonomy API can be found in the Developer's Guide, Taxonomy.

	Note
	For clarity, we use an XML representation, but you can achieve the same results with Java objects.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="false">
    <tModel tModelKey="uddi:systinet.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
</taxonomy>
  

Each taxonomy, in order to be saved, requires a valid tModel. While it must contain a tModelKey and a name, you do not need to set the content of the categoryBag.

Let's enhance the previous example and convert the taxonomy from unchecked to checked. Checked taxonomies must contain Validation. In this example, the taxonomy is checked by the Custom Validation Web service located at http://www.foo.com/MyValidationService.wsdl.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <bindingTemplate bindingKey="" serviceKey="" xmlns="urn:uddi-org:api_v3">
            <accessPoint useType="endPoint">
               http://www.foo.com/MyValidationService.wsdl
            </accessPoint>
            <tModelInstanceDetails>
                <tModelInstanceInfo 
                        tModelKey="uddi:uddi.org:v3_valueSetValidation"/>
                <tModelInstanceInfo 
                        tModelKey="uddi:systinet.com:demo:myTaxonomy"/>
            </tModelInstanceDetails>
        </bindingTemplate>
    </validation>
</taxonomy>
  

The validation element must hold the bindingTemplate identifying the validation Web service or categories structures. In this example we chose bindingTemplate. It must contain complete accessPoint and tModelInstanceDetails must hold the Valueset_validation API and tModelKey of the saved taxonomy. If the serviceKey is specified and if the businessService already exists, it must be part of the Operational Business Entity.

	Important
	Be aware that the service will be replaced during the save_taxonomy process.

If you can provide a list of allowed values, you do not need to implement your own validation Web service. Just provide the allowed values inside the categories structure (as shown below) and the Internal Validation Service will be responsible for validation of the keyedReferences.

<taxonomy xmlns="http://systinet.com/uddi/taxonomy/v3/5.0" 
        xmlns:uddi="urn:uddi-org:api_v3"
         check="true">
    <tModel tModelKey="uddi:foo.com:demo:myTaxonomy">
        <uddi:name>My taxonomy</uddi:name>
        <uddi:description>Category system</uddi:description>
    </tModel>
    <compatibilityBag>
        <compatibility>businessEntity</compatibility>
    </compatibilityBag>
    <categorizationBag>
        <categorization>categorization</categorization>
    </categorizationBag>
    <validation>
        <categories>
            <category keyName="Value A" keyValue="A"/>
            <category keyName="Value B" keyValue="B">
                <category keyName="Value B1" keyValue="B1"/>
                <category keyName="Value B3" keyValue="B3" disabled="true" />
            </category>
            <category keyName="Value C" keyValue="C"/>
        </categories>
    </validation>
</taxonomy>
  

As you can see, you can arrange your values hierarchically. This is useful for the Registry Console that implements the drill-down pattern. If you really need, you can even specify bindingTemplate along with the categories structure, but its accessPoint must point to the Internal Validation Service.

BEA AquaLogic Service Registry comes with the following predeployed taxonomies: