UDDI Spec TC
Technical Note
Understanding Key PartitionsProvide subject - see File>Property>Subject Field
Document identifier:
uddi-spec-tc-tn-understandingkeypartitions-20030216
Location:
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn- understandingkeypartitions-20030216.doc
Editor:
Ed Mooney, Sun Microsystems, Inc
Pat Felsted, Novell, Inc
Andrew Hately, IBM
Tony Rogers, Computer Associates
Contributors:
Abstract:
Key partitions are an important mechanism in ensuring the uniqueness of publisher assigned keys. This Technical Note helps you understand them.
Status:
This document is updated periodically on no particular schedule. Send comments to the editor.
Committee members should send comments on this technical note to the list. Others should subscribe to and send comments to the list. To subscribe, send an email message to with the word "subscribe" as the body of the message.
For information on whether any patents have been disclosed that may be essential to implementing this technical note, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the UDDI Spec TC web page (http://www.oasis-open.org/committees/uddi-spec/).
Table of Contents
Introduction 3
1.1 Problem statement 3
1.2 Background Material 3
2 Technical note Solution 4
2.1 Definitions 4
2.1.1 In terms of set theory 5
2.1.2 In terms of string matching 5
2.2 Technical note behavior 6
2.2.1 Conflicting keys 6
2.2.2 Assigning Keys 6
2.2.3 A way to control keys using the UDDI APIs 6
2.3 Discussion 7
2.4 Example 7
3 References 119
3.1 Normative 119
Appendix A. Acknowledgments 1210
Appendix B. Revision History 1311
Appendix C. Notices 1412
Introduction 3
1.1 Problem statement 3
1.2 Background Material 3
2 Technical note Solution 4
2.1 Definitions 4
2.2 Technical note behavior 5
2.2.1 Conflicting keys 5
2.2.2 Assigning Keys 6
2.3 Discussion 6
2.4 Example 6
3 References 8
3.1 Normative 8
Appendix A. Acknowledgments 9
Appendix B. Revision History 10
Appendix C. Notices 11
Introduction
Key partitions are an important mechanism in ensuring the uniqueness of publisher publisher-assigned keys. This Technical Note helps you understand them, how they are created, and their implications..
1.1 Problem statement
In a UDDI registry, various entities (business entities, business services, binding templates, and tModels) are assigned keys. These keys are the only unique identifiers for each of these entities in the registry.
In Version 2 of the UDDI specification, all keys were assigned by the UDDI nodes, and a UUID keying scheme was used in an endeavor to ensure that all keys were unique. The problem with a UUID scheme is that the resulting keys are far from memorable, and difficult for humans to handle. Version 3 of the UDDI specification adopts a different keying scheme to make keys more human-friendly. Part of this scheme is that keys are assigned by publishers. But a means is required to ensure that these keys are unique.
Version 3 of the UDDI specification provides a mechanism to allow rules whereby each publisher can to assert ensure that the keys it publishes will not conflict with the keys of any other publisher. The key partition is an important mechanism in applying those rulespart of that mechanism. This non-normative explanation of how key partitions work will help some publishers come up to speed on the concept more quickly.
1.2 Background Material
Sections 5.2.2 Publishing entities with publisher-assigned keys, 4.4 About uddiKeys, 9.4.2 General Keying Policy and 9.4.3 UDDI recommended keying scheme from the Version 3 specification are most relevant to this Technical Note. However, they are not prerequisite to understanding what we say here.It is not necessary to read these sections of the UDDI Version 3 specification to understand this technical note as direct quotes are included as required. The specification is recommended material for further detail on key partitions.
2 Technical note Solution
2.1 Definitions
uddiKeys allow publishers to specify keys for entities they publish in UDDI registries using “sensible looking” keys and to promote interoperation among UDDI registries [UDDIV3, sec: 4.4]. These keys must use Uniform Resource Identifiers (URIs) conforming to RFC 2396.
UDDI Node is a set of Web services supporting at least one of the Node API sets is referred to as a UDDI node. A UDDI node has these defining characteristics:
- A UDDI node supports interaction with UDDI data through one or more UDDI API sets.
- A UDDI node is a member of exactly one UDDI registry.
- A UDDI node conceptually has access to and manipulates a complete logical copy of the UDDI data managed by the registry of which it is a part. Moreover, it is this data which is manipulated by any query and publish APIs supported by the node. Typically, UDDI replication occurs between UDDI nodes which reside on different systems in order to manifest this logical copy in the node. [UDDIV3, sec: 1.5.3]
Publisher assigned keys are entity keys that are proposed by a publisher. If the publisher does not propose a key for a entity, the registry must assign one. [UDDIV3, sec: 5.5]
Key Partitions play a crucial role in managing publisher assigned keys. To understand how key partitions work, imagine starting out with a set of unique Uniform Resource Identifiers (URIs). Each URI conforms to a scheme named “uddi” and is less than or equal to 255 characters in length. We partition this set of URIs using the following method (each method is associated to an item in the below diagram):
- We identify all the URIs ending in the string “:keyGenerator” (for the time being, just accept that some of them do). We call these keyGeneratorKeys.
- For each keyGeneratorKey, there is a logical partition (think of it as a container).
- We name each partition after that part of the keyGeneratorKey up to but not including the string “:keyGenerator”. We call this the partition name.
- We sort through our set of URIs and place them into partitions, according to these rules:
a) A URI matching one of the partition names when it is a domainKey goes into the corresponding partition. We call this URI the uddiKey.
b) A URI with a prefix matching a uddiKey and a suffix consisting of a colon (“:”) followed by any sequence of letters, numbers, escaped characters (which are represented by % hexdigit hexdigit) or characters from the set "( )+,-.=@;$_!'" ; / ? @ & = + $ , - _ . ! ~ * ' ( ) but not the sequence “keyGenerator” goes into the uddiKey’s partition. We call these URIs derivedKeys. We call the suffix (excluding the leading “:”) a key specific string, which we abbreviate as “kss”.
c) A keyGeneratorKey with a prefix consisting of a derivedKey goes into the uddiKey’s partition, along together with the keyGeneratorKey’s own partition.
When we’re done, we have as many partitions as there are keyGeneratorKeys. Some partitions reside at the node root while others reside within other partitions. Each partition contains a uddiKey (see step 4a), but the keyGeneratorKey that reserved the partition resides in the containing partition (or node root, if that’s the case).
In terms of set theory
Key partitions are subsets of the space of all possible URIs that meet the requirements of being a uddiKey. There are only three possible relationships between two key partitions:
· they are the same
· one is a proper subset of the other (that is, one is wholly contained within the other)
they are disjunctdisjoint: there is no intersection between them
A little thought makes this obvious. If two key partitions have the same key generator key, then they are the same – if the key generator keys are the same, then all keys generated from that key will be in both partitions. If one partition has a key generator key which lies within the other partition, then all of the keys derived from that key generator key will lie within that partition also – if one key generator key is A, and the other AB, then clearly all keys generated from AB will fall within the partition A. And if neither key generator key lies within the other partition, then the key partitions must be completely disjoint – if one key generator key is A, and the other is B, where A and B are different, then there can be no overlap of generated keys.
Any key generator key which does not lie within the key partition of another key generator key is considered to lie within the root.
In terms of string matching
If we think of the keys as strings, then the rules may be expressed in another way.
All key generator keys are of the form A:keyGenerator, for A some string. Every key of the form Ax, for any non-empty string x that is not the string “:keyGenerator”, lies in the key partition of A:keyGenerator. Let us call A the prefix to the key generator key A:keyGenerator – it is the prefix of all the keys in that key partition.
We can see that the key partition of A:keyGenerator includes both the string AB:keyGenerator (which is the key generator key for a nested partition) and ABx (which is a key within that nested partition) for any non-empty strings B and x.
Note that A:keyGeneratorB is considered illegal, for any B that is not the empty string.
2.2 Technical note behavior
2.2.1 Conflicting keys
To ensure that publisher-generated keys do not conflict with one another, registries following the recommended keying scheme assign the authority to generate keys to publishers in the following manner:
- The conceptual space of uddiKeys is divided into non-overlapping, hierarchically arranged partitions, each of which can be associated with a publisher.
- Only the publisher associated with a particular partition is given the authority to assign keys within the partition.
- The publisher with authority for a given partition may designate any publisher it chooses for any partition directly below the partition it manages, provided it has not already designated a publisher to that partition.
- The publisher with authority for a partition may transfer its authority to another publisher.
5. Initially, the registry itself has authority for the root partition of the hierarchy.[UDDIV3, sec: 5.2.2.1]
2.2.2 Assigning Keys
Assigning your own keys is a matter of publishing entities such that you could partition their keys as described in section 2.1. You need to know:
1. The only type of entity that can have as its key a keyGeneratorKeys is a particular tModel called a key generator tModel.
2. If you’re able to publish key generator tModels (whether or not you can is a matter of policy), you own the partition reserved by that tModel key.
3. Depending upon policy you may be able to grant others the right to own key generator tModels within your partitions. We will term this “partition delegation”.
This means that in practice and depending upon the registry’s policies, assigning your own keys is a matter of:
1. Publishing key generator tModels to reserve the partitions you want.
2. Publishing entities using keys derived from the names of your partitions.
A way to control keys using the UDDI APIs
Registry policy can restrict who may publish which keys. In its simplest form, it may be stated that only the publisher who owns the tModel which is the keyGenerator for a key partition may publish entries with keys from that partition. In fact, the statement can be even stricter than this:
The publisher MUST own the key generator tModel for the keyGenerator that is the direct generator of any new key they create.use.
For example, owning the keyGenerator “uddi:mammal.com:giraffe:keyGenerator” does not give a publisher the immediate right to use the key “uddi:mammal.com:giraffe:African:wild” (even though that key lies within the key partition of that keyGenerator); the publisher must first publish the key generator tModel for “uddi:mammal.com:giraffe:African:keyGenerator”. Note that this publisher is entitled to publish that key generator tModel, and thus acquire the right to publish the key they wanted, unless that keyGenerator has already been published. This is assuming that the registry is strictly enforcing the rules relating to key generation.
All that being said, the question arises as to how a publisher gets their first keyGenerator. The language that has been used to date is that a publisher “gets permission” or “has permission” to use a particular keyGenerator. Is this an out-of-band process? Or can we formalize it using UDDI’s APIs? There is a way we can formalize this process. What can be done is that another publisher (possibly a registry administrator) can publish the keyGenerator tModel, and then transfer ownership of that tModel to the publisher who wants it. So the publisher who owns the “uddi:mammal.com:keyGenerator” tModel can publish the “uddi:mammal.com:giraffe:keyGenerator” tModel – they are entitled to do so, and this publication does not violate the policy of the registry (assuming it has not already been published) – it is a simple save_tModel call from the publishing API. Then they can transfer ownership of this tModel to the publisher who wants it, using the custody and ownership transfer API. Once the new publisher owns the key generator tModel, they are entitled to publish entities with keys within the partition of that keyGenerator, including new key generator tModels derived from it.
It is worth noting that once a publisher transfers a keyGenerator tModel to another publisher, they give up the right to generate new control over all keys derived from it. They are no longer entitled to publish keys from within its partition. Thus transferring a keyGenerator tModel to another publisher effectively makes a hole in the set of keys a publisher may publish. That’s quite deliberate: only one publisher, the one owning the keyGenerator tModel, can publish keys derived directly from that keyGenerator. This is how keyGenerators ensure the uniqueness of the derived keys.
There is one minor point to clarify: it is quite likely that a registry will want to control the publication of domain key keyGenerator tModels. It seems appropriate that these may only be published by a publisher who is an administrator of the registry, although this is not formally stated in the UDDI specification.
QUESTIONS:
Might a registry enact a policy that denies some publishers permission to transfer keyGenerator tModels to other publishers?
Do we need to formalize the concept of an administrative publisher, one who can publish domain key keyGenerator tModels?