uddiKey及其分配策略研究

彭立

（湖南第一師范學(xué)院信息科學(xué)與工程系，湖南長沙 410205）

uddiKey及其分配策略研究

彭立

（湖南第一師范學(xué)院信息科學(xué)與工程系，湖南長沙 410205）

UDDI要求實(shí)體在發(fā)布時必須被分配一key作為其唯一性標(biāo)識。UDDI V2的key由UDDI節(jié)點(diǎn)生成，key的可讀性差且不可移植。UDDI V3的uddiKey方案規(guī)定key必須采用URI格式，并通過引入key分區(qū)概念使發(fā)布者為新實(shí)體分配key成為可能。通過研究uddiKey的格式及兩種分配方式，探討了解決老版本key問題的辦法，提出了單注冊中心和多注冊中心環(huán)境下的uddiKey分配策略，其核心內(nèi)容是確保key的唯一性，特別是在多注冊中心環(huán)境下，需要一根注冊中心負(fù)責(zé)key空間的分配。

uddiKey；分配策略；key分區(qū)；key移植

一、引言

在Web服務(wù)技術(shù)框架中，統(tǒng)一描述、發(fā)現(xiàn)和集成（UDDI）為分布式環(huán)境中的Web服務(wù)提供了信息發(fā)布與查詢的標(biāo)準(zhǔn)。UDDI要求實(shí)體在發(fā)布時必須被分配一鍵值（key）作為其唯一性標(biāo)識。UDDI V2用通用唯一識別碼（UUID）作為key，它是由UDDI節(jié)點(diǎn)（以下簡稱為節(jié)點(diǎn)）通過ISO/IEC 11578：1996標(biāo)準(zhǔn)算法生成的十六進(jìn)制字符串[1]，該算法確保了數(shù)據(jù)的唯一性，但生成的key可讀性差且不可移植[2]。UDDI V3的uddiKey方案采用URI（統(tǒng)一資源標(biāo)識符）作為key格式，并通過引入key分區(qū)的概念支持發(fā)布者為新實(shí)體分配key，從而為解決老版本key問題提供了理論依據(jù)，并使多UDDI注冊中心（以下簡稱為注冊中心）數(shù)據(jù)共享成為可能。

二、uddiKey格式

UDDI V3的uddiKey方案對key格式進(jìn)行了重新定義（下文中key和uddiKey可以混用），規(guī)定所有的key必須是符合RFC2396標(biāo)準(zhǔn)的URI。用ABNF標(biāo)記法表示的uddiKey語法格式的主要內(nèi)容如下所示[3]：

derivedKey=nonKeyGeneratorKey“：”KSS（Key Specific String，KSS由大小寫字符、數(shù)字和其他URI允許的符號組成，但不能為字符串“keygenerator”）

keyGeneratorKey=nonKeyGeneratorKey“：keygenerator”

該語法表明，uddiKey分為nonKeyGeneratorKey和keyGeneratorKey兩類，nonKeyGeneratorKey分為uuidkey、domainKey和derivedKey，其中，uuidKey本質(zhì)上就是UUID，如uddi：4CD7E4BC-648B-426D-9936-443EAAC8AE23；domainKey由域名加前綴“uuid：”構(gòu)成，如uddi：tempuri.com；derivedKey采用遞歸定義，通過在nonKeyGeneratorKey后添加冒號和KSS擴(kuò)展而成，如uddi：tempuri.com：fish。通過分析不難發(fā)現(xiàn)，uuidKey與老版本UUID key兼容，可讀性較差；而domainKey和基于domainKey擴(kuò)展而成的derivedKey具有較好的可讀性，從而便于理解和記憶，例如：example公司發(fā)布的名為buying的Web服務(wù)，其key為基于域名的derivedKey，如uddi：example.org：buyingservice，該key既明確了公司的名稱，也說明了服務(wù)的用途。

三、uddiKey分配方式

UDDI V2只允許節(jié)點(diǎn)為實(shí)體分配key，而UDDI V3規(guī)定，key既可由節(jié)點(diǎn)分配，也可由發(fā)布者分配[4]。

（一）節(jié)點(diǎn)分配key

實(shí)體發(fā)布時，如果發(fā)布者沒有為其分配key，節(jié)點(diǎn)必須為其分配。節(jié)點(diǎn)生成的key屬于uuidKey類型。因?yàn)閡uidKey本質(zhì)上就是UUID，因此，節(jié)點(diǎn)分配的key是全球唯一的，但無法移植。

考慮一具體場景：Example公司想在其私有注冊中心中發(fā)布一businessEntity，為了便于客戶查詢，它采用非標(biāo)準(zhǔn)分類法GLN對businessEntity進(jìn)行分類，為此它先發(fā)布了代表該分類法的tModel，并在businessEntity中對該tModel進(jìn)行引用。為了被更多的客戶發(fā)現(xiàn)，Example公司決定在公共注冊中心再次發(fā)布該businessEntity，同樣，它仍須先發(fā)布代表GLN分類法的tModel。如果key由節(jié)點(diǎn)生成，兩個注冊中心為tModel分配的key肯定不同，即該tModel無法在key不變的情況下被兩個注冊中心共享。因此，在businessEntity再次發(fā)布時，其分類信息便會丟失。

解決該問題的一個辦法是，于businessEntity再次發(fā)布之前，將對該tModel的引用（keyedReference的tModelKey屬性）設(shè)為公共注冊中心為其分配的key。此辦法盡管可行，但增加了管理負(fù)擔(dān)，且延誤了再次發(fā)布的時間；而讓發(fā)布者為該tModel分配key，成為了另一種更為有效的解決辦法。

（二）發(fā)布者分配key

URI具有分層結(jié)構(gòu)，uddiKey空間被分成不重疊、分層管理的key分區(qū)（以下簡稱為分區(qū)），每個分區(qū)可分別由一個發(fā)布者控制，發(fā)布者可在自己擁有的分區(qū)內(nèi)生成key，這是發(fā)布者分配key的基本思路。分區(qū)創(chuàng)建及key分配的規(guī)則總結(jié)如下[2]：

（1）節(jié)點(diǎn)管理員是根分區(qū)“uddi：”的擁有者，他可在根分區(qū)內(nèi)分配key；根分區(qū)不能轉(zhuǎn)讓給其他發(fā)布者。

（2）只有分區(qū)擁有者才能在自己的分區(qū)內(nèi)為新實(shí)體分配key，構(gòu)造key的方法為：在分區(qū)名后面添加冒號和KSS來構(gòu)造key。

（3）分區(qū)擁有者可在其分區(qū)下方創(chuàng)建子分區(qū)，方法為：通過在其分區(qū)內(nèi)某個key的后面添加保留字符串“：keygenerator”來構(gòu)造 keyGeneratorKey，然后發(fā)布一key為該keyGeneratorKey的key generator tModel，該keyGeneratorKey指明了子分區(qū)名。例如：節(jié)點(diǎn)管理員通過發(fā)布一key為uddi：example1.org：keygenerator的tModel為example1公司創(chuàng)建了子分區(qū)uddi：example1.org。

（4）分區(qū)擁有者可通過轉(zhuǎn)讓 key generator tModel所有權(quán)的方式將分區(qū)轉(zhuǎn)讓給其他發(fā)布者。例如：節(jié)點(diǎn)管理員創(chuàng)建了key為uddi：example1.org：keygenerator的tModel，將該tModel的所有權(quán)轉(zhuǎn)讓給example1公司后，example公司就成為了分區(qū)uddi：example1.org的擁有者。

（5）一旦key generator tModel的所有權(quán)被轉(zhuǎn)讓，其原始擁有者就不能在該tModel指定的分區(qū)內(nèi)分配key。

對以上規(guī)則進(jìn)行分析可得出結(jié)論：key分區(qū)必須逐層創(chuàng)建；開始時，除節(jié)點(diǎn)管理員之外的其他發(fā)布者并不擁有任何分區(qū)，應(yīng)讓節(jié)點(diǎn)管理員為其創(chuàng)建頂層分區(qū)（根分區(qū)的下一層子分區(qū)），然后將該分區(qū)轉(zhuǎn)讓給他，此后他才能在其分區(qū)內(nèi)分配key，并在其分區(qū)下方創(chuàng)建子分區(qū)。

圖1為發(fā)布者分配key的實(shí)例，每個盒子代表了一個分區(qū)，分區(qū)名位于盒子上方，內(nèi)部包含了發(fā)布者分配的key。節(jié)點(diǎn)管理員首先為example公司發(fā)布了 key為 uddi：example.org：keygenerator的key generatortModel，然后將該tModel的所有權(quán)轉(zhuǎn)讓給他，使其成為分區(qū)uddi：example.org的擁有者，接著該公司發(fā)布了名為buying的Web服務(wù)，為其分配key值uddi：example.org：buying；因?yàn)楣鞠螺牭膄inance部門希望作為發(fā)布者單獨(dú)發(fā)布服務(wù)，公司通過發(fā)布 key為 uddi：example.org：finance：generator的 key generator tModel創(chuàng)建了子分區(qū)uddi：example.org：finance，然后將該 tModel的所有權(quán)轉(zhuǎn)讓給finance部門，使其成為子分區(qū)的擁有者，最后，finance部門發(fā)布了名為 payroll的Web服務(wù)，為其分配key值uddi：example.org：fi-nance：payroll。

圖1 發(fā)布者分配key的實(shí)例

為確保發(fā)布者分配的key不發(fā)生沖突，一方面，節(jié)點(diǎn)必須阻止發(fā)布具有相同key的key generator tModel，從而避免key分區(qū)沖突；另一方面，發(fā)布者必須自己維護(hù)其分區(qū)內(nèi)key的唯一性，否則，發(fā)布操作可能會覆蓋之前已經(jīng)存在的數(shù)據(jù)。

由發(fā)布者分配key可確保key具有更好的可讀性，更重要的是，可為在不同注冊中心發(fā)布的相同實(shí)體分配相同的key（key移植），從而使多注冊中心數(shù)據(jù)共享成為可能。

四、uddiKey分配策略

在uddiKey方案的框架內(nèi)對key分配策略進(jìn)行規(guī)定，可規(guī)范并統(tǒng)一節(jié)點(diǎn)和發(fā)布者分配key的行為。

（一）單注冊中心環(huán)境下的uddiKey分配策略

對節(jié)點(diǎn)規(guī)定如下：

（1）實(shí)體（除key generator tModel之外）發(fā)布時，如果發(fā)布者沒有為其分配key，節(jié)點(diǎn)必須為其分配，key類型為uuid。

（2）key generator tModel發(fā)布時，如果發(fā)布者沒有為其分配key，節(jié)點(diǎn)應(yīng)予以阻止。

（3）節(jié)點(diǎn)應(yīng)阻止任何key類型為keyGeneratorKey的非tModel實(shí)體的發(fā)布。

（4）節(jié)點(diǎn)應(yīng)阻止任何發(fā)布者在不屬于自己的分區(qū)內(nèi)為新實(shí)體分配key。

（5）節(jié)點(diǎn)管理員應(yīng)根據(jù)其他發(fā)布者的需要為其創(chuàng)建頂層分區(qū)，分區(qū)名基于其所在公司的域名，然后將頂層分區(qū)轉(zhuǎn)讓給他。

（6）節(jié)點(diǎn)必須阻止發(fā)布具有相同key的key generator tModel。

（7）節(jié)點(diǎn)應(yīng)接受發(fā)布者為新實(shí)體分配的key，如果該key滿足以下兩個條件：

a.該key位于某個key generator tModel指定的分區(qū)，且該tModel沒有隱藏。

b.發(fā)布者與a中tModel的擁有者是同一人。

對發(fā)布者規(guī)定如下：

（1）除節(jié)點(diǎn)管理員之外的其他發(fā)布者應(yīng)根據(jù)需要請求節(jié)點(diǎn)管理員為其創(chuàng)建頂層分區(qū)，并通過分區(qū)轉(zhuǎn)讓的方式獲取頂層分區(qū)的擁有權(quán)。

（2）發(fā)布者可在其擁有的分區(qū)內(nèi)為新實(shí)體分配key，但應(yīng)保證key的唯一性和可讀性。

（3）發(fā)布者可在其擁有的分區(qū)下方創(chuàng)建子分區(qū)。

（4）發(fā)布者可將其擁有的分區(qū)轉(zhuǎn)讓給其他發(fā)布者。

（二）多注冊中心環(huán)境下的uddiKey分配策略

