UDDI バージョン 3 の仕様では、キーに使用できるスペースが拡張されています。 推奨される UDDI スキームに従っている任意の URI (Universal Resource Identifier) をエンティティー・キーにすることができます。 レジストリー・ポリシーに応じて、UDDI レジストリーだけではなく、エンティティーのパブリッシャーによってキーを割り当てることもできます。
エンティティー・キーは、UDDI レジストリー内のエンティティー処理に使用される ID です。 各エンティティー (例えば、businessEntity、businessService、bindingTemplate、または tModel など) には、 最初に UDDI レジストリーに公開されるときに生成または割り当てられる固有の ID があります。 キーは、特定のレジストリー内では固有でなければなりません。 UDDI バージョン 1 およびバージョン 2 では、スペースは Universal Unique Identifier (UUID) に限られます。 UDDI バージョン 3 の仕様では、エンティティー・キーは推奨される UDDI スキームに従っている任意の URI にすることができます。
UDDI バージョン 3 の仕様では、レジストリー・ポリシーに応じて、UDDI レジストリーだけでなく、エンティティーのパブリッシャーによってキーを割り当てることもできます。 これらの違いによって、キーの一意性の維持とキー・スペースの管理に問題が発生します。
UDDI バージョン 3 レジストリーは、 推奨される UDDI スキームをインプリメントします。 詳しくは、UDDI バージョン 3 仕様のセクション 4.4 を参照してください。(http://uddi.org/pubs/uddi_v3.htm). このスキームでは、 キーのフォーマット、有効な文字、およびキー・スペースの概念が定義されています。
UDDI バージョン 3 レジストリーでは、 キーは任意の URI であり、255 文字までに制限されています。次の図は、 UDDI キー・スキームのさまざまなキー・タイプを示したものです。
UDDI レジストリーのインスタンスは、ルート・レジストリーとして構成することも、関連レジストリーとして構成することもできます。
ルート・レジストリーは、独自のルート・キー・ジェネレーターを定義することで、独自のルート・キー・スペースを定義します。 これにより、レジストリーが管理するキー・スペース全体が定義されます。 レジストリーが生成するすべてのキーはこのキー・スペース内にあります。 ポリシーによって許可されていれば、パブリッシャーは、<rootkeygenerator>:<subdivisionIdentifier>:keygenerator 形式の 新しい tModel キー・ジェネレーターを公開してこのキー・スペースのサブディビジョンを要求し、割り振られたキー・スペースのサブディビジョン内 (<rootkeygenerator>:<subdivisionIdentifier>:<kss>) にある以後の公開要求に、パブリッシャーが指定したキーを組み込むことができます。
キーの衝突を避けるため、関連レジストリーは、 まず、関連付けたいルート・レジストリーに tModel:keygenerator 要求を実行依頼し、次にこのルート・レジストリーのキー・スペースのサブディビジョンを独自のルート・キー・ジェネレーターとして使用することにより、独自のルート・キー・ジェネレーターを確立する必要があります。 こうすることで、関連レジストリーが生成または受諾したキーと、 ルート・レジストリー・キー・スペースにあるその他のキーとの間で衝突が起きることを確実に防げます。
キーの一意性を維持するため、単純なルールを適用しています。 すなわち、レジストリーは独自のルート・キー・ジェネレーターが定義したキー・スペース内でのみ新しいキーを生成し、 パブリッシャーが (以前に成功した tModel の「tModel:keygenerator」公開要求の結果として) 所有するキー・スペースの サブディビジョン内にあるパブリッシャー指定のキーのみを受け入れるというルールです。
with a Root keygenerator: uddi:aPrivateRegistryKeySpaceIdentifier:keygenerator generates Entity Keys of format: uddi:aPrivateRegistryKeySpaceIdentifier:<uuid> depending on Policy, accepts tModel:keygenerator requests from Publishers for ‘top-level’ subdivisions of format: uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:keygenerator
ポリシーによっては、パブリッシャーは、ルート・レジストリーのキー・スペースの最上位のサブディビジョンに対する要求を、独自の使用を目的として実行依頼することができます。 (この場合のポリシーは、レジストリーがパブリッシャー指定のキーをサポートするかどうかと、特定のパブリッシャーが自身のユーザー資格を使用してキー・スペースに要求の実行依頼を行うことができるかどうかです。)
ルート・レジストリーのキー・スペース内にある最上位レベル・サブディビジョンと同様に、パブリッシャーはキー・スペースのサブディビジョンを追加作成することができます。
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:keygenerator
以降のサブディビジョン a に対する要求が正常に実行されるのは、要求しているパブリッシャーが、上位のサブディビジョン (この場合は uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:keygenerator) の tModel を以前に要求し、所有している場合です。
パブリッシャーによるルート・レジストリーのキー・スペースのサブ ディビジョン要求が正常に実行された後、そのパブリッシャーは以後の公開要求で パブリッシャー提供のキーとして使用するために生成するキーが、そのサブディビ ジョン内で固有のものとなるよう、独自のスキームを確立して保守する必要があり ます。
有効なスキームは、割り振られたキー・スペース・サブディビジョン内で、固有の派生キーを生成する必要があります。 例えば、固有の (増分する) 数値索引などを含めます。
前の例に続いて、単純な例を示します。
uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:keygenerator valid keys are: uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:1 uddi:aPrivateRegistryKeySpaceIdentifier:aPublisherSubdivisionIdentifier:a:2