Katharine,
I will raise this on today's OASIS UDDI
TC call when we discuss the currrent change request to solicit feedback.
I believe the issue around affiliation
has been that an affiliated registry is only trusted to generate keys within
a given key partition and the proposal below would change that relationship
significantly. While an exception could be made for the keys in the
UUID format, external UUID generation is still an issue of trusting the
affliliate (to have a good UUID algorithm at least).
I do believe, however, that the current
framework for key generation policy should be flexible enough to allow
this behavior already:
9.4.2
Registry General Keying Policy
UDDI Version 3 introduces the ability for
publishers to generate entity keys. This feature preserves the requirement
for distinct keys while enabling keys to be created in a safe, efficient
manner.
A registry MUST have a policy on key format
and key generation. The registry MUST have a policy on data integrity or
how the keyspace is protected from unauthorized modification.
Registries MAY use whatever keying policies
they wish subject only to the constraints that keys MUST be URIs, and the
registry MUST have policies that prevent key collisions.
Andrew Hately
IBM Austin
UDDI Development, Emerging Technologies
Katharine Jagger <>
02/13/2003 06:41 AM
To
cc
Subject
Re: [uddi-spec] Change request
for deriving V2 key directly when V3 key 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
John Colgrave <> on 07/02/2003 10:57:18
To:
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:
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