數(shù)據(jù)共享是多注冊中心互聯(lián)的主要目的。由發(fā)布者分配key可實(shí)現(xiàn)key移植，從而成為多注冊中心數(shù)據(jù)共享的必要手段。然而，在某注冊中心成功發(fā)布的實(shí)體，有可能在其它注冊中心發(fā)布失敗，因?yàn)榘l(fā)布者為該實(shí)體分配的key可能會與其它注冊中心內(nèi)已有的key發(fā)生沖突。為確保實(shí)體在所有注冊中心成功發(fā)布，需要一種機(jī)制來保證key分配的全局唯一性，避免key沖突。為此，可考慮將某個注冊中心設(shè)為根注冊中心，它具有key空間的分配權(quán)，其它注冊中心依靠根注冊中心分配分區(qū)和保證分區(qū)的唯一性，其它注冊中心成為根注冊中心的附屬注冊中心。依靠根注冊中心作為key空間分配的仲裁者，所有注冊中心的分區(qū)都不會發(fā)生沖突，但在某注冊中心的key空間內(nèi)，key的唯一性應(yīng)由它的節(jié)點(diǎn)和發(fā)布者負(fù)責(zé)維護(hù)。

附屬注冊中心的節(jié)點(diǎn)（簡稱為附屬節(jié)點(diǎn)）在投入運(yùn)行前，應(yīng)通過以下方式向根注冊中心申請key空間：根注冊中心節(jié)點(diǎn)管理員在其節(jié)點(diǎn)內(nèi)為附屬節(jié)點(diǎn)創(chuàng)建頂層分區(qū)，分區(qū)名基于附屬節(jié)點(diǎn)的域名，如uuid：affiliatedNode1，一旦創(chuàng)建成功，則意味著附屬節(jié)點(diǎn)分區(qū)的唯一性得到保證；附屬節(jié)點(diǎn)管理員在自己節(jié)點(diǎn)內(nèi)再次創(chuàng)建該頂層分區(qū)，該頂層分區(qū)就成為了附屬節(jié)點(diǎn)的key空間。一旦獲得了key空間，附屬節(jié)點(diǎn)和其發(fā)布者為新實(shí)體分配的key就必須位于該空間范圍內(nèi)。

在以上分析的基礎(chǔ)上，可對多注冊中心環(huán)境下的uddiKey分配策略做出規(guī)定。根注冊中心的uddikey分配策略與單注冊中心完全相同。對于附屬注冊中心，因?yàn)楦綄俟?jié)點(diǎn)的key空間不再是根分區(qū)，而變成了頂層分區(qū)，因此需對節(jié)點(diǎn)和發(fā)布者的行為做出相應(yīng)修改。將單注冊中心環(huán)境下對節(jié)點(diǎn)規(guī)定的第（1）條改為：實(shí)體（除key generator tModel之外）發(fā)布時，如果發(fā)布者沒有為其分配key，節(jié)點(diǎn)必須為其分配，key格式為domainKey：uuid；第（5）條改為：節(jié)點(diǎn)管理員應(yīng)根據(jù)其他發(fā)布者的需要在節(jié)點(diǎn)分區(qū)下方為其創(chuàng)建子分區(qū)，分區(qū)名基于其所在公司的域名，如uuid：affiliatedNode1：example，然后將該分區(qū)轉(zhuǎn)讓給他。將單注冊中心環(huán)境下對發(fā)布者規(guī)定的第（1）條改為：除節(jié)點(diǎn)管理員之外的其他發(fā)布者應(yīng)根據(jù)需要請求節(jié)點(diǎn)管理員為其創(chuàng)建節(jié)點(diǎn)分區(qū)的下一層子分區(qū)，并通過分區(qū)轉(zhuǎn)讓的方式獲取該分區(qū)的擁有權(quán)。其它規(guī)定保持不變。

五、結(jié)束語

uddiKey方案的主要目的是使發(fā)布者能為新實(shí)體指定“易于理解”的key并促進(jìn)注冊中心的互操作。key分區(qū)概念的引入，使發(fā)布者為新實(shí)體分配key成為可能，從而可以避免老版本key可讀性差且不可移植的缺點(diǎn)。單注冊中心、多注冊中心環(huán)境下key分配策略的核心內(nèi)容是確保key的唯一性，特別是在多注冊中心環(huán)境下，需要有一根注冊中心負(fù)責(zé)key空間的分配。

key移植是多注冊中心數(shù)據(jù)共享的基礎(chǔ)。在以后的工作中，將基于多注冊中心環(huán)境下的key分配策略對多注冊中心互聯(lián)模型展開研究。此外，本文提出的key分配策略對UDDI V3的實(shí)現(xiàn)具有較好的指導(dǎo)作用。

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

[責(zé)任編輯：胡 偉]