網絡服務裝置和方法
2023-05-16 06:13:01 1
專利名稱：網絡服務裝置和方法
技術領域：
本發明大體上涉及UDDI註冊和網絡服務，尤其是涉及對這些設備提供實際效果的方法、裝置和系統。
相關技術UDDI(通用描述、發現和集成)是一個標準集，其使得使用網絡服務的應用程式能夠快速、便捷且動態地交互作用。UDDI是用於建立一個與平臺無關的開放式框架，用於通過網際網路以及可操作的註冊中心，描述服務、發現企業以及集成系統服務。更多細節可參看網址www.uddi.org。
UDDI註冊為使用網絡服務的結構化系統提供有力的支持。圖1a示意性地闡釋了基本網絡服務和UDDI概念。圖1b示意性闡釋了網絡服務環境的簡化協議棧。UDDI提供了網絡服務信息的信息庫，這本身也可以作為一種網絡服務來提供。
UDDI允許應用程式公開其如何通過網絡相互作用。每種「網絡服務」是自描述、自包容、模塊化單元的應用程式邏輯，通過網絡連接為其他應用程式提供某些系統功能。應用程式藉助於普遍的網絡協議和數據格式訪問網絡服務，而不必考慮各個網絡服務是如何實現的。網絡服務可以和其他網絡服務結合和匹配，來執行較大的工作流程或商業企業。
UDDI標準描述了一個特定用途的信息庫，用來管理網絡服務類型、商業組織的描述以及如何調用網絡服務的細節。該標準不必詳細說明如何執行標準，也不必說明其實現是否應該包括使用了資料庫、目錄或任何其他介質的存儲器。
制定UDDI標準的組織創辦的網址上(http//www.uddi.org/faqs.html)有許多常見問題(FAQ)。其中一個問題是「能夠建立一個或基於LDAP的UDDI註冊嗎？」網站給出的答案中證實在UDDI和目錄之間沒有明確的關係。UDDI說明書沒有規定註冊執行細節。UDDI說明書定義了一種基於XML的數據模型以及一組SOAP APIs來訪問和使用數據模型。SOAP APIs定義了UDDI信息庫出現的狀態。執行UDDI可以建立在LDAP目錄上，只要其符合規定的狀態。因此，所有的UDDI執行都可以建立在關係資料庫上。
需要注意的是目錄技術，如X.500和LDAP，是可擴展的、通用的數據存儲，也是最常用的管理用戶和資源的關聯語言。這些是很完備的技術，已經廣泛應用，並且認為非常穩定和可靠。
但是在目錄上執行UDDI標準(www.uddi.org上可獲取)需要解決許多問題。UDDI標準遺留了許多重要的未解決的問題，例如●UDDI標準定義了大量對象，其中一些對象以層次結構相關聯，但UDDI沒有定義一個包含所有對象的層次結構。例如，商業服務對象位於企業實體對象之下，而綁定模板對象位於商業服務對象之下。圖2闡釋了這種層次結構的一個實例。企業實體對象標註為21，商業服務對象標註為22，而綁定模板對象標註為23。同樣需要注意的是標註為24的TModel對象和這些對象沒有層次關係。同樣也有其他概念例如發行者聲明沒有層次化定義。
●對於需要允許用戶僅能改變在他/她的控制下的這些對象，能夠創建有效的執行方法，●創建有效的執行方法能夠允許UDDI註冊進行分布，●創建有效的執行方法能夠加強搜索和更新的可管理性以及性能，
●如何用相對有效的方法描述複雜的UDDI對象。例如企業實體，商業服務，綁定模板和/或TModel具有複合的重複要素。而這些重複要素又包含了其他重複的要素。例如企業實體包含聯繫方式，而聯繫方式包含地址。地址可能包含地址行和電話號碼。圖13示意性地闡釋了企業實體中一個相對複雜對象的UDDI概念。企業實體對象131包括例如一系列屬性132，如授權名稱，企業鍵，以及名稱。名稱有一個或多個名稱欄位133，如「文本」或「名稱」自身中固有的。還有「語言」。此處可能有一個或多個該類欄位133，●如何相對快速搜索重複要素所包含的特定項目，●如何在目錄對象的層次結構中表示UDDI信息和請求，●如何有效地處理UDDI對象以及其所有相關信息的刪除，以及●如何優化搜索過程中獲得的中間搜索結果的結構，考慮到目錄存儲介質的限制，從而把目錄訪問和重複訪問存儲器的操作最小化。實際中，可以存儲目錄條目並以隨機順序返回，且目錄結果太大以至於不能對其排序，●如何有效地表示與發行者聲明相關的數據，●如何創建有效的發行者聲明的實現方法，尤其是考慮到尋找相關企業的實現方法，●如何根據關係來有效地搜索發行者聲明，●如何處理髮行者聲明的有效性，●如何限制創建的聲明以及刪除企業實體所有者生成的企業實體，●如何有效地按照UDDI標準中的定義來處理相關的屬性集合，●如何定義屬性和對象來增強搜索性能。
現在已經提出了許多種UDDI模式。但是沒有一個模式解決了至少上述問題。例如一種模式提出了相對簡單化地把UDDI對象映射到目錄對象，而沒有考慮複雜性和優化以獲得有效的商業實現。但仍然不清楚許多UDDI服務(尤其是find_series)如何能夠在該模式下有效實現。
例如，圖14示意性地闡釋了企業實體中相對複雜對象的Novell表示形式。企業實體對象141，包括例如一系列屬性142，分別具有「類型」和「數值」。如圖所示，授權名字的值是「Bill」，企業鍵的值是「890.obale.890......」，而名稱有多個值143，144即en#CAIN#CATSUDDI(圖13)和Novell(圖14)實例中的表示形式不是用於網絡服務的有效表示形式。
因此需要解決上述的一般問題和其他問題，以提供一種相對可擴展的、有效且可靠的基於目錄的UDDI實現。
發明內容
網絡服務目錄包括至少一個企業實體對象以及至少一個用戶對象，其中至少一個企業實體對象設置在至少一個用戶對象之下。
網絡服務系統包括一個其中可以對企業進行註冊的註冊中，該註冊中心包括一個有層次結構的目錄，該目錄包括至少一個企業實體對象和至少一個用戶對象，該企業實體對象被設置在至少一個用戶對象之下，以及一個存儲系統，其用於存儲商業信息，並可通過層次結構目錄訪問。
參照優選實施例的以下描述並結合附圖，能夠更好地理解本發明的其他目標、優點及方面，其中圖1a示意性地闡釋了一些網絡服務和UDDI概念；圖1b示意性地闡釋了一個網絡服務環境下的簡化協議棧；圖2示意性地闡釋了根據相關技術的層次結構；圖3示意性地闡釋了根據相關技術的目錄服務模型；圖4示意性地闡釋了根據本發明的一個實施例，用X.500目錄技術實現的UDDI服務模型的基礎組件；
圖5示意性地闡釋了根據本發明的一個實施例中的服務投影圖；圖6示意性地闡釋了根據本發明的一個實施例，綁定模板和TModel之間的相關性；圖7示意性地闡釋了根據本發明的一個實施例，TModel如何在兩個實體間建立關係；圖8闡釋了根據本發明的一個實施例，請求添加一個發行者聲明的邏輯表示形式；圖9闡釋了根據本發明的一個實施例，UDDI數據對象構造器的邏輯表示形式；圖10示意性地闡釋了在用戶對象之下設置企業實體對象；圖11示意性地闡釋了在用戶對象之上設置域對象；圖12示意性地闡釋了根據本發明的一個實施例的一種模式草圖；圖13示意性地闡釋了根據相關技術，企業實體中相對複雜對象的UDDI概念；圖14示意性地闡釋了根據相關技術，企業實體中相對複雜對象的Novell表示形式；圖15示意性地闡釋了根據本發明的一個實施例，引入了層次結構用於表示企業實體中相對複雜的對象；圖16示意性地闡釋了根據本發明的一個實施例的綁定模板的分層子結構；圖17示意性地闡釋了展平和/或合併的綁定模板子結構；以及圖18是能夠執行本發明的不同方面的計算機系統的框圖。
具體實施例方式
如圖所示描述本發明的優選實施例，為了清楚起見而使用了專用術語。但是本發明不僅限於所選的專用術語，應該理解各個特定要素包括所有以相似方法操作的同等技術。
圖18示出了一個能夠執行本發明的方法和系統的計算機系統實例。本發明的系統和方法可以用計算機系統上運行的軟體應用程式形式來實現，例如大型機、個人計算機(PC)、手持計算機，伺服器等。軟體應用程式可以存儲在計算機系統能在本地訪問的記錄介質上，例如軟盤、高密度磁碟、硬碟等，或者可用計算機系統遠程控制，並通過硬線或無線連接到網絡進行訪問，例如區域網或網際網路。
圖18中示出了一種能夠執行本方法和系統的計算機系統實例。計算機系統180通常包括一個中央處理器(CPU)182，存儲器184，例如隨機訪問存儲器(RAM)，列印接口186，顯示單元188，(LAN)區域網數據傳輸控制器190，LAN接口192，網絡控制器194，內部總線196，及一個或多個輸入設備198，例如鍵盤、滑鼠等。如圖所示，系統180可以通過鏈路202連接到數據存儲設備，例如硬碟200。
下面概括描述本發明的實施例的幾個突出特徵以及其具有的一些優點。
根據本發明的實施例，在用戶層之上創建一個信息庫層，這樣可以在各個不同的伺服器上設置一個信息庫。這種信息庫層包括一個或多個目錄節點，它們共同構成了目錄前綴。這也認為是信息庫的「域」或「名稱」。這樣做的優點是能夠提供一個單獨的空間來保存關於域的信息。節點的名稱表示這一目錄的前綴。
可創建一個用戶對象來保存表示UDDI帳戶的數據。這樣做的優點是能夠提供一個單獨的空間來保存關於用戶/帳戶的信息。
企業實體對象位於用戶對象之下，商業服務對象位於企業實體對象之下，而綁定模板對象位於商業服務對象之下。這樣做的優點是用戶對象層之上的信息庫或『域』層能夠將多個信息庫互相傳遞或邏輯連接。域層可設置成多個級別，例如不同的國家，AU、US、EP等；或按大洲進行組織。
另一個優點是此特性可以使用X500目錄的分布特性來實現。例如為了實現該特徵，可以在虛擬目錄樹的頂端設置「世界(World)」或「企業(Corporation)」節點，而在各個UDDI子樹(UDDI名稱空間)的頂端設置一個名稱唯一的節點。這些「節點」前綴對用戶是不可見的，能允許UDDI信息庫對目錄分布進行平衡。
根據本發明的一個實施例，企業實體對象可以是用戶對象的子對象(child)。企業實體、商業服務和綁定模板層次結構之上的用戶/帳戶使每個用戶擁有自己的子樹。這樣能提高可管理性和安全性。容易限制用戶僅能修改和/或控制他們自己的子樹。使用目錄子樹搜索操作同樣能提高性能。
根據一個實施例，用戶定義的TModel可以作為此用戶對象的子對象，因此更容易實現安全性。因為用戶僅能修改和/或控制其自身的子樹，從而加強了可管理性和安全性。使用目錄子樹搜索操作同樣能提高性能。
本發明的一個實施例表示了使用X.500/LDAP目錄技術的UDDI環境的「映射」。尤其是X.500和LDAP目錄技術的層次結構已證明適用於UDDI環境。仔細設計附加的要素(例如用戶對象)使得層次結構更適合UDDI環境的需求。
本發明全文中，術語「目錄(Directory)」包括X.500、LDAP和類似的技術，術語「用戶(Users)」理解為也包括「帳戶(Account)」，反之亦然；而術語「信息庫(Repository)」認為也包括『目錄前綴(Directory pre-fix)』，『域(Domain)』和/或『節點(Node)』，反之亦然。
網絡服務最初被設計為企業、合伙人、顧客、供應商等組織之間的服務。本文中，UDDI被設計為這些組織提供的服務的一個信息庫。
現在很明顯網絡服務和UDDI在企業內是很有用的，可以用於在組織內集成應用程式。同樣很明顯網絡服務和UDDI能用於集成特定商家的產品集內的產品。其同樣適用於商業領域之外，例如政府部門、大型教育機構，以及許多非企業實體的其他情況中。
下列描述儘管也是關於企業方面，它對於任何類型的環境具有同等的適用性，尤其適用於上述類型的環境。
企業UDDI註冊是一種能在企業內配置的服務，用於發布內部消費的信息和服務。另外，企業UDDI服務可以進行平衡以提供其他功能，如用於分布應用程式的配置發現。
目前期望網絡服務能在企業內部以及合作夥伴之間快速和容易地集成商業過程。有效應用網絡服務的一個要素是公共的UDDI註冊，其能夠讓軟體要素動態發現並通過網際網路連接到適合的服務。網絡服務也能夠在商業公司內集成商業進程。此種情況下，UDDI註冊中心變成組織的基礎結構的一部分(例如一個重要的企業應用程式)，且因此提供了最高級別的安全性、性能、可靠性和易管理性。目錄技術提供了一個理想的基礎架構來滿足企業UDDI註冊最苛刻的要求。
企業UDDI註冊可以定義成能夠為UDDI提供標準兼容支持的註冊，但除此之外還定義了四個用於配置的領域。這些區域包括安全性以限制僅允許授權用戶訪問，分布性以支持大規模配置，可管理性用於實際生產系統，以及可用性以滿足服務級別協定。
有力的安全性是一個對特定企業配置的重要要求。公共UDDI註冊的唯一用途是幫助任何人都能發現可用的服務。UDDI註冊的唯一用途使得合適的人發現這些服務。這是一個重要的區別。
網際網路UDDI註冊被認為不適合用於企業內的網絡服務配置。例如與工資單系統或員工福利管理程序接口的網絡服務的定義，不能傳遞到網際網路UDDI註冊。
安全性需求也意味著即使內部配置的UDDI註冊也能提供有力的訪問控制。這是因為UDDI註冊基本上具備一個指南，指示可以做什麼以及如何做。UDDI註冊能夠對任何可用的網絡服務提供商業級的說明，以及對完整定義了這些服務的可編程接口的WSDL提供指導。這為程序開發者和黑客都提供了一個高效工具。
因此期望能限制訪問用於金融敏感或機密(例如醫療記錄)系統的接口定義。即使在開發組織內部，對於這些授權用戶限制訪問特殊網絡服務的信息也是很明智的。
企業內部使用不安全的UDDI註冊，或通過外部網的選定商業夥伴，是非常冒險的。由於有免費下載工具，具有很低專業水平的人也可以訪問和使用網絡服務。任何實際的企業方案都能實現標準UDDI服務，同時具有透明的控制訪問網絡服務信息的能力。
考慮到分布性，在許多情況下，可以小規模進行UDDI註冊的初期配置。但是隨著網絡服務的需求日益增長，大規模配置將變得更加普遍。另外由於發現UDDI註冊的新功能會加速註冊的使用和配置。
地理分布組織內的較大規模的實現和使用能驅使一個組織內實現多個UDDI註冊。解決分布式註冊的方案使得其對任意單個註冊很苛刻，要能夠動態連接到其他註冊以滿足它們的請求。一旦確定，註冊中心之間的通信可以越過防火牆，延伸到值得信任的商業夥伴的註冊中心，或者甚至是網際網路UDDI註冊。
目前認為有兩種基本的方法來解決註冊中心之間通信的需求。一種方法是複製，其中同一個條目的名稱空間位於多個伺服器上。另一種方法是分布，其中互連的伺服器有不同的條目的名稱空間，但作為一個邏輯服務進行操作。
儘管這兩種方法常被誤認為是相似的，但實際上是完全不同的。
在複製方法中，信息在每個需要查詢的伺服器上被複製。這是一種相對簡單，甚至過於簡單的方案，但它引入了同步更新的需求，且隨著註冊數量和內容的增長，這肯定會增加網絡擁塞。複製技術更適用的環境是伺服器數量較少，信息量少而且較少改變的環境。對於企業配置，複製對於保持容錯備援(fail-over)環境中的備份信息庫是非常有用的。使用複製技術很難保持地理上或功能上分布式伺服器的同步。
在分布方法中，信息在每個參與的伺服器上用邏輯來表示，但信息只存儲在單個註冊中心內。只有在需要時才把查詢傳送給其他的註冊中心。因此返回的信息可以保證是最新的。這提供了一個更新點，從而消除了複製技術中產生的同步和帶寬消耗的問題。真正的分布被認為是解決伺服器之間可擴展連接的一個解決方案。
對於企業UDDI註冊，分布通常在兩個的環境下使用。第一個是用在帶有地理上分離的辦公室的組織，其中每個辦公室分別產生新的UDDI條目和使用UDDI服務。雖然能夠運行一個單一的集中式UDDI註冊中心，但帶寬限制和時區差別使得這種方案很難實現。
分布註冊提供了一種靈活的，可擴展的方案。在這種情況下，每個參與的辦公室有一個單獨的註冊中心，而各個註冊中心把其他註冊中心看作其自身內容的邏輯部分。註冊服務考慮到所有的連接細節，而顧客不需要考慮地理因素。
第二種情況發生在當企業需要將自身內部的UDDI系統連接到可信賴的合作夥伴，或者是公共網絡註冊時。尤其在公共註冊的情況下，複製是難以實現的。網絡運營商可能不願意把其註冊部分複製到企業的內部註冊中心去。分布方法再次可以解決該問題。現在還沒有用於分布方面的UDDI標準，而且複製方案也認為是十分複雜。應當有一種方案能夠具有UDDI分布方法的優點，而且不需要對標準進行修改。
考慮到可管理性，作為企業內部實現關鍵任務功能的要素，UDDI應該滿足性能和可靠性的要求。其不應該僅作為開發者的一個有力工具。客戶端的讀取訪問將是UDDI註冊的最常見以及最關鍵的操作。對性能進行優化以滿足最大吞吐量，而搜索查詢的響應時間不應受較複雜搜索的影響。隨著註冊大小和複雜性的增加不會損害系統性能。作為UDDI註冊基礎的數據存儲應該有工業實用性和完全支持交易以及自動修復。另外，UDDI伺服器應具有較高的可用性和支持特性如網絡容錯備援(fail-over)和熱備份。系統管理者應該具有能力使得UDDI易於維護、監視和控制。這些能力包括能改變控制、規則和設置的動態配置，而不需離線服務，在線備份和調整用於較高的可用性，管理控制以停止註冊中心的「搜索(trawling)」以及防止拒絕服務的攻擊，通過SNMP或其他類型的報警機制進行監控，為安全、統計、查詢以及信息更新而對單獨的日誌文件進行審核及診斷，以及支持複製、分布和路由的配置選項。
已經提出了許多基於開發者的UDDI註冊。這些註冊能夠為小型的開發團隊提供有用的特性，但並不是真正的產品級的系統。網絡服務開發目前飛快增長，從而產生了相應的對企業級註冊的需求，這種註冊能夠快速升級以滿足日益增長的網絡服務配置。
UDDI註冊提供了一種服務。這種服務依賴於許多應用程式。在線商務的情況下，服務始終存在可能是非常重要的。例如UDDI註冊需要提供99.9％可用性的服務水平協定。為了能達到這種可用性，UDDI註冊可以在兩個或多個機器上複製，並且提供機制確保這些機器能保持同步，如果某些機器不可用，任何輸入的查詢能夠自動路由至一臺可用的機器。
前面已經指出，UDDI認為與電話目錄服務十分類似。因此信息存儲的目錄模型是一個用於在其上建立UDDI註冊服務的非常好的基礎。目錄模型已經為基於目錄服務的特定需求進行了演變和開發，具有企業級開發所需的安全性、可擴展性和可靠性。
在應用程式結構中，以上描述的大多數項目是在服務層實現的，而不是在數據存儲層實現的。關係資料庫(RDBMS)是很普通的工具包，許多不同種類的應用程式都可以構建在其上。RDBMS致力於提供可靠的數據訪問功能，而不是終端應用程式需要的額外服務功能。
圖3中顯示的目錄服務結構闡釋了服務層31與其他要素相分離。將接口功能封裝到服務層31產生了可重複使用的服務基礎結構要素。一個非常完美的實例就是網絡伺服器。網絡伺服器提供了一系列功能(HTTP訪問、CGI處理等等)，這些功能共同組成了一種有用的服務，其能夠嵌入一個獨立的組件。同樣，已經將目錄服務模型開發成為一種特定類型的應用程式提供其所需功能。目錄技術為鑑定和授權領域的許多關鍵的應用提供了基礎。
UDDI認為與另一種類型的目錄服務相似。UDDI造成的許多實現問題可以通過目錄技術來解決。例如對於UDDI電話目錄操作中很普遍的非常有效的查找和搜索操作，需要對UDDI進行優化。
已經引起注意的是如果企業中成功配置了UDDI服務，UDDI服務需要提供很強的安全性、分布性和可管理性。這與已經被嵌入企業級目錄服務的方案非常相似。
構造企業UDDI註冊的一種方法是擴展現有的目錄基礎結構，這種方法已經在高性能、實際應用程式中進行了嘗試和測試。
目錄服務結構提供了一種用於實現企業UDDI註冊的最優的工具。二者的結合提供了成功註冊所必需的特性。圖4中示意性闡釋的UDDI服務表示了實現這種基礎構造的要素。UDDI語義橋(SEMANTIC BRIDGE)41是一個服務要素，它將UDDI的SOAP實現42和目錄44支持的LADP接口43聯繫起來。目錄44傳送訪問的信息，同時支持安全控制、分布機制以及管理性能。RDBMS 45提供了下層物理數據管理、企業完整性以及備份和修復機制。
UDDI註冊產品可以直接建立在RDBMS技術上。關係資料庫儘管在許多方面都十分有用和有效，但其自身不能滿足目錄處理的特殊需求。
使用RDBMS或其他下層數據存儲系統能夠從頭建立一個目錄類型的應用程式。但是這並不是最有效的方法。
另一種方法是應用目錄服務模型來提供UDDI註冊，並且為這種特定類型的應用程式提供其所需功能。即使UDDI註冊所需更多功能也可以通過現代工業級目錄服務來提供。UDDI註冊可以被看作成帶有專用通信和API的目錄服務。在目錄上提供UDDI註冊能夠提供必需的安全性、分布管理特性，而不需要修改UDDI標準以獲得這些特性。
仔細設計數據表示形式能夠獲得UDDI信息庫所需的功能和性能。
下面描述參照不同的UDDI概念。這些UDDI概念更詳細的描述可參看UDDI標準規範(http//www.uddi.org/specification.html)。
對目錄來說，模式是表示存儲在目錄中的數據要素，以及這些要素如何互相連接。這包括對各個可能屬性的說明(一個屬性佔有一頁數據)，不同對象的說明(一個對象是多個屬性的集合)，以及適當的對象層次結構的說明。該說明中使用的特定模式注釋是eTrust目錄中使用的，是Computer Associates International公司的產品。「eTrust」是產品名稱和Computer Associates International公司的註冊商標。當然也可以使用其它模式注釋。
本發明描述了一種使用目錄作為資料庫來實現UDDI信息庫的方案。該方案包含了許多概念。同樣也使用了許多技術來提高UDDI執行的效果。下面是其中一些概念的簡要描述。這些概念和技術更詳細的描述將在隨後描述本發明的實施例時進行闡述。
該方案的目的是提供優化操作。該方案包括把屬性、對象類、註冊和層次結構的定義具體化以增強操作效果。該方案至少在安全性、性能、可管理性以及分布方面能夠提供顯著的優點。
現在將描述系統的層次結構。X.500目錄支持內部分布，提供了一種分布式的UDDI信息庫，而不需要UDDI層次的任何編碼。一個層次劃分了信息庫的內容。該方案的(可選的)域層使得該層、每個域條目以及該層之下的所有條目可以設置在獨立的目錄伺服器上，該伺服器對於UDDI層編程是透明的。圖11闡釋了本發明中這一方面的一個實施例。這將在隨後詳細描述。
根據本發明的一個實施例，用戶對象位於商業和TModel對象之上。用戶對象為存儲與用戶相關的信息提供了一個空間。其同樣也為用戶公開的所有數據提供了一個定位點。圖10闡釋了本發明中這一方面的一個實施例。這將在隨後詳細描述。
這種域/用戶層次系統加強了安全性。UDDI實現方法能夠加強用戶對其數據對象子樹的控制。
還提供了對用戶控制條目的搜索。通過使用位於用戶對象下的子樹搜索可以增強對用戶控制的數據的搜索。
通過詳細說明綁定模板中的TModel能夠發現企業。這等同於「通過發現x的一個(或多個)子對象來發現x」。換句話說，查詢就是「找到所有提供某種服務的企業，這些服務有一個綁定模板能夠定位TModel」。這種查詢通過尋找向後代對象的DN(特定名稱)以及去除不需要的層次來實現，從而產生企業實體的DN。按此同樣能夠進行複製品的刪除。由於本發明的結構的層次特性，從而產生了這種尋找特徵。
可以使用對象類所獨有的屬性來實現搜索。這是一個具有兩個優點的優化過程。其簡化了搜索的記錄，並且通過去除「弱」的子句能產生更好的性能。「弱」子句是濾波器的一部分，能夠返回大量的條目，或者其指的一個屬性是許多條目的一部分。當通過名稱搜索企業實體時，為每個名稱使用相同的屬性名一般有兩個選擇把對象類包括在對象類或過濾搜索結果中。如果企業名稱有一個獨有的對象類，僅能實現前者，而即使如此，對象類也是一個弱子句，會產生更多的管理費用。後者意味著額外的編碼，以及返回的結果清單比期望結果大的多的潛在的可能性。
例如考慮一個叫做「Mckenna’s Testing Services」的公司，其提供了較寬的網絡服務的範圍，所有名稱中包括「Mckenna’s」—搜索名稱中具有「Mckenna’s」的企業實體都會對所有服務返回即時結果。這些中間結果可以刪除，但是處理它們會降低性能。
推薦能夠在搜索中詳細說明屬性名稱，且這個屬性名稱能獨一無二的標記出所搜索的對象類。繼續上面的實例，如果這樣說明(euBusinessEntityName＝Mckenna’s*)，搜索就簡單得多。
這種方案產生了很強的搜索，因為其僅在期望的區域內搜索，效率很高。強有力的搜索包括返回少量條目的搜索。目錄能索引euBusinessEntityName屬性，並返回索引結果—這產生了很好的性能，並避免了處理不必要的中間結果。
對於簡單的查詢，這種方案意味著搜索企業實體名稱是單個子句，而不是另一個方案中必需的複合句。設想如果名稱屬性是euName，而企業實體名稱對象是euBusinessEntityName。就會產生如下的搜索((euName＝Mckenna’s*)(oc＝euBusinessEntityName))這是一種更為簡單的設計，其中所有的名稱被存儲在相同的對象類中。這意味著搜索又簡化為(euName＝Mckenna’s*)，但現在對所有的名稱進行搜索得到結果，試圖定位那些父對象是企業實體的結果—這種過去的方案會產生較差的性能，以及更複雜的編程。
陰影(shadow)屬性可以用於敏感性情況。現在還很難用一個索引同時提供敏感的和非敏感的搜索。一種選擇是用非敏感的索引，然後掃描敏感性情況的結果。另一種方案是敏感的索引原始數據，然後添加又一個非敏感索引的屬性(其中儲存了相同的數據)。這樣全部所需的就是依賴於尋找限定詞，選擇合適的屬性進行搜索。
本方案中每個屬性可以是單值的。這能允許有效的索引，更高的性能以及更強的搜索性能。
使用多值屬性使得模糊搜索成為可能。也即能夠獲得非直觀以及非計劃的搜索結果。設想一個多值的數值屬性，稱為『n』，以及一個條目包含這個具有數值2和5的屬性；對搜索((n＜3)(n＞4))作出響應而返回該條目，這並不是很容易預測到的。
單值屬性是一種用於強搜索的技術。強搜索即能夠通過索引消除大多數待選結果。強搜索是提高性能的關鍵。
別名(aliases)也可以用於服務投影。使用X.500目錄作為資料庫具有顯著的優點。服務投影可以完全用X.500別名表示。其主要的優點就是保證數據完整性。別名訪問原始數據，因此對原始數據作任何改變都會立即由別名反映出來。如果目錄實現方法能支持別名完整性，那麼當原始條目被刪除時，別名就會消失而不需要額外的工作。
發行者聲明是UDDI標準中定義明確的要素之一，並且其需要認真的設計。不適當的實現方法可能導致很差的性能。
因為發行者聲明的最普遍的用途是尋找相應的企業API，其搜索與一個特定的企業實體相關的所有完備的發行者聲明，在企業實體之下設置每個聲明是很好的方案。
通過計算聲明的狀態，並把其存儲在聲明對象中，這樣能夠限制對完備的發行者聲明的搜索。這意味著返回的結果不會包含要刪除的偽參考。
把相關性對象存為輔助類允許搜索能消除任何有不需要的相關性的聲明。如果相關性被存成一個子對象，就不能生成一個單一的能解決相關性和聲明完備狀態的搜索條件。
UDDI鍵存在時可以為對象命名。UDDI為許多重要的對象類定義了鍵，這些鍵必須保證是唯一的。這意味著這些鍵可以用作這些對象的命名屬性。UDDI鍵作為命名屬性意味著不需要解決命名衝突的問題—如果預設名稱被用於一個企業實體的命名屬性時，就需要嘗試解決命名衝突的問題。
UDDI鍵不存在時也可以提供鍵來命名。並非所有的UDDI對象都有已定義的鍵。一個實例就是發行者聲明。為此，本系統使用與UDDI定義鍵相同的算法提供了一種鍵。這種重用思想意味著為其他對象寫的編碼和結構也可以再利用。
如果一系列UDDI對象是另一個對象的子對象，則這些子對象的順序是很重要的(例如地址行)，分配給予對象的鍵按照數值單調增加，這樣把鍵排序就能產生所期望的順序。這樣簡化了確保期望順序的程序。
在實際過程中，希望鍵能按照little-endian的方式變化。即鍵的最左面的字節變化最快，因為這在X.500目錄用作資料庫時進行索引會產生最好的性能。
UDDI標準在一些主要對象類型內部定義了大量的子結構。在許多情況下這些子結構是可選而且可重複的(在同一對象內可能出現零次、一次或不止一次)。一個簡單的例子是名稱子結構，包含一個字符串(名稱)和一個語言標識符。X.500方案定義不支持使用結構化屬性，因此不能直接對子結構立即清楚地映射。現在有幾種方法可以在X.500模式中實現子結構。
一種方法是利用某些類型的分隔符來區分不同的要素，從而把子結構的所有要素連結成一個單個屬性。這也許不是最優的設計選擇，因為其失去了獨立檢索或搜索這些要素的能力，並且其增加了處理數據時的複雜度。
本系統中，需要選擇特定方案來表示子結構，從而使得性能和可管理性最優。本發明公開的方案使用一種或多種不同的技術在目錄內表示子結構。這些技術可以歸結為3類一類技術是許多子結構被當作子對象進行處理。名稱是一個較好的實例企業實體名稱被存儲為企業實體的子對象。另一個實例是描述，其中一個單獨的企業描述對象是企業實體對象的子對象。圖15對本發明這一方面的實施例進行了闡釋，並在下面詳細描述。
另一類技術是展平/合併。當至少和另一個對象有關係時，該屬性可以合併成一個對象。在這種情況下，由於兩個對象結合成一個對象，層次結構被認為展開了。由於新的對象包括了合併對象的屬性併集，所以稱新的對象是合併的。最好把關係對象的內容提升為父對象。
例如圖16示意性地顯示了一種UDDI關係圖的表示形式。圖17示意性地顯示了一種目錄層次結構框圖，其中該目錄層次結構是由UDDI對象展開形成的。
通過說明，圖16闡釋了將對象162和對象163聯繫起來的對象161。
根據本發明的實施例，如果有一對一的關係，則『子對象』的層次能夠提升。換句話說，層次結構的一部分可以被摺疊或展平，對象可以合併。圖17中示意性地顯示了這一結果。父對象171包括內容A1、A2、An和一個或多個子對象，子對象9n包括內容B1、B2、Bn，C1、C2和Cn。
另一類技術是分裂(splitting)。例如在一種特殊的情況下(OverviewDoc子結構)，一個子結構包含一個不重複的要素以及一個重複要素。該不重複要素(OverviewURL)可以移入父對象，而重複要素可以設置成子對象。
本發明的另一個方面是管理。刪除一個TModel只將其在find_TModel中隱藏，但並沒有將其從信息庫中去除。因此為了正確處理TModel，可使用一個隱藏標誌。該標誌的存在表示TModel(或者用戶對象)被隱藏。沒有該標識則表示沒有被隱藏。這是對於大多數TModel的方法，因此該方法效率很高。沒有佔用未隱藏的對象的空間，也沒有使用檢索。該目錄僅檢索那些有隱藏屬性的條目。這也意味著搜索未隱藏的TModel將更快速有效。
X.500目錄用作資料庫時不能存儲空值。例如對象中不存在的(可選的)數值沒有存儲在目錄中。這樣能夠有效的使用存儲空間，並支持更強的搜索。任何依賴於屬性的搜索僅需考慮該屬性有數據的那些對象。
本系統的數據層次結構和UDDI標準的方向是非常一致的。當一個刪除UDDI對象的請求到達時，其直接映射為在目錄中刪除一個子樹。例如刪除一個服務包括刪除其名稱和描述，以及其所有綁定模板。所有這些都是目錄中服務條目的子對象。因此本系統刪除了此服務條目下方的子樹。其容易實現，且效率高。
域是一個表示層次化子樹的根部的名稱。X.500術語中，域被認為是上下文前綴。LDAP術語中其被認為是後綴。給定UDDI信息庫，一個域名允許在信息庫中使用(X.500意義上)的真正分布式的數據。UDDI標準僅支持複製。通過域節點，本系統能使用對於應用程式透明的目錄分布特性。
例如假設一個企業內部配置UDDI，但有兩個開發站點。利用分布特性，它們能夠在每個地點開發一臺分布式UDDI伺服器，允許每個站點直接觀察兩個註冊中心上發布的條目。
這樣做的一個優點是能夠「免費」分布。例如UDDI伺服器不需要做額外的工作，而目錄系統能有效地連接孤立信息。
UDDI標準中沒有規定如何存儲用戶信息。通過創建用戶對象，所有與用戶有關的信息都存儲在一個對象中，而該對象可作為保存了所有用戶公開的對象的子樹的根。這就使得安全性定義更加簡單。例如如果用戶考慮的對象(如企業、服務，甚至TModel)位於該用戶的用戶對象之下，那麼該用戶就控制這個對象。
UDDI定義了包含重複要素的對象。出於性能、搜索能力及可管理性方面的考慮，這些重複要素可以表示成子對象。
把重複結構化的數據存為子對象能夠在目錄中有效地表示數據，其中各個欄位可獨立用於搜索(以及檢索)。
例如企業實體名稱可存為企業實體對象的子對象。另一個例子是企業描述可存為企業實體對象之下的子對象。
該類型系統的優點是其能夠搜索名稱(這是一個普通的UDDI搜索)，而該條目的DN給出了此名稱所屬對象的DN。
UDDI定義了冗餘「信息庫」節點(僅包含子對象的子結構而不是屬性的UDDI結構)。這些節點可以刪除，因為它們可以根據查詢結果以相對很低的工作量來構造。在一些情況下，屬性可以從子節點提升為父節點，以便從目錄表示形式中刪除目前冗餘的子節點。
例如，TModelInstanceDetails由於不包含屬性而沒有在目錄圖表中表示。instanceDetails沒有在目錄模式中表示，因為其屬性被提到TModelInstanceInfo父節點中，作為它的子節點，overviewDoc的屬性。類別和標識口袋沒有在目錄中表示，它們的內容被作為口袋的所有者的子節點。
這樣做的優點是減少了目錄中條目的數量。尤其能將DIT的深度減到最小，這樣能夠改善性能。
圖12示意性地顯示了本發明的一個實施例中的層次結構。其中有一個或多個域或前綴121。在各個域121下面，可能有一個或多個用戶122。在各個用戶122下面，可能有一個或多個TModel 123和一個或多個企業實體(BE)124。在各個企業實體124下面，可能有一個或多個發行者聲明(PA)125，一個或多個商業服務(BS)126以及一個或多個服務投影(SP)127。在各個企業服務(BS)126下面，可能有一個或多個綁定模板(BT)128。按照特定實現方法的要求來設置別名。例如服務投影對象(圖12中所示的三角形)可能源於企業實體對象的別名。
圖12中表示的模式方案的優點根據本發明的整體說明變得更清楚。
發行者聲明位於其所引用的企業實體下面，因為它們最常用於find_RelatedBusiness請求內容中，其中規定了一個企業鍵，並通過發行者聲明搜尋所有和該鍵相關的企業。本系統定位了特定的企業，然後讀取位於其下的所有(已建立的)發行者聲明。這是定位相關聲明的快速和有效的方法。
這種方法的優點是能夠快速和高效地搜索。其同樣能很容易地維護數據完整性。例如當刪除一個企業時，也自動刪除了所有發行者聲明。
TModel可以被發布它們的用戶來改變(或撤除/隱藏)。把TModel設置在表示用戶的條目下使得安全性很容易實現。例如，如果TModel位於用戶條目之下的子樹上，那麼就可對其進行修改。反之就不能修改。更詳細地說，如果用戶的DN(特定名稱)試圖使變化與TModel的DN前綴相匹配，該用戶就能修改該條目，否則不能。可以使用目錄UDDI伺服器做出判斷(如果此DN不存在，則是命名異常)。
當從信息庫中刪除一個對象時，與該對象相關的信息也被刪除。根據本方案實施例中使用的層次結構大大簡化了這一過程。當刪除對象時，對象下方的整個條目子樹也被刪除，從而可以刪除所有(通常僅有)相關信息。刪除一個子樹可以從底向上實現。只有當所有子對象刪除時才能刪除各個條目。把所有子對象以相反的DN順序排列來實現。這樣能保證在刪除子節點的父節點之前刪除這些子節點。
這樣做的優點是用排序列表的方法代替了更複雜的遞歸方法。另外其相對簡單和存儲效率高。子樹上的所有條目按照DN排序，而刪除是用相反的順序來實現，這保證了在父節點之前刪除所有子節點。
例如在刪除一個商業服務時，系統就刪除與其相關的所有綁定模板、TModel實例信息，以及各種相關的類別信息。刪除商業服務的子樹就能刪除所有這些信息。
由於本模式中使用的層次結構，對象的DN表示了關係鏈以及對該對象的控制。注意到聲明也依賴於名稱屬性的精心選擇。
這種做法的優點是能夠減少搜索數或用於收集信息而讀取的次數。例如由於搜索結果是子對象(例如名稱)，各個條目的DN顯示了父對象(如企業實體)和所有者帳戶。
例如，商業服務的DN顯示了該企業屬於誰，以及控制該企業的用戶。
目錄不能保證任何結果的順序。當處理一個複雜的結果時(例如企業實體和其商業服務，以及其合適的名稱和描述)，獲取搜索結果並按DN對其排序，可以簡化輸出結果的格式。對輸出結果進行組織，從此使結果形式變得相當簡單。每個對象都在其子對象之前構造，因此容易把子對象設置在父對象下面，這樣就能在服務之前組織商業結果。一個對象的所有子對象出現在同一類型的下個對象之前，一個企業的所有服務出現在下個企業之前。這也能簡單遞歸構造，因為各層應用了相同的結構。
這樣做的優點是使得構造UDDI結構必需的原始條目列表的遍歷次數減到最小。
例如在排序之後，企業的搜索結果A之後是其第一個服務的結果AA，和此服務的名稱，然後是A的第二個服務AB及其名稱，然後是第二個企業B。
也可以對子對象執行搜索。例如，較常用的搜索請求是「通過找到x的一個(或多個)子對象來尋找x」。一種方法是例如通過描述綁定模板中的TModel來搜索到一個企業。換句話說，查詢就是「找到所有滿足以下條件的企業這些企業的服務包含一個引用TModel的綁定模板」。通過尋找後代對象的DN能實現這種查詢，並且撤銷不需要的層來產生企業實體的DN。這也能有利地消除重複。這種搜索方法產生的部分原因是由於本發明的實施例中的層次結構。
使用授權的唯一鍵值能簡化過程。用單個鍵能搜索整個信息庫，且其唯一性保證此處要麼沒有產生結果(如果沒有鍵值)，要麼得到一個結果(如果有鍵值的話)。目前不需要考慮在父對象範圍內的有限搜索。這就可以利用目錄提高性能，因為能充分使用資料庫索引。
這樣做的優點是能夠利用速度最快的目錄查詢。另一個優點是如果給定的對象從另一個對象引用得到，則授權的唯一名稱就很重要。
大多數索引系統的特性是數據間的相關性。如果數據是「littleendian」(最左邊的部分變化最快)，那麼數據趨於展開，因此索引能提供最優的性能。相反，如果數據是重複的，索引可能就不是十分有效。使用UUID(通用唯一標識符)算法能產生「little endian」特性。這樣做的優點是能夠將目錄性能增強到最大。
可以給派生對象添加鍵。當可重複的數據要素加入到子對象時，需要添加一個命名屬性，其構成了它的DN的最後一部分。在一個目錄中，命名屬性不同於其同胞對象，因為同一個父對象不存在兩個名稱相同的子對象。
可以使用兩種類型的鍵。對於不要求順序的子對象，使用UUID算法，因為其保證獨一無二。在順序很重要的地方，使用具有單調增加特性的鍵來保證順序。
UDDI標準中，企業實體能提供兩類服務控制服務(信息庫中用子對象描述)，以及為這些對象提供一個接口，但實際上由另一個企業實體提供的服務。後者在公開的UDDI信息庫用別名來描述。別名能準確地提供正確的特徵。例如，如果原始對象(服務)由其所有者做某種變化(也許添加了另一個綁定模板)，那麼通過別名參考的對象也「變化」。並且對於一個服務，企業實體之下的任何搜索都會產生實名和別名服務。
例如，別名可被用作服務投影，其中企業可以指向另一個企業之下定義的一個服務。
這樣做的優點是平衡別名能夠自動提供基本包括「可替換名稱」的功能。另外，如果目錄能支持別名完整性，那麼如果刪除了原始服務，任何投影也自動刪除。
UDDI標準中有許多地方不希望被其他對象直接引用，而希望通過一個中間步驟—實現—例如TModel實例信息的情況下，或者發行者聲明中引用企業實體時。在這些情況下，別名會把編碼複雜化。因此本系統用對象的引用來代替別名。因為根據一個實施例，本系統能保證每個對象有一個唯一的鍵，那麼鍵確切地表現為引用，有時被認為是一個「外來」鍵。
使用輔助對象類能實現屬性分組。在處理髮行者聲明時，需要使用三個能唯一識別發行者聲明的屬性，來定位發行者聲明兩個企業實體鍵，以及它們之間的相關性。但是該相關性被規定為關鍵字索引，其自身有三個不同的屬性TModel鍵，鍵名稱以及鍵值。一種方法是把這種相關性存為發行者聲明的子對象。但是這不能對特定的發行者聲明作最有效的搜索。通過把這種相關性關鍵字索引作為發行者聲明條目的輔助類，能夠一次搜索中搜索全部五個屬性，並且因此準確地提取出所需的發行者聲明對象。
本發明的一種方案使用了常規的面向對象的設計技術，例如產生具有同一屬性名稱的全部關鍵字索引。但是這種方案很難並且很昂貴，為了分離例如一個企業實體類別關鍵字索引，且避免將其與TModel類別關鍵字索引相混淆。同樣其必需在濾波器中包括對象類別術語，且這些術語是弱的(信息庫中有較高的重複率)。
例如為各種不同類型的關鍵字索引分配一種不同的對象類和不同的屬性名稱，意味著對於特定屬性名稱的任何搜索必須包含該對象類。同樣意味著目錄伺服器能構造一個檢索，其中僅包含對於所需的特定類型的條目。這種檢索會較小，因此也更快。
例如，類似「euBusinessEntityName＝Smith」的搜索會查閱euBusinessEntityName的索引，因此不會被任何稱為euTModelName的屬性中包含Smith的條目所混淆。
同樣可能需要UDDI標準範圍之外的工具。這種工具需要提供UDDI標準規定之外的訪問方法。為了使用這些工具，本發明定義了抽象類，這些類綁定了表示單個UDDI概念的所有對象類。這樣定義了能考慮所有名稱或所有關鍵字索引的搜索。
例如，有一個抽象類euName是所有名稱-類型對象類的超類，包括euBusinessEntityName和euTModelName。
UDDI標準規定了能夠用敏感性的和非敏感性的方法來搜索名稱。可以用非敏感性的索引來處理，然後獲取條目並敏感性地對其進行檢驗，但這種方法會降低性能。在這種情況下最好定義一個包含相同數據的陰影域，但是以不同方式被檢索。同樣，陰影屬性也可用於語言上的不同，如變音符標記。
例如，euBusinessEntityName對象類包含各個名稱的兩份拷貝。第一個版本的索引是非敏感性，同時第二個版本的索引是敏感性。不管請求什麼行為，都能最優地構造搜索濾波器。
信息庫中的各個屬性(除了對象類)都是單值的。這樣能夠使目錄構造更有效地索引，並在搜索過程中提供更好的性能。
這樣也消除了在搜索過程中出現偽匹配(false positive)結果的可能性。例如考慮搜索一個以「Fr」開始，以「nk」結束的名稱。期望能產生一個名稱類似「Frank」的(有效)條目。但是如果名稱是多值屬性，可能獲得名稱類似「Fred」和「Tink」的無效的條目，因為這個條目與兩個準則匹配。通過使用單值的名稱，各個名稱都是條目的子對象，就可以消除「Fred」和「Tink」的偽匹配。
操作屬性是由UDDI應用程式管理的特殊屬性，但這些屬性對用戶是不可見的。
UDDI數據存儲中，應當能夠有一種方式來把正在使用的TModel從已經「撤除」的TModel中區分出來。當刪除一個TModel時，它可能仍然被許多條目所使用，所以並沒有被真正刪除。相反它被隱藏起來，這意味著它沒有作為find_TModel請求的一部分結果而返回，但是仍通過get_TModelDetail請求進行查詢。這是使用一個叫做euHidden的屬性來實現的，其被添加到隱藏的TModel中。對於任何搜索TModel的濾波器添加一個搜索步驟是有益且高效的，它能消除任何包含euHidden屬性的條目。
目錄實現過程中，一般認為一個屬性有一個主值是沒有效率的。例如有一個隱藏屬性把99％的條目設置成FALSE會產生很差的性能—索引幾乎不可用。
認為更加有效的是大多數條目被存儲為沒有隱藏屬性，僅把該屬性添加到那些要隱藏的條目中。這種額外的效果是不必佔用存儲空間來保持所有「FALSE」值。目前用於找出所有沒有隱藏的TModel的濾波器是「(！euTModel＝*))」，這是對存在測試的求反，且存在測試是很快的，尤其當屬性僅在一小部分條目中存在時。
現在描述本發明的實施例以說明用於解決目錄內容的實現和UDDI標準要點。X.500模式中有大量要素。這些要素包括屬性定義、對象類定義和名稱綁定定義。屬性定義規定了一個數據要素，給定一個唯一的標識符(OID)，一個名稱以及一個數據類型。對象類定義規定了整體使用的一系列屬性。其給出了一個唯一的標識符(OID)、名稱、以及一個數據類型。對象類定義規定了一個作為整體操作的一些屬性的集合，並為其賦予一個唯一的標識符(OID)，名稱以及一個屬性列表；屬性可能是要求的/或可選的。名稱綁定規定了可能的層次結構的一部分。名稱綁定規定了能存儲在另一個對象類之下的對象類，並規定了在本文中用於為子對象命名的子對象的一個或多個屬性。
還有很多需要附加設計的查找限定詞。如一個敏感性的查找限定詞能夠有效地同時用敏感性的和非敏感性的方法搜索文本數據。根據本發明的一個實施例，通過在對象中提供不同索引的附加欄位解決了敏感性問題。
根據該實施例，文本數據以caseExactString類型的屬性和caseIgnoreString類型的屬性存儲兩次。然後查找限定詞能確定搜索哪一欄位，從而產生了最好的性能。
例如，如果企業實體的名稱類似「Mckenna’s Iron FoundryServices」，那麼該字符串將會存儲兩次，一次存在敏感性索引的欄位裡，一次存儲在非敏感性索引的欄位裡—存儲的數據是相同的，但是下層目錄產生的索引是不同的。
另一個要點是關於如何有效地實現服務投影。根據本發明的一個實施例，可以用X.500別名特性來解決。現在有許多方法可以處理服務投影問題。本發明的實施例是通過目錄別名來處理。這是一種特殊有效的處理服務投影的方法。這樣能夠保證投影和基礎服務的連續性，因為是直接通過別名訪問基礎服務。其也保證了一旦刪除了基礎服務，投影就會消失，因此確保了連續性。
例如，如果名為Williams Accounting Service的企業實體發布了一種名為總帳核對(Gereral Ledger Cross-Check)的網絡服務，現在希望能在名為Williams Auditing Service的另一個企業實體下提供同樣的服務，這可以通過在第二個企業實體之下設置一個別名條目來實現。希望列出Williams Auditing Service提供的所有服務的查詢者會發現總帳核對服務，因為其能夠發現Williams Auditing Service直接提供的任何服務。
另一個要點是關於如何有效地實現鍵。根據本發明的一個實施例，這可以使用用於外部鍵、以及對順序無要求的鍵的UUID來解決。順序重要的地方可以使用連續的數字。儘管鍵用字符串表示，但它們並不是真正的文本數據。這些鍵相對來說沒有敏感性或變音符標記。
外部可見的鍵遵循一個規則集。當實現一個和UDDI標準版本2兼容的信息庫時，依照ISO-11578，其能夠保持UUID。當實現一個和UDDI標準的版本3兼容的庫時，其能保持遵循該版本說明書中設置的規則的鍵字符串。
需要注意的是內部使用的用於連接各要素的鍵遵循另一個規則集。順序不重要的鍵使用UUID算法。順序重要的鍵使用連續數字。
例如，表示名為Williams Auditing Service的企業實體的類別口袋中一個元素的關鍵字索引，可能引用的TModel的鍵值為12345678-1234-1234-1234-1234567890ab(UDDI v2)。類別口袋中關鍵字索引的順序並不重要，但關鍵字索引需要一個鍵作為對象的命名屬性。因此可以為該對象生成一個UUID鍵，如87654321-4321-4321-4321-ba0123456789，並用該鍵作為該對象在目錄中的命名屬性。
另一個要點是如果需要X.500分布，可以把數據組織成域的形式。根據本發明的實施例，可以通過在用戶上方創建一個信息庫層來實現，使得在不同的伺服器上設置各個信息庫。
UDDI標準不允許名稱空間是分布式的。這意味著多個UDDI註冊中心可以通過複製或直接用後端數據存儲來管理分布式的名稱空間來互相協作。
每個有命名前綴的信息庫便於實現分布的名稱空間。前綴是定義一個域的一組節點。這些節點可以看作為各個UDDI註冊中心上的信息庫層。這些節點設置在用戶層之上。
圖11闡釋了一個實例，其中有一個名為「Domain」的節點110。域110是目錄前綴，可以包含一個或多個連接到根部的節點。在域110之下，是多個用戶112、113、114的排列。設置在域110之下的用戶數可能會根據本系統的特定設置和/或用途而變化。也可根據本系統的特定設置和/或用途設置多個域。下面的實例中，它們被稱為信息庫對象，並假設它們表示物理上獨立的信息庫。當然也可能不是這種情況，這取決於本系統的特定設置和/或用途。
信息庫對象僅需要一個命名屬性。
set object-class uddiObjectClass400＝{#信息庫-可用來把用戶分成組name＝euRepositorysubclass-of topmust-containeuRepositoryName}分布是大規模目錄配置中一個重要概念，其能夠使多個節點同時共享數據，而不會佔用大量帶寬和複製引起的同步問題。
在一個實施例中，『eTrust』UDDI用下層eTrust目錄伺服器的性能來支持分布功能，為此本方案相應地這樣構造允許在樹結構的頂端有一個或多個虛擬『域』節點，並且在每個節點子樹的頂端有唯一的標識符或名稱(見下面的UDDI方案)。
而且，可以將eTrust UDDI伺服器配置為『分布式感知的』。可以規定兩個獨立的目錄前綴—一個前綴用於搜索和讀取，而另一個用於添加條目。為了開發一個分布式伺服器，下層eTrust伺服器代理按照eTrust目錄管理指南配置成分布式的。每個獨立的eTrust UDDI節點都有一個唯一的節點名稱。各個節點的搜索/讀取前綴被設置成「世界」或「企業」節點名稱。各個節點的添加前綴則設置成該節點的唯一節點名稱。
這樣，儘管每個節點把條目添加到其所有的目錄信息庫，但在所有節點中搜索條目卻是藉助於X500目錄的分布特徵實現的。
一個信息庫對象的實例可能是euRepositoryName＝Melbourne另一個要點是關於如何組織用戶使用的數據。這可以通過創建一個保存數據的用戶對象來解決。
儘管UDDI說明中沒有規定用戶對象，但根據本發明的實施例可以使用這種對象。例如用戶對象是一個用戶憑證的存儲點，以及用於發布的定位點。
圖10闡釋了這種設置的一個實例，名為『用戶』101。用戶101之下排列著其他對象，例如企業實體對象102、商業服務對象103和綁定模板對象104。用戶101之下的企業實體對象的數量可以根據本系統的特殊設置和/或用途而發生變化。也可以根據本系統的特殊設置和/或用途設置多個用戶。
用戶對象中包含的數據元素包括用戶鍵(用於為該用戶帳戶提供一個唯一的名稱)、用戶名稱和憑證(可能和密碼一樣簡單，或像PKI證明一樣複雜)。也可包含一個授權名稱(識別操作用戶帳號的授權的人或任務)。其可能也包含一個隱藏標誌，當刪除用戶帳戶時不會丟失用戶定義的任何TModel。
set object-class uddiObjectClass401＝{#用戶帳戶name＝euUserAccountsubclass-of topmust-containeuUserKey，euUserName，euCredentialsmay-contain
euAuthorizedName，euHidden}；一個用戶帳戶對象的實例如下euUserKey＝23456789-2345-2345-2345-234567890abceuUserName＝GraceeuCredentials＝Amazing76sQ(本實例中假定採用了一個簡單的用戶ID和密碼系統)另一個要點是關於如何用一種有效的方法表示與企業實體(UDDI標準中描述的對象類)有關的數據。根據本發明的實施例，通過把唯一欄位表示成對象的屬性，以及把重複要素表示成子對象，從而解決該問題。
企業實體對象是UDDI標準中一個基礎要素。標準定義了它的內容，但大多數要素是X.500模式不支持的重複性的複雜對象。這類要素可以用層次化結構來表示。
企業實體中僅有的必要要素是企業鍵。可選的要素包括一個授權名稱、一個運營商，以及一個用戶鍵(最後一項會存在普通用戶公開的企業實體中)。
set object-class uddiObjectClass402＝{#企業實體-提供服務的企業的詳細信息name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，euAuthorizedName，}；
企業實體的子對象可能是名稱(包含名稱字符串和語言編碼的鍵控排序對象)；描述(包含描述字符串和語言編碼的鍵控排序對象)；聯繫方式(一個複雜對象—稍後在下面描述)；發現URL(包含URL字符串和用途類型的鍵控對象)；通過選擇對象類而標記為類別或標識符信息的關鍵字索引；以及商業服務(下面將描述)。
企業實體對象的一個實例如下euBusinessEntityKey＝34567890-3456-3456-3456-34567890abcdeuParentUserKey＝2345678-2345-2345-2345-234567890abc需要注意的是企業實體對象的大部分直觀內容實際上存儲在企業實體對象的直系子對象中。
圖15根據本發明的一個實施例闡釋了把層次結構引入到一個子結構中，用於表示企業實體中相對複雜的對象的例子。圖15中的多值要素如下對於子對象152有語言en名稱CA對於子對象153有語言IN名稱CATS被表示成企業實體151的子對象152、153。也可能沒有子對象或者有多個子對象。
另一個要解決的要點是如何用一種有效的方法來表示與商業服務(UDDI標準中描述的對象類)有關的數據。
根據本發明的一個實施例，可以用唯一欄位表示對象屬性，以及用重複性要素表示子對象來解決該問題。
至少有兩種方法來實現商業服務。第一種是商業服務表示了企業實體提供的單個概念化服務，通過一個或多個訪問路由可獲取此服務；各個訪問路由用一個綁定模板來表示。第二種方法是商業服務是一個用於服務的分組機制，把綁定模板層中發生的單個服務進行分類。UDDI說明書中定義了任一種情況下的數據欄位。
商業服務中的要素是企業和服務鍵。企業鍵規定了擁有服務的企業實體。這並不一定是被發現的企業實體。通過服務投影，可以在幾個企業實體之下發現單個服務。服務鍵是整個UDDI信息庫的服務中的唯一標識符。這兩個鍵都用字符串表示。
set object-class uddiObjectClass403＝{#企業name＝euBusinessServicesubclass-of topmust-containeuBusinessServiceKeyeuParentBusinessKey}；此處沒有商業服務對象的可選內容。所有其它內容包括潛在的重複元素，因此用子對象來表示。商業服務的可能的子對象有綁定模板(如下)；名稱(包含名稱字符串和語言編碼的鍵控排序對象)；描述(包含說明字符串和語言編碼的鍵控排序對象)；以及標記為類別信息的關鍵字索引。
例如，一個商業服務對象如下euBusinessServiceKey＝4567890a-4567-4567-4567-4567890abcdeeuParentBusinessKey＝34567890-3456-3456-3456-34567890abcd需要注意的是企業實體對象的大部分直觀內容實際上存儲在企業實體對象的直系子對象中。
圖15描述了根據本發明的一個實施例把層次結構引入到一個子結構中，用於表示企業實體中相對複雜的對象的例子，但其同樣可以描述根據本發明的一個實施例把層次結構引入到一個子結構，用於表示商業服務中相對複雜對象的例子。圖15的企業實體151同樣適用於商業服務，同時商業服務的多值元素表示成商業服務151的子對象152、153。也可能沒有子對象或者有多個子對象。
還有一個要點是關於如何用一種有效的方法表示與綁定模板(UDDI標準中描述的一個對象類)有關的數據。根據本發明的一個實施例，可以用唯一欄位表示對象屬性，以及用重複性要素表示子對象來解決該問題。
綁定模板表示一種可以訪問特殊服務的方法。綁定模板僅需的必要要素是它的鍵和它所應用服務的鍵。可選的元素包括一個訪問點或者主機重定向器(此對象應該至少包含其中之一)。如果包含一個訪問點，那麼也應當包含訪問點類型。
set object-class uddiObjectClass404＝{#綁定模板name＝euBindingemplatesubclass-of topmust-containeuBindingTemplateKeymay-containeuParentServiceKeyeuHostingRedirectoreuAccessPointeuAccessPointType}；綁定模板的子對象可能是TModel實例信息(如下)；以及描述(包含說明字符串和語言編碼的鍵控排序對象)綁定模板的一個實例如下euBindingTemplateKey＝567890ab-5678-5678-5678-567890abcdefeuParentServiceKey＝4567890a-4567-4567-4567-4567890abcdeeuAccessPoint＝http//www.rsps.com.au/wsepeuAccessPointType＝http而且，儘管圖15描述了根據本發明的一個實施例把層次結構引入到一個子結構，用於表示企業實體中相對複雜的對象的例子，它也可以描述根據本發明的一個實施例把層次結構引入到一個子結構，用於表示綁定模板中相對複雜的對象的例子。圖15的企業實體151同樣適用於綁定模板，同時綁定模板的多值元素表示為綁定模板151的子對象152、153。也可能沒有子對象或者有多個子對象。
另一個要點是關於如何用一種有效的方法來表示與TModel(UDDI標準中描述的對象類)有關的數據。根據本發明的實施例，可以用唯一欄位表示對象屬性，以及用重複性要素表示子對象來解決該問題。
TModel表示一種思想。該思想可能是例如一種需要規定有效值的分類系統。或者也可能是數據通信協議規範。TModel是一種靈活且強大的概念，把UDDI以一種可精確查詢的方式描述複雜數據的核心。
TModel對象僅需的要素是TModel鍵和名稱。它們用字符串表示。
TModel對象的可選要素包括授權名稱、概述URL(overview Doc對象的一部分)、用戶鍵以及一個隱藏標誌。
隱藏標誌是處理TModel的一個要素。隱藏標誌描述了如何處理delete TModel這一請求。當TModel被「刪除」時，就把隱藏標誌添加到對象中。這意味著該對象不會被findTModel請求返回，但可由TModel請求訪問。
set object-class uddiObjectClass405＝{#TModel-涉及一種思想name＝euTModelsubclass-of topmust-containeuTModelKey，euTModelNamemay-contain
euAuthorizedName，euOperator，euOverviewURL，euParentUserKey，euHidden}；可能的子對象是描述(包含描述字符串和語言編碼的鍵控排序對象)；標記為類別或標識符信息的關鍵字索引；以及overview Doc說明(包含描述字符串和語言編碼的鍵控排序對象)。
TModel的一個實例如下euTModelKey＝uuid67890abc-6789-6789-6789-67890abcdef1euTModelName＝Corporate QA PolicyeuOverviewURL＝http//www.rsps.com.au/policy/qa.htmleuParentUserKey＝23456789-2345-2345-2345-234567890abc而且，儘管圖15描述了根據本發明的一個實施例把層次結構引入到一個子結構，用於表示企業實體中相對複雜的對象的例子，它也可以描述根據本發明的一個實施例把層次結構引入到一個子結構，用於表示TModel中相對複雜的對象的例子。圖15的企業實體151也適用於TModel，同時TModel的多值元素表示為TModel 151的子對象152、153。也可能沒有子對象或者有多個子對象。
另一個要點是關於如何用一種有效的方法表示與發行者聲明(UDDI標準中描述的對象類)有關的數據。根據本發明的實施例，可以用唯一欄位表示對象屬性，以及用重複性要素表示子對象來解決該問題。
發行者聲明是表示兩個企業實體之間的關係的對象。
發行者聲明所需的元素是它的鍵、源/目的企業和用戶鍵、狀態和關係。關係被規定為一個關鍵字索引，並存儲為發行者聲明條目的一個輔助類。狀態存儲為字符串，但從建立狀態對象中獲取它的可能值。所有鍵都用字符串表示。
set object-class uddiObjectClass405＝{#發行者聲明-兩個企業之間的關係name＝euPublisherAssertionsubclass-of topmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinessKey，euToUserKey，euPublisherAssertionStatus，}；發行者聲明沒有可選的內容，也沒有子對象。
發行者聲明的一個實例如下euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12euFromBusinessKey＝34567890-3456-3456-3456-34567890abcdeuFromUserKey＝23456789-2345-2345-2345-234567890abceuToBusinessKey＝09876543-6543-6543-6543-dcba09876543euToUserKey＝98765432-5432-5432-5432-cba098765432euPublisherAssertionStatus＝statuscomplete需要注意的是有一個與條目相關的輔助類euPublisherAssertionRelationshipKeyedReference，其屬於對象類，並規定了兩個已知的企業實體之間聲明的關係。一個實例如下euPublisherAssertionTModel＝uuid807A2C6A-EE22-470D-ADC7-E0424A337C03euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child另一個要點是關於如何用一種有效的方法來表示與關鍵字索引(UDDI標準中描述的一種對象類)有關的數據。這樣就更複雜，需要能夠有效地搜索特定關鍵字索引的集合例如企業實體上的類別口袋。
根據本發明的實施例，可以創建一個抽象基類來表示關鍵字索引，並將其作為各個所需集的子類來解決這個問題。這些集合在目錄中沒有描述。例如它們僅表示同一子類的一組關鍵字索引，或作為同一對象的子對象。例如企業實體的類別口袋是euBusinessEntityCategoryKeyedReference類的對象集，其中該類是特定的企業實體的子對象。需要注意的是企業實體對象也可能有多個關鍵字索引對象作為子對象，只有通過它們的對象類才能表明哪些對象類是類別口袋的一部分，以及哪些是標識口袋的一部分。
關鍵字索引被用在UDDI標準內的幾個地方。其包括一個TModel鍵、一個鍵名稱以及一個鍵值。關鍵字索引的兩個用途是類別口袋和標識口袋。這些口袋是關鍵字索引的集合，且對搜索很重要。如果用包含無差別的關鍵字索引的對象來描述這些口袋，那麼就可能很難實現有效搜索。這就是為什麼要實現多個關鍵字索引的子類。企業實體上的類別口袋用euBusinessEntityCategoryKeyedReference類的一個或多個子對象來表示。這使得很容易在這些類別包內有效的搜索帶有特定關鍵字索引的企業實體。
下面的實例顯示了抽象類和一個派生類，即如上所述的euBusinessEntityCategoryKeyedReference。需要注意的是關鍵字索引的鍵是從抽象類中繼承而來的，而TModel鍵、鍵名稱以及鍵值都全部是在派生類中規定的，因此可能有不同的名稱用於搜索。
set object-class uddiObjectClass201＝{#用於所有關鍵字索引的父類的抽象類name＝eukeyedReferencesubclass-of topmust-containeuKeyedReferenceKey}；set object-class uddiObjectClass301＝
{#企業實體分類關鍵字索引-其集合組成類別口袋name＝euBusinessEntityCategoryKeyedReferencesubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryTModeleuBusinessEntityCategoryKeyNameeuBusinessEntityCategoryKeyValue}；聯繫方式是一個複雜的對象，表示了多種信息。更類似企業實體，聯繫方式包含了多個複合重複元素，必須使用子對象類。
直屬於聯繫方式對象的僅有數據元素是一個鍵，以及該聯繫方式對應的人或任務的名稱。這是一個可選的用途類型。
所有其它可能的要素是聯繫方式對象的子對象。包括地址(地址行對象的有序列表的父對象，分別有一個鍵、用途類型、排序編碼以及TModel鍵)；電話(電話號碼加上用途類型)；電子信箱(電子信箱地址加上用途類型)；以及描述(描述字符串加上語言編碼)。
而且，儘管圖15描述了根據本發明的一個實施例把層次結構引入到一個子結構，用於表示企業實體中相對複雜的對象的例子，它也可以描述根據本發明的一個實施例把層次結構引入到一個子結構，用於表示聯繫方式對象中相對複雜的對象的例子。圖15的企業實體151也適用於聯繫方式對象，同時聯繫方式對象的多值元素表示為聯繫方式對象151的子對象152、153。也可能沒有子對象或者有多個子對象。
另一個要點是關於如何用有效的方式來表示名稱和描述(UDDI標準中規定的)，並能快速搜索特定類型的名稱或描述。
根據本發明的一個實施例，系統創建了一個抽象基類來表示名稱，以及另一個基類來表示描述，並將其作為各個所需類型的子類。當尋找特定類型的名稱(例如企業實體名稱)時搜索子類的屬性，當搜索任何名稱時就搜索抽象類。
幾個主要對象(企業實體、商業服務等)有多個名稱和描述。其原因是多方面的。對於一個企業來說有多個名稱並不是很少見的，可能有一個正式名稱，以及一個或多個通常所用的名稱。並且一個氣壓在不同語言裡可以使用不同的名稱。例如名稱被錯誤地翻譯也是常見的。例如，計算機公司Fujitsu在英語國家有很多年使用Facom這個名字。語言中使用多個字母集可能會強化這個要點。日本公司的名稱也可能在片假名中有一個版本，在平假名中有另一個版本。
由於這些原因以及其他原因，單個對象中可能出現幾次名稱和描述對象。每個實例用語言編碼來標記。UDDI版本3中有多個實例帶有同一語言編碼(版本2中是不允許的)。
尋找限定詞更增加了額外的混淆。如前所述，UDDI搜索需要能支持敏感性的和非敏感性的搜索，而在X.500目錄中兩次存儲數據可以很好地處理這點。
如下實例顯示了抽象類以及一個派生類euBusinessEntityName，其用於企業實體的名稱集合set object-class uddiObjectClass202＝{#作為所有名稱的父類的抽象類name＝euNamesubclass-of topmust-containeuNameKeymay-containeuLanguage}；set object-class uddiObjectClass331＝{#企業實體的名稱name＝euBusinessEntityNamesubclass-of euNamemust-contain
euBusinessEntityNameValue，euBusinessEntityNameValueIC#inherits euNameKey and euLanguagef from euName}；需要注意的是euBusinessEntityNameValue是包含敏感性的名稱版本的屬性；同時euBusinessEntityNameValueIC是標記為「忽略情況」的版本，因此是非敏感性的。EuNameKey欄位從抽象類繼承得來，被用於控制名稱順序，並提供一個唯一的命名屬性。
名稱對象的一個實例如下euNameKey＝890abcde-890a-890a-890a-890abcdef123euLanguage＝ENeuBusinessEntityNameValue＝Mckenna’s Validation SystemseuBusinessEntityNameValueIC＝Mckenna’s Validation Systems而且，儘管圖15描述了根據本發明的一個實施例把層次結構引入到一個子結構，用於表示企業實體中相對複雜的對象的例子，它也可以用於描述根據本發明的一個實施例把層次結構引入到一個子結構，用於表示抽象類中相對複雜的對象的例子。圖15的企業實體151同樣也適用於抽象類，同時抽象類的多值元素表示為抽象類151的子對象152、153。也可能沒有子對象或者有多個子對象。
另一個要點是關於如何創建一種有效的實現方法，只允許用戶改變那些受其控制的企業實體。根據本發明的一個實施例，可以創建由用戶對象的子對象控制的企業實體來實現。這使得安全性更容易實現。
確保一個發布用戶只能改變他/她所有的信息是很重要的。可以用不同的方案來實現這點。但是最佳的方案能夠清楚知道用戶是否授權發布一項內容給定用戶控制的所有數據位於該用戶的子樹中。
這一方案的確定對訪問企業實體整體沒有影響，因為對企業實體的所有查詢都可以從層次結構的用戶層上構建，而不會影響通用性或性能。
另一個要點是關於如何有效地實現發行者聲明，尤其是實現findRelatedBusiness的方法。根據本發明的實施例，可以創建與商業對象的子對象有關的發行者聲明來實現這點。這就避免了搜索判別條件的需求。
發行者聲明的主要用途是find_RelatedBusinesses查詢。該查詢規定了一個特殊的企業實體，並通過已建立的發行者聲明請求與該實體相關的所有企業實體的信息。這一查詢通過一種把發行者聲明設置在與其相關的企業實體之下的層次結構來簡化和加速。其額外的優點是增加了一致性。當刪除了一個企業實體時，與其同時也刪除了所有相關聯的發行者聲明(目前已經不相關)。
另一個要點是如何創建一種有效的實現方法，只允許用戶改變那些受其控制的企業實體。根據本發明的一個實施例，系統把用戶定義的TModel作為用戶對象的子對象。這使得安全性更容易實現。
與把企業實體設置在用戶條目之下相類似，把用戶定義的TModel設置在定義了這些TModel的用戶的用戶條目之下是明智的。這不會對TModel的定位產生不利的影響，因為其只能通過單一檢索訪問來定位，因為所有的TModel都是唯一命名的。
另一個要點是關於如何根據關係有效地搜索發行者聲明。根據本發明的一個實施例，這可以通過把關係關鍵字索引設置成發行者聲明條目的輔助類來實現。如果關鍵字索引是一個子對象(一種實現方法)，就不會用相同的效率對其進行搜索，且對關係的搜索不能和搜索發行者聲明的內容相結合，例如對(關鍵的)基於狀態(僅考慮已建立的聲明)的濾波器。
X.500模式系統可能不支持構造包括其他對象類作為數據要素的對象類。例如關鍵字索引不能是發行者聲明的一個數據要素。可以把關鍵字索引設置成發行者聲明的一個子對象，但這不利於創建一個引用該關鍵字索引的內容的有效搜索。
把關鍵字索引設置成發行者聲明的輔助類是對於該問題的一種有效解決方案。現在可以基於關鍵字索引的內容進行搜索，如同它是聲明的一部分。
如上所述，發行者聲明的一個實例如下euPublisherAssertionKey＝7890abcd-7890-7890-7890-7890abcdef12euFromBusinessKey＝34567890-3456-3456-3456-34567890abcdeuFromUserKey＝23456789-2345-2345-2345-234567890abceuToBusinessKey＝09876543-6543-6543-6543-dcba09876543euToUserKey＝98765432-5432-5432-5432-cba098765432euPublisherAssertionStatus＝statuscompleteeuPublisherAssertionTModel＝uuid807A2C6A-EE22-470D-ADC7-E0424A337C03euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child輔助對象類是euPublisherAssertionKeyReference，且上面列出的最後三個屬性是該類的數據要素。
根據本發明的一個實施例，如計算機協會的eTrustTM目錄可以用來實現一個理想的企業UDDI註冊平臺。eTrust目錄和LDAPv3、X.500電子目錄完全兼容，能夠用於支持UDDI網絡服務實現方法。『eTrust』目錄使得UDDI方法能夠平衡那些已經證明在大規模、商業要求的目錄服務應用程式中高度成熟的目錄解決方案。
『eTrust』目錄有許多獨特的特徵使得其作為構建UDDI註冊的平臺相當具有吸引力。其中一些特徵包括安全特徵—包括訪問控制決策、任務、安全代理、相互認證、分布式認證、分布式SSL證明內容核實以及網絡地址有效性確認；分布和路徑特性-包括並行分布式搜索、負載分配、流水線式查詢以及最短路徑路由；多主控複製機制-其結合了基於重播機制(稱為多記錄機制)的速度和基於狀態修復及平衡技術的效率；可用性特徵-包括資料庫的熱交換、網絡容錯備援(fail-over)和目錄系統代理(DSA)容錯備援；快速的緩衝存儲設計；以及配置特徵-包括動態設置(數據類型、模式規則、安全性、知識等等)，不限的數據大小、通用信息完整性規則、廣泛的管理員級控制以及一個交互式的命令控制臺。
eTrust目錄提供了一個已檢驗的X.500目錄方案。在這種已證明的基礎上可以構造一個UDDI語義橋，以建立一個與標準完全兼容的UDDI註冊。由於基礎目錄方案的性能，此處公開的實施例能提供靈活的安全性、分布性和可管理性，而不需要對現有UDDI標準進行改變或擴展。
本實施例要處理的一個要點是如何映射存儲在目錄的不同部分中的實體之間的關係。
而UDDI數據結構主要是分層次的，不同對象之間有交叉關係時可能會出現問題。
基本上有兩類關係，即可供選擇的名稱和交叉關係。根據本發明的一個實施例，可以使用別名概念描述可供選擇的名稱，從而解決該問題。基本上該方法可以通過主實體的一個虛擬子對象來「關聯」外來實體。
本實施例使用專有鍵來解決交互相關性的問題。創建類似RDBMS技術中的基本/外來鍵系統的『相關性指針』，來調整層次化目錄系統內拆散的子樹之間存在的數據實體的相關性。
現在根據本發明的實施例來描述別名的使用。UDDI商業服務投影可以很清楚地演示第一種情況。商業服務投影實際上是商業服務的一個可選擇的名稱。商業服務投影是這樣一種商業服務，其看起來屬於企業A，但實際上是屬於企業B且由企業B來定義的。
參照圖5，商業服務51是屬於企業A的服務，看起來也屬於企業B。企業A對商業服務51做出的任何改變會在看起來是企業B之下的投影服務中產生反映。同樣地，如果從註冊中刪除了商業服務51，其就不會出現在企業A或企業B下面。另外，企業實體B不會編輯或改變商業服務51。只有企業A能訪問商業服務51以進行編輯或其它發布操作。
可以使用目錄別名系統來獲得這種效果。商業服務51的別名被添加到企業實體B。別名是一種特殊的目錄伺服器的標誌，當有人看到這個別名，就向他們展示另外的條目。
這意味著當編輯原始服務時，在投影服務中也可以看到變化。如果目錄系統支持別名完整性-這是eTrust目錄的情況，此時如果刪除了服務，其投影也會被自動刪除。
另外，目錄伺服器可以被設置為當搜索投影商業服務時立即兩次顯示投影的商業服務，在每個父對象之下各顯示一次。當搜索時需要分解商業服務的父對象時，這是很有用的。
一些情況需要目錄層次結構中不相交的部分的對象能維持一定關係。
一個這樣的例子是在綁定模板和TModel之間。TModel在整個UDDI中可用於多種不同的目的。它們是類別鍵、搜索標識符、(UDDI)關係描述符，以及在這種情況下的技術規範「指紋」。「關聯」到綁定模板上的TModel描述了這一綁定模板所遵守的技術規範(參見圖8)。例如一個發行者可以關聯一個TModel，聲明它們的綁定模板符合SOAP1.1標準。
註冊中心典型地包含一組確定的TModel，其中許多TModel將由數百個甚至上千個綁定模板條目所引用。在某些情況下，註冊中心會返回所有「關聯」的TModel的詳細內容和綁定模板的詳細內容。
根據本發明的這一實施例，例如用在關係資料庫系統中的主鍵/外部鍵系統可以進行適當的修改和應用。每個存儲在註冊中心中的TModel有其自身唯一的(主)鍵。通過添加一個與所需TModel的唯一鍵相匹配的本地(外部)鍵，綁定模板可以引用TModel，。圖7闡釋了一個實例。如果TModel數據需要和綁定模板一起返回，則伺服器就可以查詢所討論的TModel。
圖6顯示了綁定模板和TModel之間的關係。
圖7顯示了TModel鍵如何創建兩個實體之間的關係。
發行者聲明是UDDI信息庫的一個重要要素。如上所述，其可以讓用戶發現哪個企業實體與感興趣的企業實體相關，以及它們如何相關。
為了防止濫用，發行者聲明可設計為只有當兩個相關的企業實體的所有者都聲明了這種關係時，所宣稱的關係才變得可見。這種保護措施的代價是實現方法複雜化，但這種精心設計對於避免較差的性能是有必要的。
一個問題是關於完整性。發行者聲明比其他任何UDD構造有更複雜的生命周期。其產生於當企業實體的所有者做出關於該企業的聲明以及該企業與另一個企業實體的關係時。另一個企業實體的所有者可以請求一個狀態報告，並查看有哪些關於其企業的聲明，或者通知他們已經超出權限(out-of-band)。不管以哪種方法，另一個企業實體的所有者可以選擇對兩個企業實體之間的關係作出一個匹配聲明。一旦此聲明完成，就對搜索findRelatedBusiness的用戶可見。如果修改或刪除任意一個或兩個聲明，而聲明再次變成不完整的，而且不可見。另外，不管刪除哪個企業實體都應立即刪除其聲明。
發行者聲明對象以能夠保持聲明完整性的方式來管理。
現在希望企業實體的所有者能夠對該所有者控制的企業實體做出(以及刪除)聲明。
本發明的實施例是基於假定UDDI信息庫是一個「大部分可讀(read-mostly)」的存儲器，正適用於X.500目錄。為此，本設計的讀數據的性能是最優的，甚至以加重寫數據的負擔為代價。
被稱為「發行者聲明(Publisher Assertion)」的對象類被設計為超出UDDI標準要求之外來保持數據，因為希望能優化搜索性能。該方案引入了一個可操作屬性，其定義了發行者聲明的狀態。在寫入目錄的時刻確定聲明的狀態，而不需要每次執行搜索時確定其狀態。
本實施例也使用了用戶鍵形式的指針。當發行者聲明寫入到目錄時，確定了「源」和「目的」企業的用戶鍵，並寫入到對象中。這簡化了getAssertionStatusReport查詢，因為要產生這樣一個報告所需全部就是搜索一個包含了產生報告的人的用戶鍵的發行者聲明。
相反，如果必須查詢該用戶下的所有企業鍵，那麼要尋找包含這些企業鍵的發行者聲明，要產生該報告需要相當大的勞動量。
發行者聲明的一個常見用途是發現與給定企業『相關』的那些企業。為了提供更好的查詢性能，把與企業相關的發行者聲明設置在該企業的子節點上。
另外，每個聲明的狀態作為可操作屬性記錄在聲明中。這使得能夠只查詢位於感興趣的公司之下帶有完整狀態的發行者聲明。這簡化了findRelatedBusinesses搜索，因為該搜索僅檢索那些完整的聲明。
為了簡化安全性，一個用戶控制的所有企業以及它們的發行者聲明都可以是該用戶帳戶條目之下的子節點。只允許用戶訪問用戶帳戶條目之下的子樹的這種實現方法加強了訪問控制。
需要注意的是表示狀態的可操作屬性由UDDI來管理。當用戶發布一個已經由另一個企業所做出的聲明，UDDI實現方法將更新另一個聲明的狀態，該聲明位於受另一個企業用戶控制的子樹中。訪問控制能做到這一點。
另一個可替換的實施例可以存儲兩個發行者聲明對象，兩個相關的企業實體之下各設置一個，這樣在其自身的子樹之下就有一個發行者聲明。例如發行者聲明子樹可以位於信息庫對象之下。在這種情況下當首次存儲聲明時，其處於未完成狀態(例如tokeyincomplete或fromkeyincomplete，這取決於哪一邊做出該聲明)。如果發行者聲明由一個候補用戶作出聲明，就把狀態改為完成。如果從兩個發行者聲明中刪除任一個，那麼狀態又變為未完成。如果兩邊都刪除了發行者聲明，那麼就刪除了發行者聲明對象。這能有利地產生聲明的一份拷貝，且大多數維護工作都只是修改一個表示聲明狀態的屬性。
圖12示意性地闡釋了本發明的一個實施例的層次結構。示意性地闡釋了兩個替換的實施例，其中發行者聲明對象位於企業實體和/或信息庫對象之下。
圖8闡釋了一種請求添加發行者聲明的方法。在步驟S80中，可以判定該請求是否有效。如果無效(否，步驟S80)，則請求失敗(步驟S92)。如果請求有效(步驟S80的結果是「是」)，則判斷請求是否來自我們的企業(步驟S82)。如果不是來自我們的企業(步驟S82的結果是「否」)，則判斷請求是否是到達我們的企業(步驟S84)。如果不是到達我們的企業(步驟S84的結果是「否」)，則請求失敗(步驟S92)。如果請求是到達我們的企業(步驟S84的結果是「是」)，則判斷該聲明是否由企業所有者做出(步驟S86)。如果該聲明不是由所有者做出(步驟S86的結果是「否」)，則寫入一個未完成的聲明(步驟S94)。如果該聲明是由所有者做出的(步驟S86的結果是「是」)，就寫入一個完成的聲明(步驟S96)。返回到步驟S82，如果判定了該請求是來自我們的企業(步驟S82的結果是「是」)，則判斷該請求是否到達我們的企業(步驟S88)。如果不是到達我們的企業(步驟S88的結果是「否」)，則判斷是否是到達企業所有者做出的聲明(步驟S90)。如果聲明不是由到達商業所有者做出的(步驟S90的結果是「否」)，則寫入了未完成的聲明(步驟S94)。如果步驟S88的結果是肯定的(到達我們的企業)，或者步驟S90的結果是肯定的(到達商業所有者做出的聲明)，就寫入完成的聲明(步驟S96)。
下一個要點處理如何在搜索操作中優化中間搜索結果的構造，考慮到目錄存儲介質的限制，從而使目錄訪問和信息庫內迭代操作減到最小。實際過程中，目錄條目可以用任意順序存儲並返回，且目錄結果可能太大而無法排序。
根據本發明的一個實施例，提供了一個面向對象的存儲器內數據存儲系統，其與一個唯一結果排序機制相耦合，該機制根據特異名稱對中間結果進行排序。這使得搜索能返回許多不同類型的對象—企業實體，商業服務等—並且仍允許系統容易地構造正確的XML結構以把數據返回到用戶。需要注意的是網絡服務交互是以XML形式進行的。
下面描述這種系統的說明。本發明的UDDI企業實體和任何子對象數據元素可以根據下列層次結構在目錄中表示企業實體(BusinessEntity)●商業服務(BusinessService)○綁定模板(BindingTemplate)
○綁定模板(BindingTemplate)○服務名稱(ServiceName)○服務名稱(ServiceName)●商業服務(BusinessService)○綁定模板(BindingTemplate)○綁定模板(BindingTemplate)○服務名稱(ServiceName)○服務名稱(ServiceName)●企業名稱(BusinessName)●企業名稱(BusinessName)●企業描述(BusinessDescription)●企業描述(BusinessDescription)需要注意的是服務名稱、企業名稱和企業描述已經在本發明的處理子結構和對象分離的相關內容中進行了描述。
企業實體獲取編碼基於所需的一個或多個企業實體的唯一鍵來執行目錄子樹搜索。搜索返回所發現的條目與所有子條目。目錄標準不能保證返回的條目有任何特定順序—甚至不能保證子條目會緊跟在其父條目之後。
因此獲取編碼根據特異名稱對返回的條目進行排序。這能保證子條目在其父條目之後排列，因此很容易區分從屬關係。可以使用不同的排序算法。所用的排序算法在對條目部分排序時能產生高性能。
結果構造的算法在操作時基本上是「深度優先、從左至右的樹形」。這在圖論中稱為「後序遍歷」。
排序列表被送到一個新企業實體對象的構造方法。在面向對象程序結構中，該對象例如被設計成描述UDDI企業實體。企業實體對象包含從最後一個條目提供的數據『構造自身』的編碼。編碼反覆遍歷整個列表，對每個條目做出判斷。可以理解列表中的第一個條目是企業實體自身的主條目，一旦它尋找到另一個企業實體就認為構造已經完成—列表順序確保能實現該點。一旦其尋找到商業服務或其他子條目，就初始化一個適當類型的對象，並把列表和一個說明列表開始位置的指針一起傳送到新對象的構造器。
每個對象基本上包含相似的程序代碼來處理自身構造，以及把任意子條目構造成合適的子對象的委託構造。
通過這種方式，僅需執行一個目錄搜索，且用有效的方式來處理生成的列表，每個條目只處理一次。如果生成的列表仍然是任意順序的，或以某些其他方式進行排序，列表必須用多條路徑來處理，以便正確地根據生成的條目來構造UDDI層次結構。
對於層次結構中不同編程對象的委託構造和列表處理能把程序代碼保持得相對較小，從而使執行效率更高，速度也更快。
圖9闡釋了程序構造(對象)，包括排序後的條目列表的描述。判斷項目列表中是否有其他項目。如果沒有其他項目(否，步驟S100)，該程序退出(步驟S118)。如果有其他額外的項目(是，步驟S100)，就取回列表中的下一個項目(步驟S102)。然後就判斷該項目是否屬於這種對象類型。如果該項目屬於這個對象類型(是，步驟S104)，就根據該項目設置對象屬性(步驟S106)且程序返回到步驟S100。如果不屬於該對象類型(否，步驟S104)，就判斷該對象類型的項目是否已經被處理(否，步驟S108)。如果該對象類型的項目還沒有被處理(否，步驟S108)，程序返回到步驟S100。如果該對象類型的項目已經被處理(是，步驟S108)，就判斷該項目是否是該對象的一個固有要素(如名稱、描述等)。如果它是一個固有要素(是，步驟S110)，就把該項目添加到對象屬性中並執行備用的程序(步驟S112)，且程序返回到步驟S100。如果它不是一個固有要素(否，步驟S110)，就判定該項目是否是該對象的一個子對象(例如商業服務，如果這是個企業實體)。如果它是一個子對象(是，步驟S114)，系統對正確類型的對象進行初始化，並把項目列表傳送到一個構造器(步驟S116)，且程序返回到步驟S100。如果它不是一個子對象(否，步驟S114)，程序返回到步驟S100。
下列「real word「的實例闡釋了LDAP目錄希望返回的任意順序的類型。
SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvalueuddiDescriptionSearchResultEntryobjectNameserviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceSearchResultEntry
objectNamenameKey＝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-著重強調的名稱條目是列表頂部的企業實體註冊的一頁，且如果它出現在企業服務條目和其他企業實體的分支子條目之前是很有用的。但是它出現在列表的末尾，這迫使任何搜索整個列表的程序代碼要確保企業實體的所有直系子對象都被處理過。而這可能不是最有效率的。
因此，已經根據規則排序的相同的數據根據本發明的實施例可以表示如下SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvalueuddiDescriptionSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntityName
SearchResultEntryobjectNameserviceKey＝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—著重強調的條目現在出現在列表中一個更為邏輯的位置，且藉助於這點現在可以寫入程序代碼。當條目數量增加到實際伺服器負載時，節省的程序時間是十分可觀的。
下面是本發明的另一個實施例。
#描述UDDI數據和/或目錄中關係的計劃......表達式100#Computer Associates eTrust UDDI Configuration Schema#Copyright2002 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 uddiAttributeType201＝{#用於KeyedReferenc和所有其導出類name＝euKeyedReferenceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType202＝{#用於UserAccountname＝euUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType203＝{#用於BusinessEntity，TModel及其它name＝euParentUserKeysyntax＝caseIgnoreStringsingle-valued
}；set attribute uddiAttributeType204＝{#用於BusinessEntityname＝euBusinessEntityKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType205＝{#用於BusinessService及其它name＝euParentBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType206＝{#用於BusinessServicename＝euBusinessServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType207＝{#用於BindingTemplate及其它name＝euParentServiceKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType208＝{#用於BindingTemplatename＝euBindingTemplateKeysyntax＝caseIgnoreString
single-valued}；set attribute uddiAttributeType209＝{#用於TModelname＝euTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType210＝{#用於PublisherAssertionname＝euPublisherAssertionKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType211＝{#用於PublisherAssertionname＝euFromBusinessKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType212＝{#用於PublisherAssertionname＝euFromUserKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType213＝{#用於PublisherAssertionname＝euToBusinessKey
syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType214＝{#用於PublisherAssertionname＝euToUserKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType216＝{#用於DiscoveryURLname＝euDiscoveryURLKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType217＝{#用於Contactname＝euContactKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType218＝{#用於Addressname＝euAddressKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType219＝{#用於Address
name＝euAddressTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType220＝{#用於AddressLinename＝euAddressLineKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType221＝{#用於Phonename＝euPhoneKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType222＝{#用於Emailname＝euEmailKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType223＝{#用於TmodelInstanceInfoname＝euInstanceTModelKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType224＝
{#用於Name及其所有導出類name＝euNameKeysyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType225＝{#用於Description及其所有導出類name＝euDescriptionKeysyntax＝caseIgnoreStringsingle-valued}；#----------------------------------------------------------------------------------#keyed references中使用的屬性set attribute uddiAttributeType301＝{#用於BusinessEntityCategoryname＝euBusinessEntityCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType302＝{#用於BusinessEntityCategoryname＝euBusinessEntityCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType303＝{#用於BusinessEntityCategory
name＝euBusinessEntityCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType304＝{#用於BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType305＝{#用於BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType306＝{#用於BusinessEntityIdentifiername＝euBusinessEntityIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType307＝{#用於BusinessServiceCategoryname＝euBusinessServiceCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType308＝
{#用於BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType309＝{#用於BusinessServiceCategoryname＝euBusinessServiceCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType310＝{#用於TModelCategoryname＝euTModelCategoryKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType311＝{#用於TModelCategoryname＝euTModelCategoryKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType312＝{#用於TModelCategoryname＝euTModelCategoryKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；
set attribute uddiAttributeType313＝{#用於TModelIdentifiername＝euTModelIdentifierKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType314＝{#用於TModelIdentifiername＝euTModelIdentifierKRKeyNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType315＝{#用於TModelIdentifiername＝euTModelIdentifierKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType316＝{#用於PublisherAssertionname＝euPublisherAssertionKRTModelsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType317＝{#用於PublisherAssertionname＝euPublisherAssertionKRKeyNamesyntax＝caseIgnoreStringsingle-valued
}；set attribute uddiAttributeType318＝{#用於PublisherAssertionname＝euPublisherAssertionKRKeyValuesyntax＝caseIgnoreStringsingle-valued}；#---------------------------------------------------------------------------#用於名稱和描述的屬性set attribute uddiAttributeType361＝{#用於Business Entity Namename＝euBusinessEntityNameValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType381＝{#用於Business Entity Namename＝euBusinessEntityNameValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType362＝{#用於Business Service Namename＝euBusinessServiceNameValuesyntax＝caseExactStringsingle-valued}；
set attribute uddiAttributeType382＝{#用於Business Service Namename＝euBusinessServiceNameValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType363＝{#用於Business Entity Descriptionname＝euBusinessEntityDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType383＝{#用於Business Entity Descriptionname＝euBusinessEntityDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType364＝{#用於Business Service Descriptionname＝euBusinessServiceDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType384＝{#用於Business Service Descriptionname＝euBusinessServiceDescriptionValueICsyntax＝caseIgnoreStringsingle-valued
}；set attribute uddiAttributeType365＝{#用於TModel Descriptionname＝euTModelDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType385＝{#用於TModel Descriptionname＝euTModelDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType366＝{#用於TModel Instance Info Descriptionname＝euTModelInstanceInfoDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType386＝{#用於TModel Instance Info Descriptionname＝euTModelInstanceInfoDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType367＝{#用於TModel Instance Details Descriptionname＝euTModelInstanceDetailsDescriptionValuesyntax＝caseExactString
single-valued}；set attribute uddiAttributeType387＝{#用於TModel Instance Details Descriptionname＝euTModelInstanceDetailsDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType368＝{#用於Overview Doc Descriptionname＝euOverviewDocDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType388＝{#用於Overview Doc Descriptionname＝euOverviewDocDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType369＝{#用於Binding Template Descriptionname＝euBindingTemplateDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType389＝{#用於Binding Template Descriptionname＝euBindingTemplateDescriptionValueIC
syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType370＝{#用於Contact Descriptionname＝euContactDescriptionValuesyntax＝caseExactStringsingle-valued}；set attribute uddiAttributeType390＝{#用於Contact Descriptionname＝euContactDescriptionValueICsyntax＝caseIgnoreStringsingle-valued}；#-----------------------------------------------------------------------------------#其他屬性set attribute uddiAttributeType400＝{#用於Name和Descriptionname＝euLanguagesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType401＝{#用於Repositoryname＝euRepositoryNamesyntax＝caseIgnoreString
single-valued}；set attribute uddiAttributeType402＝{#用於UserAccountname＝euUserNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType403＝{#用於UserAccountname＝euCredentialssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType404＝{#用於UserAccountname＝euAuthorizedNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType405＝{#用於UserAccount和TModelname＝euHiddensyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType406＝{#用於BusinessEntity和TModelname＝euOperator
syntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType407＝{#用於Contactname＝euContactNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType408＝{#用於discoveryURL、contact、address、phone、emailname＝euUserTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType409＝{#用於phonename＝euPhoneNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType419＝{#用於emailname＝euEmailAddresssyntax＝caseIgnoreStringsingle-valued
}；set attribute uddiAttributeType411＝{#用於addresssname＝euSortCodesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType412＝{#用於BindingTemplatename＝euHostingRedirectorsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType413＝{#用於BindingTemplatename＝euAccessControlsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType414＝{#用於BindingTemplatename＝euAccessPointTypesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType415＝{#用於TModel
name＝euTModelNamesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType416＝{#用於TModelname＝euOverviewURLsyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType417＝{#用於AddressLinename＝euAddressLineValuesyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType418＝{#用於tmodelinstance infoname＝euInstanceParmssyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType420＝{#用於PublisherAssertionname＝euPublisherAssertionStatussyntax＝caseIgnoreStringsingle-valued}；set attribute uddiAttributeType421＝
{#用於DiscoveryURLname＝euDiscoveryURLValuesyntax＝caseIgnoreStringsingle-valued}；#------------------------------------------------------------------------------------#抽象類——不能在目錄中存儲該類！set object-class uddiObjectClass201＝{#用作所有關鍵字索引的父類的抽象類name＝euKeyedReferencesubclass-of topkind＝abstractmust-containeuKeyedReferenceKey}；#注意關鍵字索引也應包含tModel鍵、鍵名稱和鍵值，#每個導出類添加這些值，使得它們有不同的名稱，#便於搜索如下屬性的標準化名稱#euXXXTModel#euXXXKeyName#euXXXKeyValue#其中，XXX是對象的名稱和關鍵字索引的目的}；set object-class uddiObjectClass202＝{#用作所有名稱的父類的抽象類name＝euNamesubclass-of top
kind＝abstractmust-containeuNameKeymay-containeuLanguage#注意名稱也應有一個包含特有名稱的字符串，該字符串往往有一個#euXXXNameValue格式的名稱，其中XXX是父對象的名稱#這將使搜索效率最高#該屬性還有另一個版本添加IC的忽略大小寫版本}；set object-class uddiObjectClass203＝{#用作所有描述的父類的抽象類name＝euDescriptionsubclass-of topkind＝abstractmust-containeuDescriptionKeymay-containeuLanguage#注意描述也應有一個包含特有名稱的字符串，該字符串往往有一個#euXXXDescriptionValue格式的名稱，其中XXX是父對象的名稱#這將使搜索效率最高#該屬性還有另一個版本添加IC的忽略大小寫版本}；#---------------------------------------------------------------------------------------#關鍵字索引類型
set object-class uddiObjectClass301＝{#BusinessEntityCategory關鍵字索引——其集合組成分類口袋name＝euBusinessEntityCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryKRKeyValuemay-containeuBusinessEntityCategoryKRTModeleuBusinessEntityCategoryKRKeyName}；set object-class uddiObjectClass302＝{#BusinessEntityIdentifier關鍵字索引——其集合組成分類口袋name＝euBusinessEntityIdentifierKRsubclass-of euKeyedReferencemust-containeuBusinessEntityIdentifierKRKeyValuemay-containeuBusinessEntityIdentifierKRTModeleuBusinessEntityIdentifierKRKeyName}；set object-class uddiObjectClass303＝{#BusinessServiceCategory關鍵字索引——其集合組成分類口袋name＝euBusinessServiceCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessServiceCategoryKRKeyValuemay-containeuBusinessServiceCategoryKRTModeleuBusinessServiceCategoryKRKeyName
}；set object-class uddiObjectClass304＝{#TModelCategory關鍵字索引——其集合組成分類口袋name＝euTModelCategoryKRsubclass-of euKeyedReferencemust-containeuTModelCategoryKRKeyValuemay-containeuTModelCategoryKRTModeleuTModelCategoryKRKeyName}；set object-class uddiObjectClass305＝{#TModelIdentifier關鍵字索引——其集合組成口袋name＝euTModelIdentifierKRsubclass-of euKeyedReferencemust-containeuTModelIdentifierKRKeyValuemay-containeuTModelIdentifierKRTModeleuTModelIdentifierKRKeyName}；set object-class uddiObjectClass306＝{#PublisherAssertion關鍵字索引——用作給出所關心的輔助類name＝euPublisherAssertionKRsubclass-of euKeyedReferencekind＝auxiliarymust-containeuPublisherAssertionKRKeyValuemay-contain
euPublisherAssertionKRTModeleuPublisherAssertionKRKeyName}；#--------------------------------------------------------------------------------#名稱和描述類型set object-class uddiObjectClass331＝{#BusinessEntity的名稱name＝euBusinessEntityNamesubclass-of euNamemust-containeuBusinessEntityNameValueeuBusinessEntityNameValueIC#從euName繼承euNameKey和euLanguage}；set object-class uddiObjectClass332＝{#BusinessService的名稱name＝euBusinessServiceNamesubclass-of euNamemust-containeuBusinessServiceNameValueeuBusinessServiceNameValueIC#從euName繼承euNameKey和euLanguage}；set object-class uddiObjectClass341＝{#BusinessEntity的描述name＝euBusinessEntityDescriptionsubclass-of euDescription
must-containeuBusinessEntityDescriptionValueeuBusinessEntityDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass342＝{#BusinessService的描述name＝euBusinessServiceDescriptionsubclass-of euDescriptionmust-containeuBusinessServiceDescriptionValueeuBusinessServiceDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass343＝{#TModel的描述name＝euTModelDescriptionsubclass-of euDescriptionmust-containeuTModelDescriptionValueeuTModelDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass344＝{#TModelInstanceInfo的描述name＝euTModelInstanceInfoDescriptionsubclass-of euDescriptionmust-containeuTModelInstanceInfoDescriptionValue
euTModelInstanceInfoDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass345＝{#TModelInstanceDetails的描述name＝euTModelInstanceDetailsDescriptionsubclass-of euDescriptionmust-containeuTModelInstanceDetailsDescriptionValueeuTModelInstanceDetailsDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass346＝{#OverviewDoc的描述name＝euOverviewDocDescriptionsubclass-of euDescriptionmust-containeuOverviewDocDescriptionValueeuOverviewDocDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass347＝{#Contact的描述name＝euContactDescriptionsubclass-of euDescriptionmust-containeuContactDescriptionValueeuContactDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage
}；set object-class uddiObjectClass348＝{#BindingTemplate的描述name＝euBindingTemplateDescriptionsubclass-of euDescriptionmust-containeuBindingTemplateDescriptionValueeuBindingTemplateDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；#---------------------------------------------------------------------------------------------#主要對象set object-class uddiObjectClass400＝{#repository——用於把用戶分組name＝euRepositorysubclass-of topmust-containeuRepositoryName}；set object-class uddiObjectClass401＝{#UserAccount——用於存儲用戶信息name＝euUserAccountsubclass-of topmust-containeuUserKey，euUserName，euCredentials
may-containeuAuthorizedName，euHidden#注意該用戶公布的所有BusinessEntity和TModel都是該對象的子類}；set object-class uddiObjectClass402＝{#BusinessEntity——提供服務的實體的細節name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，euAuthorizedName，euOperator#注意BusinessEntity的許多屬性都存儲在該對象的子對象裡#尤其是那些出現不只一次的屬性}；set object-class uddiObjectClass403＝{#BusinessService——企業實體提供的服務的細節name＝euBusinessServicesubclass-of topmust-containeuBusinessServiceKeymay-containeuParentBusinessKey#注意該服務的所有BindingTemplate都是此服務的子類}；set object-class uddiObjectClass404＝
{#BindingTemplate——如何訪問某一特定企業服務的細節name＝euBindingTemplatesubclass-of topmust-containeuBindingTemplateKeymay-containeuParentServiceKeyeuHostingRedirector，euAccessPoint，euAccessPointType#注意HostingRedirector和AccessPoint應當只少該服務的所有BindingTemplate都是此服務的子類}；set object-class uddiObjectClass405＝{#TModel——對某一思想的引用。一種分類機制可能只是一個標準的引用name＝euTModelsubclass-of topmust-containeuTModelKey，euTModelNamemay-containeuAuthorizedNameeuOperator，euOverviewURL，euParentUserKey，euHidden#注意Hidden在「刪除」TModel時使用}；set object-class uddiObjectClass406＝
{#PublisherAssertion——宣稱兩個企業之間的某一關係name＝euPublisherAssertionsubclass-of topmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinessKey，euToUserKey，euPublisherAssertionStatus#注意關係將存儲為類型euPublisherAssertionKeyedReference的輔助類#這允許直接搜索該輔助類的元素}；#-----------------------------------------------------------------------------------#次要對象——包含重複數據的主要對象的大多數子對象set object-class uddiObjectClass501＝{#DiscoveryURL——存在於企業實體之下name＝euDiscoveryURLsubclass-of topmust-containeuDiscoveryURLKey，euDiscoveryURLValue，euUseType}；set object-class uddiObjectClass502＝
{#Contact——存在於企業實體之下——十分複雜，可能有許多子對象name＝euContactsubclass-of topmust-containeuContactKey，euContactNamemay-containeuUseType}；set object-class uddiObjectClass503＝{#Address——存在於Contact之下name＝euAddresssubclass-of topmust-containeuAddressKeymay-containeuSortCode，euAddressTModelKey，euUseType}；set object-class uddiObjectClass504＝{#AddressLine——存在於Address之下，組成地址行name＝euAddressLinesubclass-of topmust-containeuAddressLineKey，euAddressLineValue
}；set object-class uddiObjectClass505＝{#Phone——存在於Contact之下name＝euPhonesubclass-of topmust-containeuPhoneKey，euPhoneNumbermay-containeuUseType}；set object-class uddiObjectClass506＝{#Email——存在於Contact之下name＝euEmailsubclass-of topmust-containeuEmailKey，euEmailAddressmay-containeuUseType}；set object-class uddiObjectClass507＝{#TModelInstanceInfo——存在於BindingTemplate之下name＝euTModelInstanceInfosubclass-of topmust-contain
euInstanceTModelKeymay-containeuInstanceParms，euOverviewURL}；#-------------------------------------------------------------------------#名稱綁定schema set name-binding uddiBinding101＝{#綁定到頂部——最高層子對象name＝euRepository-topeuRepository allowable-parent topnamed-by euRepositoryName}；schema set name-binding uddiBinding102＝{#綁定到頂部——最高層子對象name＝euUserAccount-topeuUserAccount allowable-parent topnamed-by euUserKey}；schema set name-binding uddiBinding103＝{#綁定到euRepositoryname＝euUserAccount-euRepositoryeuUserAccount allowable-parent euRepositorynamed-by euUserKey}；schema set name-binding uddiBinding104＝
{#綁定TModel到「頂部」——用於標準TModel(不被用戶公布)name＝euTModel-euRepositoryeuTModel allowable-parent euRepositorynamed-by euTModelKey}；schema set name-binding uddiBinding105＝{#綁定到organization——最高層子對象name＝euRepository-organizationeuRepository allowable-parent organizationnamed-by euRepositoryName}；schema set name-binding uddiBinding106＝{#考慮到可供選擇的配置，把PublisherAssertion綁定到euRepositoryname＝euPublisherAssertion-euRepositoryeuPublisherAssertion allowable-parent euRepositorynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding107＝{#綁定Repository層次——允許多層repository結構name＝euRepository-euRepositoryeuRepository allowable-parent euRepositorynamed-by euRepositoryName}；schema set name-binding uddiBinding201＝{#把BusinessEntity綁定到UserAccount——第二層name＝euBusinessEntity-euUserAccounteuBusinessEntity allowable-parent euUserAccountnamed-by euBusinessEntityKey}；
schema set name-binding uddiBinding202＝{#把TModel綁定到UserAccount——第二層name＝euTModel-euUserAccounteuTModel allowable-parent euUserAccountnamed-by euTModelKey}；schema set name-binding uddiBinding301＝{#把服務綁定到企業——第三層name＝euBusinessService-euBusinessEntityeuBusinessService allowable-parent euBusinessEntitynamed-by euBusinessServiceKey}；schema set name-binding uddiBinding302＝{#把Contact綁定到企業——第三層name＝euContact-euBusinessEntityeuContact allowable-parent euBusinessEntitynamed-by euContactKey}；schema set name-binding uddiBinding303＝{#把DiscoveryURL綁定到企業——第三層name＝euDiscoveryURL-euBusinessEntityeuDiscoveryURL allowable-parent euBusinessEntitynamed-by euDiscoveryURLKey}；schema setname-binding uddiBinding304＝{#企業下方的Namename＝euBusinessEntityName-euBusinessEntityeuBusinessEntityName allowable-parent euBusinessEntitynamed-by euNameKey
}；schema set name-binding uddiBinding305＝{#企業下方的Descriptionname＝euBusinessEntityDescription-euBusinessEntityeuBusinessEntityDescription allowable-parent euBusinessEntitynamed-by euDescriptionKey}；schema set name-binding uddiBinding306＝{#企業下方的PublisherAssertionname＝euPublisherAssertion-euBusinessEntityeuPublisherAssertion allowable-parent euBusinessEntitynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding307＝{#企業實體下方的Identifiername＝euBusinessEntityIdentifier-euBusinessEntityeuBusinessEntityIdentifier allowable-parent euBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding308＝{#企業下方的Categoryname＝euBusinessEntityCategory-euBusinessEntityeuBusinessEntityCategory allowable-parent euBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding310＝{#TModel下方的Descriptionname＝euTModelDescription-euTModeleuTModelDescription allowable-parent euTModel
named-by euDescriptionKey}；schema set name-binding uddiBinding311＝{#TModel下方OverviewURL的Descriptionname＝euOverviewDocDescription-euTModeleuOverviewDocDescription allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding3l2＝{#TModel下方的Identifiername＝euTModelIdentifierKR-euTModeleuTModelIdentifierKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding313＝{#TModel下方的Categoryname＝euTModelCategoryKR-euTModeleuTModelCategoryKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding401＝{#Contact下方的Addressname＝euAddress-euContacteuAddress allowable-parent euContactnamed-by euAddressKey}；schema set name-binding uddiBinding402＝{#Contact下方的電話號碼name＝euPhone-euContact
euPhone allowable-parent euContactnamed-by euPhoneKey}；schema set name-binding uddiBinding403＝{#Contact下方的Emailname＝euEmail-euContacteuEmail allowable-parent euContactnamed-by euEmailKey}；schema set name-binding uddiBinding404＝{#Contact下方的Descriptionname＝euContactDescription-euContacteuContactDescription allowable-parent euContactnamed-by euDescriptionKey}；schema set name-binding uddiBinding409＝{#服務下方的Namename＝euBusinessServiceName-euBusinessServiceeuBusinessServiceName allowable-parent euBusinessServicenamed-by euNameKey}；schema set name-binding uddiBinding410＝{#服務下方的Descriptionname＝euBusinessServiceDescription-euBusinessServiceeuBusinessServiceDescription allowable-parent euBusinessServicenamed-by euDescriptionKey}；schema set name-binding uddiBinding411＝{#服務下方的Category
name＝euBusinessServiceCategory-euBusinessServiceeuBusinessServiceCategory allowable-parent euBusinessServicenamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding412＝{#服務下方的BindingTemplatename＝euBindingTemplate-euBusinessServiceeuBindingTemplate allowable-parent euBusinessServicenamed-by euBindingTemplateKey}；schema set name-binding uddiBinding501＝{#地址下方的AddressLinename＝euAddressLine-euAddresseuAddressLine allowable-parent euAddressnamed-by euAddressLineKey}；schema set name-binding uddiBinding502＝{#BindingTemplate下方的Descriptionname＝euBindingTemplateDescription-euBindingTemplateeuBindingTemplateDescription allowable-parent euBindingTemplatenamed-by euDescriptionKey}；schema set name-binding uddiBinding510＝{#BindingTemplate下方的Descriptionname＝euTModelInstanceInfo-euBindingTemplateeuTModelInstanceInfo allowable-parent euBindingTemplatenamed-by euInstanceTModelKey}；schema set name-binding uddiBinding601＝
{#TModelInstanceInfo下方的Descriptionname＝euTModelInstanceInfoDescription-euTModelInstanceInfoeuTModelInstanceInfoDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；schema set name-binding uddiBinding602＝{#TModelInstanceInfo下方的InstanceDetailsDescriptionname＝euTModelInstanceDetailsDescription-euTModelInstanceInfoeuTModelInstanceDetailsDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；schema set name-binding uddiBinding603＝{#TModelInstanceInfo下方的OverviewDocDescriptionname＝euOverviewDocDescription-euTModelInstanceInfoeuOverviewDocDescription allowable-parent euTModelInstanceInfonamed-by euDescriptionKey}；由於本發明可以用幾種方式來實施，而沒有偏離本發明的基本特徵的主旨，應該理解上述實施例並不限制本發明，除非另有說明，而應該在所附的權利要求所確定的主旨和範圍內廣泛的構造。不同的修正和等效的設置確定為也包括在本發明以及所附權利要求的主旨和範圍之內。
權利要求
1.一種網絡服務目錄包括至少一個企業實體對象；以及至少一個用戶對象，其中至少一個企業實體對象設置在至少一個用戶對象之下。
2.如權利要求1中所述的網絡服務目錄，還包括至少一個商業服務對象；以及至少一個綁定模板對象；其中至少一個商業服務對象設置在至少一個企業實體對象之下，且至少一個綁定模板對象設置在至少一個商業服務對象之下。
3.如權利要求1中所述的網絡服務目錄，其中藉助於至少一個相應的用戶子對象，至少一個企業實體對象設置在至少一個用戶對象之下。
4.如權利要求1中所述的網絡服務目錄，還包括至少一個域對象，其中至少一個用戶對象設置在至少一個域對象之下。
5.如權利要求1中所述的網絡服務目錄，還包括適用於實現網絡服務目錄的裝置，且其中調用了目錄服務。
6.如權利要求5中所述的網絡服務目錄，其中使用X.500和LDAP協議中的至少一個協議來調用目錄服務。
7.一種網絡服務系統，包括一個註冊中心，其中可以進行企業註冊，該註冊中心包括一個具有層次結構的目錄，所述目錄包括至少一個企業實體對象和至少一個用戶對象，至少一個企業實體對象設置在至少一個用戶對象之下；以及一個存儲系統，用於存儲企業信息，並通過具有層次結構的目錄進行訪問。
全文摘要
一種網絡服務目錄，包括至少一個企業實體對象和至少一個用戶對象，其中至少一個企業實體對象位於至少一個用戶對象之下。
文檔編號H04L29/06GK1678997SQ03820168
公開日2005年10月5日 申請日期2003年8月25日 優先權日2002年8月26日
發明者理察·哈維, 蒂莫西·本特利 申請人:計算機聯合思想公司