UDDI registry Version 3 entity keys

UDDI registry Version 3 entity keys

The UDDI Version 3 specification expands the space available for keys. Entity keys can be any Universal Resource Identifier (URI) that follows the recommended UDDI scheme. Depending on registry policy, both the UDDI registry and the publisher of the entity can assign keys.
Entity keys are identifiers used to address entities in a UDDI registry. Each businessEntity, businessService, bindingTemplate, or tModel entity has a unique identifier that is generated or assigned when it is first published in the UDDI registry. In a particular registry, a key must be unique. For UDDI Version 1 and Version 2, the space is limited to a universal unique identifier (UUID). For UDDI Version 3, entity keys can be any URI that follows the recommended UDDI scheme.
For UDDI Version 3, depending on registry policy, not only can the UDDI registry assign keys, but also the publisher of the entity. These differences raise issues for maintaining key uniqueness and managing key space.

UDDI Scheme

The 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.
In the UDDI Version 3 registry, a key is any URI and is limited to 255 characters. The following diagram shows the different types of keys in the UDDI key scheme:

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

The uuidKey keys contain two tokens, the mandatory uddi and a <UUID>. These keys ensure uniqueness through the UUID algorithm.

The domainKey keys contain two tokens, the mandatory uddi and a domain name. These keys are for creating additional mutually exclusive key spaces.

The derivedKey keys are composite keys based on a subkey, which is any uddiKey, and an additional token, kss, which is a key-specific string that differentiates keys. A publisher can assign the kss token, or the kss token can be calculated algorithmically (UUID).
Another concept included in the UDDI key scheme is a key generator. A key generator represents a key space. A publisher can save entities by using keys from a certain key space only if that publisher owns the key generator that represents the key space. This feature helps to secure unique keys. The key generator is a tModel entity, with a key that is in the form <subkey>:keygenerator. By owning this tModel entity, a publisher can assign keys in the form <subkey>:<kss>. The publisher can also publish new key generator tModel entities in the form <subkey>:<kss>:keygenerator.

Key uniqueness and registry root key space

We can configure instances of the UDDI registry as a root registry or as an affiliate registry.
Root registries define their own root key space by defining their own root key generator. This action defines the total key space that the registry manages. All keys that the registry generates are in this key space. If the policy allows, publishers can request subdivisions of this key space by publishing new key generator tModel entities in the form <rootkeygenerator>:<subdivisionIdentifier>:keygenerator. Publishers can then include publisher-supplied keys in subsequent publish requests that are in 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 want to be an affiliate of, and then using this subdivision of the key space of the root registry as their own root key generator. This process ensures that there are no collisions between keys that are 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 generates new keys only in the key space defined by its own root key generator. The registry only accepts publisher-supplied keys that are in subdivisions of key space that the publisher owns, that is, as the result of a previous successful tModel tModel:keygenerator publish request.

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:aPublisherSubdivisionIdentifier:
keygenerator
Publish tModel:keygenerator requests for subdivisions of key space

Depending on policy, a publisher can submit a request for a top-level subdivision of the key space in the root registry for its own use. The policy can specify whether the registry supports publisher-supplied keys and whether the user entitlements of particular publisher allow the publisher to submit requests for key space.
As well as top-level subdivisions of the key space in the root registry, a publisher can also create additional subdivisions of key space.
The following simple example is a continuation of the previous example and requests the subdivision a:
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:
a:keygenerator
For a request for a further subdivision to be successful, the publisher that requested, and owns, the tModel entity for the previous subdivision must make the request. In the previous example, this publisher is uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:keygenerator).

Publish with a publisher-supplied key

After a publisher successfully requests a subdivision of the key space in a root registry, that publisher must establish and maintain its own scheme to ensure that the keys that are generated for use as publisher-supplied keys in subsequent publish requests are unique in the subdivision.
Valid schemes need to generate keys that are unique derived keys in the allocated key space subdivision, for example by including a unique (incremented) numeric index.
The following simple example continues from the previous example. For a key space subdivision that results from the tModel:keygenerator request:
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:
a:keygenerator
 valid keys are:
 uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:1
 uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:2 
Concept topic