uddiKey及其分配策略研究

彭立

（湖南第一师范学院信息科学与工程系，湖南长沙 410205）

uddiKey及其分配策略研究

彭立

（湖南第一师范学院信息科学与工程系，湖南长沙 410205）

UDDI要求实体在发布时必须被分配一key作为其唯一性标识。UDDI V2的key由UDDI节点生成，key的可读性差且不可移植。UDDI V3的uddiKey方案规定key必须采用URI格式，并通过引入key分区概念使发布者为新实体分配key成为可能。通过研究uddiKey的格式及两种分配方式，探讨了解决老版本key问题的办法，提出了单注册中心和多注册中心环境下的uddiKey分配策略，其核心内容是确保key的唯一性，特别是在多注册中心环境下，需要一根注册中心负责key空间的分配。

uddiKey；分配策略；key分区；key移植

一、引言

在Web服务技术框架中，统一描述、发现和集成（UDDI）为分布式环境中的Web服务提供了信息发布与查询的标准。UDDI要求实体在发布时必须被分配一键值（key）作为其唯一性标识。UDDI V2用通用唯一识别码（UUID）作为key，它是由UDDI节点（以下简称为节点）通过ISO/IEC 11578：1996标准算法生成的十六进制字符串[1]，该算法确保了数据的唯一性，但生成的key可读性差且不可移植[2]。UDDI V3的uddiKey方案采用URI（统一资源标识符）作为key格式，并通过引入key分区的概念支持发布者为新实体分配key，从而为解决老版本key问题提供了理论依据，并使多UDDI注册中心（以下简称为注册中心）数据共享成为可能。

二、uddiKey格式

UDDI V3的uddiKey方案对key格式进行了重新定义（下文中key和uddiKey可以混用），规定所有的key必须是符合RFC2396标准的URI。用ABNF标记法表示的uddiKey语法格式的主要内容如下所示[3]：

derivedKey=nonKeyGeneratorKey“：”KSS（Key Specific String，KSS由大小写字符、数字和其他URI允许的符号组成，但不能为字符串“keygenerator”）

keyGeneratorKey=nonKeyGeneratorKey“：keygenerator”

该语法表明，uddiKey分为nonKeyGeneratorKey和keyGeneratorKey两类，nonKeyGeneratorKey分为uuidkey、domainKey和derivedKey，其中，uuidKey本质上就是UUID，如uddi：4CD7E4BC-648B-426D-9936-443EAAC8AE23；domainKey由域名加前缀“uuid：”构成，如uddi：tempuri.com；derivedKey采用递归定义，通过在nonKeyGeneratorKey后添加冒号和KSS扩展而成，如uddi：tempuri.com：fish。通过分析不难发现，uuidKey与老版本UUID key兼容，可读性较差；而domainKey和基于domainKey扩展而成的derivedKey具有较好的可读性，从而便于理解和记忆，例如：example公司发布的名为buying的Web服务，其key为基于域名的derivedKey，如uddi：example.org：buyingservice，该key既明确了公司的名称，也说明了服务的用途。

三、uddiKey分配方式

UDDI V2只允许节点为实体分配key，而UDDI V3规定，key既可由节点分配，也可由发布者分配[4]。

（一）节点分配key

实体发布时，如果发布者没有为其分配key，节点必须为其分配。节点生成的key属于uuidKey类型。因为uuidKey本质上就是UUID，因此，节点分配的key是全球唯一的，但无法移植。

考虑一具体场景：Example公司想在其私有注册中心中发布一businessEntity，为了便于客户查询，它采用非标准分类法GLN对businessEntity进行分类，为此它先发布了代表该分类法的tModel，并在businessEntity中对该tModel进行引用。为了被更多的客户发现，Example公司决定在公共注册中心再次发布该businessEntity，同样，它仍须先发布代表GLN分类法的tModel。如果key由节点生成，两个注册中心为tModel分配的key肯定不同，即该tModel无法在key不变的情况下被两个注册中心共享。因此，在businessEntity再次发布时，其分类信息便会丢失。

解决该问题的一个办法是，于businessEntity再次发布之前，将对该tModel的引用（keyedReference的tModelKey属性）设为公共注册中心为其分配的key。此办法尽管可行，但增加了管理负担，且延误了再次发布的时间；而让发布者为该tModel分配key，成为了另一种更为有效的解决办法。

（二）发布者分配key

URI具有分层结构，uddiKey空间被分成不重叠、分层管理的key分区（以下简称为分区），每个分区可分别由一个发布者控制，发布者可在自己拥有的分区内生成key，这是发布者分配key的基本思路。分区创建及key分配的规则总结如下[2]：

