[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [uddi-spec] Change request for deriving V2 key directly when V3key is a UUID key
Dear All This is my first post to this mailing list so please forgive me any errors! I am however following a number of INs / CRs with interest, and would like to offer some comments on CR-023. I think these changes are positive because they mean that entities with v3 uuidKeys will (presumably subject to policy as John mentions) always have a v1/2 key that consists of the same uuid, whether the v3 key was created by migration of a v1/2 entity, or by new publication of a v1/2/3 entity. However this does not address key mapping / hashing in affiliate registries. I think further improvements could be made in order to facilitate entity promotion from affiliate registries. In the tables below I have tried to outline the various key mapping and hashing algorithms to be used in different circumstances (root or affiliate registries, migration or new publication), both as the spec currently stands and as I understand CR-023. Perhaps it would be useful to put a similar table into the CR? Currently (Section 10.1.3.2), in an affiliate registry (e.g. with top-level key partition "uddi:example.com:keyGenerator") , when a v1/v2 key is migrated to v3, the new v3 key is formed by appending "uddi:example.com:" to the start of the key (after removing "uuid:" from the start of tModelKeys). This algorithm is reversible within the affiliate registry itself, but upon promotion of the entity to a root registry, the v2 key will change from its original uuid key to the hash of the key "uddi:example.com:<uuid>". This situation does not occur (in the spec as it stands) with newly published entities, whose v1/2 keys are already the hash of the v3 key. With the proposed changes, it is not only migrated keys whose v1/2 key will change upon promotion to the root registry, but also v1/2 keys of newly published v1/2/3 entities (because the v1/2 keys are no longer the hash of the v3 key). However, a simple solution exists: When an affiliate registry migrates its v1/2 entities to v3, instead of prefixing each key with, for example, "uddi:example.com:", it simply prefixes each key with "uddi:". When an affiliate registry publishes a new entity with a node-assigned key, it simply generates a <uuid> and assigns that to be the v2 key, and "uddi:<uuid>" to be the v3 key. An affiliate registry may still choose to generate all its node-assigned keys in the partition "uddi:example.com:keyGenerator", but in this case the v1/2 key is generated via the hashing algorithm. (The spec states that a node may choose to generate node-assigned keys in the partition of any keyGenerator it owns.) These steps ensure that when entities are promoted to a root registry, neither the v3 nor the v1/2 key will change. Publishers in a root registry are allowed (so long as policy permits) to publish uuidKeys in this way, so the affiliate does not need to possess an extra keyGenerator tModel to achieve this. This solution does of course mean that an affiliate registry will contain keys which are outside the affiliate's top-level key partition which it obtained from the root registry. However, as I understand it, the purpose of obtaining such a keyGenerator from the root registry is to ensure uniqueness of publisher-assigned keys. This is not necessary in the case of uuids. Please let me know your opinions on whether or not this is a plausible solution. Regards, Katharine Jagger. Possible implementations below: Currently the spec proposes the following: A. Root Registry i) Migration v1/2 to v3. Just add "uddi:" to front of key. (First remove "uuid:" from tModelKeys.) Reversible algorithm. v1/2 v3 <uuid> uddi:<uuid> SAME uuid. ii) New Publication v1/2/3 node-assigned uuid keys. First generate the v3 key, then hash to produce the v2 key. Algorithm NOT reversible. v1/2 v3 <uuid> uddi:<uuid> DIFFERENT uuid. B. Affiliate Registry, eg. with top-level key partition "uddi:example.com:keyGenerator". i) Migration v1/2 to v3. Just add "uddi:example.com:" to front of key. (First remove "uuid:" from tModelKeys.) Reversible algorithm WITHIN THE AFFILIATE REGISTRY. v1/2 key is NOT maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:example.com:<uuid> SAME uuid. ii) New Publication v1/2/3 node-assigned uuid keys. First generate the v3 key, then hash to produce the v2 key. Algorithm NOT reversible. v1/2 key is maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:example.com:<uuid> DIFFERENT uuid. The Implementation Note proposes the following (changes from spec in red): A. Root Registry i) Migration v1/2 to v3. Just add "uddi:" to front of key. (First remove "uuid:" from tModelKeys.) Reversible algorithm. v1/2 v3 <uuid> uddi:<uuid> SAME uuid. ii) New Publication v1/2/3 node-assigned uuid keys. Generate a single uuid, which is the same for v1/2 and v3 keys. Reversible algorithm. v1/2 v3 <uuid> uddi:<uuid> SAME uuid. B. Affiliate Registry, eg. with top-level key partition "uddi:example.com:keyGenerator". i) Migration v1/2 to v3. Just add "uddi:example.com:" to front of key. (First remove "uuid:" from tModelKeys.) Reversible algorithm WITHIN THE AFFILIATE REGISTRY. v1/2 key is NOT maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:example.com:<uuid> SAME uuid. ii) New Publication v1/2/3 node-assigned uuid keys. Generate a single uuid, which is the same for v1/2 and v3 keys. Reversible algorithm. v1/2 key is NOT maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:example.com:<uuid> SAME uuid. My suggestion is as follows: A. Root Registry Same as implementation note. B. Affiliate Registry, eg. with top-level key partition "uddi:example.com:keyGenerator". i) Migration v1/2 to v3. Just add "uddi:" to front of key. (First remove "uuid:" from tModelKeys.) Reversible algorithm in both root and affiliate registries. v1/2 key is maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:<uuid> SAME uuid. ii) New Publication v1/2/3 node-assigned uuid keys. Generate a single uuid, which is the same for v1/2 and v3 keys. Reversible algorithm in both root and affiliate registries. v1/2 key is maintained upon promotion to root registry. v1/2 v3 <uuid> uddi:<uuid> SAME uuid. -------------------------------------------------------------------------------- Katharine Jagger - Software Engineer IBM WebSphere UDDI Registry Web Services Development MP 208, IBM UK Labs, Hursley, Winchester, SO21 2JN A4133; Tel: Ext. +44 (0)1962 815196; Int. 245196 kjagger@uk.ibm.com John Colgrave <colgrave@hursley.ibm.com> on 07/02/2003 10:57:18 To: uddi-spec@lists.oasis-open.org cc: Subject: Re: [uddi-spec] Change request for deriving V2 key directly when V3 key is a UUID key I think it is reasonable to short-circuit the production of a V1/V2 key from a V3 uuidKey. I am not sure I understand the relevance of "root key space" and "root registry" - is it not simply the case that if a V3 save is made that results in a V3 uuidKey then the mapping should apply and not the hashing, but if a UUID is used in any other context then the hashing would still apply? I would add something to the beginning of 10.1.1 rather than letting the reader wade through the algorithm and then tell them that it does not apply to V3 uuidKeys. Do we not need a new policy definition? I cannot see anything that says what approach is used to generate V1/V2 keys during a V3 save much less allowing for V3 uuidKeys to be treated differently. John ----- Original Message ----- From: Andrew Hately To: uddi-spec@lists.oasis-open.org Sent: Friday, February 07, 2003 1:06 AM Subject: [uddi-spec] Change request for deriving V2 key directly when V3 key is a UUID key Please find attached a change request for review. Andrew Hately IBM Austin UDDI Development, Emerging Technologies
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC