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- ），男，湖南汨羅人，湖南第一師范學院講師。

[責任編輯：胡 偉]