UDDI Registry V3 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, for example businessEntity, businessService, bindingTemplate or tModel, 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 V3 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 V3 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.

In the UDDI V3 Registry, 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).

Another concept included in the UDDI key scheme is a key generator. A key generator is used to represent a key space. A publisher is only allowed to save entities using keys from a certain key space if it owns the key generator that represents the key space. This aids in securing unique keys. The key generator is a tModel entity, which key is in the form “<subkey>:keyGenerator”. By owning this tModel, a publisher can assign keys in the form “<subkey>:<kss>. The publisher can also publish new tModel key generators of the form “<subkey>:<kss>:keygenerator

 

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