Publisher-Assigned Keys

Publisher-Assigned Keys ^Locate

Under UDDI v1 and v2, keys are generated automatically when a structure is published. Generated keys in these versions are in form (uuid:)8-4-4-4-12 where the numbers indicate a count of hexadecimal values. For example, uuid:327A56F0-3299-4461-BC23-5CD513E95C55. Note that the prefix "uuid:" was only used in tModelKeys.

In UDDI v3 users may assign keys when saving a structure for the first time. These Keys can be 255 characters long and can contain numbers and Latin characters, so that the key itself describes what the UDDI structure means. For example, the key uddi:systinet.com:uddiRegistry:demo:businessService has the following elements:

The prefix uddi: is a schema much like http: or ftp: and must be always present.
systinet.com is an optional host name.
The elements uddiRegistry, demo, and businessService represent a hierarchy of domains. The domain demo is a subdomain of uddiRegistry.

This description is sufficient for our purposes for now. For a more precise description of keys, please see the UDDI v3 Specification.

Generating Keys ^Locate

The key generator tModel is a tModel with a key in the form domain:keygenerator. This tModel permits its owner to save structures with keys in the form domain:string. For example, the tModel uddi:systinet.com:uddiRegistry:demo:keygenerator allows its owner to publish structures with keys like:

uddi:systinet.com:uddiRegistry:demo:businessService
uddi:systinet.com:uddiRegistry:demo:b52

These are derived keys of the uddi:systinet.com:uddiRegistry:demo domain.

With one exception, the key generator tModel does not allow the user to save keys from subdomains such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate, that is, derived keys of uddi:systinet.com:uddiRegistry:demo:businessService.

The key generator tModel, however, permits the user to save the key generator for each direct subdomain. For example, the user can save uddi:systinet.com:uddiRegistry:demo:businessService:keygenerator. After creating this second key generator, the user is permitted to save structures with keys of the uddi:systinet.com:uddiRegistry:demo:businessService domain, such as uddi:systinet.com:uddiRegistry:demo:businessService:exchangeRate.

	Important
	To generate keys for a domain, the user must own the domain's key generator tModel. Only the administrator can save structures with assigned keys without having the key generator tModel. To enable this process for other users, the administrator must save the domain's tModel and then change its ownership to the user via custody transfer. For more information, please see Publish Custody Transfer.

Affiliations of Registries ^Locate

The rules above ensure that two users can not create structures with the same key. A complicated situation arises when one user wants to copy UDDI structures from one registry to another while preserving the keys of those structures. There are two problems:

The key of the copied structure must not exist on the second registry. The key must be unique - this is required by the UDDI specification.
The user must be allowed to save a structure with a specified key on the second registry.

The Affiliated registries mechanism solves both problems. An affiliation is a relationship between two registries. The first registry gives up generation of keys for a certain domain and transfers this privilege to the second registry. This ensures that keys from both registries are unique.

	Note
In the examples below we name the two registries 'master' and 'slave'. Moreover there are three people: The person 1 is an administrator of the master registry, this account is called master-admin. The person 2 is an administrator of the slave registry (account slave-admin) and a common user on the master registry (account master-user2). The person 3 is a common user on slave registry (account slave-user3) and a common user on master registry (account master-user3).

Note

In the examples below we name the two registries 'master' and 'slave'. Moreover there are three people:

The person 1 is an administrator of the master registry, this account is called master-admin.
The person 2 is an administrator of the slave registry (account slave-admin) and a common user on the master registry (account master-user2).
The person 3 is a common user on slave registry (account slave-user3) and a common user on master registry (account master-user3).

Affiliation Setup ^Locate

To set up an affiliation:

The administrator of the slave registry (slave-admin) registers a user account on the master registry (master-user2).
Master-user2 requests a key generator tModel from the administrator of the Master registry.
This administrator, master-admin, creates the key generator tModel and transfers it to the master-user2 account using custody transfer.
Person 2 manually copies the key generator tModel to the slave registry (his slave-admin account has permission to assign any key) and sets up the slave registry to generate all keys based on this key generator. For more information, please see Node in the Administrator's Guide.

All keys generated by the slave registry or its users will be from the domain or some subdomain defined by the key generator.

Copying Structures with Key Preservation ^Locate

Given key should refer to the same structure no matter which registry the structure is in.

Suppose that slave-admin creates a key generator tModel for slave-user3 and this user uses the key generator to generate a key for a structure in the slave registry. To copy the structure to the master registry, this key generator tModel must exist on both registries.

To copy a structure from the slave to the master registry:

The slave-user3 must ask person 2 (slave-admin) to copy the second key generator, because only the holder of the account master-user2, as owner of the first key generator, can do this on the master registry.
Then master-user2 transfers ownership of the second key generator in the master registry to master-user3. Now master-user3 can copy the structure while preserving the generated keys.