OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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