（1）节点管理员是根分区“uddi：”的拥有者，他可在根分区内分配key；根分区不能转让给其他发布者。

（2）只有分区拥有者才能在自己的分区内为新实体分配key，构造key的方法为：在分区名后面添加冒号和KSS来构造key。

（3）分区拥有者可在其分区下方创建子分区，方法为：通过在其分区内某个key的后面添加保留字符串“：keygenerator”来构造 keyGeneratorKey，然后发布一key为该keyGeneratorKey的key generator tModel，该keyGeneratorKey指明了子分区名。例如：节点管理员通过发布一key为uddi：example1.org：keygenerator的tModel为example1公司创建了子分区uddi：example1.org。

（4）分区拥有者可通过转让 key generator tModel所有权的方式将分区转让给其他发布者。例如：节点管理员创建了key为uddi：example1.org：keygenerator的tModel，将该tModel的所有权转让给example1公司后，example公司就成为了分区uddi：example1.org的拥有者。

（5）一旦key generator tModel的所有权被转让，其原始拥有者就不能在该tModel指定的分区内分配key。

对以上规则进行分析可得出结论：key分区必须逐层创建；开始时，除节点管理员之外的其他发布者并不拥有任何分区，应让节点管理员为其创建顶层分区（根分区的下一层子分区），然后将该分区转让给他，此后他才能在其分区内分配key，并在其分区下方创建子分区。

图1为发布者分配key的实例，每个盒子代表了一个分区，分区名位于盒子上方，内部包含了发布者分配的key。节点管理员首先为example公司发布了 key为 uddi：example.org：keygenerator的key generatortModel，然后将该tModel的所有权转让给他，使其成为分区uddi：example.org的拥有者，接着该公司发布了名为buying的Web服务，为其分配key值uddi：example.org：buying；因为公司下辖的finance部门希望作为发布者单独发布服务，公司通过发布 key为 uddi：example.org：finance：generator的 key generator tModel创建了子分区uddi：example.org：finance，然后将该 tModel的所有权转让给finance部门，使其成为子分区的拥有者，最后，finance部门发布了名为 payroll的Web服务，为其分配key值uddi：example.org：fi-nance：payroll。

图1 发布者分配key的实例

为确保发布者分配的key不发生冲突，一方面，节点必须阻止发布具有相同key的key generator tModel，从而避免key分区冲突；另一方面，发布者必须自己维护其分区内key的唯一性，否则，发布操作可能会覆盖之前已经存在的数据。

由发布者分配key可确保key具有更好的可读性，更重要的是，可为在不同注册中心发布的相同实体分配相同的key（key移植），从而使多注册中心数据共享成为可能。

四、uddiKey分配策略

在uddiKey方案的框架内对key分配策略进行规定，可规范并统一节点和发布者分配key的行为。

（一）单注册中心环境下的uddiKey分配策略

对节点规定如下：

（1）实体（除key generator tModel之外）发布时，如果发布者没有为其分配key，节点必须为其分配，key类型为uuid。

（2）key generator tModel发布时，如果发布者没有为其分配key，节点应予以阻止。

（3）节点应阻止任何key类型为keyGeneratorKey的非tModel实体的发布。

（4）节点应阻止任何发布者在不属于自己的分区内为新实体分配key。

（5）节点管理员应根据其他发布者的需要为其创建顶层分区，分区名基于其所在公司的域名，然后将顶层分区转让给他。

（6）节点必须阻止发布具有相同key的key generator tModel。

（7）节点应接受发布者为新实体分配的key，如果该key满足以下两个条件：

a.该key位于某个key generator tModel指定的分区，且该tModel没有隐藏。

b.发布者与a中tModel的拥有者是同一人。

对发布者规定如下：

（1）除节点管理员之外的其他发布者应根据需要请求节点管理员为其创建顶层分区，并通过分区转让的方式获取顶层分区的拥有权。

（2）发布者可在其拥有的分区内为新实体分配key，但应保证key的唯一性和可读性。

（3）发布者可在其拥有的分区下方创建子分区。

（4）发布者可将其拥有的分区转让给其他发布者。

（二）多注册中心环境下的uddiKey分配策略

