UDDI Registry Version 3 Entity Keys

Entity Keys, UDDI v1/2 uuid and UDDI v3 uddi keys

Entity keys are identifiers used to address entities within a UDDI registry. Each entity; businessEntity, businessService, bindingTemplate, and tModel (also Subscriptions), has a unique identifier generated or assigned when first published in the UDDI registry. Within a particular registry, a key MUST be unique. The UDDI version 3 specification expands the space available for keys; it is not limited to a UUID as in versions 1 and 2. Entity keys can now be any URI (Universal Resource Identifier) that follows the recommended UDDI scheme.

Another difference introduced by the UDDI Version 3 specification is that depending on registry policy, keys can be assigned, not only by the UDDI registry, but also by the publisher of the entity. These differences raise issues in maintaining key uniqueness and managing key space.

UDDI Scheme

The IBM UDDI Version 3 registry implements the recommended UDDI scheme, as detailed in Section 4.4 of the UDDI Version 3 Specification. (http://uddi.org/pubs/uddi_v3.htm). This scheme defines the format of the keys, the valid characters, and the concept of key space.

A UDDI Version 3 a key is any URI (Universal Resource Identifier) and is limited to 255 characters. The following diagram shows the different types of keys within the UDDI key scheme:

All keys are composed of a set of tokens that are separated by ':'. The first token for all keys that follow the UDDI scheme is "uddi". There are three types of keys:

1. The uuidKeys contain two tokens, the mandatory "uddi" and a <UUID>. These keys assure uniqueness through the UUID algorithm.

2. The domainKeys also contain 2 tokens but its second token is a Domain Name. These keys are intended for creating additional mutually-exclusive key spaces.

3. The derivedkeys are composite keys based on a subkey, which is any uddiKey, and an additional token, kss, which is a key specific string. The kss is what differentiates keys and it can be assigned by a publisher or calculated algorithmically (UUID).

Key uniqueness and registry root key space

Instances of UDDI registry can be configured to be a 'Root' registry, or an 'Affiliate' registry.

Root registries define their own 'root' key space by defining their own root key generator. This defines the total key space the registry manages. All keys the registry generates are within this key space, and, if allowed by Policy, publishers may request sub-divisions of this key space by publishing new tModel key generators of the form <rootkeygenerator>:<subdivisionIdentifier>:keygenerator and then may include publisher-supplied-keys in subsequent publish requests which are within their allocated key space subdivision. ("<rootkeygenerator>:<subdivisionIdentifier>:<kss>).

To avoid key collisions, affiliate registries must establish their root key generator by first submitting a tModel:keygenerator request to the root registry they wish to be an affiliate of, and then using this (subdivision of the root registry's key space) as their own root key generator. This ensures there are no collisions between keys generated or accepted by an affiliate registry and other keys in the root registry key space.

To maintain key uniqueness simple rules are applied, the registry only generates new keys within the key space defined by its own root key generator, and only accepts publisher-supplied-keys which are within a subdivisions of key space owned by the publisher (as the result of a prior successful tModel 'tModel:keygenerator' publish request).

The public UDDI Universal Business Registry (UBR) is a root registry which has a root key generator of uddi:keygenerator so to avoid collisions with keys of entities published in the UBR, it is recommended that private Root registries do not use this as their root key generator.

Simple example for a private Root Registry:

with a Root keygenerator:

uddi:aPrivateRegistryKeySpaceIdentifier:keygenerator  

generates Entity Keys of format:

uddi:aPrivateRegistryKeySpaceIdentifier:<uuid>

depending on Policy, accepts tModel:keygenerator requests from Publishers for 'top-level' subdivisions 
of format:
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:keygenerator 

Publishing 'tModel:keyGenerator' requests for subdivisions of key space

As identified above, depending on Policy, (whether the registry supports publisher supplied keys and whether a particular publisher's User entitlements allow the publisher to submit requests for key space) a publisher can submit a request for a (top-level) subdivision of the root registry's key space for its own use.

In addition to 'top-level' subdivisions of the root registry's key space, a publisher can also create further subdivisions of key space for its own use. A simple example of this is (continuing the example above):

uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:a:keygenerator

This request for a further subdivision 'a' is successful when requested by the publisher who previously requested (and hence owns) the tModel for the 'level above' (in this case uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:keygenerator).

Publishing with a 'publisher supplied' key

Having successfully requested a subdivision of a root registry's key space, a publisher must establish and maintain their own scheme for ensuring that the keys generated to be used as publisher-supplied-keys in subsequent publish requests are unique within the subdivision.

Valid schemes need to generate keys which are unique derived keys within the allocated key space subdivision, for example including a unique (incremented) numeric index.

A simple example of this is (continuing the example above): For key space subdivision resulting from tModel:keyGenerator request:

uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:a:keygenerator 
valid keys are:

uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:a:1

uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisonIdentifier:a:2