jUDDI devs,
I've been pouring over the spec and I think I've settled on the publisher-assigned key generation policy we should go with. This has been an annoying concept to research because the spec always talks about a "publisher" owning a key generator (and other entities, for that matter), yet it has no explanation (or any related data structure) for what a "publisher" is. So, if a "publisher" wants to publish entities with its own keys, it has to publish a tModel keygenerator entity. When it finally publishes an entity that requires key gen, you have to tie the keyGenerator tModel to the publisher in a proprietary way (the key generator is an entity that can't really be tied to the standard UDDI entities). jUDDI provides the "publisher" structure to act as a kind of user and ownership device, but I've always viewed that as a simple solution that should be made as transparent as possible so developers can implement their own user-based solution. With the advent of the key-generation feature, it's becoming harder to keep the "publisher" transparent. But, hopefully, the policy I've come up with will allow me to do so. Here it is: 1) A "root" publisher will be installed with jUDDI. This publisher is an Administrator and owns the top-level domain key generator (ex. "uddi:juddi.apache.org:keygenerator"). This top level domain is configurable by the jUDDI implementer. 2) A "uddi" publisher will be installed with jUDDI that owns all the keyGenerators described in the spec (among many other pre-defined entities). This publisher will only be used for UDDI-specific publishing which will really only occur whenever the spec changes. 3) Other publishers can publish as many keyGenerators as they want, BELOW the root key generator (ex. "uddi:juddi.apache.org:mykeygen:keygenerator"). 4) Once a key generator is "reserved", no other publisher can own a key generator in the same "key space". 5) When a publisher provides a key for a new entity, it will be checked against all the key generators it owns to ensure it is valid. It is up to the publisher to organize the keys as they see fit (consistent with spec). 6) When publisher has no key generators, yet tries to publish a new entity without a key, key is generated using root key generator and appending a UUID. 7) When publisher has key generators, yet tries to publish a new entity without a key, key is generated using root key generator and appending a UUID. It is not up to jUDDI to determine which key generator they might want to use. I believe this policy captures the spirit of the specification without being too complicated. If you have any questions, concerns or think there's something I missed, please let me know. I plan on starting to implement this policy in short order. Thanks, Jeff
