UDDI registry V3 entity keys
The UDDI V3 specification expands the space available for keys. Entity keys can now be any URI (Universal Resource Identifier) that follows the recommended UDDI scheme. Depending on registry policy, keys can be assigned, not only by the UDDI registry, but also by the publisher of the entity.
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 that is generated or assigned when it is first published in the UDDI registry. Within a particular registry, a key must be unique. In the UDDI V1 and V2, the space is limited to a universal unique identifier (UUID) . In the UDDI V3 specification, entity keys can be any URI that follows the recommended UDDI scheme.
In the UDDI V3 specification, 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 for maintaining key uniqueness and managing key space.
UDDI Scheme
The 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 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 ‘:’. 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 also contain two tokens but the second token is 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. 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 can save entities using keys from a certain key space only if that publisher owns the key generator that represents the key space. This restriction 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 tModel key generators in the form <subkey>:<kss>:keygenerator.
Key uniqueness and registry root key space
Instances of the UDDI registry can be configured as 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 that the registry manages. All keys that the registry generates are within this key space. If allowed by policy, publishers can request sub-divisions of this key space by publishing new tModel key generators in the form <rootkeygenerator>:<subdivisionIdentifier>:keygenerator, and then can 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 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 that 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 generates new keys only in the key space defined by its own root key generator, and only accepts publisher-supplied keys that are in subdivisions of key space that the publisher owns (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
Publishing tModel:keyGenerator requests for subdivisions of key space
Depending on policy, a publisher can submit a request for a top-level subdivision in the key space of the root registry for its own use. (The policy is whether the registry supports publisher supplied keys and whether a particular publisher’s User entitlements allow the publisher to submit requests for key space).
As well as top-level subdivisions in the key space of the root registry, a publisher can also create additional subdivisions of key space. Continuing from the previous example, a simple example of this is:
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:keygenerator
This request for a further subdivision a is successful when it is requested by the publisher who previously requested, and owns, the tModel for the subdivision above (in this case, uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:keygenerator).
Publishing with a publisher-supplied key
After a publisher successfully requests a subdivision in the key space of 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 within 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.
Continuing from the previous example, a simple example of this is: 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
Related tasks
UDDI registry client programming