專利名稱：Web服務(wù)設(shè)備和方法
技術(shù)領(lǐng)域：
本發(fā)明大體上涉及UDDI注冊以及web服務(wù)，尤其是用于為此類服務(wù)提供實際效果的方法、設(shè)備和系統(tǒng)。
背景技術(shù)：
UDDI(通用描述、發(fā)現(xiàn)和集成)是一個標準集，被定義用于使那些使用web服務(wù)的應(yīng)用程序可以快速、輕松和動態(tài)地彼此進行交互作用。UDDI被用于創(chuàng)建一個獨立于平臺的、開放的框架結(jié)構(gòu)，用于使用因特網(wǎng)以及可操作的注冊中心來描述服務(wù)、發(fā)現(xiàn)交易和集成系統(tǒng)服務(wù)。詳細情況可查閱web站點www.UDDI.org。
UDDI注冊為使用web服務(wù)構(gòu)建的系統(tǒng)提供了有力的支持。圖1a示意性地描述了基本的web服務(wù)和UDDI概念。圖1b示意性地描述了用于所述web服務(wù)環(huán)境的簡化的協(xié)議棧。UDDI為web服務(wù)信息提供了信息庫，并且其本身也是通過web服務(wù)提供的。
UDDI允許應(yīng)用程序公布如何在web上進行交互。每種web服務(wù)都是應(yīng)用邏輯的自描述、自包含的模塊化單元，其通過因特網(wǎng)連接為其他應(yīng)用提高了某些系統(tǒng)功能。應(yīng)用程序通過普遍存在的web協(xié)議和數(shù)據(jù)格式來訪問web服務(wù)、因此不需要關(guān)心每個web服務(wù)是如何實現(xiàn)的。web服務(wù)能與其他的web服務(wù)混合和匹配，以運行一個較大的工作流程或商業(yè)交易。
UDDI標準描述一個專用的信息庫，用于管理web服務(wù)類型，商業(yè)組織的描述，以及如何調(diào)用網(wǎng)絡(luò)服務(wù)的細節(jié)。這些標準不必詳細說明標準是怎樣實現(xiàn)的，也不必詳細說明其實施方式是否包括使用數(shù)據(jù)庫、目錄或任何其他介質(zhì)的存儲器。
在負責UDDI標準的組織所管理的網(wǎng)站上(http//www.uddi.org/faqs.html)有很多被經(jīng)常提問的問題。這些問題之一是″一個UDDI注冊能被建造于LDAP之上或基于LDAP嗎？″在回答中，該網(wǎng)站披露在UDDI和目錄之間沒有明確的關(guān)系。UDDI規(guī)范限定注冊的實施細節(jié)。UDDI規(guī)范定義一種基于XML的數(shù)據(jù)模型和一組SOAPAPI，以訪問和操縱數(shù)據(jù)模型。SOAP API定義了UDDI出現(xiàn)的狀態(tài)。UDDI的實施可以建立在一個LDAP目錄上，只要其遵從規(guī)定的狀態(tài)。因此迄今為止所有的UDDI實施方式都建立在關(guān)系數(shù)據(jù)庫上。
需要注意的是，諸如X.500和LDAP的目錄技術(shù)是可擴展的、通用的數(shù)據(jù)存儲，也是最常用的管理用戶和資源的關(guān)聯(lián)語言。這些是已經(jīng)良好開發(fā)的技術(shù)，被廣泛采用，并且被認為非常穩(wěn)定和值得信賴。
然而，在目錄上實施UDDI標準(參見www.uddi.org)需要解決許多問題。UDDI標準留下許多重要問題仍未解決，諸如●UDDI標準定義了許多對象，其中一些對象通過層次結(jié)構(gòu)而相關(guān)聯(lián)，但UDDI沒有定義一個包含所有對象的層次結(jié)構(gòu)。
例如企業(yè)服務(wù)對象位于企業(yè)實體對象之下，而綁定模板對象位于企業(yè)服務(wù)之下。附圖2示出了這種層次結(jié)構(gòu)的一個例子。企業(yè)實體對象被標記為21，企業(yè)服務(wù)對象被標記為22，而綁定模板對象被標記為23。還需注意的是例如被標記為24的TModel對象按層次與這些對象沒有層次關(guān)系。還有其他的概念例如發(fā)布者聲明不是按等級定義的。
●創(chuàng)建該技術(shù)要求的有效的實施方式以允許用戶改變由他/她控制的那些對象，●創(chuàng)建一種有效的實施方式，以允許UDDI注冊進行分布，●創(chuàng)建一種有效的實施方式，其改善了可管理性，以及搜索和更新的性能，
●如何以有效的方式表示復(fù)雜UDDI對象。例如企業(yè)實體，企業(yè)服務(wù)，綁定模板和/或TModel具有混合的重復(fù)要素。而這些重復(fù)要素又包含了其他的重復(fù)要素。例如，一個企業(yè)實體可以包含聯(lián)系方式，而該聯(lián)系方式可以包含地址。地址可包含地址行和電話號碼。圖13示例了在企業(yè)實體中一個相對復(fù)雜的對象的UDDI概念。企業(yè)實體對象131，包括例如一系列屬性132，如AuthorizedName，BusinessKey，以及名稱。名稱具有一個或多個名稱字段133，例如“文本”或“名稱”自身中固有的。同樣還有“語言”。此處可能有一個或多個這種字段133，●如何為包含在重復(fù)要素中的特定項目提供相對快速的搜索，●如何在目錄對象的層次結(jié)構(gòu)中表示UDDI信息和要求，●如何以有效的方式管理UDDI對象以及所有與它們有關(guān)的信息的刪除，以及●如何優(yōu)化在搜索操作期間中間搜索結(jié)果集合的構(gòu)建，以便在考慮了目錄存儲介質(zhì)限制的情況下，使得目錄訪問和迭代的存儲器內(nèi)操作被最小化。實際上，目錄條目可以被存儲并以任意的次序返回，并且目錄結(jié)果太大而難于進行排序，●如何以有效的方式表示有關(guān)發(fā)布者聲明的數(shù)據(jù)，●如何創(chuàng)建發(fā)布者聲明的有效的實施方式，特別是查找相關(guān)企業(yè)的實施方式，●如何根據(jù)關(guān)系來有效搜索發(fā)布者聲明，●如何管理該發(fā)布者聲明的有效性，●如何限制為一個企業(yè)實體所創(chuàng)建和刪除的聲明是由企業(yè)實體的擁有者做出的，●如何高效地按照UDDI標準中的定義來管理屬性的有關(guān)集合，●如何定義屬性和對象來提高搜索的性能。已經(jīng)建議了各種UDDI方案。然而，沒有一個可以被認為解決了至少上述問題。例如，一種方案提供了UDDI對象到目錄對象的相對簡單的映射，而沒有考慮產(chǎn)生有效的商業(yè)實施的復(fù)雜性和優(yōu)化。仍然不清楚在這種方案中多個UDDI服務(wù)(特別是find_series)是怎樣有效實施的。
例如，圖14示意性地示出了在一企業(yè)實體中相對復(fù)雜的對象的Novell表示。該企業(yè)實體對象141，包括例如一系列屬性142，每個屬性都具有“類型”和“數(shù)值”。如圖所示，授權(quán)名字(AuthorizedName)的值是“Bill”，企業(yè)鍵(BusinessKey)的值是“890.obale.890....”，而名稱(Name)具有多個值143，144，即en#CAIN#CATSUDDI(圖13)和Novell(圖14)的示例不是用于Web服務(wù)的有效表示。
因而，需要解決上面提到的常見問題以及其他的問題，以便基于目錄提供一個相對可擴展的、有效的和可靠的UDDI實施。

發(fā)明內(nèi)容
一種應(yīng)用在Web服務(wù)系統(tǒng)中的方法，包括在第一企業(yè)實體之下提供至少一個第一企業(yè)服務(wù)，在第二企業(yè)實體之下提供企業(yè)服務(wù)投影，該企業(yè)服務(wù)投影反映了在第二企業(yè)實體之下的至少一個第一企業(yè)服務(wù)。
一種應(yīng)用在Web服務(wù)系統(tǒng)中的包括計算機可執(zhí)行代碼的計算機記錄介質(zhì)，包括用于在第一企業(yè)實體之下提供至少一個第一企業(yè)服務(wù)的代碼，在第二企業(yè)實體之下提供企業(yè)服務(wù)投影的代碼，該企業(yè)服務(wù)投影反映了在第二企業(yè)實體之下的至少一個第一企業(yè)服務(wù)。


結(jié)合附圖，參考對優(yōu)選實施例的以下描述，可以更好地理解本發(fā)明更多的對象，優(yōu)點和方面，其中圖1a示意性地示出了一些Web服務(wù)和UDDI概念；圖1b示意性地示出了用于Web服務(wù)環(huán)境下的簡化的協(xié)議棧；
圖2示意性地示出了現(xiàn)有技術(shù)的層次結(jié)構(gòu)；圖3示意性地示出了現(xiàn)有技術(shù)的目錄服務(wù)模型；圖4示意性地示出了根據(jù)本發(fā)明實施例，使用X.500目錄技術(shù)實施的UDDI服務(wù)模型的基礎(chǔ)組件；圖5示意性地示出了根據(jù)本發(fā)明的實施例的服務(wù)投影；圖6用示意圖示出了根據(jù)本發(fā)明實施例，在綁定模板和TModel之間的關(guān)系；圖7用示意圖示出了根據(jù)本發(fā)明實施例，TModel如何創(chuàng)建兩個實體之間的關(guān)系；圖8用示意圖示出了根據(jù)本發(fā)明實施例，增加發(fā)布者聲明的請求的邏輯表示；圖9示出了根據(jù)本發(fā)明用于UDDI數(shù)據(jù)對象的構(gòu)造程序的邏輯表示；圖10示意性地示出了在用戶對象之下設(shè)置企業(yè)實體；圖11示意性地示出了在用戶對象之上設(shè)置域?qū)ο?；圖12示意性地示出了根據(jù)本發(fā)明實施例的該方案的概述；圖13示意性地示出了根據(jù)相關(guān)技術(shù)在企業(yè)實體中一個相對復(fù)雜的對象的UDDI概念；圖14示意性地示出了在一企業(yè)實體中相對復(fù)雜的對象的Novell表示；圖15示意性地示出了介紹了用于企業(yè)實體中一個相對復(fù)雜的對象的表示的層次結(jié)構(gòu)；圖16用示意圖示出了根據(jù)本發(fā)明實施例的綁定模板層次的子結(jié)構(gòu)；圖17示例示出了被展平和/或合并的綁定模板子結(jié)構(gòu)；以及圖18是一種能夠?qū)嵤┍景l(fā)明各方面的計算機系統(tǒng)的方框圖。
具體實施例方式
在描述由附圖所示的本發(fā)明優(yōu)選實施例時，為了清楚起見采用了特定的術(shù)語。然而，本申請并不限制在如此選擇的具體術(shù)語上，應(yīng)該理解每個具體要素包括了以相似方式工作的所有等同技術(shù)。
圖18示出了可以實施本發(fā)明的方法和系統(tǒng)的計算機系統(tǒng)的實例。本發(fā)明的系統(tǒng)和方法可以通過運行于計算機系統(tǒng)上的軟件應(yīng)用程序來實施，例如，大型機、個人電腦(PC)、便攜式電腦、服務(wù)器等等。所述軟件應(yīng)用程序可存儲在可由該計算機系統(tǒng)本地訪問的記錄介質(zhì)上(例如軟盤、緊致盤、硬盤等)，或者可以遠離計算機系統(tǒng)而經(jīng)由硬連線或無線連線連接到網(wǎng)絡(luò)上(例如，局域網(wǎng)或因特網(wǎng))。
在圖18中示出了能夠?qū)嵤┰摲椒ê拖到y(tǒng)的計算機系統(tǒng)的實例。該計算機系統(tǒng)總體上被稱為系統(tǒng)180，可以包括一個中央處理器(CPU)182，存儲器184(例如隨機訪問存儲器(RAM))，打印機接口186，顯示單元188，(LAN)局域網(wǎng)數(shù)據(jù)傳輸控制器190，局域網(wǎng)接口192，網(wǎng)絡(luò)控制器194，內(nèi)部總線196，以及一個或多個輸入設(shè)備198(例如鍵盤，鼠標等等)，如圖所示，該系統(tǒng)180可以經(jīng)由一條鏈路202連接到數(shù)據(jù)存儲器，例如硬盤200。
以下總結(jié)了本發(fā)明各種實施例的一些顯著的特征以及由其提供一些優(yōu)點。
根據(jù)本發(fā)明的一個實施例，在不同用戶層上創(chuàng)建了一個信息庫層(repository layer)因此各信息庫可以位于不同的服務(wù)器上。這個信息庫層包括一個或多個目錄節(jié)點，它們共同構(gòu)成了該目錄的前綴。這也可以被稱為信息庫的“域(Domain)”或“名稱(Name)”。這樣做的優(yōu)點是，它提供了一個單獨的場所來保持關(guān)于域的信息。該節(jié)點的名稱表示這一目錄的前綴。
可以創(chuàng)建一個用戶對象來保持表示UDDI帳戶的數(shù)據(jù)。這樣做的優(yōu)點是，它提供了一個單獨的場所來保持有關(guān)用戶/帳戶的信息。
企業(yè)實體對象可以被安排在用戶對象之下，企業(yè)服務(wù)對象在企業(yè)實體對象之下，而綁定模板對象在企業(yè)服務(wù)對象之下。這樣做的優(yōu)點在于在用戶對象層之上的信息庫或者“域”層可以被布置在一起或者被邏輯連接到一起。域?qū)涌梢员辉O(shè)置成多個級別，例如不同的國家AU，US，EP等，或者按照大洲來組織。
另一個優(yōu)點是該特征可以通過使用X500目錄的分布式特征來實現(xiàn)。例如，為了實施上述特征，將“世界(World)”或“公司(Corporation)”節(jié)點設(shè)置在虛擬目錄樹的頂端，將一個被唯一命名的節(jié)點設(shè)置在每個UDDI子樹(UDDI名稱空間)的頂端。這些“節(jié)點”前綴對于用戶來說是不可見的，但是這些節(jié)點前綴允許UDDI信息庫對目錄的分布進行平衡。
根據(jù)本發(fā)明的一個實施例，企業(yè)實體對象可以是用戶對象的一個子對象。在企業(yè)實體、企業(yè)服務(wù)和綁定模板的層次結(jié)構(gòu)之上具有用戶/帳戶使得每個用戶具有自己的子樹。這提高了可管理性和安全性。可以很容易地將用戶限制為只能修改和/或控制其自己的子樹。通過使用目錄子樹搜索操作，性能也得到了提高。
根據(jù)一個實施例，由用戶定義的TModel是用戶對象的一個子對象，因而易于實現(xiàn)安全性。因為用戶只能修改和/或控制其自己的子樹，這提高了可管理性和安全性。通過使用目錄的子樹搜索操作，性能也得到了提高。
本發(fā)明的一個實施例中，使用X.500/LDAP目錄技術(shù)來表示UDDI環(huán)境的“映射”。特別地，已經(jīng)發(fā)現(xiàn)X.500和LDAP目錄技術(shù)的層次結(jié)構(gòu)適于UDDI環(huán)境。精心地設(shè)計附加的要素(例如用戶對象)可以使層次結(jié)構(gòu)更適于UDDI環(huán)境的需要。
在本發(fā)明的全文中，術(shù)語“目錄(Directory)”包括X.500、LDAP以及類似的技術(shù)；術(shù)語“用戶(Users)”被理解為也包含“帳戶(Account)”，反之亦然；而術(shù)語“信息庫(Repository)”被理解為包括“目錄前綴(Directory pre-fix)”、“域(Domain)”和/或“節(jié)點(Node)”，反之亦然。
Web服務(wù)最初被視為組織之間的服務(wù)，例如企業(yè)、合伙人、顧客、供應(yīng)商之間的服務(wù)。在這里，UDDI被視為這些組織所提供的服務(wù)的一個信息庫。
現(xiàn)在很明顯，Web服務(wù)和UDDI在一個企業(yè)內(nèi)非常有用，可以用于集成組織內(nèi)部的應(yīng)用。同樣明顯的是，Web服務(wù)和UDDI可用于從一個給定的賣主那里將產(chǎn)品集成到一個產(chǎn)品集中。在商業(yè)環(huán)境之外的其它領(lǐng)域也仍然適用，例如大型教研機構(gòu)以及許多其他的非企業(yè)實體的情況。
以下的描述盡管是關(guān)于一個企業(yè)來描述的，但也同樣適用于任何類型的環(huán)境，特別適用于上面提到的環(huán)境類型。
一個企業(yè)UDDI注冊是一種可在該企業(yè)內(nèi)部展開的服務(wù)，以便發(fā)布內(nèi)部消耗的信息和服務(wù)。另外，可以對企業(yè)UDDI服務(wù)進行平衡，以提供其他的功能，例如用于分布式應(yīng)用的配置發(fā)現(xiàn)。
為了滿足在企業(yè)內(nèi)部以及與合伙人之間快速和簡單地集成商業(yè)處理的愿望，推動了Web服務(wù)的發(fā)展。一種有效使用Web服務(wù)的要素是公共UDDI注冊，它允許軟件要素動態(tài)地發(fā)現(xiàn)因特網(wǎng)上的適當服務(wù)并與之連接。網(wǎng)絡(luò)服務(wù)也能夠集成企業(yè)內(nèi)部的商務(wù)處理。在這種情況下，UDDI注冊中心可以變成組織的基礎(chǔ)結(jié)構(gòu)(例如一個重要的企業(yè)應(yīng)用)的一部分，并因此供應(yīng)最高等級的安全性、性能、可靠性和可管理性。目錄技術(shù)提供了理想的基礎(chǔ)架構(gòu)來支持企業(yè)UDDI注冊的嚴格要求。
企業(yè)UDDI注冊可以被定義為對UDDI提供了與標準兼容的支持，但除此之外還解決了四個方面的展開問題。這些方面包括安全性—限制只有授權(quán)用戶才能訪問；分布性—以支持大規(guī)模配置；用于一個實際生產(chǎn)系統(tǒng)的可管理性；以及有效性—以滿足服務(wù)級協(xié)定。
對于特定企業(yè)配置來說，高度的安全性是一個重要的要求。公共的UDDI注冊只是用于幫助任何人發(fā)現(xiàn)可用服務(wù)的單純目的。而UDDI注冊只是用于使適合的人發(fā)現(xiàn)這些服務(wù)的目的。這是一個重要的區(qū)別。
因特網(wǎng)UDDI注冊被認為不適于在企業(yè)內(nèi)展開Web服務(wù)。例如，與工資單系統(tǒng)或者與雇員利益管理接口的Web服務(wù)的定義不能被張貼到因特網(wǎng)的UDDI注冊。
安全性要求也意味著，即使一個內(nèi)部配置的UDDI注冊也提供了嚴格的訪問控制。這是因為UDDI注冊本質(zhì)上提供了指導(dǎo)，教導(dǎo)可以做什么以及怎樣去做。UDDI注冊能夠?qū)θ魏慰捎肳eb服務(wù)提供企業(yè)級的說明，以及對完整定義了這些服務(wù)的可編程接口的WSDL提供了指導(dǎo)。這為應(yīng)用程序開發(fā)者和黑客們都提供了高生產(chǎn)效率的工具。
因此，希望限制對于金融敏感或者機密(例如醫(yī)療記錄)系統(tǒng)的接口定義進行的訪問。即便是在開發(fā)組織內(nèi)部，把關(guān)于具體Web服務(wù)之信息的訪問權(quán)限制到被批準的人員也是很明智的。
在企業(yè)內(nèi)部使用不安全的UDDI注冊，或通過外聯(lián)網(wǎng)與選定的商務(wù)伙伴使用不安全的UDDI注冊都是極端危險的。由于可自由下載的工具，專業(yè)水平不是很好的人也可以訪問和使用Web服務(wù)。任何實際的企業(yè)解決方案可以實施一個標準的UDDI服務(wù)，具有對于有關(guān)Web服務(wù)的信息進行透明控制訪問的能力。
考慮到分布性，在多數(shù)情況下，UDDI注冊的初始展開可以小規(guī)模地進行。然而，隨著Web服務(wù)要求的增長，大規(guī)模展開也變得更為常見。此外，隨著UDDI注冊的新功能的發(fā)現(xiàn)，也會促進注冊使用和展開。
地理分布的組織內(nèi)的較大規(guī)模的實施和使用推動了在單個組織內(nèi)實施多個UDDI注冊。這種趨于分布式注冊的演進使得對于任何單個注冊中心來說能夠動態(tài)地同其他注冊中心進行交互以為它們的請求服務(wù)而變得十分苛刻。一旦建立起來，內(nèi)部注冊中心之間的通信可以超出防火墻的范圍，延伸到值得信賴的商業(yè)伙伴處的注冊中心，甚至是因特網(wǎng)UDDI注冊。
目前認為有兩種基本的方法來解決注冊中心之間通信的需要。一種方案是復(fù)制(REPLICATION)，其中同一個條目的名稱空間位于多個服務(wù)器上。另一個方案是分配(DISTRIBUTION)，其中互聯(lián)的服務(wù)器具有不同的條目的域名空間，然而它們作為一個邏輯服務(wù)來操作。
雖然這兩個方案常被人誤以為是相似的，但它們有顯著區(qū)別。
在復(fù)制方案中，在每一個需要查詢信息的服務(wù)器上復(fù)制信息。這是一種相對簡單的解決方案，甚至有點過分簡單，但是它引入了同步更新的技術(shù)要求，而且隨著注冊數(shù)目以及其內(nèi)容量的增漲，這將會增加網(wǎng)絡(luò)擁塞。復(fù)制技術(shù)最適于服務(wù)器數(shù)目很少、信息量很少并且變化不多的環(huán)境。對于企業(yè)配置來說，復(fù)制有益于在一個容錯備援(fail-over)環(huán)境中維護備份信息庫。使用復(fù)制技術(shù)時，保持那些在地理上或者功能上分布的服務(wù)器之間的同步是非常困難的。
在分布式方案中，信息在每個參與的服務(wù)器上被邏輯表示，但只在單個的注冊中心內(nèi)存儲。只有在需要時才將查詢分配給其它的注冊中心。因而保證了所返回的信息是最新的信息。這樣提供了一個更新點，并消除了復(fù)制技術(shù)本身具有的同步和帶寬消耗問題。真正的分布被認為是服務(wù)器之間的可擴展連接的一種解決方案。
對于企業(yè)UDDI注冊，分布通常在兩種情況下使用。第一種是具有地理上分散的部門的組織，每個部門產(chǎn)生新的UDDI條目和使用UDDI服務(wù)。盡管能夠運行單一集中式的UDDI注冊，但是帶寬限制和時區(qū)差別通常會使得其難于實現(xiàn)，甚至于不能實行。
分布式注冊提供了靈活的、可擴展的解決方案。在這種情況下，每個參與的部門具有一個獨立的注冊中心，并且每個注冊中心把其它的注冊中心視為其自身內(nèi)容的邏輯組成部分。注冊服務(wù)考慮到所有的連接細節(jié)，而客戶不需要考慮地理因素。
第二種情況是，企業(yè)需要將其內(nèi)部的UDDI系統(tǒng)連接到可信任的合伙人的UDDI系統(tǒng)上，或者連接到公共因特網(wǎng)注冊中心上。特別地，當連接到公共注冊中心時，復(fù)制將會產(chǎn)生問題。因特網(wǎng)運營商也許不希望將它們的注冊的一部分復(fù)制到該企業(yè)的內(nèi)部注冊中心去。同樣，使用分布式方案可以解決這一問題。目前，不存在用于分布式的UDDI標準，而各種復(fù)制的建議方案又十分復(fù)雜。應(yīng)當有一種解決方案可以提供UDDI分布式方案的優(yōu)點而不需要修改該標準。
關(guān)于可管理性，由于要素在企業(yè)內(nèi)執(zhí)行關(guān)鍵任務(wù)的功能，因此UDDI應(yīng)該滿足性能和可靠性要求。它不僅僅是開發(fā)人員的一種有力工具?？蛻舳说淖x取訪問將會是UDDI注冊最為頻繁和在時間上要求最嚴格的使用情形。對性能進行優(yōu)化以獲得最大處理量，而查詢的響應(yīng)時間會受到較復(fù)雜的搜索操作的影響。性能將不會因注冊的規(guī)模和復(fù)雜性增加而降低。支持該UDDI注冊的數(shù)據(jù)存儲應(yīng)當有工業(yè)實用性，并且完全支持交易和自動恢復(fù)。另外，UDDI服務(wù)器應(yīng)具有高度的可用性，并支持諸如網(wǎng)絡(luò)的容錯備援(fail-over)以及熱備份的特性。系統(tǒng)管理員應(yīng)當具有能力使得UDDI注冊易于維護、監(jiān)視與控制。這些能力包括無需脫機服務(wù)就能改變控制、規(guī)則和設(shè)置的動態(tài)配置(DYNAMICCONFIGURATION)，在線備份和調(diào)整(ONLINE BACKUPS ANDTUNING)，以獲得較高的可用性，管理控制(ADMINISTRATIVECONTROLS)，以停止注冊中心的“搜索(trawling)”，并防止拒絕服務(wù)的攻擊，通過SNMP或者其他類型的告警機制進行監(jiān)控(MONITORING)，對于安全、統(tǒng)計、查詢和更新信息對單獨的記錄文件進行審計和診斷(AUDITING AND DIAGNOSTICS)，以及支持復(fù)制、分布和路由的選擇。
已經(jīng)提出了許多基于開發(fā)人員的UDDI注冊技術(shù)。這些技術(shù)可以為小的開發(fā)團體提高有益的特性，但并不是真正的產(chǎn)品質(zhì)量級的管理系統(tǒng)。Web服務(wù)開發(fā)正在迅速增長，因此也相應(yīng)地需要這樣一種企業(yè)質(zhì)量級注冊，其能夠快速地擴展以支持當前的Web服務(wù)配置。
UDDI注冊提供了一種服務(wù)。這種服務(wù)依賴于許多應(yīng)用程序。對于在線商務(wù)來說，重要的是這種服務(wù)必須一直存在。例如，UDDI注冊需要提供99.99％可用性的服務(wù)等級協(xié)定。為了實現(xiàn)這種可用性，可以在兩個或者多個機器上復(fù)制UDDI注冊，并且提供機制來確保這些機器之間的同步，如果任一機器變得不能利用，則將輸入的查詢自動路由到一個可用機器上。
如已經(jīng)指出的，UDDI可以被視為與電話目錄服務(wù)十分類似。因此，信息存儲的目錄模型是一個良好基礎(chǔ)，根據(jù)它創(chuàng)建了UDDI注冊服務(wù)。該目錄模型已經(jīng)被演變和開發(fā)以滿足基于目錄的服務(wù)的特定需求，其具有企業(yè)級開發(fā)所需的安全性、可擴展性和可靠性。
在應(yīng)用程序體系結(jié)構(gòu)中，上述的大部分項目是在服務(wù)層實現(xiàn)的，而非在數(shù)據(jù)存儲層實現(xiàn)。關(guān)系數(shù)據(jù)庫(RDBMS)是通用工具包，以之為基礎(chǔ)可以構(gòu)建許多不同類型的應(yīng)用。關(guān)系數(shù)據(jù)庫致力于提供可靠的數(shù)據(jù)訪問功能性，而不是終端應(yīng)用所需的額外的服務(wù)功能。
圖3中所示的目錄服務(wù)體系結(jié)構(gòu)示出了將服務(wù)層同其它組件相分離。將接口功能封裝到服務(wù)層31，由此獲得了可重用的服務(wù)基礎(chǔ)組件。一個很好例子就是web服務(wù)器。web服務(wù)器提供了許多功能(HTTP訪問，CGI處理等等)，它們共同構(gòu)成了一種能夠嵌入一個獨立組件的服務(wù)。同樣地，本目錄服務(wù)模型已經(jīng)被開發(fā)為一種特定類型的應(yīng)用程序以提供所需要的功能。在認證和授權(quán)領(lǐng)域，目錄技術(shù)為許多關(guān)鍵的應(yīng)用提供了基礎(chǔ)。
UDDI可以被視為類似于另一種目錄服務(wù)。因此可以了解，由UDDI帶來的許多實施時的問題都可以通過使用目錄技術(shù)得以解決。例如，對目錄進行優(yōu)化以獲得極其有效的查找和搜索操作，這些操作對于UDDI電話目錄操作而言是十分普遍的。
已經(jīng)指出，如果要在一個企業(yè)中成功地開展UDDI服務(wù)，則它必須提供嚴格的安全性、分布性和可管理性等能力。有許多十分相同的屬性已經(jīng)被結(jié)合進企業(yè)級目錄服務(wù)的解決方案中。
一種構(gòu)建企業(yè)UDDI注冊的方法是對已經(jīng)在高性能、實際應(yīng)用中被嘗試和測試過的現(xiàn)有的目錄結(jié)構(gòu)進行擴展。
目錄服務(wù)結(jié)構(gòu)為實現(xiàn)企業(yè)UDDI注冊提供了最理想的工具。這種組合可以提供成功注冊所需的特性。如附圖4所示的UDDI服務(wù)表示了有可能被用于實現(xiàn)這種基礎(chǔ)結(jié)構(gòu)的要素。UDDI語義橋(SEMANTICBRIDGE)41是一種服務(wù)要素，它被設(shè)置在UDDI的SOAP實施42和目錄44所支持的LADP接口43之間。目錄44遞送訪問的信息，并支持安全控制、分布機制、以及管理能力。RDBMS 45提供基礎(chǔ)的物理數(shù)據(jù)管理、交易完整性以及備份和恢復(fù)機制。
UDDI注冊產(chǎn)品可以被直接構(gòu)筑在RDBMS技術(shù)上。關(guān)系數(shù)據(jù)庫雖然在許多方面都很有用和可靠，但是其自身不能滿足目錄處理特有的技術(shù)要求也可能以RDBMS或者其他數(shù)據(jù)存儲系統(tǒng)為基礎(chǔ)，從頭開始來構(gòu)建一種目錄類型的應(yīng)用。然而，這并不是最為有效的途徑。
一種替換的方案是使用目錄服務(wù)模型來提供UDDI注冊和提供這種特定類型的應(yīng)用所需要的功能。通過現(xiàn)代的工業(yè)級目錄服務(wù)甚至可以提供UDDI注冊所需要的更多的功能。UDDI注冊可以被視為具有專用通信和API的目錄服務(wù)。在目錄上提供UDDI服務(wù)可以提供必需的安全性、分布性和管理能力，而無需修改UDDI標準就可以獲得這些益處。
細心地設(shè)計數(shù)據(jù)表示方法將有益于獲得UDDI信息庫所需的功能性和性能。
以下描述引用了各種UDDI概念。對于這些UDDI概念的更為詳細的描述可以通過查閱UDDI規(guī)范(http/www.uddi.org/specification.html)獲得。
對目錄語來說，模式是對于可以被存儲在該目錄中的那些數(shù)據(jù)要素的描述，以及這些要素被連接在一起的方式。它包括了各種可能的屬性的描述(一個屬性占有一頁數(shù)據(jù)段)，不同對象的描述(一個對象是多個屬性的集合)，和可能的對象層次結(jié)構(gòu)的說明。在這個說明中所使用的特別的模式注釋是eTrust目錄中(它是ComputerAssociates International公司的一種產(chǎn)品)所使用的模式?！癳Trust”是Computer Associates International公司的產(chǎn)品名稱和商標。當然也可以使用其他的模式注釋。
本發(fā)明描述了一種模式，其被用于實現(xiàn)一個使用目錄進行數(shù)據(jù)存儲的UDDI信息庫。在這個模式中涉及許多概念。也有許多的技術(shù)被用來提高這種UDDI的執(zhí)行效果。下面對這些概念中的一些進行了簡要描述。對于這些概念和技術(shù)的更為詳細的描述將在隨后描述本發(fā)明的實施例時一起描述。
該模式被設(shè)計用于提供優(yōu)化的操作。該模式設(shè)計中包括對屬性、對象類、條目以及層次結(jié)構(gòu)的定義，以提高操作效果。本模式設(shè)計至少在安全性、性能、可管理性以及分布性方面提供了顯著的益處。
現(xiàn)在將描述該系統(tǒng)的層次結(jié)構(gòu)。X.500目錄支持在內(nèi)部分布，無須在UDDI層次進行任何編碼就能提供一種分布式的UDDI信息庫。每個級別對信息庫的內(nèi)容進行了劃分。這種模式的(任選的)域級別使得該層、每個域以及該層之下的所有條目都可以被設(shè)置在對于UDDI級別的編程為透明的一個獨立的目錄服務(wù)器上。附圖11示出了本發(fā)明這一方面的一個實施例。將在下面對其進行更為詳細的描述。
根據(jù)本發(fā)明的一個實施例，用戶對象可以被置于企業(yè)和TModel對象之上。用戶對象提供了一個空間來存儲與該用戶有關(guān)的信息。它也為該用戶所發(fā)布的所有數(shù)據(jù)提供了一個定位指針。附圖10示出了本發(fā)明這一方面的一個實施例。將在下面對其進行更為詳細的描述。
在這種域/用戶的體系結(jié)構(gòu)系統(tǒng)中有利于實現(xiàn)安全性。UDDI實施可以使得用戶對于它們的數(shù)據(jù)對象的子樹的控制得以實現(xiàn)。
還提供了對用戶控制的條目的搜索。可以通過搜索在用戶對象之下的子樹來提供對受該用戶控制的數(shù)據(jù)所進行的搜索。
可以通過指定一個在綁定模板中產(chǎn)生的TModel來查找一個企業(yè)。這等價于“通過查找x的一個(或多個)孩子來查找x”。換言之，查詢可以是“找到提供某種服務(wù)的所有企業(yè)，這些服務(wù)具有一個綁定模板能夠定位的TModel”。這樣的查詢可以通過查找派生對象的DN(識別名稱)并拋棄不需要的層來完成，以獲得該企業(yè)實體的DN。也有可能以這種方式進行復(fù)制品的刪除。由于本發(fā)明的這種結(jié)構(gòu)的層次特性而帶來了這種查找特征。
可以使用對象類所獨有的屬性來執(zhí)行搜索。這種優(yōu)化具有兩個益處。這簡化了搜索的記錄，并且通過消除“弱”條件而獲得了優(yōu)越的性能。一個“弱”條件是濾波器的一部分，它會返回許多的條目，或者會引用一個是許多條目的一部分的屬性。對于每個名稱都使用相同的屬性名稱的設(shè)計在按照名稱搜索企業(yè)實體時有兩個選擇在搜索中包含對象類或者對搜索結(jié)果進行篩選。前者只有在企業(yè)名稱具有唯一的對象類時才是可能的，并且即便如此，對象類也是一個弱條件，會出現(xiàn)很多次。后者意味著額外的代碼，以及將有可能返回比期望結(jié)果大很多的結(jié)果列表。
例如，考慮一個名為“McKenna’s Testing Services”的公司，其提供了很多Web服務(wù)，在這些服務(wù)的名稱中都包含了“McKenna’s”—則對于名稱中包含有“McKenna’s”的企業(yè)實體進行搜索也將會返回所有這些服務(wù)作為中間結(jié)果。這些中間結(jié)果可以被消除，但是對它們進行的處理降低了系統(tǒng)性能。
因此希望能在搜索中指定一個屬性名稱，并且使得屬性名稱對于要查找的對象類而言是唯一標識的。為了繼續(xù)以上的例子，如果我們指定(euBusinessEntityName＝McKenna’s*)，搜索將會更加簡單。
這種設(shè)計帶來了強搜索，由于它們只對期望區(qū)域進行搜索因此十分有效。強搜索包括只返回很少實體的搜索。目錄可以對euBusinessEntityName屬性進行索引，并且從索引中返回結(jié)果-這樣可以獲得良好的性能，并且避免了對不必要的中間結(jié)果進行的處理。
對于簡單的查詢而言，這種設(shè)計意味著，搜索一個企業(yè)實體是一單個條件，而不是復(fù)合的(這在另一設(shè)計中是必須的)。假設(shè)將名稱屬性稱為euName，而將企業(yè)實體對象稱為euBusinessEntityName。將獲得如下的搜索(&(euName＝McKenna’s*)(oc＝euBusinessEntityName))甚至還有更簡單的設(shè)計，其中所有名稱被存儲在相同的對象類中。這意味著搜索被再次減小到(euName＝McKenna’s*)，但是我們必須辛苦地處理所有名稱的結(jié)果，嘗試定位那些在企業(yè)實體中具有父對象的結(jié)果-后一種方案將容易帶來較差的性能以及比較復(fù)雜的編程。
可以在大小寫敏感的情形中使用陰影(shadow)屬性。使用單個索引來提供大小寫敏感和大小寫不敏感的搜索并不是一件很簡單的事情。一種選擇是按照不區(qū)分大小寫的方式進行索引，然后以區(qū)分大小寫的方式對結(jié)果進行掃描。另一種方案是以區(qū)分大小寫的方式對原始數(shù)據(jù)進行索引，并且添加一個不區(qū)分大小寫的第二屬性(其中存儲有相同的數(shù)據(jù))。然后所需要做的就是選擇適當?shù)膶傩砸员愀鶕?jù)查找質(zhì)量來進行搜索。
在這個設(shè)計中的每個屬性都是單值的。這樣可以獲得有效的索引、較高的性能以及更強的搜索。
使用多值屬性有可能會導(dǎo)致不明確的搜索。也就是說，有可能會得到不直觀并且非計劃中的搜索結(jié)果。假設(shè)一個多值數(shù)值屬性，稱為“n”，包含該屬性實體具有值2和5；當搜索(&(n＜3)(n＞4))時會返回該條目，這種情形很難被預(yù)測。
單值屬性是在強搜索中使用的技術(shù)。強搜索通過索引消除了大部分的候選結(jié)果。強搜索是改善性能的關(guān)鍵所在。
對于服務(wù)投影可以使用別名(Aliases)。這在使用X.500目錄作為數(shù)據(jù)存儲時可以帶來顯著的益處。只使用X.500別名就可以表示服務(wù)投影。這對于確保數(shù)據(jù)完整性很有作用。別名可以訪問原始數(shù)據(jù)，因此對于原始數(shù)據(jù)的任何改變都可以立即通過別名反映出來。如果目錄實施支持別名完整性，則當原始條目被刪掉時別名就會消失，而無需附加的工作。
發(fā)布者斷言是在UDDI標準中定義最不明確的要素之一，因此需要被精心地規(guī)劃。不適當?shù)膶崿F(xiàn)將很容易導(dǎo)致較差的性能。
由于發(fā)布者斷言通常用于fin_relatedBusiness API中，該API被用于搜索與一個指定的企業(yè)實體有關(guān)的所有已完成的發(fā)布者斷言，好的設(shè)計是把每個斷言都至于該斷言所引用的企業(yè)實體之下。
通過計算斷言的狀態(tài)，并將其存儲在斷言對象中?？梢詫⑺阉飨拗频揭淹瓿傻臄嘌?。這意味著返回的結(jié)果不會包含要被刪除的錯誤的引用。
把關(guān)系對象作為輔助的類存儲使得搜索可以消除任何具有不希望的關(guān)系的斷言。如果關(guān)系作為子對象存儲，有不能生成一個單一搜索搜索來解決關(guān)系和斷言完成狀態(tài)。
UDDI鍵值存在時可以為對象命名。UDDI為許多的重要對象類定義鍵值。并且這些鍵值被規(guī)定為保證其是唯一的。這意味著這些鍵值可以被用作為對象的命名屬性。使用UDDI鍵值作為命名屬性意味著不需要分辨命名沖突-如果例如默認名稱被用作為一個企業(yè)實體的命名屬性時這是需要的。
UDDI鍵值不存在時也可以提供鍵值來進行命名。也就是說，并非所有的UDDI對象都具有已定義的鍵值。一個實例是發(fā)布者斷言。對于這些斷言，當前系統(tǒng)提供了一個鍵值，使用與UDDI定義的鍵值相同的算法。該思想的復(fù)用意味著為其它對象而編寫的代碼和結(jié)構(gòu)可以被再次利用。
當一系列的UDDI對象是另一對象的子對象時，則這些子對象的順序十分重要(例如地址行)，分配給子對象的鍵值按數(shù)值單調(diào)增加，因此對這些鍵值進行排序可以獲得期望的順序。這簡化了確保期望順序的處理。
在實際應(yīng)用中，期望鍵值以一種little-endian的方式變化。也就是說，鍵值最左邊的字節(jié)變化最快，因為這樣可以在使用X.500作為數(shù)據(jù)存儲時獲得最佳性能。
UDDI標準在一些主對象類型內(nèi)定義了多個子結(jié)構(gòu)。在許多情況下，這些子結(jié)構(gòu)是任選的，并且可以重復(fù)(在同一對象中可以出現(xiàn)零次、一次或者多次)。一個簡單的實例是名稱子結(jié)構(gòu)，包含一個字符串(名稱)和一個語言標識符。X.500模式定義不支持這種結(jié)構(gòu)化屬性的使用，因此不存在十分清楚的子結(jié)構(gòu)映射。有一些方法被用于在X.500模式中實現(xiàn)這些子結(jié)構(gòu)。
一種將子結(jié)構(gòu)的組件連接成單個屬性的方法是使用某種分隔符來劃分各種要素。這不是最佳的設(shè)計選擇，因為它喪失了單獨對組件進行索引或者搜索的能力，并且增加了在處理這些數(shù)據(jù)時的處理復(fù)雜性。
在本系統(tǒng)中，用于表示子結(jié)構(gòu)的特定設(shè)計被選擇用來優(yōu)化性能和可管理性。所公開的設(shè)計可以使用眾多技術(shù)中的一種或者多種來表述目錄中的子結(jié)構(gòu)。這些技術(shù)可以被歸納為3類一類技術(shù)是將許多的子結(jié)構(gòu)作為子對象處理。名稱是一個很好的例子企業(yè)實體名稱作為企業(yè)實體的子對象而存儲。另一個實例是描述，單個的企業(yè)描述對象是企業(yè)實體對象的子對象。附圖15提供了本發(fā)明這一方面的實施例，并且將在下面更詳細的進行描述。
另一類技術(shù)是展平/合并(flattening/merging)。當至少和另一對象有關(guān)系時，可以將屬性合并到單個對象中。在這種情況下，層次結(jié)構(gòu)被展平，因為兩個對象被組合成一個對象。新對象被合并，因為該新對象包含了來自組成它的對象的屬性的組合。優(yōu)選地，關(guān)系對象的內(nèi)容被提升為父對象。
例如，圖16示例了UDDI關(guān)系圖的一種表示形式。圖17示出了一種目錄層次結(jié)構(gòu)圖，其中通過展平UDDI對象而形成了目錄層次結(jié)構(gòu)。
為了解釋，圖16示出了對象161，它將對象163和對象162聯(lián)系起來。
根據(jù)本發(fā)明的一個實施例，當存在一對一的關(guān)系時，“子對象”被提升。換言之，該部分的層次結(jié)構(gòu)被折疊或者展平，并且合并對象。其結(jié)構(gòu)如圖17中所示。父對象171具有內(nèi)容A1、A2、An以及一個或者多個子對象，子對象9n包括內(nèi)容B1、B2、Bn、C1、C2以及Cn。
另一類技術(shù)是分割(splitting)。例如，在一種特定情況下(OverviewDoc子結(jié)構(gòu))，子結(jié)構(gòu)中包含了不重復(fù)的要素以及重復(fù)的要素。不重復(fù)的要素(OverviewURL)可以被移入到父對象中，而重復(fù)的要素可以作為子對象。
本發(fā)明的另一方面是管理操作。刪除一個TModel就會將其從find_TModel隱藏起來，但并不是從信息庫中刪除它。相應(yīng)地，為了正確處理TModel，可以使用一個隱藏標志。存在該隱藏標志表示該TModel(或者用戶對象)被隱藏。沒有隱藏標志表示其未被隱藏。對于絕大多數(shù)TModel來說情況確實如此，因此該方案是有效的。未隱藏的對象不會占據(jù)空間，也不會使用索引。該目錄將只去索引那些不具有隱藏屬性的條目。這也意味著搜索未被隱藏的TModel會更快速和有效。
被用作數(shù)據(jù)存儲的X.500目錄鼓勵了不存儲空值的設(shè)計。例如，對象中不存在的一個(任選的)值將不會在目錄中存儲。這樣可以有效使用存儲空間，并且進行更強的搜索。依賴于屬性的任何搜索只需要考慮具有該屬性的數(shù)據(jù)的那些對象。
本系統(tǒng)的數(shù)據(jù)層次結(jié)構(gòu)與UDDI標準的目的可以很好地匹配。當刪除UDDI對象的請求到達時，它直接映射為在目錄中刪除一個子樹。例如，刪除一個服務(wù)包括刪除它的名稱和描述，以及它的所有綁定模板。所有這些都是該服務(wù)條目在目錄中的子對象。相應(yīng)地，本系統(tǒng)從上到下地從該服務(wù)條目中刪除子樹。這易于實現(xiàn)并且很有效。
域是表示一個層次子樹的基礎(chǔ)的名稱。在X.500術(shù)語中，域被稱為上下文前綴。在LDAP術(shù)語中，它被稱為后綴。給UDDI信息庫一個域名使得真正可以在信息庫中分布式使用該數(shù)據(jù)(在X.500情況下)。UDDI標準只支持復(fù)制。通過具有域節(jié)點，該系統(tǒng)可以使用對該應(yīng)用程序透明的目錄分布特性。
例如，假設(shè)一個企業(yè)在內(nèi)部配置了UDDI，但是具有兩個開發(fā)站點。利用該分布特性，它們可以在每個站點都配置一個分布式UDDI服務(wù)器，得每個站點都能直接瀏覽在兩個注冊上發(fā)布的項目。
這樣作的優(yōu)點在于它允許自由的分布。例如，UDDI服務(wù)器不需要作任何額外的工作，并且目錄系統(tǒng)有效地把孤立信息聯(lián)系在一起。
在UDDI標準中沒有規(guī)定如何存儲用戶信息。通過創(chuàng)建用戶對象，所有與用戶有關(guān)的信息都可以被存儲在單個對象中，并且該對象可以被用作保存該用戶所發(fā)布的所有對象的子樹的根。這使得安全性的定義更加簡單。例如，如果用戶所考慮的對象(比如企業(yè)、服務(wù)甚至是TModel)在該用戶的用戶對象之下，則用戶就可以控制它。
UDDI定義了包含重復(fù)要素的對象。出于性能、可搜索性以及可管理性方面的考慮，這些重復(fù)的要素可以被表示為子對象。
把重復(fù)的結(jié)構(gòu)化對象作為子對象存儲可以在目錄中有效地表示數(shù)據(jù)，在搜索時每個字段都單獨可獲得(以及索引)。
例如，企業(yè)實體名稱可以作為該企業(yè)實體對象的子對象進行存儲。另一實例是企業(yè)描述，它可以作為子對象存儲在企業(yè)實體對象之下。
這類系統(tǒng)的優(yōu)點在于，它允許搜索一個名稱(一種普通的UDDI搜索)，并且該條目的DN給出了該名稱所屬的對象的DN。
UDDI定義了冗余的“信息庫”節(jié)點(只包含子對象子結(jié)構(gòu)而不是屬性的UDDI結(jié)構(gòu))。因此這些節(jié)點可以根據(jù)查詢結(jié)果而以相對較低的代價構(gòu)建，因此可以被刪除。在某些情況下，屬性可以從子節(jié)點提升為父節(jié)點，以從目錄表示中刪除當前的冗余子節(jié)點。
例如，由于TModelInstanceDetails未包含屬性，因此沒有在目錄圖表中表示出來。由于instanceDetails的屬性被提升到TModelInstanceInfo的父對象overviewDoc中(如同其子對象的屬性一樣)，因此也沒有在目錄模式中表示。在目錄中也沒有表示種類和標識符袋，因為其內(nèi)容是該袋的擁有者的子對象。
這樣作的好處是，減少了目錄中的條目數(shù)量。特別地，它最小化了DIT的深度，因此改善了性能。
附圖12原理性地示出了根據(jù)本發(fā)明一個實施例的層次結(jié)構(gòu)。提供了一個或者多個域或者前綴121。在每一個域121之下，有一個或者多個用戶122。在每一個用戶122之下，提供了一個或者多個TModel123以及一個或者多個企業(yè)實體(BE)124。在每個企業(yè)實體124之下，提供了一個或者多個發(fā)布者斷言(PA)125、一個或者多個企業(yè)服務(wù)(BS)126以及一個或者多個服務(wù)投影(SP)127。在每個企業(yè)服務(wù)(BS)126之下，有一個或者多個綁定模板(BT)128?？梢园凑仗囟▽嵤┑男枰獊碓O(shè)置別名。例如，服務(wù)投影對象(圖12中所示的三角)可以作為別名從企業(yè)實體對象中產(chǎn)生。
通讀本發(fā)明將會明了如圖12所示的這種模式設(shè)計的優(yōu)點。
發(fā)布者斷言被設(shè)置在它們所引用的企業(yè)實體之下，因為它們通常是在find_RelatedBusinesses調(diào)用中使用，該調(diào)用指定了一個企業(yè)鍵值，并且經(jīng)由發(fā)布者斷言來查找與該鍵值有關(guān)的所有企業(yè)。本系統(tǒng)定位所知道的企業(yè)，然后讀取其下的所有(已建立的)發(fā)布者斷言。
這樣做的優(yōu)點是，允許快速有效的搜索。也易于維護數(shù)據(jù)的完整性。例如，當一個企業(yè)被刪除時，任何的發(fā)布者斷言也都被自動刪除。
TModels可以被發(fā)布它們的用戶改變(或者修復(fù)/隱藏)。把它們設(shè)置在表示該用戶的條目之下可以使得安全性更簡單。例如，如果TModel存在于該用戶條目之下的子樹中，則它可以被修改。反之，則不能。
更為詳細地說，如果想要進行改變的用戶的DN(區(qū)別名稱)與該TModel的DN的前綴匹配，則條目可以被該用戶修改，否則，則不允許修改。目錄可以被用于之下這種判斷(當DN不存在時命名異常)。
當從信息庫中刪除一個對象時，與該對象相關(guān)的信息也可被刪除。通過根據(jù)本模式的實施例而使用的層次設(shè)計使之得到了極大的簡化。當刪除對象時，以之為根的整個子樹都被刪除，并且這一處理可以刪除所有(并且通常是唯一的)相關(guān)信息。可以從底部向上執(zhí)行子樹的刪除。只有當條目的所有子節(jié)點都被刪除之后才能刪除各個條目。這是通過以逆DN順序列出所有的子節(jié)點來實現(xiàn)的。這樣保證了在父節(jié)點之前子節(jié)點的刪除。
這樣做的優(yōu)點在于，用排序列表的方法替代了更加復(fù)雜的遞歸方法。此外，這樣也相對簡單并且節(jié)省存儲器。當子樹中的所有條目都按照DN進行排序，并且以相反順序執(zhí)行刪除之后，這樣確保了所有的子節(jié)點在其父節(jié)點之前被刪除。
例如，當刪除一個企業(yè)服務(wù)時，系統(tǒng)刪除與之相關(guān)的所有綁定模板、它們的TModel實例信息以及各種相關(guān)的種類信息。所有這些可以通過刪除以該企業(yè)服務(wù)為根的子樹來完成。
由于在該方案中所使用的層次結(jié)構(gòu)，一個對象的DN揭示了擁有關(guān)系鏈以及對于該對象的控制。注意，斷言也取決于在命名屬性時的精心選擇。
這樣作的優(yōu)點在于，減少了被用于收集信息的搜索數(shù)或者讀取的次數(shù)。例如，使用作為子對象(例如名稱)的搜索結(jié)果，每個條目的DN揭示了父對象(例如BusinessEntity)以及擁有帳戶。
例如，企業(yè)服務(wù)的DN揭示了該服務(wù)所述的企業(yè)，以及控制它的用戶。
目錄并不保證結(jié)果的任何順序。當處理一個復(fù)雜的結(jié)果時(例如企業(yè)實體以及其企業(yè)服務(wù)以及它們的適當?shù)拿Q和描述)，通過按照DN來取這些搜索結(jié)果并對之排序可以簡化輸出的結(jié)構(gòu)。對它們進行組織以使結(jié)果的結(jié)構(gòu)變得相對簡單。在每個對象的子對象之前對之進行構(gòu)建，因此易于將子對象設(shè)置在其父對象之下，因此在企業(yè)的服務(wù)之前組織該企業(yè)結(jié)果。一個對象的所有子對象出現(xiàn)在相同類型的下一對象之前，一個企業(yè)的所有服務(wù)出現(xiàn)在下一企業(yè)之前。這同樣也獲得了簡單的遞歸結(jié)構(gòu)，因為在每一級別適用相同的事物。
這樣做的優(yōu)點在于最小化了通過構(gòu)建該UDDI結(jié)構(gòu)所需的原始條目列表的數(shù)量。
例如在排序之后，企業(yè)A的結(jié)果之后是其第一個服務(wù)的結(jié)果(該服務(wù)的名稱是AA)，然后是A的第二個服務(wù)(其名稱是AB)，然后是第二企業(yè)B。
也可以對子對象執(zhí)行搜索。例如，常用的搜索請求可以是“通過查找x的一個(或者多個)孩子來查找x”。通過搜索來找到企業(yè)的一種方式是例如通過指定在綁定模板中產(chǎn)生的TModel來實現(xiàn)。換言之，查詢是“找到具有一個其綁定模板引用了該TModel的服務(wù)的所有企業(yè)”?？梢酝ㄟ^查找派生對象的DN來完成這種查詢，并砍掉不需要的級別來獲得企業(yè)實體的DN。有益地，這也消除了重復(fù)。這種搜索方法部分歸功于本發(fā)明該實施例的層次結(jié)構(gòu)。
使用得到確保的唯一鍵值可以使問題簡化?？梢运阉髡麄€信息庫以尋找單個鍵值，并且唯一性確保了要么沒有結(jié)果(如果不存在該鍵值的話)，要么有一個結(jié)果(如果鍵值存在)。不需要考慮將搜索限制在父對象的范圍內(nèi)?？梢詮哪夸浿蝎@得增強的性能，因為可以充分地利用數(shù)據(jù)庫索引。
這樣做的優(yōu)點在于可以使用最快的目錄查詢。另一優(yōu)點在于如果給定對象被另一對象引用，則確保唯一的名稱十分重要。
大多數(shù)索引系統(tǒng)的一個特性是數(shù)據(jù)之間的相關(guān)性。如果數(shù)據(jù)是“l(fā)ittle-endian”(最左邊的部分變化最快)，則數(shù)據(jù)趨于展開，并且索引可以給出最好的性能。相反，如果數(shù)據(jù)是重復(fù)的，則索引不是十分有效?？梢允褂肬UID(全球唯一標識符)算法，其具有“l(fā)ittle-endian”特性。這樣做的另一優(yōu)點是最大化了目錄的性能。
可以向派生的對象添加鍵值。在將重復(fù)的數(shù)據(jù)要素加入到子對象時，需要添加一個命名屬性，形成其DN的最后一部分(arc)。在目錄中命名屬性與其同胞對象不同，因為同一父對象中沒有任何兩個子對象具有相同的名稱。
可以使用兩種類型的鍵值。對于不需要排序的子對象，使用UUID算法，因為這樣可以保證唯一性。對于需要排序的情形，使用具有單調(diào)增長的鍵值，以確保順序。
在UDDI標準中，企業(yè)實體可以提供兩種服務(wù)控制服務(wù)(在信息庫中使用子對象表示)，以及提供了接口的服務(wù)，但實際上它們也是由其它的企業(yè)實體提供的。后者可以在所公開的UDDI信息庫中用別名來表示。別名確切地提供了正確的特征。例如，如果原始對象(服務(wù))被其擁有者(也可能是添加了另一綁定模板)以某種方式改變，則通過別名而引用的對象也“改變”。而且，在該企業(yè)實體中對服務(wù)的任何搜索都能獲得實際的以及別名引用的服務(wù)。
例如，別名可以被用于服務(wù)投影，其中企業(yè)指向在另一企業(yè)之下定義的一個服務(wù)。這樣做的優(yōu)點在于，別名自動提供涉及“可替換名稱”的功能。此外，如果目錄支持別名完整性，則當刪除原始服務(wù)時，將自動刪掉任何投影。
在UDDI標準中有許多地方不希望被其他對象直接引用，而希望通過一個中間步驟實現(xiàn)—例如，TModel實例信息的情況下，或者在發(fā)布者斷言中引用企業(yè)實體的情況下。在這些情況下，別名將使代碼復(fù)雜。因此，本發(fā)明可以使用對象的引用來代替別名。因為，根據(jù)一個實施例，本系統(tǒng)確保每個對象具有唯一的鍵值，則鍵值可以確切地被用作引用，有時候也稱為“外來”鍵值。
使用輔助對象類可以執(zhí)行屬性分組。在處理發(fā)布者斷言時需要使用三個唯一識別該發(fā)布者斷言的屬性來定位發(fā)布者斷言兩個企業(yè)實體鍵值以及它們之間的關(guān)系。然而，該關(guān)系被規(guī)定為鍵值引用，其自身也是三個不同屬性TModel鍵值、鍵值名稱以及鍵值。一種方式是把關(guān)系作為發(fā)布者斷言的子對象加以存儲。然而，這樣不能最有效地搜索特定的發(fā)布者斷言。通過使關(guān)系的鍵值引用成為發(fā)布者斷言條目的輔助類，有可能在單個搜索中搜索所有的5個屬性，因而準確地提取出了所需的發(fā)布者斷言對象。
這種方案的一種設(shè)計可以使用常規(guī)的面向?qū)ο笤O(shè)計技術(shù)，并且導(dǎo)致了例如所有鍵值引用都具有相同的屬性名稱。然而這種設(shè)計使得難于分開例如企業(yè)實體種類的鍵值引用并且使得分開的成本很高，為了避免與TModel種類鍵值引用來說也會產(chǎn)生類似情形。也使得在濾波器中必須包含對象類術(shù)語，并且這種術(shù)語很弱(在信息庫中有很高的重復(fù)率)。
給例如每個不同種類的鍵值引用分配一個不同的對象類以及不同的屬性名稱，這意味著對于特定屬性名稱的任何搜索必須隱含該對象類。同樣意味著目錄服務(wù)器可以構(gòu)建一個索引，該索引中只是對期望的特定種類的條目才具有條目。這種索引比較小，通常也比較快。
例如，類似“euBusinessEntityName＝Smith”的搜索將會參考索引的euBusinessEntityName，因此不會和屬性euTModelName中包含Smith的條目混淆。
同樣可能還要調(diào)用UDDI標準的范圍之外的工具。這種工具需要提供除UDDI標準中規(guī)定的之外的其它訪問方式。為了使用這種工具，本發(fā)明定義了抽象類，其綁定了表示單個UDDI概念的所有對象類。這樣允許定義如下的搜索，該搜索可以尋找例如所有名稱或者所有鍵值引用。
例如，存在抽象對象類euName，其為所有名稱-類型對象類的超類，包括euBusinessEntityName和euTModelName。
UDDI標準規(guī)定，可以以大小寫敏感和大小寫不敏感的方式搜索名稱。這可以通過對大小寫不敏感進行索引來解決，然后檢索條目，并且對它們進行大小寫敏感檢查，但是這種方案會降低性能。最后在這些情況下定義一個陰影區(qū)域，其包含了相同數(shù)據(jù)，但是被不同索引。相似地，陰影屬性可以被用于語言中的變體，例如，變音符標記。
例如，euBusinessEntityName對象類包含了每個名稱的兩份拷貝。第一版本按照大小寫不敏感的方式進行索引，而第二種版本按照大小寫敏感的方式進行索引。這允許構(gòu)建無論請求什么行為都具有良好性能的搜索濾波器。
信息庫中的每種屬性(除對象類之外)都可以是單值的。這樣目錄有可能構(gòu)建更有效的索引并且在搜索時提供更好的性能。
這也去除了在搜索時虛假的肯定結(jié)果的可能性。例如考慮一個搜索，其查找以“Fr”開始，以“nk”結(jié)束的名稱。也許期望獲得名稱類似于“Frank”的(有效)條目。但是，如果名稱是多值屬性的話，則有可能獲得其兩個名稱類似于“Fred”和“Tink”的無效條目，因為該條目也匹配所規(guī)定的兩個標準。通過使用單值名稱，每個都是該條目的一個子對象，因此消除了“Fred”和“Tink”的錯誤匹配。
可操作屬性是可以由UDDI應(yīng)用進行管理、但是不能被用戶看到的特殊屬性。
在UDDI數(shù)據(jù)的存儲中，應(yīng)當可能有一種方式來區(qū)分正在使用的TModel和已經(jīng)“隱退”的TModel。當刪除一個TModel時，它也許有可能正被許多的條目使用，而不能被真正刪除。相反它被隱藏起來(這意味著它將不能作為find_TModel調(diào)用的結(jié)果的一部分而返回)，仍然可以通過get_TModelDetail調(diào)用來查詢。這可以通過使用被稱為euHidden的屬性而實施，該屬性被添加到那些被隱藏的TModel上。對搜索TModel的濾波器添加這樣一個搜索步驟也許是有益和有效的，其可以消除包含euHidden屬性的任何條目。
在目錄實現(xiàn)過程中，只有一個主值的屬性通常被認為十分低效。例如，具有一個對于99％的條目都設(shè)定為FALSE的隱藏屬性將會產(chǎn)生很差的性能-索引將變得幾乎不可用。
有效的方式是存儲大部分不具有隱藏屬性的條目，并且只將該屬性添加到要被隱藏的那些條目中。這樣作的附加益處是不需要存儲空間來保持所有的那些“FALSE”值?，F(xiàn)在用于查找所有那些未被隱藏的TModel的濾波器將變成“(！(euTModel＝*))”-是對存在測試的否定，并且存在測試十分快速，特別是當該屬性只存在于一小部分條目中時。
現(xiàn)在將描述本發(fā)明的一個實施例，以解決在目錄環(huán)境下的實現(xiàn)以及UDDI標準的發(fā)布。對于一個X.500方案存在許多要素。這些要素包括屬性定義，對象類定義以及名稱綁定定義。屬性定義規(guī)定了單個數(shù)據(jù)要素，給它一個唯一的標識符(OID)、名稱以及數(shù)據(jù)類型。對象類定義規(guī)定了可以作為一個整體而被操作的屬性的集合。它給出了唯一的標識符(OID)、名稱以及屬性列表；這些屬性可以是所要求的也可以是任選的。名稱綁定規(guī)定了部分的可能層次。名稱綁定指定了一個對象類，其可以存儲在另一個對象類之下，并且規(guī)定了孩子(在這種情況下被稱為子對象)的一個或多個屬性。
還有很多需要附加設(shè)計的查找限定詞。一種查找限定詞是大小寫敏感的，用于以大小寫敏感和大小寫不敏感的方式有效地搜索文本數(shù)據(jù)。根據(jù)本發(fā)明的實施例，大小寫敏感可以通過在對象中提供附加的字段來分辯，并進行不同的索引。
根據(jù)該實施例，文本數(shù)據(jù)以caseExactString類型的屬性和caseIgnoreString類型的屬性被存儲兩次。然后查找限定詞確定搜索哪個字段，由此獲得最佳性能。
例如，如果企業(yè)實體具有一個類似“McKenna’s Iron FoundryServices”的名稱，則該字符串被存儲兩次，一次存在以大小寫敏感的方式進行索引的字段中，一次存在以大小寫不敏感的方式進行索引的字段中-存儲的數(shù)據(jù)是相同的，但是底層目錄產(chǎn)生的索引不同。
另一問題涉及服務(wù)投影的有效實現(xiàn)。根據(jù)本發(fā)明的一個實施例，可以使用X.500別名特性來解決。有許多方式來處理服務(wù)投影。本發(fā)明的實施例通過目錄別名來處理它們。這對它們是一種很有效的實施方式。它確保了投影于基礎(chǔ)服務(wù)的一致性，因為基礎(chǔ)服務(wù)是通過這些別名直接訪問的。也確保了當基礎(chǔ)服務(wù)被刪除時投影將會消失，因而確保了一致性。
例如，如果稱為Williams Accounting Service的企業(yè)實體發(fā)布了一個名為總帳核對(General Ledger Cross-Check)的Web服務(wù)，期望在一個名為Williams Auditing Service的另一個企業(yè)實體中提供相同的服務(wù)，然后這可以通過在第二企業(yè)實體之下設(shè)置一個別名條目來實現(xiàn)。列出由Williams Auditing Service所提供的服務(wù)的詢問者將查找總帳核對服務(wù)，就如查找直接使用Williams Auditing Service提供的任何服務(wù)一樣。
另一問題涉及鍵值的有效實現(xiàn)。根據(jù)本發(fā)明的一個實施例，這是通過在順序不重要的情況下使用UUID作為外部鍵值和鍵值來解決的。在順序重要的情況下可以使用連續(xù)數(shù)字。盡管鍵值被表示為字符串，但是它們并不是真正的文本數(shù)據(jù)。無需大小寫敏感或者變音符標記就可以進行比較。
外部可見的鍵值遵循一組規(guī)則。當實施一個與UDDI規(guī)范的版本2兼容的信息庫時，它們保持UUID，與ISO-11578兼容。當實施UDDI規(guī)范的版本3的信息庫時它們按照該版本的規(guī)范所制定的規(guī)則來保持鍵值字符串。
注意在內(nèi)部用于將要素聯(lián)系在一起的鍵值遵循另外一組規(guī)則。那些順序不重要的鍵值使用UUID。那些順序重要的鍵值使用序列號。
例如，一個鍵值引用表示被稱為Williams Auditing Service的企業(yè)實體的種類袋的一個要素，其可以引起一個鍵值為12345678-1234-1234-1234-1234567890ab(UDDI v2)的TModel。在種類袋中鍵值引用的順序不重要，但是鍵值引用需要鍵值被用作該對象的命名屬性。因而，我們可以為該對象產(chǎn)生一個UUID鍵值，如87654321-4321-4321-4321-ba0123456789，并且使用它作為該對象在目錄中的命名屬性。
另一問題是如果希望X.500分布，則需要將數(shù)據(jù)組織成域的形式。根據(jù)本發(fā)明的一個實施例這是通過在用戶之上創(chuàng)建信息庫層來解決的，以便每個信息庫可以被設(shè)置在不同的服務(wù)器上。
UDDI標準不允許分布式的名稱空間。這意味著，多個UDDI注冊可以通過復(fù)制或者通過直接用后臺數(shù)據(jù)存儲來管理分布式名稱空間以進行彼此協(xié)作。
通過具有命名前綴的信息庫可以實現(xiàn)分布式的名稱空間。該前綴是定義一個域的一組節(jié)點。這些節(jié)點可以被視為在每個UDDI注冊之上的信息庫層。這些節(jié)點被設(shè)置在用戶級別之上。
圖11實例了這種節(jié)點的一個實例，稱為“域(Domain)”110。域110是目錄的前綴，并且可以包含到根節(jié)點為止的一個或多個節(jié)點。在域110之下，該實例表示出了多個用戶112、113和114的排列。在域110之下設(shè)置的用戶數(shù)目可以根據(jù)該系統(tǒng)的特定配置和/或使用而變化。根據(jù)該系統(tǒng)的特殊配置和/或使用也可以安排有多個域。在以下的例子中，它們被稱為信息庫對象，并假設(shè)它們表示物理上獨立的信息庫。當然，根據(jù)該系統(tǒng)的特殊配置和使用，也并非一定如此。
信息庫對象僅需要一個命名屬性。
set object-class UDDIObjectClass:400＝{ #信息庫-可以用于把用戶分成組name＝euRepositorysubclass-of topmust-containeuRepositoryName}在大規(guī)模目錄配置中，分布是一個重要概念，因為它允許數(shù)據(jù)被多個節(jié)點共享，而不需要復(fù)制所需的過多的帶寬負荷和同步問題。
在一個實施例中，“eTrust”UDDI使用下層eTrust目錄服務(wù)器的性能來支持分布，為此本方案可以這樣來設(shè)計在樹層次結(jié)構(gòu)的頂端允許有一個或多個虛擬的“域”節(jié)點，在每個節(jié)點子樹的頂端允許唯一的節(jié)點標識符或者名稱(參見以下的UDDI模式描述)。
此外，可以將eTrust UDDI服務(wù)器配置為“分布式感知的(distribution-aware)”?？梢灾付▋蓚€分開的目錄前綴-個用于搜索和讀取，另一個用于添加條目。為了配置一個分布式服務(wù)器，底層的eTrust UDDI目錄服務(wù)器代理按照eTrust目錄管理指南被配置成分布式的。每個獨立的eTrust UDDI節(jié)點被設(shè)定為“World”或者“Corporation”節(jié)點名稱。每個節(jié)點的Add前綴被設(shè)定為該節(jié)點的唯一名稱。
以這種方式，每個節(jié)點把條目添加到其自身的目錄信息庫中，但是通過X.500目錄的分布特征在所有節(jié)點中搜索條目。
信息庫對象的一個實例是euRepositoryName＝Melbourne另一個問題設(shè)計對關(guān)于該用戶的數(shù)據(jù)進行的組織。這可以通過創(chuàng)建用于保持這些數(shù)據(jù)的用戶對象得以解決。
盡管在UDDI規(guī)范中沒有規(guī)定任何用戶對象，根據(jù)本發(fā)明的實施例可以利用這種對象。例如，用戶對象可以是一個用于該用戶憑證的存儲器指針和用于發(fā)布的定位指針。
附圖10示例了這種安排的一個實例，稱為“用戶”101。在用戶101之下設(shè)置了其它對象，例如企業(yè)實體對象102、企業(yè)服務(wù)對象103以及綁定模板對象104。在用戶101之下的企業(yè)實體對象的數(shù)目可以根據(jù)該系統(tǒng)的特殊配置和/或使用而變化。根據(jù)該系統(tǒng)的特定配置和/或使用也可以安排有多個用戶。
在用戶對象中保存的數(shù)據(jù)要素包括用戶鍵值(用于提供為該用戶帳戶一個唯一的名稱)、用戶名稱、以及憑證(可以是一個簡單的密碼，或者復(fù)雜的PKI認證)。還可以包含一個認證的名稱(識別被授權(quán)操作該用戶帳戶的人或者角色)。也可以包含一個隱藏標志，用于處理用戶帳戶的刪除，而不會丟失由該用戶定義的任何TModel。
set object-class UDDIObjectClass:401＝{ #用戶帳戶name＝euUserAccountsubclass-of topmust-containeuUserKey，
euUserName，euCredentialsmay-containeuAuthorizedName，euHidden}；用戶帳戶對象的一個實例是euUserKey＝23456789-2345-2345-2345-234567890abceuUserName＝GraceeuCredentials＝Amazing76sQ(假設(shè)在這個例子中采用了一個簡單的用戶ID和口令系統(tǒng))另一問題涉及以有效的方式來表示有關(guān)企業(yè)實體的數(shù)據(jù)(在UDDI標準中描述的一個對象類)。根據(jù)本發(fā)明的一個實施例這是通過將唯一的字段表示為對象的屬性，并且將重復(fù)的要素表示子對象來解決的。
企業(yè)實體對象是UDDI標準的一個基礎(chǔ)要素。其內(nèi)容由標準定義，但是它的大多數(shù)要素是不能得到X.500模式支持的重復(fù)的復(fù)雜對象。這種要素可以用層次結(jié)構(gòu)安排來表示。
在企業(yè)實體中唯一需要的要素是企業(yè)鍵值。任選的要素包括授權(quán)的名稱、操作者以及用戶鍵值(后者將出現(xiàn)在由正常用戶發(fā)布的企業(yè)實體中)。
set object-class UDDIObj ectClass:402＝{ #企業(yè)實體—提供服務(wù)的企業(yè)的詳細描述name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，
euAuthorizedName，}；企業(yè)實體可能的子對象是名稱(一個包含名稱字符串和語言代碼的對象，具有鍵值以進行排序)；描述(一個包含描述字符串和語言代碼的對象，具有鍵值以進行排序)；聯(lián)系方式(一個復(fù)雜對象-將在下面描述)；發(fā)現(xiàn)URL(一個包含URL字符串和使用類型的對象，具有鍵值)；鍵值索引，通過選擇對象類被標記為種類或標識符信息；以及企業(yè)服務(wù)(將在下面描述)。
企業(yè)實體對象的一個實例為euBusinessEntityKey＝34567890-3456-3456-3456-34567890abcdeuParentUserKey＝23456789-2345-2345-2345-234567890abc注意企業(yè)實體對象的大部分明顯的內(nèi)容實際被存儲在企業(yè)實體對象直接的子對象中。
圖15示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例，以表示企業(yè)實體中的一個相對復(fù)雜的對象。在圖15中，多值要素如下對于子對象152，有Language enName CA對于子對象153，有LanguageINName CATS其被表示為企業(yè)實體151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
要解決的另一問題是以有效的方式表示有關(guān)企業(yè)服務(wù)的數(shù)據(jù)(在UDDI標準中描述的對象類)。
根據(jù)本發(fā)明的一個實施例可以通過用唯一的字段表示對象屬性，以及用重復(fù)要素表示子對象來解決。
可以用至少兩種方式來實現(xiàn)該企業(yè)服務(wù)。第一種方式是，企業(yè)服務(wù)表示由企業(yè)實體提供的單個概念化的服務(wù)，通過一個或者多個訪問路由而獲得，每個訪問路由都由綁定模板表示。第二種方式是，對于服務(wù)的分組機制，分成在綁定模板級別發(fā)生的單獨的服務(wù)。在這兩種情況下，數(shù)據(jù)字段都定義在UDDI規(guī)范中。
企業(yè)服務(wù)的要素是企業(yè)和服務(wù)鍵值。企業(yè)鍵值規(guī)定了擁有該服務(wù)的企業(yè)實體。這在發(fā)現(xiàn)它的企業(yè)實體中不是必要的。通過服務(wù)投影可以在多種企業(yè)實體中找到單個服務(wù)。該服務(wù)鍵值是整個UDDI信息庫的服務(wù)的唯一標識符。兩種鍵值都可以表示為字符串。
set object-class UDDIObjectClass:403＝{#企業(yè)name＝euBusinessServicesubclass-of topmust-containeuBusinessServiceKey，euParentBusinessKey}；在企業(yè)服務(wù)對象中沒有可選內(nèi)容。多有其它內(nèi)容由可能重復(fù)的要素組成，因此被表示為子對象。企業(yè)服務(wù)可能的子對象為綁定模板(見下文)；名稱(一個包含名稱字符串和語言代碼的對象，具有鍵值以進行排序)；描述(一個包含描述字符串和語言代碼的對象，具有鍵值以進行排序)；鍵值引用，被標記為種類信息。
例如，企業(yè)服務(wù)對象可以是euBusinessServiceKey＝4567890a-4567-4567-4567-4567890abcdeeuParentBusinessKey＝34567890-3456-3456-3456-34567890abcd注意企業(yè)服務(wù)對象的大部分明顯的內(nèi)容實際被存儲在企業(yè)服務(wù)對象直接的子對象中。
盡管圖15示例了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例，以表示企業(yè)實體中的一個相對復(fù)雜的對象，但是它同樣示例了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中以表示企業(yè)服務(wù)中的一個相對復(fù)雜的對象的實例。圖15的企業(yè)實體151同樣適用于企業(yè)服務(wù)，而企業(yè)服務(wù)的多值要素被表示為企業(yè)服務(wù)151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
要解決的另一問題是以有效的方式表示有關(guān)綁定模本的數(shù)據(jù)(在UDDI標準中描述的對象類)。根據(jù)本發(fā)明的一個實施例可以通過將唯一的字段表示為對象屬性將重復(fù)要素表示為子對象來解決。
綁定模板表示可以用于訪問特定服務(wù)的方式。在綁定模板中唯一需要的要素是其鍵值以及它所適用的服務(wù)的鍵值?？蛇x要素包括訪問點或者主機導(dǎo)向器(該對象應(yīng)當具有這兩個要素中的一個)。如果存在訪問點，則存在訪問點類型。
set object-class UDDIObjectClass:404＝{ #綁定模板name＝euBindingTemplatesubclass-of topmust-containeuBindingTemplateKeymay-containeuParentServiceKey，euHostingRedirector，euAccessPoint，euAccessPointType}；綁定模板可能的子對象為TModel實例信息(見下文)；以及描述(一個包含描述字符串和語言代碼的對象，具有鍵值以進行排序)綁定模板的一個實例是euBindingTemplateKey＝567890ab-5678-5678-5678-567890abcdefeuParentServiceKey＝4567890a-4567-4567-4567-4567890abcdeeuAccessPoint＝http//www.rsps.com.au/wsepeuAccessPointType＝http。
同樣地，盡管圖15示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例以表示企業(yè)實體中的一個相對復(fù)雜的對象，但是它同樣示例了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中以表示綁定模板中的一個相對復(fù)雜的對象的實例。圖15的企業(yè)實體151同樣適用于綁定模板，而綁定模板的多值要素被表示為綁定模板151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
要解決的另一問題是以有效的方式表示有關(guān)TModel的數(shù)據(jù)(在UDDI標準中描述的對象類)。根據(jù)本發(fā)明的一個實施例可以通過用唯一的字段表示對象屬性，用重復(fù)要素表示子對象來解決。
一個TModel表示一個想法。該想法可以是例如一個分類系統(tǒng)，需要規(guī)定有效的值?；蛘咚梢允菍?shù)據(jù)通信協(xié)議的規(guī)定。TModel是一個靈活而有力的概念，集中于UDDI以它們能夠被精確查詢的方式來表示復(fù)雜數(shù)據(jù)的能力。
TModel對象中唯一需要的要素是TModel鍵值和名稱。它們被表示為字符串。
TModel對象的可選要素是被授權(quán)的名稱、概述URL(概述文檔對象(Overview Doc object)的一部分)、一個用戶鍵值以及一個隱藏標志。
隱藏標志是對TModel進行處理的要素。隱藏標志是處理deleteTModel調(diào)用的方式。當一個TModel被“刪除”時，隱藏標志被添加到該對象。這意味著，對象將不會返回給findTModel調(diào)用，但是可以被getTModel調(diào)用訪問。
set object-class UDDIObjectClass:405＝{ #TModel-涉及一種想法name＝euTModelsubclass-of topmust-containeuTModelKey，euTModeIName
may-containeuAuthorizedName，euOperator，euOverviewURL，euParentUserKey，euHidden}；可能的子對象是描述(Description)(一個包含描述字符串和語言代碼的對象，具有鍵值以進行排序)；鍵值引用，被標記為種類或者標識符信息；以及Overview Doc Description(一個包含描述字符串和語言代碼的對象，具有鍵值以進行排序)TModel的一個實例為euTModelKey＝uuid:67890abc-6789-6789-6789-67890abcdef1euTModeIName＝Corporate QA PolicyeuOverviewURL＝http//www.rsps.com.au/policy/qa.htmleuParentUserKey＝23456789-2345-2345-2345-234567890abc同樣地，盡管圖15示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例以表示企業(yè)實體中的一個相對復(fù)雜的對象，但是它同樣示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中以表示TModel中的一個相對復(fù)雜的對象的實例。圖15的企業(yè)實體151同樣適用于TModel，而TModel的多值要素被表示為TModel 151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
另一問題涉及以有效的方式來表示有關(guān)發(fā)布者斷言(UDDI標準中描述的一個對象類)的數(shù)據(jù)。
根據(jù)本發(fā)明一個實施例，這可以通過將唯一字段表示為對象的屬性以及對于要求的關(guān)系鍵值引用使用輔助類來解決。
發(fā)布者斷言是一個表示兩個企業(yè)實體之間的關(guān)系的對象。
發(fā)布者斷言所需要的要素是其鍵值，去往和來自的企業(yè)和用戶鍵值，狀態(tài)以及關(guān)系。關(guān)系被規(guī)定為鍵值引用，并且作為輔助類存儲到發(fā)布者斷言條目。狀態(tài)作為字符串存儲，但是從完成狀態(tài)(CompletionStatus)對象中提取它的可能值。所有的鍵值被表示為字符串。
set object-class UDDIObjectClass:406＝{ #發(fā)布者斷言-兩個企業(yè)之間的關(guān)系name＝euPublisherAssertionsubclass-of topmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinesKey，euToUserKey，euPublisherAssertionStatus}在發(fā)布者斷言中沒有可選內(nèi)容，并且沒有子對象。
發(fā)布者斷言的一個實例為euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12euFromBusinessKey＝34567890-3456-3456-3456-34567890abcdeuFromUserKey＝23456789-2345-2345-2345-234567890abceuToBusinessKey＝09876543-6543-6543-6543-dcbaO9876543euToUserKey＝98765432-5432-5432-5432-cbaO98765432euPublisherAssertionStatus＝status:complete注意，存在與該條目相關(guān)的輔助類；它是對象類euPublisherAssertionRelationshipKeyedReference，并且將規(guī)定被斷言要插入到兩個企業(yè)實體之間的關(guān)系。一個例子是euPublisherAssertionTModel＝uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child另一個問題是以有效的方式表示有關(guān)鍵值引用(在UDDI標準中描述的對象類)的數(shù)據(jù)。由于需要能夠有效地搜索鍵值引用的特定集合使得問題更加復(fù)雜例如，企業(yè)實體上的種類袋。
根據(jù)本發(fā)明的一個實施例，這可以通過創(chuàng)建一個抽象基類表示鍵值引用以及對于每個期望的集合創(chuàng)建一個子類來解決。這些集合在目錄中沒有被表示。例如，它們是相同子類的一組鍵值引用，是相同對象的子對象。例如，企業(yè)實體的種類袋是類euBusinessEntityCategoryKeyedReference的對象，其本身是規(guī)定的企業(yè)實體的子對象。注意企業(yè)實體對象也可以具有多個鍵值引用對象作為子對象，利用它們的對象類更容易明了哪些是種類袋的一部分，哪些是標識符袋的一部分。
鍵值引用被用于UDDI數(shù)據(jù)模型內(nèi)的幾個地方。它們包括TModel鍵值、鍵值名稱。鍵值引用的兩種用途是種類袋和標識符袋。這些袋是鍵值引用的集合，并且對于搜索來說十分重要。如果使用包含無區(qū)分鍵值引用的對象來表示這些袋，則有可能很難實施有效搜索。這也是實施鍵值引用的一些子類的原因。企業(yè)實體上的種類袋可以被類euBusinessEntityCategoryKeyedReference的一個或者多個子對象表示。這樣易于在企業(yè)實體的種類袋中使用規(guī)定的鍵值引用來對企業(yè)實體進行有效的搜索。
下面的實例表示了抽象類和一個衍生類，euBusinessEntityCategoryKeyedReference，如以上所討論的。注意鍵值引用的鍵值是從抽象類中繼承而來的，而TModel鍵值、鍵值名稱以及鍵值都是在衍生類中規(guī)定的，因此它們在搜索時具有不同的名稱。
set object-class UDDIObjectClass:201＝{ #作為所有鍵值引用的父類的抽象類name＝euKeyedReferencesubclass-of topmust-containeuKeyedReferenceKey}；
set object-class UDDIObjectClass:301＝{ #企業(yè)實體種類鍵值引用-構(gòu)成種類袋的集合name＝euBusinessEntityCategoryKeyedReferencesubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryTModel，euBusinessEntityCategoryKeyName，euBusinessEntityCategoryKeyValue}；聯(lián)系方式是一個復(fù)雜對象，表示各種信息。與企業(yè)實體十分相似，一個聯(lián)系方式保存了各種復(fù)合的重復(fù)要素，必須使用子對象類。
作為聯(lián)系方式對象的直接部分的數(shù)據(jù)要素是鍵值、聯(lián)系方式所表示的人或角色的名稱?？蛇x的還有使用類型。
所有可能的其它要素是聯(lián)系方式對象的子對象。它們是地址(Address)(地址線對象的一個有序列表的父對象，每個都具有鍵值，使用類型，排序代碼，以及TModel鍵值)；電話(Phone)(電話號碼及使用類型)；電子郵件(E-mail)(電子郵件地址及使用類型)；以及描述(Description)(描述字符串及語言代碼)同樣地，盡管附圖15示例了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例，以表示企業(yè)實體中的一個相對復(fù)雜的對象，但是它同樣示例了根據(jù)本發(fā)明將層次引入到于結(jié)構(gòu)中以表示聯(lián)系方式對象中的一個相對復(fù)雜的對象的實例。圖15的企業(yè)實體151同樣適用于聯(lián)系方式對象，而聯(lián)系方式對象的多值要素被表示為聯(lián)系方式對象151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
另一個問題涉及以有效的方式來表示名稱和描述(在UDDI標準中規(guī)定的)，以及允許快速搜索特定類型的名稱或描述。
根據(jù)本發(fā)明實施例，系統(tǒng)創(chuàng)建一個抽象基類來表示名稱，以及另一個抽象基類來表示描述，以及為每種期望的類型創(chuàng)建子類。當查找特定類型的名稱時(例如，企業(yè)實體名稱)搜索該子類的屬性，當查找任何名稱時美搜索抽象類。
幾個主要對象(企業(yè)實體，企業(yè)服務(wù)等)都可以有多個名稱和描述。其原因有多個。一個企業(yè)有多個名稱的情形并不罕見，有一個正式名稱，還會有一個或者多個俗稱。而且，企業(yè)可以在不同的語言中使用不同的名稱。一個名稱被不當翻譯的情形也很平常。例如，計算機公司富士通在許多英語國家中使用很多年英文名稱Facom。在具有多種字符集的語言中該問題會進一步惡化。日本公司也許會有一個片假名的名稱版本，還有一個平假名的名稱版本。
由于以上的理由，對于單個對象來說名稱和描述對象可能出現(xiàn)多次。每個實例都與一種語言代碼有關(guān)。在UDDI版本3中有多個具有相同語言代碼的實例(這在版本2中是不允許的)。
查找限定詞會帶來其它的問題。如前面指出的，需要UDDI搜索來支持大小寫敏感和大小寫不敏感的搜索，并且最好通過在X.500目錄中把數(shù)據(jù)存儲兩次來解決。
以下的實例表示抽象類以及一個衍生類，euBusinessEntityName，被用作企業(yè)實體的名稱的集合set object-class UDDIObjectClass:202＝{ #作為所有名稱的父類的抽象類name＝euNamesubclass-of topmust-containeuNameKeymay-containeuLanguage}；set object-class UDDIObjectClass:331＝{ #企業(yè)實體的名稱name＝euBusinessEntityNamesubclass-of euName
must-containeuBusinessEntityNameValue，euBusinessEntityNameValuelC#從euName中繼承euNameKey和euLanguage}；注意euBusinessEntityNameValue是包含了名稱的大小寫敏感版本的屬性；而euBusinessEntityNameValuelC是被標記為“忽略大小寫”的版本，因而對大小寫不敏感。從抽象類中繼承的euNameKey字段被用于名稱的控制和排序，并且提供了唯一的命名屬性。
名稱對象的一個實例為euNameKey＝890abcde-890a-890a-890a-890abcdef123euLanguage＝ENeuBusinessEntityNameValue＝McKenna′s Validation SystemseuBusinessEntityNameValuelC＝McKenna′s Validation Systems同樣地，盡管圖15示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中的一個實例以表示企業(yè)實體中的一個相對復(fù)雜的對象，但是它同樣示出了根據(jù)本發(fā)明將層次引入到子結(jié)構(gòu)中以表示抽象類中的一個相對復(fù)雜的對象的實例。圖15的企業(yè)實體151同樣適用于抽象類，而綁定模板的多值要素被表示為抽象類151的子對象152，153。也有可能沒有子對象，或者有更多子對象。
另一個問題涉及創(chuàng)建一種有效的實施方式來滿足只讓得到許可的用戶去修改那些在他/她控制之下的企業(yè)實體的技術(shù)要求。根據(jù)本發(fā)明的實施例，通過使得被用戶控制的企業(yè)實體成為用戶對象的孩子得以實現(xiàn)。這使得安全性更易于實現(xiàn)。
很重要的一點是確保一個發(fā)布用戶只能修改他/她所擁有的信息。還有可能使用多種設(shè)計來完成。然而，最佳設(shè)計是立即清楚用戶是否被授權(quán)發(fā)布一個項目由給定用戶控制的所有數(shù)據(jù)都位于該用戶的子樹中。
由于到企業(yè)實體中的所有查詢都是從層次結(jié)構(gòu)中用戶層之上執(zhí)行的，而沒有丟失通用性和性能，因此該設(shè)計對于以企業(yè)實體為整體進行方便的訪問沒有影響。
另一個問題涉及創(chuàng)建發(fā)布者斷言的有效實施方式，特別是findRelatedBusiness方法的實施方式。根據(jù)本發(fā)明的實施例，可以通過使得與一個企業(yè)有關(guān)的發(fā)布者斷言成為該企業(yè)對象的子對象來實現(xiàn)。這樣就消除了對該標準進行搜索的需要。
發(fā)布者斷言的一種主要用途是find RelatedBusinesses查詢。該查詢規(guī)定了特定的企業(yè)實體，并且通過完成的發(fā)布者斷言請求與該實體相關(guān)的所有企業(yè)實體的信息。通過一種將發(fā)布者斷言置于與它相關(guān)的企業(yè)實體之下的層次可以簡化和加速這種查詢。這樣做可以獲得增強一致性的附加益處。當一個企業(yè)實體被刪除時，所有與之相關(guān)的發(fā)布者斷言也被刪除。
另一問題涉及創(chuàng)建一種有效實施，使得允許用戶修改受他/她控制的TModel。根據(jù)本發(fā)明的實施例，該系統(tǒng)把用戶定義的TModel做成該用戶對象的子對象。這使得安全性易于實現(xiàn)。
由于相似的理由，對于被管理的那些企業(yè)實體，將其置于用戶項目之下，明智的選擇是把用戶定義的TModel置于定義它們的該用戶的用于項目之下。由于所有的TModel被唯一地命名，因此可以通過單個被索引的訪問來定位TModel這對于定位TModel不會產(chǎn)生不利影響。
另一個問題涉及通過關(guān)系對發(fā)布者斷言實施有效搜索。根據(jù)本發(fā)明實施例，通過將關(guān)系的鍵值引用做成發(fā)布者條目的輔助類可以實現(xiàn)這一點。如果鍵值引用是一個孩子(一種實施方式)，它不能以相等的效率進行搜索，并且對于該關(guān)系的搜索不能與對該出版者斷言之內(nèi)容的搜索組合，例如，狀態(tài)的(臨界)濾波器(只考慮已完成的斷言)。
X.500模式系統(tǒng)也許不支持構(gòu)建包含其它對象類作為數(shù)據(jù)要素的對象類。例如，鍵值引用不能是發(fā)布者斷言的數(shù)據(jù)要素。有可能將鍵值引用做成發(fā)布者斷言的孩子，但是這并不能促進參考該鍵值引用內(nèi)容的有效搜索的構(gòu)建。
將鍵值引用做成發(fā)布者斷言條目的輔助類是該問題的一個有效的解決方案，然后有可能對該鍵值引用的內(nèi)容進行搜索，盡管它只是斷言的一部分。
如上所述，發(fā)布者斷言的一個實例可以是euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12euFromBusinessKey＝34567890-3456-3456-3456-34567890abcdeuFromUserKey＝23456789-2345-2345-2345-234567890abceuToBusinessKey＝09876543-6543-6543-6543-dcbaO9876543euToUserKey＝98765432-5432-5432-5432-cbaO98765432euPublisherAssertionStatus＝status:completeeuPublisherAssertionTModel＝uuid:807A2C6A-EE22-470D-ADC7-E0424A337C03euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child輔助對象類是euPublisherAssertionKeyReference，并且上面列出的后三個屬性是該類的數(shù)據(jù)要素。
根據(jù)本發(fā)明的實施例，諸如計算機聯(lián)合公司的eTrustTM目錄的目錄可以被用于實施理想的企業(yè)UDDI注冊平臺。eTrust目錄完全兼容LDAPv3，X.500電子目錄，可以被用于鞏固UDDI Web服務(wù)實施。eTrust目錄允許UDDI實施平衡高度成熟的目錄解決方案，這已經(jīng)在大規(guī)模，企業(yè)關(guān)鍵的目錄服務(wù)應(yīng)用中得到驗證。
eTrust目錄還存在許多獨特的特性使得它作為建立UDDI注冊的平臺及其具有吸引力。其中一些包括安全特性、包括訪問控制策略、規(guī)則、安全代理、相互認證、分布式認證、分布式SSL證書主題驗證以及網(wǎng)絡(luò)地址確認；分布和路由能力包括并行分布式搜索，負載分擔、查詢流以及最短路徑路由；多主機復(fù)制方案，其組合了基于重放的機制(也成為多寫入)的速度和效率與基于狀態(tài)的恢復(fù)和調(diào)節(jié)；可用特性，包括數(shù)據(jù)庫的熱交換，網(wǎng)絡(luò)的容錯備援以及目錄系統(tǒng)代理(DSA)備援；被認為非?？焖俚母咚倬彌_設(shè)計；以及配置特性，包括(數(shù)據(jù)類型，模式規(guī)則，安全性，知識等等的)動態(tài)配置，不受限的數(shù)據(jù)大小，常用信息完整性規(guī)則，擴展的管理控制以及交互的命令控制臺。
eTrust目錄提供了一個可靠的X.500目錄解決方案。在這一可靠的基礎(chǔ)之上能夠?qū)嵤︰DDI語義橋，以便啟動完全與標準兼容的UDDI注冊。由于其下層的目錄方案的能力，此處所公開的實施例可以獲得靈活的安全性，分布以及管理性，而不需要對現(xiàn)有UDDI標準進行改變或者擴展。
本實施例的一個問題是處理如何在目錄全異部分中存儲的實體直接映射關(guān)系。
盡管UDDI數(shù)據(jù)結(jié)構(gòu)是主要的層次，不同對象之間的交叉關(guān)系也會產(chǎn)生問題。
基本上有兩種關(guān)系，即，替換名和交叉關(guān)系。根據(jù)本發(fā)明的一個實施例，通過使用別名的概念來尋址替換名可以解決這個問題?；旧线@樣作會添加(attach)一個外實體作為主實體的虛擬孩子。
本實施例使用唯一的鍵值來解決交叉關(guān)系的問題。這樣做的效果是，與RDBME技術(shù)中的主/外鍵值系統(tǒng)十分相似，創(chuàng)建一個“關(guān)系指針”來模擬數(shù)據(jù)實體之間的關(guān)系，這些數(shù)據(jù)實體存在于一個分層次的目錄系統(tǒng)內(nèi)不相交的子樹之間。
現(xiàn)在將描述根據(jù)本發(fā)明的實施例使用別名。第一種情況是通過實施UDDI企業(yè)服務(wù)投影非常清晰地表示出來。企業(yè)服務(wù)投影實際上是企業(yè)服務(wù)的替換名。企業(yè)服務(wù)投影是一種看起來屬于企業(yè)A但實際上屬于企業(yè)B并且由企業(yè)B定義的企業(yè)服務(wù)。
參考圖5，企業(yè)A所擁有的企業(yè)服務(wù)51看起來也屬于企業(yè)B。企業(yè)A對企業(yè)服務(wù)51所作的任何改變都會在投影的服務(wù)中反映出來，似乎是由企業(yè)B進行的。相似地，圖過從注冊中刪除企業(yè)服務(wù)51，則它將不會再出現(xiàn)在企業(yè)A和企業(yè)B之下。另外，企業(yè)B既不能編輯也不能改變企業(yè)服務(wù)51。為了編輯以及其它的發(fā)布目的，只有企業(yè)A可以訪問企業(yè)服務(wù)51。
可以利用目錄別名系統(tǒng)來獲得這一效果。企業(yè)服務(wù)51的別名被添加到企業(yè)實體B。別名是目錄服務(wù)器的特殊標記，其意思實際上是“當有人看到這個別名時在這里向它們顯示其它的條目”。
這意味著，當編輯原始服務(wù)時，在投影中的改變也是可見的。如果目錄系統(tǒng)支持別名完整性(對于eTrust目錄來說確實如此)，當服務(wù)被刪除時，投影也會被自動刪掉。
此外，目錄服務(wù)器可以被配置用于在搜索被投影的企業(yè)服務(wù)時顯示它兩次，分別在每個父親之下。當執(zhí)行的搜索需要分別企業(yè)服務(wù)的父親時這樣做是有益的。
某些情形下要求在目錄層次的不相交部分的中的對象維持一個關(guān)系。
其實例在綁定模板和Tmodel之間。Tmodel在整個UDDI中被用于各種目的。它們是分類鍵值，搜索標識符，(UDDI)關(guān)系描述符以及在本例中的技術(shù)規(guī)范“指紋”。被附加到一個綁定模板上的Tmodel描述了該綁定模板(見圖8)所遵循的技術(shù)規(guī)范。例如，發(fā)布者可以附加一個Tmodel，斷言它們的綁定模板遵循SOAP 1.1標準。
一個注冊通常包含了Tmodel的有限集合，其中的許多將被數(shù)以百計甚至千計的綁定模板條目所引用。在某些情況下，注冊將使用綁定模板的細節(jié)來返回任何附加的Tmodel的細節(jié)。
根據(jù)本發(fā)明的實施例，諸如在關(guān)系數(shù)據(jù)庫系統(tǒng)中使用的主/外鍵值系統(tǒng)可以被適當?shù)匦薷暮蛻?yīng)用。存儲在注冊中的每個Tmodel有其自己的唯一(主)鍵值。綁定模板通過增加一個與所需要的Tmodel的唯一鍵值匹配的本地(外)鍵值來引用Tmodel。圖7實例了這種情況的一個實例。如果Tmodel數(shù)據(jù)需要與綁定模板一起返回，則服務(wù)器可以查詢所關(guān)心的Tmodel。
圖6示出了綁定模板和Tmodel之間的關(guān)系。
圖7示出了Tmodel鍵值怎樣創(chuàng)建兩個實體之間的關(guān)系。
發(fā)布者斷言是UDDI信息庫的一個重要要素。如以上指出的。它為用戶提供了發(fā)現(xiàn)哪個實體與感興趣的企業(yè)實體相關(guān)以及如何相關(guān)的能力。
發(fā)布者斷言被設(shè)計用于阻止濫用，因為只有當所涉及的企業(yè)實體的擁有者斷言了該關(guān)系時被斷言的關(guān)系才變得可見。這種保護是有代價的，它使得實施更加復(fù)雜，并且必須精心設(shè)計以避免性能降低。
一個問題是完整性。與其它UDDI結(jié)構(gòu)相比，發(fā)布者斷言具有復(fù)雜的生命周期。當企業(yè)實體的擁有者對該企業(yè)以及其與另一企業(yè)實體的關(guān)系做出斷言時產(chǎn)生發(fā)布者斷言。另一企業(yè)實體的擁有者可以請求一個狀態(tài)報告，并且發(fā)現(xiàn)關(guān)于它們的企業(yè)已經(jīng)做出了什么斷言，或者它們可以在通道外被通知。另一企業(yè)實體的擁有者可以選擇任一方式對兩個企業(yè)實體之間的關(guān)系做出匹配的斷言。當斷言完成并且對用戶可見時調(diào)用findRelatedBusiness?？梢孕薷幕騽h除一個或者兩個斷言，并且斷言再次變成不完整的，而不再可見。此外，刪除任一企業(yè)實體都將立即刪掉斷言。
可以用一種維護斷言的完整性的方式來管理發(fā)布者斷言對象。
希望企業(yè)實體的擁有者能夠?qū)τ伤刂频钠髽I(yè)實體做出(已經(jīng)刪掉)斷言。
本發(fā)明的實施例是以如下的假設(shè)為基礎(chǔ)的，即，UDDI信息庫是一個“以讀為主(read-mostly)”存儲，如專用于X.500目錄的存儲。為此，可以優(yōu)化設(shè)計以獲得更好的讀取性能，甚至是以提高寫操作的負擔為代價。
設(shè)計一種被稱為發(fā)布者斷言的對象類來保存UDDI標準所需的數(shù)據(jù)之外的數(shù)據(jù)，因此，希望最優(yōu)化搜索性能。該設(shè)計引入一個操作屬性，其定義了發(fā)布者斷言的狀態(tài)。在寫入到目錄時確定斷言的狀態(tài)，并且以這種方式不需要在每次執(zhí)行搜索是都進行確定。
本實施例還使用用戶鍵值形式的指針。當發(fā)布者斷言被寫入到目錄時，確定用于“去往的”和“來自的”企業(yè)的用戶鍵值，并將其寫入到對象中。這簡化了getAssertionStatusReport查詢，因為產(chǎn)生這種報告所需要的知識搜索發(fā)布者斷言，其包含了產(chǎn)生該報告的人的用戶鍵值。
與之對照，如果必須查詢用戶之下的所有企業(yè)鍵值，然后查找包含那些企業(yè)鍵值的發(fā)布者斷言來產(chǎn)生報告，則將需要相當?shù)墓ぷ髁俊?br> 發(fā)布者斷言的一種平常用途是發(fā)現(xiàn)與給定企業(yè)有關(guān)的那些企業(yè)。為了提供查詢的良好性能，與企業(yè)有關(guān)的發(fā)布者斷言作為該企業(yè)的子節(jié)點設(shè)置。
此外，每個斷言的狀態(tài)作為一個操作屬性被記錄在斷言中。這樣有可能只是查詢其狀態(tài)完全位于感興趣的公司之下的發(fā)布者斷言。由于該搜索將只是調(diào)用那些完成了的斷言，因此簡化了findRelatedBusinesses的搜索。
為了簡化安全性，由一個用戶控制的所有企業(yè)以及它們的出版者斷言可以是該企業(yè)的帳戶條目下的子節(jié)點。這種實施方式迫使訪問控制只是允許用戶訪問該用戶的帳戶條目之下的子樹。
注意表示該狀態(tài)的操作屬性由該UDDI實施方式進行管理。當用戶發(fā)布一個已經(jīng)被另一斷言的企業(yè)斷言過的斷言時，UDDI實施將會更新該另一斷言的狀態(tài)，所述另一斷言在另一企業(yè)的用戶所控制的子樹中。
作為存儲兩個發(fā)布者斷言對象的替換實施例(在所涉及的兩個企業(yè)實體之下各有一個)，在其自己的子樹中提供單個的發(fā)布者斷言對象。例如，可以在信息庫對象之下提供發(fā)布者斷言子樹。在這種情形下當最初存儲斷言時，賦予其一個不完整狀態(tài)(根據(jù)是哪一方做出斷言可以是tokeyincomplete或者fromkeyincomplete)。如果發(fā)布者斷言被一個互補用戶斷言，則狀態(tài)變?yōu)橥暾?。如果發(fā)布者斷言被二者之一刪除，則狀態(tài)又變成不完整的。如果發(fā)布者斷言被雙方刪除，則刪掉發(fā)布者斷言對象。有益地，這樣可以只有一個斷言的拷貝，并且大部分的維護工作是對保存了斷言狀態(tài)的單個屬性進行修改。
圖12示意性地示例了根據(jù)本發(fā)明一個實施例的層次。該示意圖示例了兩種替換方案，其中發(fā)布者斷言被置于企業(yè)實體和/或信息庫對象之下。
圖8示出了一種請求添加發(fā)布者斷言的方法。在步驟S80，判斷請求是否有效。如果無效(否，步驟S80)，則請求失敗(步驟S92)。如果請求有效(是，不知道S80)，則判斷請求是否來自我們的企業(yè)(步驟S82)。如果不是來自我們的企業(yè)(否，步驟S82)，則判斷是否到我們的企業(yè)(步驟S84)。如果是到我們的企業(yè)(是，步驟S84)，判斷該斷言是否來自和由擁有者做出(步驟S86)。如果斷言不是來自和由擁有者做出(否，步驟S86)，則寫入不完整的斷言(步驟S94)。如果斷言來自并且由擁有者做出(是，步驟S86)，則寫入完整斷言(步驟S96)。返回到步驟S82，如果判斷請求來自我們的企業(yè)(是，步驟S82)，判斷它是否到我們的企業(yè)(步驟S88)。如果不是到我們的企業(yè)(否，步驟S88)，判斷斷言是否到擁有者并且由擁有者做出(步驟S90)。如果斷言不是到擁有者和由擁有者做出(否，步驟S90)，寫入不完整斷言(步驟S94)。如果步驟S88的結(jié)果為是(到我們的企業(yè))，或者步驟S90的結(jié)果為是(斷言由擁有者做出并且到擁有者)，寫入完整的斷言(步驟S96)。
下一個問題處理在搜索操作期間怎樣優(yōu)化中間搜索結(jié)果集合，以便在考慮到目錄存儲介質(zhì)限制的情況下，目錄訪問和迭代的存儲器內(nèi)操作得以最小化。實踐中，目錄條目可以以任意的順序被存儲和返回，并且目錄結(jié)果太大而不能排序。
根據(jù)本發(fā)明的實施例，提供了一種與唯一結(jié)果排序方案耦合在一起的面向?qū)ο蟮拇鎯ζ鲀?nèi)數(shù)據(jù)存儲系統(tǒng)，所述排序方案按照區(qū)別名稱(Distinguished Name)對中間結(jié)果進行排序。這使得一個搜索返回許多類型的對象-BusinessEntity，BusinessServices等-并且仍然允許系統(tǒng)容易地構(gòu)建正確的XML結(jié)構(gòu)來返回數(shù)據(jù)給用戶。注意Web服務(wù)交互在XML中。
現(xiàn)在將描述此類系統(tǒng)的描述。UDDI BusinessEntity以及在本發(fā)明中的任何數(shù)據(jù)要素都根據(jù)以下結(jié)構(gòu)在目錄中表示(部分地)BusinessEntity·BusinessServiceobindingTemplateo BindingTemplateo ServiceName
o ServiceName·BusinessServiceo BindingTemplateo BindingTemplateo ServiceNameo ServiceName·BusinessName·BusinessName·BusinessDescription·BusinessDescription注意ServiceName，BusinessName以及BusinessDescription已經(jīng)結(jié)果本發(fā)明處理子結(jié)構(gòu)和對象分割(Object Splitting)而進行了描述。
BusinessEntity恢復(fù)代碼基于所需要的企業(yè)實體的唯一鍵值之下目錄子樹搜索。該搜索會返回找到的條目，以及子條目。目錄標準不能保證返回條目的任何特定順序-甚至子條目也不一定緊隨其父條目。
因此，恢復(fù)代碼按照區(qū)別名稱對返回的條目進行排序。這確保了子條目按順序在去父條目之后，并且可以輕松地區(qū)分父子關(guān)系?？梢允褂枚喾N排序算法。如果條目是被部分排序，則所使用的排序算法應(yīng)當具有高性能的特征。
用于結(jié)果構(gòu)建的算法基本上是以“深度優(yōu)先，從左向右遍歷樹(depth-first，left-to-right tree-walk)”。這在圖論中也被稱為“后序遍歷”。
排序后的列表被傳遞給一個新的BusinessEntity對象的構(gòu)造器方法。該對象可以是例如被設(shè)計用于表示一個UDDI企業(yè)實體的面向?qū)ο缶幊痰慕Y(jié)構(gòu)。該BusinessEntity對象包含了代碼，以根據(jù)該條目列表中提供的數(shù)據(jù)來“構(gòu)建它自己”。代碼迭代地通過列表，對于每個條目進行判斷?？梢岳斫庠摿斜碇械牡谝粋€條目應(yīng)當是企業(yè)實體本身的主條目，并且一旦它發(fā)現(xiàn)了另一BusinessEntity，可以理解為已經(jīng)完成了該結(jié)構(gòu)-列表的有序性保證了這一點。一旦發(fā)現(xiàn)了BusinessService或者其它子條目，就為一個適當類型的對象生成實例，并且列表被傳送到一個新的對象的構(gòu)造器，以及一個指針，用于告訴該構(gòu)造器在列表中的什么地方開始。
每個對象基本上包含相似的代碼來處理其自身的構(gòu)建，并且把任何子條目的構(gòu)造委托給適當?shù)淖訉ο蟆?br> 這樣，只需要執(zhí)行單個條目搜索，并且以有效的方式來處理獲得的列表，每個條目只被處理一次。如果列表是任意順序的，或者以其它方式排序，則必須對列表進行多通處理，才能根據(jù)獲得的條目來構(gòu)造一個UDDI層次。
構(gòu)造的委托以及在層次中對不同編程對象的列表處理使得處理代碼的尺寸相對較小，因而更加有效和快速。
附圖9示例了編程構(gòu)造(對象)，包括排序的條目列表的表示。判斷在列表中是否還有其它項目。如果沒有額外的項目(否，步驟S100)，退出進程(步驟S118)。如果存在額外的項目(是，步驟S100)，則檢索列表中的下一項目(步驟S102)。然后判斷該項目是否屬于這種對象類型。如果項目屬于這種對象類型(是，步驟S104)，則基于該項目來設(shè)置對象屬性(步驟S106)，并且進程返回到步驟S100。如果不屬于這種對象類型(否，步驟S104)，判斷是否已經(jīng)處理了一個該對象類型的項目(步驟S108)。如果還未處理該對象類型的項目(否，步驟S108)，則進程返回到步驟S100。如果已經(jīng)處理了一個該對象類型的項目(是，步驟S108)，判斷該項目是否為該對象的一個固有組件(例如Name，Description等等)。如果是一個固有組件(是，步驟S110)，則將該項目添加到該對象屬性并且執(zhí)行額外的處理(步驟S112)，并且處理返回到步驟S100。如果不是一個固有組件(否，步驟S110)，判斷該項目是否為該對象的子對象(例如，BusinessService，當對象是BusinessEntity時)。如果它是一個子對象(是，步驟S114)，則系統(tǒng)為正確類型的對象生成實例，并將項目列表傳遞給構(gòu)造器(步驟S116)，并且進程返回到步驟S100。如果不是一個子對象(否，步驟S114)，則進程返回到步驟S100。
以下是一個“真實世界(real world)”實例，表示期望返回的任意順序的LDAP目錄。
SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvalueuddiDescriptionSearchResultEntryobjectNameserviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClass
valuebusinessServiceSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceNameSearchResultEntryobjectNamebindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebindingTemplateSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntityName列表1—著重強調(diào)的名稱條目是列表頂部的企業(yè)實體注冊的一頁，且如果它出現(xiàn)在企業(yè)服務(wù)條目和其他企業(yè)實體的分支子條目之前是很有用的。但是它出現(xiàn)在列表的末尾，這迫使任何搜索整個列表的程序代碼要確保企業(yè)實體的所有直系子對象都被處理過。而這可能不是最有效率的。
因此，已經(jīng)根據(jù)規(guī)則排序的相同的數(shù)據(jù)根據(jù)本發(fā)明的實施例可以表示如下SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvalueuddiDescriptionSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributes
typeobjectClassvaluebusinessEntityNameSearchResultEntryobjectNameserviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceSearchResultEntryobjectNamebindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebindingTemplateSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceName列表2—著重強調(diào)的條目現(xiàn)在出現(xiàn)在列表中一個更為邏輯的位置，且借助于這點現(xiàn)在可以寫入程序代碼。當條目數(shù)量增加到實際服務(wù)器負載時，節(jié)省的程序時間是十分可觀的。
下面是本發(fā)明的另一個實施例。
#描述UDDI數(shù)據(jù)和/或目錄中關(guān)系的計劃......表達式100#Computer Associates eTrust UDDI Configuration Schema#Copyright2002 Computer Associates Incset oid-prefix uddiAttributeType＝(1.3.6.1.4.1.3327.80.1)；set oid-prefix uddiObjectClass＝(1.3.6.1.4.1.3327.80.2)；set oid-prefix uddiBinding＝(1.3.6.1.4.1.3327.80.3)；#-----------------------------------------------------------------------------------#Key attributesset attribute uddiAttributeType:201＝{#用于KeyedReferenc和所有其導(dǎo)出類name＝euKeyedReferenceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:202＝{#用于UserAccountname＝euUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:203＝{#用于BusinessEntity，TModel及其它name＝euParentUserKey
syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:204＝{#用于BusinessEntityname＝euBusinessEntityKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:205＝{#用于BusinessService及其它name＝euParentBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:206＝{#用于BusinessServicename＝euBusinessServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:207＝{#用于BindingTemplate及其它name＝euParentServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:208＝{#用于BindingTemplate
name＝euBindingTemplateKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:209＝{#用于TModelname＝euTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:210＝{#用于PublisherAssertionname＝euPublisherAssertionKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:211＝{#用于PublisherAssertionname＝euFromBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:212＝{#用于PublisherAssertionname＝euFromUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:213＝{#用于PubIisherAssertionname＝euToBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:214＝{#用于PublisherAssertionname＝euToUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:216＝{#用于DiscoveryURLname＝euDiscoveryURLKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:217＝{#用于聯(lián)系方式name＝euContactKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:218＝{#用于Addressname＝euAddressKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:219＝{#用于Addressname＝euAddressTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:220＝{#用于AddressLinename＝euAddressLineKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:221＝{#用于Phonename＝euPhoneKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:222＝{#用于Emailname＝euEmailKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:223＝{#用于TmodelInstanceInfoname＝euInstanceTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:224＝{#用于Name及其所有導(dǎo)出類name＝euNameKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:225＝{#用于Description及其所有導(dǎo)出類name＝euDescriptionKeysyntax＝caseIgnoreStringsingle-valued}；#----------------------------------------------------------------------------------#keyed references中使用的屬性set attribute uddiAttributeType:301＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:302＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:303＝{#用于BusinessEntityCategoryname＝euBusinessEntityCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:304＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:305＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:306＝{#用于BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:307＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType:308＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:309＝{#用于BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:310＝{#用于TModelCategoryname＝euTModelCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:311＝{#用于TModelCategoryname＝euTModelCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:312＝{#用于TModelCategoryname＝euTModelCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:313＝{#用于TModelIdentifiername＝euTModelIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:314＝{#用于TModelIdentifiername＝euTModelIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:315＝{#用于TModelIdentifiername＝euTModelIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:316＝{#用于PublisherAssertionname＝euPublisherAssertionKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:317＝{#用于PublisherAssertionname＝euPublisherAssertionKRKeyName
syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:318＝{#用于PublisherAssertionname＝euPublisherAssertionKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；#---------------------------------------------------------------------------#用于名稱和描述的屬性set attribute uddiAttributeType:361＝{#用于Business Entity Namename＝euBusinessEntityNameValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:381＝{#用于Business Entity Namename＝euBusinessEntityNameValuelCsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:362＝{#用于Business Service Namename＝euBusinessServiceNameValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:382＝{#用于Business Service Namename＝euBusinessServiceNameValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:363＝{#用于Business Entity Descriptionname＝euBusinessEntityDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:383＝{#用于Business Entity Descriptionname＝euBusinessEntityDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:364＝{#用于Business Service Deseriptionname＝euBusinessServiceDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:384＝{#用于Business Service Descriptionname＝euBusinessServiceDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:365＝{#用于TModel Descriptionname＝euTModelDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:385＝{#用于TModel Descriptionname＝euTModelDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:366＝{#用于TModelInstance Info Descriptionname＝euTModelInstanceInfoDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:386＝{#用于TModel Iustance Info Descriptionname＝euTModelInstanceInfoDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:367＝{#用于TModel Instance Details Description
name＝euTModelInstanceDetailsDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:387＝{#用于TModel Instance Details Descriptionname＝euTModelInstanceDetailsDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:368＝{#用于Overview Doc Descriptionname＝euOverviewDocDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:388＝{#用于Overview Doc Descriptionname＝euOveryiewDocDescription ValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:369＝{#用于Binding Template Descriptionname＝euBindingTemplateDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:389＝{#用于Binding Template Descriptionname＝euBindingTemplateDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:370＝{#用于Contact Descriptionname＝euContactDescription Valuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType:390＝{#用于Contact Descriptionname＝euContactDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；#----------------------------------------------------------------------------------#其他屬性set attribute uddiAttributeType:400＝{#用于Name和Descriptionname＝euLanguagesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:401＝{#用于Repositoryname＝euRepositoryNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:402＝{#用于UserAccountname＝euUserNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:403＝{#用于UserAccountname＝euCredentialssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:404＝{#用于UserAccountname＝euAuthorizedNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:405＝{#用于UserAccount和TModelname＝euHiddensyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:406＝{#用于BusinessEntity和TModelname＝euOperatorsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:407＝{#用于Contactname＝euContactNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:408＝{#用于discoveryURL、contact、address、phone、emailname＝euUserTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:409＝{#用于phonename＝euPhoneNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:419＝{#用于emailname＝euEmailAddresssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:411＝{#用于addresssname＝euSortCodesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:412＝{#用于BindingTemplatename＝euHostingRedirectorsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:413＝{#用于BindingTemplatename＝euAccessControlsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:414＝{#用于BindingTemplatename＝euAccessPointTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:415＝{#用于TModelname＝euTModelNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:416＝{#用于TModelname＝euOverviewURLsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:417＝{#用于AddressLinename＝euAddressLineValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:418＝{#用于tmodel instance infoname＝euInstanceParmssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:420＝{#用于PublisherAssertionname＝euPublisherAssertionStatussyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType:421＝{#用于DiscoveryURLname＝euDiscoveryURLValuesyntax＝caseIgnoreStringsingle-valued}；#-----------------------------------------------------------------------------------#抽象類——不能在目錄中存儲該類！set object-class uddiObjectClass:201＝{#用作所有關(guān)鍵字索引的父類的抽象類name＝euKeyedReferencesubclass-of topkind＝abstractmust-containeuKeyedReferenceKey}；#注意關(guān)鍵字索引也應(yīng)包含tModel鍵、鍵名稱和鍵值，#每個導(dǎo)出類添加這些值，使得它們有不同的名稱，#便于搜索如下屬性的標準化名稱# euXXXTModel# euXXXKeyName# euXXXKeyValue#其中，XXX是對象的名稱和關(guān)鍵字索引的目的}；set object-class uddiObjectClass:202＝{#用作所有名稱的父類的抽象類name＝euNamesubclass-of topkind＝abstractmust-containeuNameKeymay-containeuLanguage#注意名稱也應(yīng)有一個包含特有名稱的字符串，該字符串往往有一個#euXXXNameValue格式的名稱，其中XXX是父對象的名稱#這將使搜索效率最高#該屬性還有另一個版本添加IC的忽略大小寫版本}；set object-class uddiObjectClass:203＝{#用作所有描述的父類的抽象類name＝euDescriptionsubclass-of topkind＝abstractmust-containeuDescriptionKeymay-containeuLangu age#注意描述也應(yīng)有一個包含特有名稱的字符串，該字符串往往有一個# euXXXDescriptionValue格式的名稱，其中XXX是父對象的名稱#這將使搜索效率最高#該屬性還有另一個版本添加IC的忽略大小寫版本}；#---------------------------------------------------------------------------------------------#關(guān)鍵字索引類型set object-class uddiObjectClass:301＝{#BusinessEntityCategory關(guān)鍵字索引——其集合組成分類口袋name＝euBusinessEntityCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryKRKeyValuemay-containeuBusinessEntityCategoryKRTModeleuBusinessEntityCategoryKRKeyName}；set object-class uddiObjectClass:302＝{#BusinessEntityIdentifier關(guān)鍵字索引——其集合組成分類口袋name＝euBusinessEntityIdentifierKRsubclass-of euKeyedReferencemust-containeuBusinessEntityIdentifierKRKeyValuemay-containeuBusinessEntityIdentifierKRTModeleuBusinessEntityIdentifierKRKeyName}；set object-class uddiObjectClass:303＝{#BusinessServiceCategory關(guān)鍵字索引——其集合組成分類口袋name＝euBusinessServiceCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessServiceCategoryKRKeyValuemay-contain
euBusinessServiceCategoryKRTModeleuBusinessServiceCategoryKRKeyName}；set object-class uddiObjectClass:304＝{#TModelCategory關(guān)鍵字索引——其集合組成分類口袋name＝euTModelCategoryKRsubclass-of euKeyedReferencemust-containeuTModelCategoryKRKeyValuemay-containeuTModelCategoryKRTModeleuTModelCategoryKRKeyName}；set object-class uddiObjectClass:305＝{#TModelIdentifier關(guān)鍵字索引——其集合組成口袋name＝euTModelIdentifierKRsubclass-of euKeyedReferencemust-containeuTModelIdentifierKRKeyValuemay-containeuTModelIdentifierKRTModeleuTModelIdentifierKRKeyName}；set object-class uddiObjectClass:306＝{#PublisherAssertion關(guān)鍵字索引——用作給出所關(guān)心的輔助類name＝euPublisherAssertionKRsubclass-of euKeyedReferencekind＝auxiliarymust-contain
euPublisherAssertionKRKeyValuemay-containeuPublisherAssertionKRTModeleuPublisherAssertionKRKeyName}；#----------------------------------------------------------------------------------#名稱和描述類型set object-class uddiObjectClass:331＝{#BusinessEntity的名稱name＝euBusinessEntityNamesubclass-of euNamemust-containeuBusinessEntityNameValueeuBusinessEntityNameValueIC#從euName繼承euNameKey和euLanguage}；set object-class uddiObjectClass:332＝{#BusinessService的名稱name＝euBusinessServiceNamesubclass-of euNamemust-containeuBusinessServiceNameValueeuBusinessServiceNameValueIC#從euName繼承euNameKey和euLanguage}；set object-class uddiObjectClass:341＝{#BusinessEntity的描述name＝euBusinessEntityDescriptionsubclass-of euDescriptionmust-containeuBusinessEntityDescription ValueeuBusinessEntityDescription ValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:342＝{#BusinessService的描述name＝euBusinessServiceDescriptionsubclass-of euDescriptionmust-containeuBusinessServiceDescriptionValueeuBusinessServiceDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:343＝{#TModel的描述name＝euTModelDescriptionsubclass-of euDescriptionmust-containeuTModelDescriptionValueeuTModelDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:344＝{#TModelInstanceInfo的描述name＝euTModelInstanceInfoDescriptionsubclass-of euDescriptionmust-containeuTModelInstanceInfoDescriptionValueeuTModelInstanceInfoDescriptionValneIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:345＝{#TModelInstanceDetails的描述name＝euTModelInstanceDetailsDescriptionsubclass-of euDescriptionmust-containeuTModelInstanceDetailsDescriptionValneeuTModelInstanceDetailsDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:346＝{#OveryiewDoc的描述name＝euOverviewDocDescriptionsubclass-of euDescriptionmust-containeuOverviewDocDescriptionValueeuOverviewDocDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:347＝{#Contact的描述name＝euContactDescriptionsubclass-of euDescriptionmust-containeuContactDescriptionValue
euContactDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass:348＝{#BindingTemplate的描述name＝euBindingTemplateDescriptionsubclass-of euDescriptionmust-containeuBindingTemplateDescriptionValueeuBindingTemplateDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；#--------------------------------------------------------------------------------------------------#主要對象set object-class uddiObjectClass:400＝{#repository——用于把用戶分組name＝euRepositorysubclass-of topmust-containeuRepositoryName}；set object-class uddiObjectClass:401＝{#UserAccount——用于存儲用戶信息name＝euUserAccountsubclass-of topmust-containeuUserKey，euUserName，euCredentialsmay-containeuAuthorizedName，euHidden#注意該用戶公布的所有BusinessEntity和TModel都是該對象的子類}；set object-class uddiObjectClass:402＝{#BusinessEntity——提供服務(wù)的實體的細節(jié)name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，euAuthorizedName，euOperator#注意BusinessEntity的許多屬性都存儲在該對象的子對象里#尤其是那些出現(xiàn)不只一次的屬性}；set object-class uddiObjectClass:403＝{#BusinessService——企業(yè)實體提供的服務(wù)的細節(jié)name＝euBusinessServicesubclass-of topmust-containeuBusinessServiceKeymay-containeuParentBusinessKey#注意該服務(wù)的所有BindingTemplate都是此服務(wù)的子類
}；set object-class uddiObjectClass:404＝{#BindingTemplate——如何訪問某一特定企業(yè)服務(wù)的細節(jié)name＝euBindingTemplatesubclass-of topmust-containeuBindingTemplateKeymay-containeuParentServiceKeyeuHostingRedirector，euAccessPoint，euAccessPointType#注意HostingRedirector和AccessPoint應(yīng)當只少該服務(wù)的所有BindingTemplate都是此服務(wù)的子類}；set object-class uddiObjectClass:405＝{#TModel——對某一思想的引用。一種分類機制可能只是一個標準的引用name＝euTModelsubclass-of topmust-containeuTModelKey，euTModelNamemay-containeuAuthorizedNameeuOperator，euOverviewURL，euParentUserKey，euHidden#注意Hidden在“刪除”TModel時使用}；set object-class uddiObjectClass:406＝{#PublisherAssertion——宣稱兩個企業(yè)之間的某一關(guān)系name＝euPublisherAssertionsubclass-oftopmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinessKey，euToUserKey，euPublisherAssertionStatus#注意關(guān)系將存儲為類型euPublisherAssertionKeyedReference的輔助類#這允許直接搜索該輔助類的元素}；#--------------------------------------------------------------------------------#次要對象——包含重復(fù)數(shù)據(jù)的主要對象的大多數(shù)子對象set object-class uddiObjectClass:501＝{#DiscoveryURL——存在于企業(yè)實體之下name＝euDiscoveryURLsubclass-of topmust-containeuDiscoveryURLKey，euDiscoveryURLValue，euUseType}；set object-class uddiObjectClass:502＝{#Contact——存在于企業(yè)實體之下——十分復(fù)雜，可能有許多子對象name＝euContactsubclass-of topmust-containeuContactKey，euContactNamemay-containeuUseType}；set object-class uddiObjectClass:503＝{#Address——存在于Contact之下name＝euAddresssubclass-of topmust-containeuAddressKeymay-containeuSortCode，euAddressTModelKey，euUseType}；set object-class uddiObjectClass:504＝{#AddressLine——存在于Address之下，組成地址行name＝euAddressLinesubclass-of topmust-contain
euAddress LineKey，euAddressLineValue}；set object-class uddiObjectClass:505＝{#Phone——存在于Contact之下name＝euPhonesubclass-of topmust-containeuPhoneKey，euPhoneNumbermay-containeuUseType}；set object-class uddiObjectClass:506＝{#Email——存在于Contact之下name＝euEmailsubclass-of topmust-containeuEmailKey，euEmailAddressmay-containeuUseType}；set object-class uddiObjectClass:507＝{#TModelInstanceInfo——存在于BindingTemplate之下name＝euTModelInstanceInfosubclass-of topmust-containeuInstanceTModelKeymay-containeuInstanceParms，euOverviewURL}；#-------------------------------------------------------------------------#名稱綁定schema set name-binding uddiBinding:101＝{#綁定到頂部——最高層子對象name＝euRepository-topeuRepository allowable-parent topnamed-by euRepositoryName}；schema set name-binding uddiBinding:102＝{#綁定到頂部——最高層子對象name＝euUserAccount-topeuUserAccount allowable-parent topnamed-by euUserKey}；schema set name-binding uddiBinding:103＝{#綁定到euRepositoryname＝euUserAccount-euRepositoryeuUserAccount allowable-parent euRepositorynamed-by euUserKey}；schema set name-binding uddiBinding:104＝{#綁定TModel到“頂部”——用于標準TModel(不被用戶公布)name＝euTModel-euRepositoryeuTModel allowable-parent euRepositorynamed-by euTModelKey}；schema set name-binding uddiBinding:105＝{#綁定到organization——最高層子對象name＝euRepository-organizationeuRepository allowable-parent organizationnamed-by euRepositoryName}；schema set name-binding uddiBinding:106＝{#考慮到可供選擇的配置，把PublisherAssertion綁定到euRepositoryname＝euPublisherAssertion-euRepositoryeuPublisherAssertion allowable-parent euRepositorynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding:107＝{#綁定Repository層次——允許多層repository結(jié)構(gòu)name＝euRepository-euRepositoryeuRepository allowable-parent euRepositorynamed-by euRepositoryName}；schema set name-binding uddiBinding:201＝{#把BusinessEntity綁定到UserAccount——第二層name＝euBusinessEntity-euUserAccounteuBusinessEntity allowable-parent euUserAccount
named-by euBusinessEntityKey}；schema set name-binding uddiBinding:202＝{#把TModel綁定到UserAccount——第二層name＝euTModel-euUserAccounteuTModel allowable-parent euUserAccountnamed-by euTModelKey}；schema set name-binding uddiBinding:301＝{#把服務(wù)綁定到企業(yè)——第三層name＝euBusinessService-euBusinessEntityeuBusinessService allowable-parent euBusinessEntitynamed-by euBusinessServiceKey}；schema set name-binding uddiBinding:302＝{#把聯(lián)系方式綁定到企業(yè)——第三層name＝euContact-euBusinessEntityeuContact allowable-parent euBusinessEntitynamed-by euContactKey}；schema set name-binding uddiBinding:303＝{#把DiscoveryURL綁定到企業(yè)——第三層name＝euDiscoveryURL-euBusinessEntityeuDiscoveryURL allowable-parent euBusinessEntitynamed-by euDiscoveryURLKey}；schema set name-binding uddiBinding:304＝{#企業(yè)下方的Namename＝euBusinessEntityName-euBusinessEntity
euBusinessEntityName allowable-parent euBusinessEntitynamed-by euNameKey}；schema set name-binding uddiBinding:305＝{#企業(yè)下方的Descriptionname＝euBusinessEntityDescription-euBusinessEntityeuBusinessEntityDescription allowable-parent euBusinessEntitynamed-by euDescriptionKey}；schema set name-binding uddiBinding:306＝{#企業(yè)下方的PublisherAssertionname＝euPublisherAssertion-euBusinessEntityeuPublisherAssertion allowable-parent euBusinessEntitynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding:307＝{#企業(yè)實體下方的Identifiername＝euBusinessEntityIdentifier-euBusinessEntityeuBusinessEntityIdentifier allowable-parent euBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:308＝{#企業(yè)下方的Categoryname＝euBusinessEntityCategory-euBusinessEntityeuBusinessEntityCategory allowable-parent euBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:310＝{#TModel下方的Description
name＝euTModelDescription-euTModeleuTModelDescription allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding:311＝{#TModel下方OverviewURL的Descriptionname＝euOverviewDocDescription-euTModeleuOverviewDocDescription allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding:312＝{#TModel下方的Identifiername＝euTModelIdentifierKR-euTModeleuTModelIdentifierKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:313＝{#TModel下方的Categoryname＝euTModelCategoryKR-euTModeleuTModelCategoryKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:401＝{#聯(lián)系方式下方的Addressname＝euAddress-euContacteuAddress allowable-parent euContactnamed-by euAddressKey}；schema set name-binding uddiBinding:402＝{#聯(lián)系方式下方的電話號碼name＝euPhone-euContacteuPhone allowable-parent euContactnamed-by euPhoneKey}；schema set name-binding uddiBinding:403＝{#聯(lián)系方式下方的Emailname＝euEmail-euContacteuEmail allowable-parent euContactnamed-by euEmailKey}；schema set name-binding uddiBinding:404＝{#聯(lián)系方式下方的描述name＝euContactDescription-euContacteuContactDescription allowable-parent euContactnamed-by euDescriptionKey}；schema set name-binding uddiBinding:409＝{#服務(wù)下方的Namename＝euBusinessServiceName-euBusinessServiceeuBusinessServiceName allowable-parent euBusinessServicenamed-by euNameKey}；schema set name-binding uddiBinding:410＝{#服務(wù)下方的Descriptionname＝euBusinessServiceDescription-euBusinessServiceeuBusinessServiceDescription allowable-parent euBusinessServicenamed-by euDescriptionKey}；schema set name-binding uddiBinding:411＝{#服務(wù)下方的Categoryname＝euBusinessServiceCategory-euBusinessServiceeuBusinessServiceCategory allowable-parent euBusinessServicenamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding:412＝{#服務(wù)下方的BindingTemplatename＝euBindingTemplate-euBusinessServiceeuBindingTemplate allowable-parent euBusinessServicenamed-by euBindingTemplateKey}；schema set name-binding uddiBinding:501＝{#地址下方的AddressLinename＝euAddressLine-euAddresseuAddressLine allowable-parent euAddressnamed-by euAddressLineKey}；schema set name-binding uddiBinding:502＝{#BindingTemplate下方的Descriptionname＝euBindingTemplateDescription-euBindingTemplateeuBindingTemplateDescription allowable-parent euBindingTemplatenamed-by euDescriptionKey}；schema set name-binding uddiBinding:510＝{#BindingTemplate下方的Descriptionname＝euTModelInstanceInfo-euBindingTemplateeuTModelInstanceInfo allowable-parent euBindingTemplatenamed-by euInstanceTModelKey
}；schema set name-binding uddiBinding:601＝{#TModelInstanceInfo下方的Descriptionname＝euTModelInstanceInfoDescription-euTModelInstanceInfoeuTModelInstanceInfoDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；schema set name-binding uddiBinding:602＝{#TModelInstanceInfo下方的InstanceDetailsDescriptionname＝euTModelInstanceDetailsDescription-euTModelInstanceInfoeuTModelInstanceDetailsDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；schema set name-binding uddiBinding:603＝{#TModelInstanceInfo下方的OverviewDocDescriptionname＝euOverviewDocDescription-euTModelInstanceInfoeuOverviewDocDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；由于本發(fā)明可以用多種形式實現(xiàn)，而不會背離本發(fā)明的基本特征的精神，因此應(yīng)當理解，除非特別指明，上述實施例不能用于限制本發(fā)明，而應(yīng)當以附加的權(quán)利要求所定義的范圍來廣泛地解釋本發(fā)明的精神和范圍。各種修改和等價設(shè)置被預(yù)定包含在本發(fā)明以及附加的權(quán)利要求的范圍中。
權(quán)利要求
1.一種應(yīng)用在Web服務(wù)系統(tǒng)中的方法，包括在第一企業(yè)實體下，提供至少一個第一企業(yè)服務(wù)；以及在第二企業(yè)實體下提供一個企業(yè)服務(wù)投影，該企業(yè)服務(wù)投影在第二企業(yè)服務(wù)實體下反映了所述至少一個第一企業(yè)服務(wù)。
2.權(quán)利要求1所述的方法，還包括表示一個替換名，包括利用目錄技術(shù)的別名特征來表示該替換名。
3.權(quán)利要求2所述的方法，其中該別名特征是以一個別名對象實現(xiàn)的，該別名對象包含一個命名屬性和一個別名對象名稱，前者的值等于替換名，后者的值是該別名所指向的目錄對象的名稱。
4.一種包括計算機可執(zhí)行代碼的計算機記錄介質(zhì)，以便在Web服務(wù)系統(tǒng)中使用，包括用于在第一企業(yè)實體下提供至少一個第一企業(yè)服務(wù)的代碼；以及用于在第二企業(yè)實體下提供一個企業(yè)服務(wù)投影的代碼，該企業(yè)服務(wù)投影在第二企業(yè)服務(wù)實體下反映了所述至少一個第一企業(yè)服務(wù)。
5.權(quán)利要求4所述的計算機記錄介質(zhì)，還包括用于表示一個替換名的代碼，包括利用目錄技術(shù)的別名特征來表示該替換名。
6.權(quán)利要求5中所述的計算機記錄介質(zhì)，其中該別名特征是以一個別名對象實現(xiàn)的，該別名對象包含一個命名屬性和一個別名對象名稱，前者的值等于替換名，后者的值是該別名所指向的目錄對象的名稱。
全文摘要
一種在Web服務(wù)系統(tǒng)中使用的方法，包括在第一企業(yè)實體下，提供至少一個第一企業(yè)服務(wù)，以及在第二企業(yè)實體下提供一個企業(yè)服務(wù)投影，該企業(yè)服務(wù)投影在第二企業(yè)服務(wù)實體下反映了所述至少一個第一企業(yè)服務(wù)。
文檔編號G06F15/16GK1678991SQ03820202
公開日2005年10月5日 申請日期2003年8月25日 優(yōu)先權(quán)日2002年8月26日
發(fā)明者理查德·哈維, 蒂莫西·本特利 申請人:計算機聯(lián)合思想公司