数据共享是多注册中心互联的主要目的。由发布者分配key可实现key移植，从而成为多注册中心数据共享的必要手段。然而，在某注册中心成功发布的实体，有可能在其它注册中心发布失败，因为发布者为该实体分配的key可能会与其它注册中心内已有的key发生冲突。为确保实体在所有注册中心成功发布，需要一种机制来保证key分配的全局唯一性，避免key冲突。为此，可考虑将某个注册中心设为根注册中心，它具有key空间的分配权，其它注册中心依靠根注册中心分配分区和保证分区的唯一性，其它注册中心成为根注册中心的附属注册中心。依靠根注册中心作为key空间分配的仲裁者，所有注册中心的分区都不会发生冲突，但在某注册中心的key空间内，key的唯一性应由它的节点和发布者负责维护。

附属注册中心的节点（简称为附属节点）在投入运行前，应通过以下方式向根注册中心申请key空间：根注册中心节点管理员在其节点内为附属节点创建顶层分区，分区名基于附属节点的域名，如uuid：affiliatedNode1，一旦创建成功，则意味着附属节点分区的唯一性得到保证；附属节点管理员在自己节点内再次创建该顶层分区，该顶层分区就成为了附属节点的key空间。一旦获得了key空间，附属节点和其发布者为新实体分配的key就必须位于该空间范围内。

在以上分析的基础上，可对多注册中心环境下的uddiKey分配策略做出规定。根注册中心的uddikey分配策略与单注册中心完全相同。对于附属注册中心，因为附属节点的key空间不再是根分区，而变成了顶层分区，因此需对节点和发布者的行为做出相应修改。将单注册中心环境下对节点规定的第（1）条改为：实体（除key generator tModel之外）发布时，如果发布者没有为其分配key，节点必须为其分配，key格式为domainKey：uuid；第（5）条改为：节点管理员应根据其他发布者的需要在节点分区下方为其创建子分区，分区名基于其所在公司的域名，如uuid：affiliatedNode1：example，然后将该分区转让给他。将单注册中心环境下对发布者规定的第（1）条改为：除节点管理员之外的其他发布者应根据需要请求节点管理员为其创建节点分区的下一层子分区，并通过分区转让的方式获取该分区的拥有权。其它规定保持不变。

五、结束语

uddiKey方案的主要目的是使发布者能为新实体指定“易于理解”的key并促进注册中心的互操作。key分区概念的引入，使发布者为新实体分配key成为可能，从而可以避免老版本key可读性差且不可移植的缺点。单注册中心、多注册中心环境下key分配策略的核心内容是确保key的唯一性，特别是在多注册中心环境下，需要有一根注册中心负责key空间的分配。

key移植是多注册中心数据共享的基础。在以后的工作中，将基于多注册中心环境下的key分配策略对多注册中心互联模型展开研究。此外，本文提出的key分配策略对UDDI V3的实现具有较好的指导作用。

[1]OASIS.UDDI Version 2.03Data Structure Reference [EB/OL].（2002-01-19）.http：//uddi.org/pubs/DataS-tructure-V2.03-Published-20020719.pdf.

[2]OASIS.Understanding Key Partitions[EB/OL].http：//www.oasis-open.org/committees/uddi-spec/doc/tns. htm#keypartition.

[3]OASIS.UDDI Version 3.0.2[EB/OL].（2004-10-19）. http：//uddi.org/pubs/uddi-v3.0.2-20041019.pdf.

[4]OASIS.UBR Operators Council Announces Beta Release of UDDI Business Registry for UDDI Version 3.0[EB/OL].（2003-08-25）.http：//xml.coverpages.org/ni 2003-08-25-a.html

Research on UddiKey and Its Assignment Strategy

PENG Li
（Department ofInformation Science and Engineering，Hunan First Normal University，Changsha，Hunan 410205）

UDDI requires that an entity should be assigned akey as its identifierforuniqueness when published. UDDI V2keys are generated by UDDI nodes，so they lack readability and are non-portable.UDDI V3uddiKey scheme prescribesthat the form of keys must be URI，and the introduction of the conception of key partition make it possible for a new entity to be assigned a key by a pulisher.By studying uddiKey formats and its two assignment means，the solution to the old-version key issueswasdiscussed and the key assignment policiesin asingle-registry and a multi-registry environment were suggested，the core of which is the guarantee of key uniqueness，especially in a multi-registry environment，aroot registry isneeded to take responsibility forkey space assignment.

UddiKey；assignment strategy；key partition；uniqueness；readability；portable key

TP301.6

A

1674-831X（2010）05-0148-04

2010-04-10

彭 立（1974- ），男，湖南汨罗人，湖南第一师范学院讲师。

[责任编辑：胡 伟]