Web服務設備和方法

2023-04-24 17:04:51

專利名稱：Web服務設備和方法
技術領域：
本發明通常涉及UDDI註冊中心和WEB服務，尤其涉及在這樣的服務的實際實施中使用的方法，設備和系統。
背景技術：
UDDI(統一描述，發現和集成(Universal Description，Discoveryand Integration))是一組標準，其被定義以允許使用WEB服務的應用迅速、容易和動態地彼此交互。UDDI被用來建立平臺無關的開放式框架，用於描述服務，發現企業和集成使用網際網路的系統服務，並且用於描述工作註冊中心。參照WEB站點www.uddi.org以了解詳情。
UDDI註冊中心(UDDI registry)對利用WEB服務構造的系統提供有價值的支持。圖1a示意性圖解了基本WEB服務和UDDI概念。圖1b示意性圖解了WEB服務環境的簡化協議堆棧。UDDI提供WEB服務信息的資料庫(repository)，並且自身通過WEB服務來提供。
UDDI允許應用公開其希望如何在WEB上進行交互。每個′WEB服務′是自描述的、自包含的應用邏輯模塊單元，其通過網際網路連接為其它應用提供某個系統功能。應用通過通用的Web協議和數據格式訪問WEB服務，但不必關心如何實現每個WEB服務。WEB服務能夠與其它WEB服務混合和匹配以執行較大的工作流程或企業事務。
UDDI標準描述了被用來管理WEB服務類型的說明，企業組織和關於如何調用WEB服務的細節的專用資料庫。標準不必規定應當如何實現標準，也不必規定實現是否應當包含利用資料庫，目錄或任何其他介質的存儲。
在負責UDDI標準的組織託管的WEB站點(http//www.uddi.org/faqs.html)上有一些常見問題解答(FAQ)。這些問題之一是″UDDI註冊中心能夠被建立在LDAP上或基於LDAP嗎？″作為回答，這個WEB站點公開道在UDDI和目錄之間沒有正式的關係。″UDDI規範沒有規定註冊中心實現細節。UDDI規範定義了基於XML的數據模型和一組SOAP API，以訪問和操作該數據模型。SOAP API定義了UDDI資料庫所表現出的特性。UDDI實現能夠建立在LDAP目錄上，只要它符合規定的特性。到目前為止，所有UDDI實現均建立在關係資料庫上。″應當注意，例如X.500和LDAP的目錄技術是可擴展的通用數據存儲，並且其相關語言經常被用來管理用戶和資源。它們是非常精心設計的技術，得到廣泛採用，並且被認為是非常穩定和可靠的。
然而，在目錄上實現UDDI標準(可從www.uddi.org得到)需要解決若干問題。UDDI標準留下許多重要的問題有待解決，例如●UDDI標準定義了若干對象，其中一些對象通過層次結構相關，但是UDDI沒有定義全包括的層次結構。例如，企業服務對象會處於企業實體對象下面，而綁定模板對象會處於企業服務下面。圖2圖解了這個層次結構的例子。企業實體對象被表示為21，企業服務對象被表示為22，綁定模板對象被表示為23。還應當注意，例如表示為24的TModel對象在層次上與這些對象無關。還存在例如發布者聲明(Publisher Assertion)、在層次上沒有定義的其它概念。
●建立滿足只允許用戶改變在其控制下的那些對象的要求的高效實現，●建立允許UDDI註冊中心為分布式的高效實現，●建立增強管理特性和搜索與更新的性能的高效實現。
●如何以相對高效的方式表示複雜UDDI對象。例如，企業實體，企業服務，綁定模板和/或TModel具有複合的重複單元。於是這些重複單元能夠包含進一步的重複單元。例如，企業實體可以包含聯繫(contacts)，而聯繫可以包含地址。地址可以包含地址行(address line)和電話號碼。圖13示意性圖解了企業實體中相對複雜對象的UDDI概念。企業實體對象131例如包含若干屬性132，例如授權名字(AuthorizedName)，企業關鍵字(BusinessKey)和名字(Name)。名字具有一或多個名字欄位133，例如′文本′，或者這可以隱含在′名字′自身中。還有′語言′。可以存在這些欄位133的一或多個。
●如何對重複單元中包含的特定項提供相對快速的搜索。
●如何在目錄對象層次結構中表示UDDI信息和要求，●如何以高效方式管理UDDI對象和所有其相關信息的刪除，以及●考慮到目錄存儲介質的限制，如何優化搜索操作期間中間搜索結果集合的構造，使得目錄訪問和迭代存儲器內(in-memory)操作最小化。實際上，可以以任意順序存儲和返回目錄項，並且目錄結果可能過大以致不能排序。
●如何以高效方式表示涉及發布者聲明的數據，●如何建立發布者聲明的高效實現，尤其是對於findrelatedBusiness方法的實現，●如何通過關係實現發布者聲明的高效搜索，●如何管理髮布者聲明的有效性，●如何約束由企業實體的所有者針對企業實體建立和刪除的聲明。
●如何高效管理UDDI標準中定義的相關屬性集合，●如何定義屬性和對象以增強搜索性能。
已經提出各種UDDI模式(UDDI Schema)。然而沒有任何UDDI模式被認為解決了至少上述問題。例如，一個模式提供了相對簡單的UDDI對象到目錄對象的映射，而不必涉及到產生高效商用實現的複雜度和優化。同樣不清楚在這樣的模式中如何能夠高效實現若干UDDI服務(尤其是find系列的服務)。
例如，圖14示意性圖解了企業實體中的相對複雜對象的Novell表示。企業實體對象141包含例如若干屬性142，每個屬性具有′類型′和′值′。如圖所示，存在具有值′Bill′的授權名字，具有值′890.obale.890......′的企業關鍵字，和具有多值143，144，即en#CAIN#CATS的名字。
UDDI(圖13)和Novell(圖14)的示例性表示不被認為是對於WEB服務的高效表示。
於是，需要解決上述一般性問題以及其它問題，以提供一種基於目錄的UDDI的可擴展、高效和可靠的實現。

發明內容
一種為WEB服務結構中的對象產生關鍵字的方法，包括確定對象是否具有定義的第一關鍵字，以及如果對象具有定義的第一關鍵字，則為該對象提供定義的第一關鍵字，並且如果對象不具有定義的第一關鍵字，則為該對象提供第二關鍵字。
一種包含計算機可執行代碼的計算機記錄介質，所述計算機可執行代碼用於為WEB服務結構中的對象產生關鍵字，包括用於確定對象是否具有定義的第一關鍵字的代碼，用於在對象具有定義的第一關鍵字的情況下為該對象提供定義的第一關鍵字的代碼，和用於在對象不具有定義的第一關鍵字的情況下為該對象提供第二關鍵字的代碼。


參照以下結合附圖對優選實施例進行的說明可更好地理解本發明的其它目的，優點和方面，其中圖1a示意性圖解了某些WEB服務和UDDI概念；圖1b示意性圖解了WEB服務環境的簡化協議堆棧；圖2示意性圖解了現有技術的層次結構；圖3示意性圖解了現有技術的目錄服務模型；圖4根據本發明實施例示意性圖解了利用X.500目錄技術實現的UDDI服務模型的基礎部件；
圖5根據本發明實施例示意性圖解了服務投影(ServiceProjection)；圖6根據本發明實施例示意性圖解了綁定模板和TModel之間的關係；圖7根據本發明實施例示意性圖解了TModel如何建立2個實體之間的關係；圖8根據本發明實施例圖解了增加發布者聲明的請求的邏輯表示；圖9根據本發明實施例圖解了UDDI數據對象的構造函數(constructor)的邏輯表示；圖10示意性圖解了將企業實體對象放在用戶對象下面的情況；圖11示意性圖解了將域對象放在用戶對象下面的情況；圖12根據本發明實施例示意性圖解了模式的概況；圖13根據現有技術示意性圖解了企業實體中的相對複雜對象的UDDI概念；圖14示意性圖解了企業實體中的相對複雜對象的Novell表示；圖15根據本發明實施例示意性圖解了引入層次結構以表示企業實體中的相對複雜對象的情況；圖16根據本發明實施例示意性圖解了綁定模板層次子結構；圖17示意性圖解了扁平化和/或合併的綁定模板子結構；而圖18是能夠實現本發明各個方面的計算機系統的模塊圖。
具體實施例方式
在描述附圖中圖解的本發明的優選實施例時，為了清楚而使用特定的術語。然而本發明不限於選擇的特定術語，應當理解，各個特定單元包含所有以類似方式工作的技術等價特徵。
圖18示出了可以實現本發明的方法和系統的計算機系統的例子。可以以在例如大型機，個人計算機(PC)，手持計算機，伺服器等等的計算機系統上運行的軟體應用的形式實現本發明的系統和方法。軟體應用可以存儲在計算機系統本地可訪問的記錄介質，例如軟盤，光碟，硬碟等等中，或者可以遠離計算機系統並且可通過針對例如區域網或網際網路的網絡的硬連線或無線連接來訪問。
圖18示出了能夠實現本發明的方法和系統的計算機系統的例子。通常稱為系統180的計算機系統可以包含中央處理單元(CPU)182，例如隨機訪問存儲器(RAM)的存儲器184，印表機接口186，顯示單元188，(LAN)區域網數據傳輸控制器190，LAN接口192，網絡控制器194，內部總線196和一或多個輸入設備198，例如鍵盤，滑鼠等等。如圖所示，系統180可以通過鏈路202連接到例如硬碟的數據存儲設備200。
下面總結了本發明實施例的一些顯著特徵，以及因而提供的一些優點。
根據本發明的實施例，在用戶之上建立資料庫層，因而每個資料庫能夠被放到不同的伺服器上。這個資料庫層包含共同形成目錄前綴(Directory pre-fix)的一或多個目錄節點。這也可以被稱作資料庫的′域′或′名字′。其優點在於提供單獨位置以保存關於域的信息。這個節點的名字表示目錄前綴。
可以建立用戶對象以保存表示UDDI帳戶的數據。其優點在於提供單獨位置以保存關於用戶/帳戶的信息。
企業實體對象可以被排列在用戶對象下面，企業服務對象可以被排列在企業實體對象下面，綁定模板對象可以被排列在企業服務對象下面。其優點在於用戶對象層之上的資料庫或′域′層允許將若干資料庫布置或邏輯連接在一起。域層可以按若干層次排列，例如使不同國家，即AU，US，EP等等按大陸組織。
另一個優點在於通過使用X.500目錄的分布特性可以為這個特徵提供效果。例如，為實現這個，′世界′或′公司′節點被放在虛擬目錄樹的頂端，並且唯一命名的節點被放在每個UDDI子樹(UDDI名字空間)的頂端。雖然對用戶不可見，然而這些′節點′前綴允許UDDI資料庫影響到(leverage)目錄分布。
根據本發明的實施例，可以使企業實體對象作為用戶對象的子節點。使用戶/帳戶在企業實體，企業服務和綁定模板層次上，提供了使每個用戶具有其自身的子樹的效果。這增強了可管理性和安全性。用戶被容易地限制於只修改和/或控制其自身的子樹。這也通過利用目錄子樹搜索操作增強了性能。
根據實施例，用戶定義的TModel可以作為用戶對象的子節點，於是使得安全性易於實現。由於用戶只能修改和/或控制其自身的子樹，這增強了可管理性和安全性。這也通過利用目錄子樹搜索操作增強了性能。
本發明的實施例表示利用X.500/LDAP目錄技術的UDDI環境的′映射′。尤其是，已經發現X.500和LDAP目錄技術的層次結構適用於UDDI環境。附加單元(例如用戶對象)的精心設計使得層次結構更加適合UDDI環境的需要。
在本發明中，術語目錄要包含X.500，LDAP和類似技術；術語′用戶′被理解為也包含′帳戶′，並且反之亦然；而術語′資料庫′被理解為也包含′目錄前綴′，′域′和/或′節點′，並且反之亦然。
WEB服務最初被認為是例如企業，夥伴，客戶，供應商的組織之間的服務。在這個環境中，UDDI被考慮為這些組織提供的服務的單獨資料庫。
現在顯然WEB服務和UDDI可用於企業內以在組織內集成應用。也顯然WEB服務和UDDI可用於在來自指定廠商的產品集合內集成產品。這同樣適用於商用環境以外的領域，例如政府部門，大型教育機構，和許多其它非商用實體的實例。
儘管針對的是企業，然而以下說明同樣適用於任何類型的環境，尤其適用於上述類型的環境。
企業UDDI註冊中心可以是這樣的服務，其能夠部署在企業內以發布供內部使用的信息和服務。另外，企業UDDI服務可以受到影響以提供其它功能，例如用於分布式應用的配置發現。
希望WEB服務能夠迅速和容易地在內部和與夥伴集成企業過程。有效利用WEB服務的一個部件是公共UDDI註冊中心，其允許軟體部件動態發現和連接到網際網路上的適當服務。WEB服務也提供能夠集成企業內的業務過程的承諾。在這種情況下，UDDI註冊中心可以變成組織的基礎設施的一部分(例如重要企業應用)，因此提供最高等級的安全性，性能，可靠性和可管理性。目錄技術提供理想基礎以支持企業UDDI註冊中心的嚴格要求。
企業UDDI註冊中心可以被定義成提供對UDDI的符合標準的支持，但是又進行超越以解決有關部署的4方面問題。這些方面包含將訪問僅限於授權用戶的安全性，支持大型部署的分布，用於真實生產系統的可管理性，和滿足服務等級協議的可用性。
強安全性可以是某些企業部署的重要要求。公共UDDI註冊中心的存在完全是為了幫助任一方發現可用服務。UDDI註冊中心的存在完全是為了使正確的人們發現這些服務。這是重要的區別。
網際網路UDDI註冊中心被認為對於在企業中部署WEB服務是不適當的。例如，接口到薪水系統或僱員收益管理應用的WEB服務的定義不會發布到網際網路UDDI註冊中心上。
安全性要求也可以意味著甚至內部部署的UDDI註冊中心也要提供強訪問控制。這是由於UDDI註冊中心基本上提供關於能夠做什麼和如何做的指導。UDDI註冊中心提供任何可用WEB服務的企業級的描述，並且對完全定義那些服務的編程接口的WSDL提供指示。這為應用開發人員以及黑客提供高生產率工具。
因此，期望限制對財務敏感或機密(例如醫藥記錄)系統的接口定義的訪問。甚至在開發組織內部，最好限制對關於授權的特定WEB服務的信息的訪問。
在企業內，或由選定企業成員通過企業外部網際網路使用非安全UDDI註冊中心是非常危險的。藉助可自由下載的工具，技能水平相對較低的人們能夠訪問和使用WEB服務。任何真正的企業解決方案均能夠以透明控制對有關WEB服務的信息的訪問的能力，實現標準UDDI服務。
對於分布，在許多情況下，UDDI註冊中心的初始部署將具有較小規模。然而隨著WEB服務需求的增長，通常會變成大型部署。另外，註冊中心的應用和部署會隨著UDDI註冊中心的新功能的發現而得到加速。
更大型的實現和地理上分布的組織內的使用會促使在單獨組織內實現多個UDDI註冊中心。向分布式註冊中心的演變使得任何個體註冊中心能夠與其它註冊中心動態交互以服務於其請求的能力變得重要。一旦被建立，註冊中心間的通信能夠擴展超出防火牆，以包含受信企業夥伴的註冊中心，或甚至與網際網路UDDI註冊中心通信。
考慮有2個基本方案以滿足註冊中心間通信的需要。一個方案是複製，其中多個伺服器上存在相同的名字空間項。另一個方案是分布，其中互連伺服器具有不同的名字空間項，然而它們提供一個邏輯服務。
儘管這2個方案經常被混淆為類似的，然而它們有相當的不同。
在複製方案中，在可能需要查找信息的每個伺服器中複製信息。這是相對簡單的，甚至過分簡單的解決方案，但是它引入了同步更新的需求，並且根據定義，它會隨著註冊中心數量和其內容量的增長而增加網絡阻塞。複製技術最適於伺服器數量較少，信息量較低並且很少改變的環境。對於企業部署，複製經常用於在故障恢復環境中維護備份資料庫。使用複製技術非常難以保持地理上或功能上分布的伺服器的同步。
在分布方案中，在每個參與的伺服器上邏輯表示信息，但是信息只存儲在單個註冊中心中。僅在需要時查詢才被分布到其它註冊中心。於是保證返回的信息是最新的。這提供了單點更新，並且消除了複製技術固有的同步和帶寬消耗問題。真正分布被認為是伺服器之間可伸縮連通性的一個解決辦法。
對於企業UDDI註冊中心，存在2種通常會使用分布的情況。第一種情況用於具有地理上分隔的辦公室的組織，其中每個辦公室產生新的UDDI項並且使用UDDI服務。雖然可能能夠運行單個的集中式UDDI註冊中心，然而帶寬約束和時差經常使得難以運行，以致不可工作。
分布式註冊中心提供靈活、可伸縮的解決方案。在這種情況下，每個參與的辦公室具有分立的註冊中心，並且每個註冊中心將其它註冊中心視為其自身內容的邏輯部分。註冊中心服務負責所有的連通細節，並且客戶不必關心地理問題。
第二種情景出現在企業需要將其內部UDDI系統連接到受信夥伴的UDDI系統或公共網際網路註冊中心時。尤其在公共註冊中心的情況下，複製是有問題的。網際網路註冊中心操作人員可能不希望將其註冊中心的部分複製到企業的內部註冊中心。於是，分布式方案是一個辦法。當前，沒有針對分布的UDDI標準，並且關於複製的建議被認為是複雜的。一個解決方案會提供UDDI分布式方案的益處，而無需修改標準。
對於可管理性，作為執行企業內的任務關鍵功能的部件，UDDI應當滿足性能和可靠性要求。它不應只是作為開發人員的方便實用程序而存在。客戶端的讀取訪問將是對UDDI註冊中心的最頻繁和時間要求最嚴格的應用。為最大吞吐率而優化性能，並且查找查詢的響應時間不應受更複雜搜索的影響。隨著註冊中心的規模和複雜度的增長，性能不應受影響。支持UDDI註冊中心的數據存儲應當是工業級的，並且完全支持事務和自動恢復。另外，UDDI伺服器應當具有高度可用性，並且支持例如網絡故障恢復和熱後備的特性。系統管理員應當有能力使得UDDI註冊中心易於維護，監視和控制。這些能力包含無需使服務脫機而改變控制，規則和設置的動態配置，用於高可用性的在線備份和調整，停止註冊中心″搜索″和防止拒絕服務攻擊的管理控制，經由SNMP或其它類型的提醒機構的監視，利用針對安全，統計，查詢和更新信息的分立日誌文件的審計和診斷，以及支持複製，分布和路由的部署選項。
已經引入了許多以開發人員為焦點的UDDI註冊中心。這些為小型開發團隊提供了有用的能力，但不是真正的生產級的系統。WEB服務部署正迅速增長，並且對能夠迅速升級以支持正在進行的WEB服務部署的企業級註冊中心存在相應的需求。
UDDI註冊中心提供服務。許多應用會依賴此服務。在在線企業的情況下，一起提供這個服務可能是重要的。例如，可能需要UDDI註冊中心提供99.99％可用性的服務等級協議。為了利於這個可用性水平，UDDI註冊中心可以複製在兩個或更多機器上，並且提供機制以確保機器保持同步，並且確保在任何機器變得不可用的情況下，任何傳入查詢被自動路由到可用機器。
如已經指出的，UDDI可以被看作類似於電話目錄服務。於是，最好基於信息存儲的目錄模型建立UDDI註冊中心服務。已經針對基於目錄的服務的特定需求演變和開發了目錄模型，其具有企業級部署所需的安全性，可伸縮性和可靠性。
在應用體系結構中，如上所述的大部分項目被實現在服務級，而不是數據存儲級。關係資料庫(RDBMS)是能夠藉以建立許多不同類型的應用的通用工具包。RDBMS實現側重於提供堅實的數據訪問功能，而不是終端應用中需要的額外服務功能。
圖3示出的目錄服務體系結構圖解了服務層31與其它部件的分離。將接口功能封裝到服務層31中，產生了可重用服務基礎設施部件。其一個極好的例子是Web伺服器。Web伺服器提供一個功能集合(HTTP訪問，CGI處理等等)，其共同構成足夠可用於建立到獨立部件中的服務。以相同方式，已經開發了目錄服務模型以提供特定類型的應用所需的功能。目錄技術提供對認證和授權領域的許多任務關鍵應用的支持。
UDDI可被視作類似於另一個類型的目錄服務。於是可以發現，通過使用目錄技術能夠解決UDDI產生的許多實現問題。例如，針對對於UDDI電話目錄操作而言非常普遍的非常高效的發現和搜索操作而優化目錄。
已經注意到，UDDI服務應當提供強安全性，分布和可管理性能力，如果它要成功部署在企業中的話。這些是已經建立到企業級目錄服務解決方案中的非常相同的屬性。
一個構造企業UDDI註冊中心的方式是擴展現有的目錄基礎設施，這種現有的目錄基礎設施已經在高性能真實世界應用中得到嘗試和測試。
目錄服務體系結構提供優化的工具以實現企業UDDI註冊中心。這種組合支持為成功而需要的能力。圖4示意性示出的UDDI服務標識出可以針對這個基礎設施實現的部件。UDDI語義橋41是介於UDDI的SOAP實現42和目錄44支持的LADP接口43之間的服務部件。目錄44傳送其中支持安全控制，分布機制和管理能力的信息訪問。RDBMS 45提供基礎物理數據管理，事務完整性和備份與恢復機制。
UDDI註冊中心產品可以直接建立在RDBMS技術上。儘管在許多方面都是非常有用和強大的，然而關係資料庫自身不滿足目錄處理所特有的要求。
使用RDBMS或下面的其它數據存儲系統能夠初步建立目錄型應用。然而這不可能是最高效的方案。
一個替代方案是應用目錄服務模型來建立UDDI註冊中心，並且提供這個特定類型的應用所需的功能。通過現代的工業級目錄服務甚至能夠提供更多UDDI註冊中心所需的功能。UDDI註冊中心可被視作具有專用通信和API的目錄服務。在目錄上建立UDDI服務能夠提供必備的安全性，分布和管理能力，而無需修改UDDI標準以獲得益處。
精心設計的數據表示會有利於提供UDDI資料庫所需的功能和性能。
以下描述涉及各個UDDI概念。參照UDDI規範(http//www.uddi.org/specification.html)可獲得這些UDDI概念的更加詳細的描述。
在目錄用語中，模式是有關目錄中能夠存儲的數據單元和那些單元如何可以被連接在一起的描述。這包含每個可能屬性(屬性保存單段數據)的描述，各個對象(對象是屬性的集合)的描述，和可能對象層次結構的說明。本說明書中使用的特定模式符號是eTrust目錄，即Computer Associates International公司的產品所使用的符號。′eTrust′是Computer Associates International公司的產品名稱和商標。當然，可以使用其它模式符號。
本發明描述用來通過使用目錄作為數據存儲來實現UDDI資料庫的模式。存在與這個模式有關的若干概念。也存在用來增強UDDI實現的操作的若干技術。以下是對這些概念中的一些的簡要描述。後面當描述本發明的實施例時會提供這些概念和技術的更加詳細的描述。
本發明的模式被設計成提供優化操作。以增強操作的方式實施本發明的模式設計，其包含屬性，對象類，項(entry)和層次結構的定義。本發明的模式設計至少在安全性，性能，可管理性和分布方面提供顯著的優點。
現在描述系統的層次結構。X.500目錄在內部支持分布，從而在無需UDDI層次的任何編碼的情況下提供分布式UDDI資料庫。層次分割資料庫的內容。這個模式的(可選)域層次假定該層次，每個域項和在其下面的全部項均能夠對UDDI層次編程透明地被放到分立目錄伺服器上。圖11圖解了本發明這個方面的實施例。下面會更詳細地對此進行描述。
根據本發明的實施例，用戶對象被放置在企業和TModel對象之上。用戶對象提供用於存儲涉及用戶的信息的位置。它也提供針對用戶發布的全部數據的錨標點(anchor point)。圖10圖解了本發明這個方面的實施例。下面會更詳細地對此進行描述。
這個域/用戶層次系統有利於安全性。UDDI實現能夠保證用戶具有對其數據對象子樹的控制。
提供對用戶控制的項的搜索。通過在用戶對象下面使用子樹搜索，能夠增強對這個用戶控制的數據的搜索。
通過例如指定在綁定模板中出現的TModel，可以發現企業。這等同於″通過發現一個(或更多)其子節點來發現x″。換言之，查詢可以是″發現具有一服務的所有企業，該服務具有引用這個模型的綁定模板″。通過發現派生對象的DN(區別名字)並且丟棄不期望的層次以產生企業實體的DN，進行這樣的查詢。
也可以通過這種方式進行複製消除。這個發現特性源於本發明的結構的層次性質。
可以使用對對象類唯一的屬性來執行搜索。這是具有2個優點的優化。這通過消除′弱′子句簡化了搜索的編寫，並且產生出眾的性能。′弱′子句是過濾器的一部分，其返回大量的項，或者是指作為許多項的一部分的屬性。對每個名字使用相同屬性名字的設計在按照名字對企業實體進行搜索時會具有2個選擇它在搜索中包含對象類，或過濾搜索結果。前者只在企業名字具有唯一對象類的情況下才可能出現，並且即使如此，對象類仍是弱子句，從而導致更多開銷。後者意味著額外的代碼，和返回遠大於期望結果的結果列表的可能性。
例如，考慮稱作″McKenna的測試服務″的公司，其提供各式各樣的WEB服務，所有的WEB服務均在其名字中包含″McKenna的″-以在其名字中具有″McKenna的″為條件對企業實體進行的搜索會返回全部服務的中間結果。這些中間結果可以被消除，但是處理它們降低了性能。
最好能夠在搜索中指定屬性名字，並且使該屬性名字唯一標識正搜索的對象類。繼續上述例子，如果我們能夠進行以下指定，則搜索會更加簡單(euBusinessEntityName＝McKenna′s*)這樣的設計產生強搜索，由於它們單純搜索期望區域，因而是高效的。強搜索包含返回少量項的搜索。目錄能夠索引euBusinessEntityName屬性，並且根據該索引返回結果-這產生良好的性能，並且避免處理不必要的中間結果。
對於簡單查詢，這樣的設計意味著針對企業實體名字的搜索是單個子句，而不是在另一個設計中可能必要的複合子句。想像如果名字屬性被稱作euName，並且企業實體名字對象被稱作euBusinessEntityName。這會產生以下搜索((euName＝McKenna′s*)(oc＝euBusinessEntityName))
存在甚至更加簡單的設計，其中所有名字被存儲在相同對象類中。這意味著搜索再次縮減到(euName＝McKenna′s*)，但是現在我們遍歷所有名字的結果，以嘗試找到那些具有作為企業實體的父對象的結果-這個最後設計可能會產生不良性能，和更加複雜的編程。
影像屬性(shadow attribute)可以被用於大小寫敏感(case-sensitivity)。使用單個索引提供大小寫敏感和大小寫不敏感的搜索完全不是無效的。一個選擇是大小寫不敏感地進行索引，接著大小寫敏感地掃描結果。另一個解決方案是大小寫敏感地索引原始數據，並且增加大小寫不敏感地被索引的第二屬性(其中存儲相同數據)。於是需要做的只是選擇適當屬性以根據發現限定條件進行搜索。
這個設計中的每個屬性可以是單值的。這允許高效索引，更高性能和更強搜索。
使用多值屬性使得能夠進行模糊搜索。也就是說，可以得到不直觀和不期望的搜索結果。假定一個稱作′n′的多值數字屬性，並且包含這個屬性的項具有值2和5；這個項會響應搜索((n＜3)(n＞4))而被返回，這不是容易預測的。
單值屬性是用於強搜索的技術之一。強搜索是能夠通過索引消除大多數候選結果的搜索。強搜索是改進性能的關鍵。
別名可以被用於服務投影。這是使用X.500目錄作為數據存儲的顯著益處。能夠使用X.500別名巧妙地表示服務投影。這是保證數據完整性的主要優點。別名訪問原始數據，所以通過別名立即反映對原始數據的任何改變。如果目錄實現支持別名完整性，則當原始項被刪除時，別名無需附加工作便會消失。
發布者聲明是UDDI標準中定義最不清楚的元素之一，它們需要精心的設計。不適當的實現能夠容易地產生不良的性能。
由於發布者聲明的最通常的使用是搜索涉及指定企業實體的所有完整發布者聲明的find_relatedBusiness API，將每個聲明放置在其所針對的企業實體下面會是良好的設計。
通過計算聲明的狀態並且在聲明對象中存儲該狀態，可以將搜索限於完整發布者聲明。這意味著返回的結果不會包含要清除的虛假引用。
將關係對象存儲為輔助類允許搜索消除具有不期望關係的任何聲明。如果關係被存儲為子對象，則不能編寫出訪問到關係和聲明完成狀態的單個搜索。
UDDI關鍵字可以被用於對存在的目標進行命名。UDDI對許多重要對象類定義了關鍵字，並且這些關鍵字被指定為保證唯一。這意味著關鍵字能夠被用作對象的名字屬性。使用UDDI關鍵字作為名字屬性意味著不必嘗試消除命名衝突-而在例如預設名字被用作企業實體的名字屬性的情況下會需要消除命名衝突。
可以提供關鍵字以對不存在的目標進行命名。也就是說，不是所有的UDDI對象都具有定義的關鍵字。一個例子是發布者聲明。對於這些，本系統使用與UDDI定義的關鍵字相同的算法提供關鍵字。這個思路的重用意味著能夠重用針對其它對象編寫的代碼和結構。
在一系列UDDI對象是另一個對象的子對象並且子對象的順序是重要的(例如地址行(address lines))的情況下，分配給子對象的關鍵字被構造成其值單調增加，使得對關鍵字的排序產生期望的順序。這簡化了保證期望順序的處理。
實際上，期望關鍵字按照由小到大(little-endian)的方式發生改變。也就是說，關鍵字的最左字節改變最迅速，因為這在被用作數據存儲的X.500目錄中產生最優的索引性能。
UDDI標準在一些主對象類型內定義若干子結構。在許多情況下，這些子結構是可選的，並且可以重複(它們在相同對象中可以出現零次，一次或不止一次)。一個簡單例子是名字子結構，包含串(名字)和語言標識符。X.500模式定義不支持結構化屬性的使用，所以不存在現成的、清楚的子結構映射。
存在一些能夠在X.500模式中實現這些子結構的方式。
一種方式是通過使用某種分隔符分割各個元素，從而將子結構的成分串聯成單個屬性。這可能是最優的設計選擇，因為它失去分別索引或搜索成分的能力，並且增加了處理複雜度以處理數據。
在本系統中，選擇用來表示子結構的特定設計以使性能和可管理性最大化。所公開的設計可以使用各種技術中的一或多個表示目錄中的子結構。這些技術可以被概括為3個類別。
一個技術是將許多子結構處理為子對象。名字是良好的例子企業實體名字被存儲為企業實體的子對象。另一個例子是描述，其中單獨的企業描述對象是企業實體對象的子對象。圖15提供了關於本發明這個方面的實施例的說明，並且會在下面更詳細地加以描述。
另一個技術是扁平化/合併。在可能最多存在一個針對另一個對象的關係的情況下，屬性可以被合併成一個單獨的對象。在這種情況下，層次結構被稱作是扁平化的，因為2個對象已經合併成一個對象。新對象被稱作是合併的，因為新對象包含來自組合對象的屬性的組合。關係對象的內容最好被提升到父對象。
例如，圖16示意性圖解了UDDI關係圖的表示。圖17示意性圖解了目錄層次結構圖，其中通過UDDI對象的扁平化形成了目錄層次結構。
通過說明，圖16圖解了具有針對對象163的關係對象162的對象161。
根據本發明的實施例(其中存在一對一關係)，′子對象′能夠得到提升。換言之，該部分層次結構能夠被縮減或扁平化，並且對象被合併。圖17示意性圖解了結果。父對象171具有內容A1，A2，An，並且具有一或多個子對象，即子對象9n，其具有內容B1，B2，Bn，C1，C2和Cn。
另一個技術是分割。例如，在一個特定情況(OverviewDoc子結構)中，子結構包含非重複單元和重複單元。非重複單元(OverviewURL)能夠移入父對象，而重複單元可以成為子對象。
本發明的另一個方面是管理。刪除TModel使得將其從find TModel隱藏掉，但是不將其從資料庫中清除。因此，為實現正確的TModel處理，可以實現隱藏標記。這個標記的存在指示TModel(或用戶對象)被隱藏。標記的不存在指示它沒有被隱藏。對於絕大多數TModel均是如此，所以這個方案是高效的。非隱藏對象中沒有佔用空間，並且也不使用索引。目錄會只索引那些具有隱藏屬性的項。這也意味著對非隱藏TModel的搜索會是快速和高效的。
被用作數據存儲的X.500目錄促使產生不存儲空值的設計。例如，對象中不存在的(可選)值不存儲在目錄中。這使得高效使用存儲空間，並且得到更強搜索。任何對屬性的搜索只需要考慮那些具有該屬性的數據的對象。
本系統的數據層次結構很好地與UDDI標準的意圖相匹配。當請求到達以刪除UDDI對象時，它直接映射到目錄中子樹的刪除。例如，刪除服務包含刪除其名字和描述，以及全部其綁定模板。所有這些均是目錄中的服務項的子對象。因此，本系統自服務項向下刪除子樹。這容易實現並且高效。
域是表示層次子樹的基部的名字。在X.500術語中，域被稱作上下文前綴。在LDAP術語中，它被稱作後綴。為UDDI資料庫提供域名允許在資料庫中使用數據的真正分布(就X.500而言)。UDDI標準僅支持複製。通過本系統能夠對應用透明地使用目錄分布設備。
例如，假定企業內部部署UDDI，但是具有2個開發位置。對於此設施，它們能夠在每個位置部署UDDI伺服器，其中分布允許每個位置透明地觀看兩個註冊中心上發布的項目。
其優點是允許分布′免費(for free)′。例如，UDDI伺服器不必進行任何額外工作，並且目錄系統有效地將信息島連結在一起。
UDDI標準中沒有規定如何存儲用戶信息。通過建立用戶對象，涉及用戶的全部信息能夠被存儲在一個單獨的對象中，並且該對象能夠被用作保存用戶發布的全部對象的子樹的根。這使得安全性的定義更加簡單。例如，如果所考慮的對象(企業，服務或甚至TModel)在用戶的用戶對象下面，則用戶控制它。
UDDI定義包含重複單元的對象。對於例如性能，可搜索性和可管理性的益處，這些重複單元能夠被表示成子對象。
將重複的結構化數據存儲為子對象允許在目錄中高效地表示數據，其中每個欄位分別可用於搜索(和為搜索而索引)。
例如，企業實體名字能夠被存儲為企業實體對象的子對象。另一個例子是能夠被存儲為企業實體對象下面的子對象的企業描述。
這類系統的優點是允許搜索名字(是常見的UDDI搜索)，並且該項的DN提供名字屬於的對象的DN。
UDDI定義冗餘′容器′節點(只包含子對象子結構而不是屬性的UDDI結構)。這些可以被從查詢結果中清除，因為它們能夠以相對較低的成本構造。在某些情況下，屬性能夠被從子節點提升到其父節點，以從目錄表示中清除現在冗餘的子節點。
例如，由於不包含屬性，在目錄模式中不表示tModelInstanceDetails。象其子對象OverviewDoc的屬性那樣，由於其屬性被提升到tModellnstancelnfo父對象，在目錄模式中不表示instanceDetails。在目錄中不表示類別和標識符包(bag)，使其內容作為包的所有者的子對象。
其優點是減少了目錄中項的數量。尤其是，它使DIT的深度最小，從而能夠改進性能。
圖12根據本發明實施例示意性圖解了層次結構。提供一或多個域或前綴121。在每個域121下面，可以有一或多個用戶122。在每個用戶122下面，可以有一或多個TModel 123和一或多個企業實體(BE)124。在每個企業實體124下面，可以有一或多個發布者聲明(PA)125，一或多個企業服務(BS)126和一或多個服務投影(SP)127。在每個企業服務(BS)126下面，可以有一或多個綁定模板(BT)128。通過特定實現，能夠根據需要放置別名。例如，服務投影對象(如圖12中三角所示)可以從企業實體對象生出以作為別名。
通過讀取整個公開內容可理解如圖12所示的這個模式設計的優點。
發布者聲明被放置在它們所針對的企業實體下面，因為它們在find_RelatedBusinesses調用的環境中最頻繁使用，所述調用指定企業關鍵字，並且正經由發布者聲明尋找與企業關鍵字相關的所有企業。本系統找到指定的企業，接著讀取它下面的所有發布者聲明(是完整的)。這是找到相關聲明的快速和高效的方式。
其優點是允許快速和高效的搜索。它也允許容易地維護數據完整性。例如，當刪除企業時，任何發布者聲明也被自動刪除。
發布它們的用戶能夠改變(或撤消/隱藏)TModel。將它們放置在表示用戶的項下面使得安全性變得簡單。例如，如果TModel位於用戶項下面的子樹中，則能夠修改它。如果不是這樣，則不能修改。
更詳細地，如果嘗試進行改變的用戶的DN(區別名字)與TModel的DN的前綴匹配，則該用戶能夠修改該項，否則不能。目錄能夠被用來進行這個確定(如果DN不存在，則發生命名異常)，UDDI伺服器也能夠進行這個確定。
當從資料庫中刪除對象時，與該對象相關的信息也可以被刪除。通過根據本模式的實施例使用的層次設計可對此進行大大簡化。當刪除對象時，能夠刪除以其為根的整個子樹，並且這個處理能夠刪除所有相關信息(並且通常只刪除該相關信息)。能夠自底向上地刪除子樹。當刪除所有其子對象時，只能刪除每個項。通過按照相反DN順序列出所有子對象來對此進行管理。這保證刪除在其父對象之前的子對象。
其優點是排序列表方法是更加複雜的遞歸使用的替代。此外，它相對簡單和存儲器高效。當按照DN對子樹中的所有項進行排序並且以相反順序執行刪除時，這保證在其父對象之前刪除所有子對象。
例如，當刪除企業服務時，系統刪除與之相關的所有綁定模板，其TModel實例信息，和各種相關類別信息。通過刪除以企業服務為根的子樹，可以刪除所有這些。
由於這個模式的設計中使用的層次結構，對象的DN揭示了所有關係鏈和對象的控制。注意，推論也取決於名字屬性的精心選擇。
其優點是能夠減少用來收集信息的搜索或讀取的數量。例如，對於作為子對象(例如名字)的搜索結果，每個項的DN揭示出父對象(例如企業實體)和所有者帳戶。
例如，企業服務的DN揭示出它屬於的企業，以及控制它的用戶。
目錄不保證結果的任何順序。當處理複雜結果(例如企業實體及其企業服務，以及其適當名字和描述)時，通過得到搜索結果並按DN對其排序，能夠簡化輸出的構造。這對它們進行組織，使得結果的構造變得相對簡單。在其子對象之前構造每個對象，所以易於將子對象放置在其父對象下面，使得在其服務之前組織企業的結果。對象的所有子對象出現在相同類型的下一對象之前，一個企業的全部服務在下一企業出現之前。這也允許簡單的遞歸構造，因為相同的道理適用於每個層次。
其優點是使構造UDDI結構所需的遍歷原始項列表的次數最小。
例如，在排序之後，企業A的結果後面跟有其第一服務AA的結果，該服務的名字，A的第二服務AB，及其名字，接著是第二企業B。
也可以對子對象執行搜索。例如，頻繁搜索請求可以是″通過發現一個(或更多)其子對象來發現x″。通過搜索能夠發現企業的一個方式是指定例如綁定模板中出現的TModel。換言之，查詢是″發現具有一服務的所有企業，該服務具有引用這個模型的綁定模板″。通過發現派生對象的DN並且丟棄不期望的層次以產生企業實體的DN，能夠進行這些查詢。有利的是，這也消除了複製。這個搜索方法部分源於本發明實施例的層次結構。
保證唯一的關鍵字的使用簡化了工作。能夠針對單個關鍵字搜索整個資料庫，並且唯一性保證或者沒有結果(如果不存在該關鍵字)，或者有一個結果(如果它存在)。不必費心將搜索限制在父對象的範圍內。這由目錄產生增強的性能，因為它能夠使用資料庫索引進行優化。
其優點是利用了最快速類型的目錄查詢。另一個優點是在從另一個對象引用指定對象的情況下，保證唯一的名字是重要的。
多數索引系統的特性在於它們是數據相關的。如果數據是″從小到大的″(最左部分最迅速地改變)，則該數據往往被擴展，所以索引能夠提供最大性能。反之，如果數據是重複的，則索引不能非常有效。能夠使用UUID(全局唯一標識符)算法，其表現出″從小到大″特性。其優點是使目錄性能最大。
關鍵字可以被加到導出對象上。在重複數據單元被加到子對象的情況下，需要增加名字屬性，這會形成其DN的最後的弧。在目錄中，名字屬性不同於其兄弟對象，因為相同父對象的任意2個子對象均不會具有相同名字。
可以使用兩種關鍵字。對於不要求順序的子對象，使用UUID，因為這些被保證是唯一的。如果順序是重要的，則具有單調增加特性的關鍵字被用來保證順序。
在UDDI標準中，企業實體能夠提供兩種服務它控制的服務(在資料庫中通過子對象表示)，和它對其提供接口的服務，儘管它們由另一個企業實體提供。在公開的UDDI資料庫中通過別名表示後者。別名確切地提供正確的特性。例如，如果其所有者以某種方式改變初始對象(服務)(或許增加另一個綁定模板)，則通過別名引用的對象也″改變″。此外，在企業實體下面對服務的任何搜索會產生真實和帶別名的服務。
例如，別名能夠被用於服務投影，其中企業能夠指向另一個企業下面定義的服務。
其優點是起作用的別名允許基本上涉及要自動提供的″替代名字″的功能。此外，如果目錄支持別名完整性，則如果刪除原始服務，那麼任何投影會被自動清除。
在UDDI標準中，存在若干地方，其中我們不希望直接引用到另一個對象，而是希望引用到中間步驟-例如在TModel實例信息的情況下，或是引用到發布者聲明中的企業實體。在這些情況下，別名會使代碼複雜。因此，本系統可以使用對對象的引用。因為根據實施例的本系統保證每個對象具有唯一關鍵字，則該關鍵字確切充當引用，有時被稱為″外″鍵。
能夠使用輔助對象類執行屬性分組。在處理髮布者聲明時，需要使用唯一標識發布者聲明的3個屬性2個企業實體關鍵字，和其間的關係找到發布者聲明的能力。
然而，關係被指定為鍵值標識引用(keyed reference)，其自身是3個不同屬性TModel關鍵字，鍵名和鍵值。一種方式是將這個關係存儲為發布者聲明的子對象。然而這不允許對特定發布者聲明進行最高效的搜索。通過使關係鍵值標識引用(relationship keyed reference)作為發布者聲明項的輔助類，可以在單個搜索中搜索所有5個屬性，於是確切隔離出所需的發布者聲明對象。
這個模式的一個設計可以使用普通面向對象設計技術，並且產生例如具有相同屬性名字的所有鍵值標識引用。然而，這個設計會使得更加難以隔離例如企業實體類別鍵值標識引用和避免使其與TModel類別鍵值標識引用的混淆，並且使之成本更高。也會使得有必要在過濾器中包含對象類項，並且這樣的項是弱的(在資料庫中高度重複)。
例如為每個不同類型的鍵值標識引用提供不同對象類和不同屬性名字意味著對特定屬性名字的任何搜索有必要隱含對象類。也意味著目錄伺服器能夠構造這樣的索引，該索引只在其中具有針對特定類型的期望項的項。這種索引會更小並且因此更快速。
例如，類似″euBusinessEntityName＝Smith*″的搜索會查詢針對euBusinessEntityName的索引，所以不能與在稱作euTModeIName的屬性中包含Smith的項混淆。
這需要UDDI標準範圍以外的工具。這種工具可能需要提供進行超出UDDI標準中指定的範圍的訪問的手段。為允許這種工具，本發明定義抽象類，抽象類綁定表示單個UDDI概念的所有對象類。這允許定義能夠查看例如所有名字或所有鍵值標識引用的搜索。
例如，存在抽象類euName，它是包含euBusinessEntityName和euTModeIName的所有名字型對象類的超類。
UDDI標準規定可以以例如大小寫敏感和大小寫不敏感的方式搜索名字。這可以通過大小寫不敏感地進行索引，並且接著檢索各個項並且大小寫敏感地對其進行檢查來實現，但是這種方案以性能為代價。在這些情況下最好定義包含相同數據但是被不同索引的影像欄位。類似地，影像屬性能夠被用於語言中的變化，例如可區別標記。
例如，euBusinessEntityName對象類包含每個名字的2個拷貝。大小寫不敏感地索引第一版本，大小寫敏感地索引第二版本。這允許構造無論請求何行為均最優執行的搜索過濾器。
這個資料庫中的每個屬性(對象類之外)可以是單值的。這使得目錄能夠構造更加高效的索引，並且提供更好的搜索性能。
這也排除了搜索中產生虛假肯定結果的可能性。例如，考慮尋找以″Fr″為開始並且以″nk″為結束的名字的搜索。可能預計這個搜索會產生具有類似″Frank″的名字的(有效)項。然而如果名字為多值屬性，則會得到具有類似″Fred″和″Tink″的2個名字的無效項，因為這一個項與兩個規定的準則匹配。通過使用單值名字(其每個是項的子對象)，可排除″Fred″和″Tink″的虛假匹配。
操作屬性是由UDDI應用管理但是用戶不可見的特殊屬性。
在UDDI數據的存儲中，應當能夠具有將使用中的TModel與已經″撤消″的TModel區別開的方式。當TModel被刪除時，它仍然會被通過許多使用，所以它不能被真正刪除。而是將其隱藏，這意味著它不會作為find_TModel調用的結果的一部分被返回，而是仍然能夠通過get_TModelDetal調用來查詢。這通過使用稱作euHidden的屬性來實現，該屬性被加到被隱藏的TModel中。向搜索TModel的任何過濾器中增加排除包含euHidden屬性的任何項的搜索步驟是有好處和高效的。
在目錄實現中，具有主要為一個值的屬性通常被認為是非常低效的。例如，99％的項具有被設置成假的隱藏屬性會產生不良性能-索引會相當多地不可用。
被認為是更多有效的方式是沒有隱藏屬性地存儲大多數項，並且只向要隱藏的那些項增加屬性。這具有不需要存儲空間保存所有那些″假″值的附加好處。現在，用於發現所有那些不被隱藏的TModel的過濾器變成″(！(euTModel＝*))″-這是存在測試的否定，並且存在測試是快速的，尤其是當屬性只存在於小部分的項中時。
現在描述用於解決在目錄環境中的實現和UDDI標準的問題的本發明實施例。存在若干針對X.500模式的元素。這些元素包含屬性定義，對象類定義和名字綁定定義。屬性定義規定單個數據單元，從而為其指定唯一標識符(OID)，名字和數據類型。對象類定義規定作為整體操作的屬性集合。它指定唯一標識符(OID)，名字和屬性列表；屬性可以是所需的或可選的。名字綁定規定可能的層次結構的部分。名字綁定規定可以存儲在另一個對象類下面的一個對象類，並且規定子對象的屬性(多個屬性)，它在這個上下文中命名該子對象。
存在若干提出附加設計要求的發現限定符。一個發現限定符是大小寫敏感性，用於提供以大小寫敏感和大小寫不敏感的方式高效搜索文本數據的能力。
根據本發明的實施例，通過在對象中提供不同索引的附加欄位能夠解決大小寫敏感問題。根據這個實施例，文本數據在類型caseExactString的屬性和類型caseIgnoreString的屬性中被存儲兩次。發現限定符確定搜索的欄位，從而產生最大性能。
例如，如果企業實體具有類似″McKenna′s Iron FoundryServices″的名字，則該串會被存儲兩次，一次是在大小寫敏感地索引的欄位中，一次是在大小寫不敏感地索引的欄位中-存儲的數據相同，但是基礎目錄所產生的索引不同。
另一個問題涉及高效實現服務投影。根據本發明的實施例，可以使用X.500別名設施解決這個問題。存在若干能夠處理服務投影的方式。本發明的這個實施例通過目錄別名處理它們。這是實現它們的特別高效的方式。它保證投影與基服務的一致性，因為通過別名直接訪問基服務。它也保證投影會在刪除基服務時消失，於是保證一致性。
例如，如果稱作Williams會計服務的企業實體發布稱作總帳交叉核對的WEB服務，並且希望在稱作Williams審計服務的第二企業實體下面提供這個相同服務，這可以通過將別名項放置在第二企業實體下面來實現。列舉Williams審計服務提供的服務的查詢方會發現總帳交叉核對服務，就象其會發現Williams審計服務直接提供的任何服務那樣。
另一個問題涉及高效實現關鍵字。根據本發明的實施例，這通過使用外部關鍵字和其中順序不重要的關鍵字的UUID來解決。在順序很重要的情況下可以使用序號。儘管關鍵字被表示成串，然而它們不是真正的文本數據。在對大小寫或可區別標記不敏感的情況下對其進行比較。
外部可見的關鍵字遵循一組規則。當實現符合UDDI規範的版本2的資料庫時，它們保存符合ISO-11578的UUID。當實現符合UDDI規範的版本3的資料庫時，它們保存遵循該版本規範中設定的規則的鍵串。
注意，內部用來將單元連結在一起的關鍵字遵循另一個組規則。那些順序不重要的關鍵字使用UUID。在順序很重要的情況下使用序號。
例如，表示稱作Williams審計服務的企業實體的類別包的單元的鍵值標識引用可以引用具有關鍵字12345678-1234-1234-1234-1234567890ab(UDDIv2)的TModel。類別包中鍵值標識引用的順序不重要，但是鍵值標識引用需要充當對象的名字屬性的關鍵字。於是我們可以產生這個對象的有些類似於87654321-4321-4321-4321-ba0123456789的UUID關鍵字，並且使用其作為這個對象在目錄中的名字屬性。
另一個問題是在期望X.500分布的情況下，數據可以被組織到域中。根據本發明的實施例，這通過在用戶之上建立資料庫層來解決，因而每個資料庫能夠被放到不同的伺服器上。
UDDI標準不允許名字空間是分布式的。這意味著通過複製或通過透明地具有管理分布式名字空間的後臺數據存儲，多個UDDI註冊中心能夠彼此配合操作。
具有名字前綴的每個資料庫能夠利於分布式名字空間。這個前綴是定義域的一組節點。這些節點能夠被認為是每個UDDI註冊中心之上的資料庫層。這些節點被放置在用戶層之上。
圖11圖解了稱作″域″110的這種節點的例子。域110是目錄前綴，並且可以包含直至根的一或多個節點。在域110下面，這個例子圖解了例如若干用戶112，113和114的排列。根據本系統的特定配置和/或用途，可以改變域110下面排列的用戶的數量。也可以存在根據本系統的特定配置和/或用途而排列的若干個域。在下面的例子中，它們被稱為資料庫對象，表明它們表示分立的物理資料庫。當然，根據本系統的配置和/或用途，也可以不必如此。
資料庫對象需要名字屬性，但僅此而已。
set object-class uddiObjectClass400＝{#資料庫-可以用於將用戶分成組name＝euRepositorysubclass-of topmust-containeuRepositoryName}；分布是大規模目錄部署中的重要概念，因為它允許多個節點共享數據，但沒有巨大的帶寬開銷和複製的同步問題。
在一個實施例中，′eTrust′UDDI支持使用基礎eTrust目錄伺服器的能力的分布，並且為此相應構造了模式，其中允許在樹層次結構的頂端有虛擬′域′節點，並且在每個節點子樹的頂端有唯一節點標識符或名字(參見下面的UDDI模式描述)。
此外，通過配置可以使eTrust UDDI伺服器′了解分布′。能夠指定2個分立的目錄前綴-一個用於搜索和讀取，另一個用於增加項。為部署分布式伺服器，按照eTrust目錄管理指南為分布而構造基礎eTrust目錄伺服器代理。每個分立eTrust UDDI節點配有唯一節點名字。每個節點的搜索/讀取前綴被設置成′世界′或′公司′節點名字。每個節點的增加前綴被設置成該節點的唯一名字。
通過這種方式，每個節點向其自身的目錄資料庫增加項，但是通過X.500目錄的分布特性在所有節點上搜索項。
資料庫對象的例子可以是
euRepositoryName＝Melbourne另一個問題涉及組織所保存的有關用戶的數據。這可以通過建立用戶對象以保存數據來解決。
儘管UDDI規範中沒有規定用戶對象，然而可以根據本發明的實施例使用這種對象。例如，除其它以外，用戶對象可以是用戶證書的存儲點，和用於發布的錨標點。
圖10圖解了稱作′用戶′101的這種結構的例子。在用戶101下面，這個例子圖解了其它對象，例如企業實體對象102，企業服務對象103和綁定模板對象104的結構。根據本系統的特定配置和/或用途可以改變用戶101下面排列的企業實體對象的數量。也可以存在根據本系統的特定配置和/或用途而排列的若干個用戶。
用戶對象中保存的數據單元包含用戶關鍵字(用來提供這個用戶帳戶的唯一名字)，用戶名稱，和證書(可以如口令那樣簡單，或如PKI證書那樣複雜)。它也可以包含授權名字(標識授權操作用戶帳戶的人員或角色)。它也可以包含在處理用戶帳戶的刪除但不丟失用戶定義的任何TModel時使用的隱藏標記。
set object-class uddiObjectClass401＝{#用戶帳戶name＝euUserAccountsubclass-of topmust-containeuUserKey，euUserName，euCredentialsmay-containeuAuthorizedName，euHidden}；用戶帳戶對象的例子可以是
euUserKey＝23456789-2345-2345-2345-234567890abceuUserName＝GraceeuCredentials＝Amazing76sQ(在這個例子中假定已經實現簡單的userid和口令系統)另一個問題涉及以高效方式表示涉及企業實體(UDDI標準中描述的對象類)的數據。根據本發明的實施例，通過將唯一欄位表示為對象的屬性並且將重複單元表示為子對象來解決此問題。
企業實體對象是UDDI標準的基本成分。其內容由標準定義，但是其許多單元是X.500模式不支持的重複複雜對象。通過層次結構表示這種單元。
企業實體中唯一需要的單元是企業關鍵字。可選單元包含授權名字，操作人員和用戶關鍵字(這最後會出現在普通用戶發布的企業實體中)。
set object-class uddiObjectClass402＝{#企業實體-提供服務的實體的細節name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，euAuthorizedName，}；企業實體的可能子對象是名字(為排序而加鍵值標識、包含名字串和語言代碼的對象)；描述(為排序而加鍵值標識、包含描述串和語言代碼的對象)；聯繫(複雜對象-以後描述)；發現URL(包含URL串和使用類型的對象，加鍵值標識)；通過選擇對象類而被標記為類別或標識符信息的鍵值標識引用；和企業服務(如下所述)。
企業實體對象的例子可以是
euBusinessEntityKey＝34567890-3456-3456-3456-34567890abcdeuParentUserKey＝23456789-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-containeuBusinessServiceKey，euParentBusinessKey}；沒有企業服務對象的可選內容。所有其它內容包括可能的重複單元，所以被表示成子對象。企業服務的潛在子對象是綁定模板(見下文)；名字(為排序而加鍵值標識、包含名字串和語言代碼的對象)；描述(為排序而加鍵值標識、包含描述串和語言代碼的對象)；和標記為類別信息的鍵值標識引用。
例如，企業服務對象可以是euBusinessServiceKey＝4567890a-4567-4567-4567-4567890abcdeeuParentBusinessKey＝34567890-3456-3456-3456-34567890abcd注意，企業服務對象的大部分明顯內容實際被存儲在作為企業服務對象的直接子對象的對象中。
儘管圖15根據本發明實施例圖解了引入層次結構到子結構中以表示企業實體中相對複雜對象的例子，然而它同樣圖解了根據本發明實施例將層次結構引入到子結構中以表示企業服務中相對複雜對象的例子。圖15的企業實體151同樣適用於企業服務，其中企業服務的多值單元被表示成企業服務151的子對象152，153。可以沒有子對象，也可以有更多的子對象。
另一個問題涉及以高效方式表示涉及綁定模板(UDDI標準中描述的對象類)的數據。根據本發明的實施例，通過將唯一欄位表示為對象的屬性並且將重複單元表示為子對象來解決此問題。
綁定模板表示可以訪問具體服務的方式。唯一需要的綁定模板的單元是其關鍵字，和它應用到的服務的關鍵字。可選單元可以包含接入點或駐留重定向器(對象應當確切具有其中的一個)。如果提供接入點，則也應當提供接入點類型。
set object-class uddiObjectClass404＝{#綁定模板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.
再次地，儘管圖1 5根據本發明實施例圖解了引入層次結構到子結構中以表示企業實體中相對複雜對象的例子，然而它同樣圖解了根據本發明實施例將層次結構引入到子結構中以表示綁定模板中相對複雜對象的例子。圖15的企業實體151同樣適用於綁定模板，其中綁定模板的多值單元被表示成綁定模板151的子對象152，153。可以沒有子對象，也可以有更多的子對象。
另一個問題涉及以高效方式表示涉及TModel(UDDI標準中描述的對象類)的數據。根據本發明的實施例，通過將唯一欄位表示為對象的屬性並且將重複單元表示為子對象來解決此問題。
TModel表示一個思路。該思路可以是例如分類系統，從而需要指定可以確認的值。它也可以是數據通信協議規範。TModel是靈活和強力的概念，並且以UDDI以能夠精確查詢的方式表示複雜數據的能力為中心。
唯一需要的TModel對象的單元是TModel關鍵字和名字。這些被表示成串。
TModel對象的可選單元是授權名字，概述URL(概述文檔對象的部分)，用戶關鍵字和隱藏標記。
隱藏標記是TModel的處理的單元。隱藏標記是如何處理deleteTModel調用。當TModel被″刪除″時，隱藏標記被加到對象中。這意味著不會向findTModel調用返回對象，但是可被getTModel調用訪問。
set object-class uddiObjectClass405＝{#tmodel-對概念的引用name＝euTModelsubclass-of topmust-containeuTModeIKey，euTModeiNamemay-containeuAuthorizedName，euOperator，euOverviewURL，euParentUserKey，euHidden}；可能的子對象是描述(為排序而加鍵值標識、包含描述串和語言代碼的對象)；標記為類別或標識符信息的鍵值標識引用；和概述文檔描述(為排序而加鍵值標識、包含描述串和語言代碼的對象)。
TModel的例子可以是
euTModelKey＝uuid67890abc-6789-6789-6789-67890abcdef1euTModeiName＝Corporate QA PolicyeuOverviewURL＝http//www.rsps.com.au/policy/qa.htmleuParentUserKey＝23456789-2345-2345-2345-234567890abc再次地，儘管圖15根據本發明實施例圖解了引入層次結構到子結構中以表示企業實體中相對複雜對象的例子，然而它同樣圖解了根據本發明實施例將層次結構引入到子結構中以表示TModel中相對複雜對象的例子。圖15的企業實體151同樣適用於TModel，其中TModel的多值單元被表示成TModel151的子對象152，153。可以沒有子對象，也可以有更多的子對象。
另一個問題涉及以高效方式表示涉及發布者聲明(UDDI標準中描述的對象類)的數據。
根據本發明的實施例，通過將唯一欄位表示為對象的屬性並且將輔助類用於所需關係鍵值標識引用來解決此問題。
發布者聲明是表示2個企業實體之間的關係的對象。
發布者聲明的所需單元是其關鍵字，到達和來自企業(to andfrom business)和用戶關鍵字，狀態和關係。關係被指定為鍵值標識引用，並且被存儲為發布者聲明項的輔助類。狀態被存儲為串，但是從完成狀態對象提出其可能的值。所有關鍵字被表示成串。
set object-class uddiObjectClass406＝{#發布者聲明-兩個企業之間的關係name＝euPublisherAssertionsubclass-of topmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinesKey，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，並且會指定在所命名的2個企業實體之間聲明的關係。一個例子可以是euPublisherAssertionTModel＝uuid807A2C6A-EE22-470D-ADC7-E0424A337C03euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child另一個問題涉及以高效方式表示涉及鍵值標識引用(UDDI標準中描述的對象類)的數據。能夠高效搜索鍵值標識引用的特定集合的需要使得這個更加複雜例如企業實體上的類別包。
根據本發明的實施例，通過建立表示鍵值標識引用的抽象基類並且針對每個期望集合將分為子類來解決這個問題。集合在目錄中不具有表示。例如，它們的存在不超過相同子類的一組鍵值標識引用，從而作為相同對象的子對象存在。例如，企業實體的類別包是類euBusinessEntityCategoryKeyedReference的對象，其作為指定企業實體的子對象。注意，企業實體對象能夠具有作為子對象的若干鍵值標識引用對象，其中只有其對象類清楚哪些是類別包的一部分，哪些是標識符包的一部分。
在UDDI數據模型內的若干位置使用鍵值標識引用。它們包含TModel關鍵字，鍵名和鍵值。鍵值標識引用的2個用途是類別包和標識符包。這些包是鍵值標識引用的集合，並且對於搜索是重要的。如果這些包通過包含無差別鍵值標識引用的對象來表示，則可能相當難以實現高效搜索。這就是實現鍵值標識引用的若干子類的原因。通過類euBusinessEntityCategoryKeyedReference的一或多個子對象表示企業實體上的類別包。這使得易於用其類別包中的指定鍵值標識引用實現對企業實體的高效搜索。
下面的例子示出如上所述的抽象類和導出類之一euBusinessEntityCategoryKeyedReference。注意，從抽象類繼承針對鍵值標識引用的關鍵字，而TModel關鍵字，鍵名和鍵值全部在導出類中指定，所以它們可以具有用於搜索的有區別的名字。
set object-class uddiObjectClass201＝{#作為所有鍵值標識引用的父節點的抽象類name＝euKeyedReferencesubclass-of topmust-containeuKeyedReferenceKey}；set object-class uddiObjectCalss301＝{#企業實體類別鍵值標識引用-集合構成類別包name＝euBusinessEntityCategoryKeyedReferencesubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryTModel，euBusinessEntityCategoryKeyName，euBusinessEntityCategoryKeyValue}；聯繫是複雜對象，表示各種信息。非常類似於企業實體，聯繫保存各種複合重複單元，從而有必要使用子對象類。
直接作為聯繫對象的一部分的僅有數據單元是關鍵字，和聯繫表示的人員或角色的名字。存在可選的使用類型。
所有其它的可能單元是聯繫對象的子對象。這些是地址(地址行對象的排序列表的父對象，每個具有關鍵字，使用類型，排序代碼和TModel關鍵字)；電話(電話號碼加上使用類型)；電子郵件(電子郵件地址加上使用類型)；和描述(描述串加上語言代碼)。
再次地，儘管圖15根據本發明實施例圖解了引入層次結構到子結構中以表示企業實體中相對複雜對象的例子，然而它同樣圖解了根據本發明實施例將層次結構引入到子結構中以表示聯繫對象中相對複雜對象的例子。圖15的企業實體151同樣適用於聯繫對象，其中聯繫對象的多值單元被表示成聯繫對象151的子對象152，153。可以沒有子對象，也可以有更多的子對象。
另一個問題涉及以高效方式表示名字和描述(UDDI標準中指定)，以及允許快速搜索特定類型的名字或描述。
根據本發明的實施例，系統建立抽象基類以表示名字，並且建立另一個抽象基類以表示描述，而且針對每個期望類型將其劃分子類。當尋找特定類型的名字(例如企業實體名字)時搜索子類的屬性，並且當尋找任何名字時搜索抽象類。
若干主要對象(企業實體，企業服務等等)具有多個名字和描述的選項。其原因是多重的。通過多個名字得知企業並不是不常見的，其中或許有一個正式名字，一或多個非正式名字。此外，企業可以使用不同語言的不同名字。例如，名字的翻譯不佳並不是不常見的現象。例如，計算機公司Fujitsu在說英語的國家使用名字Facom許多年。在具有多字符集的語言中問題會更加惡化。日本公司的名字會具有一個片假名版本，和另一個平假名版本。
基於這些原因和其它原因，對於一個單獨的對象，名字和描述對象會出現多次。每個實例被標記上語言代碼。在UDDI版本3中可以有具有相同語言代碼的多個實例(這在版本2中是不允許的)。
發現限定符加劇了混亂。如上所述，UDDI搜索需要支持大小寫敏感和大小寫不敏感搜索，並且這最好通過在X.500目錄中存儲數據兩次來處理。
下面的例子示出用於企業實體的名字集合的抽象類和導出類之一euBusinessEntityNameset object-class uddiObjectClass202＝{#作為所有名字的父節點的抽象類name＝euNamesubclass-of topmust-containeuNameKeymay-containeuLanguage}；set object-class uddiObjectClass331＝{#企業實體的名字name＝euBusinessEntityNamesubclass-of euNamemust-containeuBusinessEntityNameValue，euBusinessEntityNameValueiC#從euName繼承euNameKey和euLanguage}；注意，euBusinessEntityNameValue是包含名字的大小寫敏感版本的屬性；而euBusinessEntityNameValuelC是標記為″忽略大小寫″的版本，於是是大小寫不敏感的。從抽象類繼承的euNameKey欄位被用來控制名字的排序，並且提供唯一名字屬性。
名字對象的例子可以是euNameKey＝890abcde-890a-890a-890a-890abcdef123
euLanguage＝ENeuBusinessEntityNameValue＝McKenna′s Validation SystemseuBusinessEntityNameValuelC＝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-dcbaO9876543euToUserKey＝98765432-5432-5432-5432-cbaO98765432euPublisherAssertionStatus＝statuscompleteeuPublisherAssertionTModel＝uuid807A2C6A-EE22-470D-ADC7-E0424A337C03
euPublisherAssertionKeyName＝wholly-owned subsidiaryeuPublisherAssertionKeyValue＝parent-child輔助對象類為euPublisherAssertionKeyReference，並且上面列出的最後三個屬性是該類的數據元素。
根據本發明的實施例，諸如Computer Associates的eTrustTM的目錄可以被用來實現理想的企業UDDI註冊中心平臺。作為完全符合LDAPv3，X.500電子目錄的eTrust目錄可以被用來支持UDDI WEB服務實現。『eTrust』目錄允許UDDI實現影響到已經在大規模業務關鍵級目錄服務應用中得到證明的高度成熟的目錄解決方案。
『eTrust』有許多獨特的特性，使得其在作為建立UDDI註冊中心的平臺方面極有吸引力。其中一些包含訪問控制策略，角色，安全代理，相互認證，分布式認證，分布式SSL證書主題驗證和網絡地址確認；分布和路由能力，包含並行分布式搜索，負載分擔，查詢流和最短路徑路由；多主複製模式(multi-master replication scheme)，其將基於應答的機制(稱為多寫(multi-write))的速度和效率與基於狀態的恢復和調節技術結合起來；可用性特性，包含資料庫熱切換，網絡故障恢復和目錄系統代理(DSA)故障恢復；被認為是快速的高速緩存設計；和部署特性，包含動態配置(數據類型，模式規則，安全，知識等等)，無限制的數據長度，一般信息完整性規則，廣泛的管理控制和交互式命令控制臺。
eTrust目錄提供得到證明的X.500目錄解決方案。在其得到證明的基礎上可實現UDDI語義橋，以允許建立完全符合標準的UDDI註冊中心。由於基礎目錄解決方案的能力，這裡公開的實施例可以實現靈活的安全性，分布和可管理性，而不必改變或擴展現有UDDI標準。
本實施例的一個問題涉及如何映射在目錄的分離部分中存儲的實體之間的關係。
雖然UDDI數據結構主要是層次化的，然而在不同對象的交叉關係方面會存在問題。
主要有兩類關係，即替代名字(alternative names)和交叉關係(cross relationship)。根據本發明的實施例，通過利用別名的概念來實現替代名字，從而解決該問題。這基本上具有將外部實體『連接』作為主實體的虛擬子實體的效果。
本實施例利用唯一關鍵字解決交叉關係的問題。這基本上具有建立相當類似於RDBMS技術的主/外鍵系統的『關係指針』，以模擬層次目錄系統內不相交子樹之間存在的數據實體之間的關係的效果。
現在描述基於本發明實施例的別名的使用。通過UDDI企業服務投影的實現可最清楚地說明第一種情形。企業服務投影實際上是企業服務的替代名字。企業服務投影是看上去屬於企業A，但實際上由企業B擁有和定義的企業服務。
參照圖5，企業服務51，即企業A所擁有的服務看上去也屬於企業B。企業A對企業服務51作出的任何改變均會反映在企業B下面出現的投影的服務中。類似地，如果企業服務51被從註冊中心中刪除，則它不再出現在企業A和企業B下面。另外，企業實體B不可以編輯或改變企業服務51。為了編輯和所有其它發布目的，只有企業A必須訪問企業服務51。
目錄別名系統可以被用來實現這個效果。企業服務51的別名被加到企業實體B中。該別名對於目錄伺服器是特殊的標記，實際告知『當某方查看此別名時，向其出示在此的這個其它項』。
這意味著當編輯原始服務時，改變在投影中也是可見的。如果目錄系統支持別名完整性(eTrust目錄便是如此)，在服務被刪除的情況下，投影也會被自動清除。
另外，目錄伺服器可以被配置成當其在每個父對象下面被搜索一次時，將投影的企業服務顯示再次。當進行需要解析企業服務的父對象的搜索時，這是有用的。
某些情況下需要目錄層次結構的不相交部分中的對象保持關係。
這個的一個例子是綁定模板和TModel之間。在整個UDDI中TModel被用於各種目的。它們是分類關鍵字，搜索標識符，(UDDI)關係描述符，以及在這個實例中的技術規範『指紋(fingerprints)』。『連接』到綁定模板的TModel描述綁定模板(參見圖8)遵從的技術規範。例如，發布者可以連接一個聲明其綁定模板遵從SOAP 1.1標準的TModel。
註冊中心通常包含有限的TModel集合，其中的許多TModel會被數百或甚至數千綁定模板項引用。在某些情況下，註冊中心會返回任何『連接』的TModel的細節和綁定模板的細節。
根據本發明的這個實施例，可以適當地修改和應用例如關係資料庫系統中使用的主/外鍵系統。註冊中心中存儲的每個TModel具有其自身的唯一(主)鍵。綁定模板通過增加與所需TModel的唯一鍵匹配的本地(外)鍵來引用TModel。圖7圖解了這個的例子。如果需要用綁定模板返回TModel數據，則伺服器可以查找有關的TModel。
圖6示出了綁定模板和TModel之間的關係。
圖7示出了TModel關鍵字如何建立兩個實體之間的關係。
發布者聲明是UDDI資料庫的重要元素。如上所述，它為用戶提供發現與有關企業實體相關的企業實體，以及它們如何相關的能力。
發布者聲明被設計成防止濫用，其中僅當所涉及的兩個企業實體的所有者已經聲明關係時，所聲明的關係才變得可見。這種保護的代價是使得實現複雜，並且需要精心的設計以避免性能惡化。
一個問題是完整性。發布者聲明比任何其它UDDI構造具有更加複雜的生命周期。當企業實體的所有者作出關於該企業及其與另一企業實體的關係的聲明時，發布者聲明便開始存在。另一企業實體的所有者可以請求狀態報告，並且發現已經作出哪些關於其企業的聲明，或者它們被通知排除(out-of-band)。在任一情況下，另一企業實體的所有者可以選擇對兩個企業實體之間的關係作出匹配的聲明。此時，聲明是完整的，並且對調用findRefatedBusinesses的用戶可見。可以修改或刪除一或兩個聲明，並且聲明再次變得不完整，而且應當不再可見。另外，任一企業實體的刪除應當立即清除聲明。
可以通過保持聲明完整性的方式來管理髮布者聲明對象。
期望企業實體的所有者能夠作出(或清除)關於該所有者控制的企業實體的聲明。
本發明的實施例基於這樣的假設，即UDDI資料庫是「以讀為主」的存儲，主要用於X.500目錄。為此，優化設計以得到更好的讀取性能，甚至以加重寫入的負載為代價。
被稱作發布者聲明的對象類被設計成保存超過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)。
下一個問題涉及如何在搜索操作期間優化中間搜索結果集合的構造，使得考慮到目錄存儲介質的限制，目錄訪問和迭代存儲器內操作最少。實際上，可以以任意順序存儲和返回目錄項，並且目錄結果可能過大以致不能排序。
根據本發明的實施例，提供一個面向對象的存儲器內數據存儲系統，該系統與一個按區別名字對中間結果進行排序的唯一結構排序模式相結合。這允許一個搜索返回許多不同類型的對象-企業實體(BusinessEntities)，企業服務(BusinessServices)，等等-並且仍然允許系統容易地構造正確的XML結構以向用戶返回數據。注意，通過XML進行Web服務交互。
現在說明這個系統的描述。根據以下層次結構在目錄中提供(部分地)本發明的UDDI企業實體和任何子數據元素企業實體●企業服務○綁定模板○綁定模板○服務名字○服務名字●企業服務○綁定模板○綁定模板○服務名字○服務名字●企業名字●企業名字●企業描述●企業描述注意，已經結合本發明涉及子結構和對象分割的方面說明了服務名字，企業名字和企業描述。
企業實體檢索代碼根據所需企業實體的唯一關鍵字執行目錄子樹搜索。這個搜索將返回找到的項和所有子項。目錄標準不保證返回的項具有任何特定的順序-或者甚至子項緊跟在其父項後面。
因此，檢索代碼接著按照區別名稱對返回的項進行排序。這保證子項將排列在其父項之後，並且能夠容易地區分父子關係。可以使用各種排序算法。所使用的排序算法應當在各個項被部分排序的情況下表現出高性能特徵。
用於結構構造的算法在操作上主要是′深度優先、從左到右的樹遍歷′。這在圖論中也稱為′後序遍歷′。
排序的列表被傳遞到新企業實體對象的構造函數方法。這個對象可以是例如被設計成表示UDDI企業實體的面向對象編程構造。企業實體對象包含根據最後的項中提供的數據′構造其自身′的代碼。該代碼迭代地移動通過列表，對每個項作出判決。可以理解，列表中的第一項應當是企業實體本身的主項，並且一旦發現另一個企業實體，可以理解，構造已經完成-列表的順序保證了這一點。一旦發現企業服務或其它子項，實例化合適類型的對象，並且將列表和告知從列表中何處開始的指針傳遞到新對象的構造函數。
每個對象基本上包含類似的處理代碼以處理其自身的構造，以及將任何子項的構造委託給合適的子對象。
通過這種方式，只需進行單次目錄搜索，並且以高效方式處理結果列表，其中每個項只被處理一次。如果列表保持任意順序或以某種其它方式排序，則列表必須經過多遍處理，以便根據結果項正確地構造UDDI層次結構。
將構造和列表處理委託給層次結構中的不同編程對象使得處理代碼的長度相當小，從而更加高效和更加快速。
圖9圖解了編程構造(對象)，包含排序項列表的表示。確定在項的列表中是否存在任何其它的項。如果沒有額外的項(否，步驟S100)，則過程退出(步驟S118)。如果有額外的項(是，步驟S100)，則取出列表中的下一項(步驟S102)。接著確定該項是否具有這個對象類型。如果該項具有這個對象類型(是，步驟S104)，則根據該項設置對象屬性(步驟S106)，並且過程返回到步驟S100。如果不具有這個對象類型(否，步驟S104)，則確定是否已經處理過具有這個對象類型的項(步驟S108)。如果尚未處理過具有這個對象類型的項(否，步驟S108)，則過程返回到步驟S100。如果已經處理過具有這個對象類型的項(是，步驟S108)，則確定該項是否這個對象的固有部件(例如名字，描述等等)。如果是固有部件(是，步驟S110)，則該項被加到對象屬性中，並且可以執行額外的處理(步驟S112)，過程返回到步驟S100。如果不是固有部件(否，步驟S110)，則確定該項是否這個對象的子對象(例如BusinessService是BusinessEntity的子對象)。如果是子對象(是，步驟S114)，則系統實例化正確類型的對象，並且將項的列表傳遞到構造函數(步驟S116)，過程返回到步驟S100。如果不是子對象(否，步驟S114)，則過程返回到步驟S100。
以下的『實字』例子演示了LDAP目錄可能預計返回的任意順序的種類。
SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvalueuddiDescription
SearchResultEntryobjectNameserviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceNameSearchResultEntryobjectNamebindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebindingTemplateSearchResultEntryobjectName
nameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntityName列表1-以粗體突出的名字項是位於列表頂端的企業實體項的葉節點，並且如果在企業服務項和企業實體的其它分支子節點之前出現，則會有利。然而，它出現在列表的末端，迫使任何處理代碼搜索整個列表以確保已經處理企業實體的所有直接子節點。
因此，按照根據本發明實施例制定的規則而排序的相同數據的一個版本SearchResultEntryobjectNamebusinessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntitytypebusinessKeyvalue1ba3034aeef738da00eef78599fe0004SearchResultEntryobjectNamedescriptionKey＝1ba3034aeef738da00eef786302b0008，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributes
typeobjectClassvalueuddiDescriptionSearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef7862fe50007，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessEntityNameSearchResultEntryobjectNameserviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceSearchResultEntryobjectNamebindingKey＝1ba3034aeef738da00eef7899fb7000e，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebindingTemplate
SearchResultEntryobjectNamenameKey＝1ba3034aeef738da00eef78970da000d，serviceKey＝1ba3034aeef738da00eef789707f000c，businessKey＝1ba3034aeef738da00eef78599fe0004，userKey＝1ba3034aedb9154900edb915491c0001，o＝CAattributestypeobjectClassvaluebusinessServiceName列表2-以粗體突出的項出現在列表中更合邏輯的位置，並且現在能夠編寫處理代碼以對此加以利用。當項的數量增加到實際伺服器負載的程度時，處理時間的節省是顯著的。
以下是本發明的另一個實施例。
#表示目錄中UDDI數據和/或關係的模式……表達式100#Computer Associates eTrust UDDI Configuration Schema#Copyright(c)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 uddiAttributeType201＝{#在KeyedReference及其所有導出類中使用name＝euKeyedReferenceKeysyntax＝caselgnoreString
single-valued}；set attribute uddiAttributeType202＝{#在UserAccount中使用name＝euUserKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType203＝{#在BusinessEntity，TModel，可能的其它類中使用name＝euParentUserKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType204＝{#在BusinessEntity中使用name＝euBusinessEntityKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType205＝{#在BusinessService，可能的其它類中使用name＝euParentBusinessKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType206＝{#在BusinessService中使用name＝euBusinessServiceKey
syntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType207＝{#在BindingTemplate，可能的其它類中使用name＝euParentServiceKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType208＝{#在BindingTemplate中使用name＝euBindingTemplateKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType209＝{#在TModel中使用name＝euTModelKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType210＝{#在PublisherAssertion中使用name＝euPublisherAssertionKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType211＝{#在PublisherAssertion中使用
name＝euFromBusinessKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType212＝{#在PublisherAssertion中使用name＝euFromUserKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType213＝{#在PublisherAssertion中使用name＝euToBusinessKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType214＝{#在PublisherAssertion中使用name＝euToUserKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType216＝{#在DiscoveryURL中使用name＝euDiscoveryURLKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType217＝
{#在Contact中使用name＝euContactKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType218＝{#在Address中使用name＝euAddressKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType219＝{#在Address中使用name＝euAddressTModelKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType220＝{#在AddressLine中使用name＝euAddressLineKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType221＝{#在Phone中使用name＝euPhoneKeysyntax＝caselgnoreStringsingle-valued}；
set attribute uddiAttributeType222＝{#在Email中使用name＝euEmailKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType223＝{#在Tmodellnstancelnfo中使用name＝eulnstanceTModelKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType224＝{#在Name，和所有導出類中使用name＝euNameKeysyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType225＝{#在Decription，和所有導出類中使用name＝euDescriptionKeysyntax＝caselgnoreStringsingle-valued}；#-----------------------#鍵值標識引用中使用的屬性set attribute uddiAttributeType301＝
{#在BusinessEntityCategory中使用name＝euBusinessEntityCategoryKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType302＝{#在BusinessEntityCategory中使用name＝euBusinessEntityCategoryKRKeyNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType303＝{#在BusinessEntityCategory中使用name＝euBusinessEntityCategoryKRKeyValuesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType304＝{#在BusinessEntityidentifier中使用name＝euBusinessEntityldentifierKRTModelsyntax＝caseglnoreStringsingle-valued}；set attribute uddiAttributeType305＝{#在BusinessEntityldentifier中使用name＝euBusinessEntityidentifierKRKeyNamesyntax＝caselgnoreStringsingle-valued}；
set attribute uddiAttributeType306＝{#在BusinessEntityldentifier中使用name＝euBusinessEntityldentifierKRKeyValuesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType307＝{#在BusinessServiceCategory中使用name＝euBusinessServiceCategoryKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType308＝{#在BusinessServiceCategory中使用name＝euBusinessServiceCategoryKRKeyNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType309＝{#在BusinessServiceCategory中使用name＝euBusinessServiceCategoryKRKeyValuesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType310＝{#在TModelCategory中使用name＝euTModelCategoryKRTModelsyntax＝caselgnoreStringsingle-valued
}；set attribute uddiAttributeType311＝{#在TModelCategory中使用name＝euTModelCategoryKRKeyNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType312＝{#在TModelCategory中使用name＝euTModelCategoryKRKeyValuesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType313＝{#在TModelldentifier中使用name＝euTModelidentifierKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType314＝{#在TModelidentifier中使用name＝euTModelidentifierKRKeyNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType315＝{#在TModelidentifier中使用name＝euTModelidentfiferKRKeyValuesyntax＝caselgnoreString
single-valued}；set attribute uddiAttributeType316＝{#在PublisherAssertion中使用name＝euPublisherAssertionKRTModelsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType317＝{#在PublisherAssertion中使用name＝euPublisherAssertionKRKeyNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType318＝{#在PublisherAssertion中使用name＝euPublisherAssertionKRKeyValuesyntax＝caselgnoreStringsingle-valued}；#------------------------#在名字和描述中使用的屬性set attribute uddiAttributeType361＝{#在企業實體名字中使用name＝euBusinessEntityNameValuesyntax＝CaseExactStringsingle-valued
}；set attribute uddiAttributeType381＝{#在企業實體名字中使用name＝euBusinessEntityNameValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType362＝{#在企業服務名字中使用name＝euBusinessServiceNameValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType382＝{#在企業服務名字中使用name＝euBusinessServiceNameValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType363＝{#在企業實體描述中使用name＝euBusinessEntityDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType383＝{#在企業實體描述中使用name＝euBusinessEntityDescriptionValuelCsyntax＝caselgnoreString
single-valued}；set attribute uddiAttributeType364＝{#在企業服務描述中使用name＝euBusinessServiceDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType384＝{#在企業服務描述中使用name＝euBusinessServiceDescriptionValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType365＝{#在tmodel描述中使用name＝euTModelDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType385＝{#在tmodel描述中使用name＝euTModelDescriptionValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType366＝{#在tmodel實例信息描述中使用name＝eu TModellnstancelnfoDescriptionValuesyntax＝CaseExactStringsingle-valued
}；set attribute uddiAttributeType386＝{#在tmodel實例信息描述中使用name＝euTModellnstancelnfoDescriptionValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType367＝{#在tmodel實例細節描述中使用name＝euTModeIInstanceDetailsDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType387＝{#在tmodel實例細節描述中使用name＝euTModelinstanceDetailsDescriptionValuelCsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType368＝{#在概述文檔描述中使用name＝euOverviewDocDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType388＝{#在概述文檔描述中使用name＝euOverviewDocDescriptionValueiCsyntax＝caselgnoreString
single-valued}；set attribute uddiAttributeType369＝{#在綁定模板描述中使用name＝euBindingTemplateDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType389＝{#在綁定模板描述中使用name＝euBindingTemplateDescriptionValueICsyntax＝caselgnoreStringsingle-valued}-set attribute uddiAttributeType370＝{#在Contact描述中使用name＝euContactDescriptionValuesyntax＝CaseExactStringsingle-valued}；set attribute uddiAttributeType390＝{#在Contact描述中使用name＝euContactDescriptionValuelCsyntax＝caselgnoreStringsingle-valued}；#--------------------#其它屬性
set attribute uddiAttributeType400＝{#在名字和描述中使用name＝euLanguagesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType401＝{#在資料庫中使用name＝euRepositoryNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType402＝{#在UserAccount中使用name＝euUserNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType403＝{#在UserAccount中使用name＝euCredentialssyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType404＝{#在UserAccount中使用name＝euAuthorizedNamesyntax＝caselgnoreStringsingle-valued
}；set attribute uddiAttributeType405＝{#在UserAccount和TModel中使用name＝euHiddensyntax＝booleansingle-valued}；set attribute uddiAttributeType406＝{#在企業實體和tmodel中使用name＝euOperatorsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType407＝{#在Contact中使用name＝euContactNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType408＝{#在discoveryURL，contact，address，phone，email中使用name＝euUseTypesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType409＝{#在phone中使用name＝euPhoneNumbersyntax＝caselgnoreString
single-valued}；set attribute uddiAttributeType419＝{#在email中使用name＝euEmailAddresssyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType411＝{#在address中使用name＝euSortCodesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType412＝{#在綁定模板中使用name＝euHostingRedirectorsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType413＝{#在綁定模板中使用name＝euAccessPointsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType414＝{#在綁定模板中使用name＝euAccessPointType
syntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType415＝{#在tmodel中使用name＝euTModelNamesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType416＝{#在tmodel中使用name＝euOverviewURLsyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType417＝{#在address line中使用name＝euAddressLineValuesyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType418＝{#在tmodel實例信息中使用name＝eulnstanceParmssyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType420＝{#在PublisherAssertion中使用
name＝euPublisherAssertionStatussyntax＝caselgnoreStringsingle-valued}；set attribute uddiAttributeType421＝{#在discovery URL中使用name＝euDiscoveryURLValuesyntax＝caselgnoreStringsingle-valued}；#----------------------#抽象類-不要試圖在目錄中存儲它們！set object-class uddiObjectClass201＝{#作為所有鍵值標識引用的父節點的抽象類name＝euKeyedReferencesubclass-of top kind＝abstractmust-containeuKeyedReferenceKey#注意帶索引的引用也應包含TModel關鍵字，關鍵字名，和關鍵字#值，每個導出類增加這些，使得它們能夠均具有不同的名字，#以利於搜索這些屬性的標準名字#euXXXTModel#euXXXKeyName#euXXXKeyValue#其中XXX是對象的名字和鍵值標識引用的目的}；
set object-class uddiObjectClass202＝{#作為所有名字的父節點的抽象類name＝euNamesubclass-of top kind＝abstractmust-containeuNameKeymay-containeuLanguage#注意名字也應具有包含名字所有者的串，該串通常#具有euXXXNameValue模式的名字，其中XXX是父對象的名字#這使搜索的效率最大#存在屬性的第二拷貝，其附有IC-這是忽略大小寫的版本}；set object-classuddiObjectCalss203＝{#作為所有描述的父節點的抽象類name＝euDescriptionsubclass-of topkind＝abstractmust-containeuDescriptionKeymay-containeuLanguage#注意描述也應具有包含描述所有者的串。
#該串通常具有euXXXDescriptionValue模式的名字，#其中XXX是父對象的名字#這使搜索的效率最大#存在屬性的第二拷貝，其附有IC-這是忽略大小寫的版本
}；#----------------------#鍵值標識引用類型set object-class uddiObjectClass301＝{#企業實體類別鍵值標識引用-集合構成類別包name＝euBusinessEntityCategoryKRsubclass-of euKeyedReferencemust-containeuBusinessEntityCategoryKRKeyValuemay-containeuBusinessEntityCategoryKRTModel，euBusinessEntityCategoryKRKeyName}；set object-class uddiObjectClass302＝{#企業實體標識鍵值標識引用-集合構成標識包name＝euBusinessEntityidentifierKRsubclass-of euKeyedReferencemust-containeuBusinessEntityldentifierKRKeyValuemay-containeuBusinessEntityldentifierKRTModel，euBusinessEntityldentifierKRKeyName}；set object-class uddiObjectClass303＝{#服務類別鍵值標識引用-集合構成類別包name＝euBusinessServiceCategoryKRsubclass-of euKeyedReference
must-containeuBusinessServiceCategoryKRKeyValuemay-containeuBusinessServiceCategoryKRTModel，euBusinessServiceCategoryKRKeyName}；set object-class uddiObjectClass304＝{#tmodel類別鍵值標識引用-集合構成類別包name＝euTModelCategoryKRsubclass-of euKeyedReferencemust-containeuTModelCategoryKRKeyValuemay-containeuTModelCategoryKRTModel，euTModelCategoryKRKeyName}；set object-class uddiObjectClass305＝{#tmodel標識鍵值標識引用-集合構成標識包name＝euTModelidentifierKRsubclass-of euKeyedReferencemust-containeuTModelldentifierKRKeyValuemay-containeuTModelIdentifierKRTModel，euTModelIdentifierKRKeyName}；set object-class uddiObj ctClass306＝{#發布者聲明鍵值標識引用-用作輔助類以提供關係name＝euPublisherAssertionKR
subclass-of euKeyedReferencekind＝auxiliarymust-containeuPublisherAssertionKRKeyValuemay-containeuPublisherAssertionKRTModel，euPublisherAssertionKRKeyName}；#-----------------------#名字和描述類型set object-class uddiObjectClass331＝{#企業實體的名字name＝euBusinessEntityNamesubclass-of euNamemust-containeuBusinessEntityNameValue，euBusinessEntityNameValuelC#從euName繼承euNameKey和euLanguage}；set object-class uddiObjectClass332＝{#企業服務的名字name＝euBusinessServiceNamesubclass-of euNamemust-containeuBusinessServiceNameValue，euBusinessServiceNameValuelC#從euName繼承euNameKey和euLanguage
}；set object-class uddiObjectClass341＝{#企業實體的描述name＝euBusinessEntityDescriptionsubclass-of euDescriptionmay-containeuBusinessEntityDescriptionValue，euBusinessEntityDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass342＝{#企業服務的描述name＝euBusinessServiceDescriptionsubclass-of euDescriptionmay-containeu BusinessServiceDescri ptionValue，euBusinessServiceDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass343＝{#tmodel的描述name＝euTModelDescriptionsubclass-of euDescriptionmay-containeuTModel DescriptionValue，euTModelDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass344＝
{#tmodel實例信息對象的描述name＝euTModelInstancelnfoDescriptionsubclass-of euDescriptionmay-containeuTModellnstancelnfoDescriptionValue，euTModellnstancelnfoDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass345＝{#tmodel實例細節對象的描述name＝euTModeIInstanceDetaiisDescriptionsubclass-of euDescriptionmay-containeuTModellnstanceDetailsDescriptionValue，euTModeIInstanceDetaiIsDescriptionValueIC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass346＝{#概述文檔對象的描述name＝euOverviewDocDescriptionsubclass-of euDescriptionmay-containeu OverviewDocDescriptionValue，eu OverviewDocDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObjectClass347＝{#contact的描述
name＝euContactDescription.
subclass-of euDescriptionmay-containeuContactDescriptionValue，euContactDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；set object-class uddiObj ectClass348＝{#綁定模板的描述name＝euBindingTemplateDescriptionsubclass-of euDescriptionmay-containeuBindingTemplateDescriptionValue，euBindingTemplateDescriptionValuelC#從euDescription繼承euDescriptionKey和euLanguage}；#---------------------------#主要對象set object-class uddiObjectClass400＝{#資料庫-可以用於將用戶分成組name＝euRepositorysubclass-of topmust-containeuRepositoryName}；set object-class uddiObjectClass401＝{#用戶帳戶-其中隱藏我們有關用戶的知識
name＝euUserAccountsubclass-of topmust-containeu UserKey，eu UserName，euCredentialsmay-containeuAuthorizedName，euHidden#注意這個用戶發布的所有企業實體和TModel均被發現為這個對象的子對象}；set object-class uddiObjectClass402＝{#企業對象-提供服務的實體的細節name＝euBusinessEntitysubclass-of topmust-containeuBusinessEntityKeymay-containeuParentUserKey，euAuthorizedName，euOperator#注意在這個對象的子對象中保存企業實體的許多屬性，#尤其是可能不止一次出現的屬性}；set object-class uddiObjectClass403＝{#企業服務-企業實體提供的服務的細節name＝euBusinessServicesubclass-of top
must-containeuBusinessServiceKeymay-containeuParentBusinessKey#注意這個服務的所有綁定模板會被發現為這個服務的子服務}；set object-class uddiObjectClass404＝{#綁定模板-如何訪問特定企業的細節name＝euBindingTemplatesubclass-of topmust-containeuBindingTemplateKeymay-containeuParentServiceKey，euHostingRedirector，euAccessPoint，euAccessPointType#注意應當具有駐留重定向器或接入點之一}；set object-class uddiObjectClass405＝{#tmodel-對概念的引用。可以是分類模式，可以只是對標準的引用name＝euTModelsubclass-of topmust-containeuTModelKey，euTModeiNamemay-containeuAuthorizedName，
euOperator，euOverviewURL，euParentUserKey，euHidden#注意當「刪除」TModel時使用Hidden}；set object-class uddiObjectClass406＝{#發布者聲明-作出有關兩個企業之間的關係的聲明name＝euPublisherAssertionsubclass-of topmust-containeuPublisherAssertionKey，euFromBusinessKey，euFromUserKey，euToBusinessKey，euToUserKey，euPublisherAssertionStatus#注意關係將被存儲為類型euPublisherAssertionKeyedReference的輔助類#這允許直接搜索輔助類的元素}；#------------------#次要對象-多數為主要對象的子對象，保存重複數據set object-class uddiObjectClass501＝{#discoveryURL-在企業實體下面發現name＝euDiscoveryURLsubclass-of top
must-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＝{#address line-在address下面發現，構成各行地址
name＝euAddressLinesubclass-oftopmust-containeuAddressLineKey，euAddressLineValue}；set object-class uddiObjectClass505＝{#phone-在contact下面發現name＝euPhonesubclass-oftopmust-containeuPhoneKey，euPhoneNumbermay-containeuUseType}；set object-class uddiObjectClass506＝{#email-在contact下面發現name＝euEmailsubclass-of topmust-containeuEmailKey，euEmailAddressmay-containeuUseType}；set object-class uddiObjectClass507＝{#tmodel實例信息-在綁定模板下面發現name＝euTModellnstancelnfo
subclass-of topmust-containeulnstanceTModelKeymay-containeulnstanceParms，eu OverviewU RL}；#-------------------#名字綁定schema set name-binding uddiBinding101＝{#綁定到最高層子對象name＝euRepository-topeuRepository allowable-parent topnamed-by euRepositoryName}；schema set name-binding uddiBinding102＝{{#綁定到最高層子對象name＝euUserAccount-topeuUserAccount allowable-parenttop named-by euUserKey}；schema set name-binding uddiBinding103＝{#綁定到euRepositoryname＝euUserAccount-euRepositoryeuUserAccount allowable-parent euRepositorynamed-by euUserKey
}；schema set name-binding uddiBinding104＝{#綁定TModel到″頂端″-用於標準TModels(非由用戶發布)name＝euTModel-euRepositoryeuTModel allowable-parent euRepositorynamed-by euTModelKey}；schema set name-binding uddiBinding105＝{#綁定到組織最高層子對象name＝euRepository-organizationeuRepository allowable-parent organizationnamed-by euRepositoryName}；schema set name-binding uddiBinding106＝{#綁定發布者聲明到資料庫以允許可選配置name＝euPublisherAssertion-euRepositoryeuPublisherAssertion allowable-parent euRepositorynamed-by euPublisherAssertionKey}；schema set name-binding uddiBinding107＝{#綁定資料庫層-允許多層資料庫結構name＝euRepository-euRepositoryeuRepository allowable-parenteuRepositorynamed-by euRepositoryName}；schema set name-binding uddiBinding201＝{#綁定企業實體到用戶帳戶-第二層name＝euBusinessEntity-euUserAccount
euBusinessEntity allowable-parent euUserAccountnamed-by euBusinessEntityKey}；schema set name-binding uddibinding202＝{#綁定tmodel到用戶帳戶-第二層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＝{#綁定聯繫到企業-第三層name＝euContact-euBusinessEntityeuContact allowable-parent euBusinessEntitynamed-by euContactKey}；schema set name-binding uddiBinding303＝{#綁定企業下面的discoveryURLname＝euDiscoveryURL-euBusinessEntityeuDiscoveryURL allowable-parenteuBusinessEntitynamed-by euDiscoveryURLKey}；schema set name-binding uddiBinding304＝{#企業下面的名字
name＝euBusinessEntityName-euBusinessEntityeuBusinessEntityName allowable-parent euBusinessEntitynamed-by euNameKey}；schema set name-binding uddiBinding305＝{#企業下面的描述name＝euBusinessEntityDescription-euBusinessEntityeuBusinessEntityDescription allowable-parent euBusinessEntitynamed-by euDescriptionKey}；schema set name-binding uddiBinding306＝{#企業下面的發布者聲明name＝euPublisherAssertion-euBusinessEntityeuPublisherAssertion allowable-parent euBusinessEntitynamed-by euPu blisherAssertionKey}；schema set name-binding uddiBinding307＝{#企業實體下面的標識name＝euBusinessEntityidentifierKR-euBusinessEntityeuBusinessEntityldentifierKRallowable-parenteuBusinessEntitynamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding308＝{#企業實體下面的類別name＝euBusinessEntityCategoryKR-euBusinessEntityeuBusinessEntityCategoryKR allowable-parenteuBusinessEntitynamed-by euKeyedReferenceKey
}；schema set name-binding uddiBinding310＝{#TModel下面的描述name＝euTModelDescription-euTModeleuTModel Description allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding311＝{#TModel下面的概述URL的描述name＝euOverviewDocDescription-euTModeleuOverviewDocDescription allowable-parent euTModelnamed-by euDescriptionKey}；schema set name-binding uddiBinding312＝{#tmodel下面的標識name＝euTModelIdentifierKR-euTModeleuTModelIdentifierKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding313＝{#TModel下面的類別name＝euTModelCategoryKR-euTModeleuTModelCategoryKR allowable-parent euTModelnamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding401＝{#聯繫下面的地址name＝euAddress-euContacteuAddress allowable-parent euContact
named-by euAddressKey}；schema set name-binding uddiBinding402＝{#聯繫下面的電話號name＝euPhone-euContacteuPhone allowable-parent euContactnamed-by euPhoneKey}；schema set name-binding uddiBinding403＝{#聯繫下面的emailname＝euEmail-euContacteuEmail allowable-parent euContactnamed-by euEmailKey}；schema set name-binding uddiBinding404＝{#聯繫下面的描述name＝euContactDescription-euContacteuContactDescription allowable-parent euContactnamed-by euDescriptionKey}；schema set name-binding uddiBinding409＝{#服務下面的名字name＝euBusinessServiceName-euBusinessServiceeuBusinessServiceName allowable-parent euBusinessServicenamed-by euNameKey}；schema set name-binding uddiBinding410＝{#服務下面的描述name＝euBusinessServiceDescription-euBusinessService
euBusinessServiceDescriptionallowable-parenteuBusinessServicenamed-by euDescriptionKey}；schema set name-binding uddiBinding411＝{#服務下面的類別name＝euBusinessServiceCategoryKR-euBusinessServiceeuBusinessServiceCategoryKR allowable-parenteuBusinessServicenamed-by euKeyedReferenceKey}；schema set name-binding uddiBinding412＝{#綁定服務下面的模板name＝euBindingTemplate-euBusinessServiceeuBindingTemplate allowable-parent euBusinessServicenamed-by euBindingTemplateKey}；schema set name-binding uddiBinding501＝{#地址下面的行name＝euAddressLine-euAddresseuAddressLine allowable-parent euAddressnamed-by euAddressLineKey}；schema set name-binding uddiBinding502＝{#綁定模板下面的描述name＝euBindingTempiateDescription-euBindingTemplateeuBindingTemplateDescriptionallowable-parenteuBindingTemplatenamed-by euDescriptionKey
}；schema set name-binding uddiBinding510＝{#綁定模板下面的tmodel實例信息name＝euTModellnstancelnfo-euBindingTemplateeuTModellnstancelnfo allowable-parent euBindingTemplatenamed-by eulnstanceTModelkey}；schema set name-binding uddiBinding601＝{#tmodel實例信息下面的描述name＝euTModellnstancelnfoDescription-euTModellnstancelnfoeuTModellnstancelnfoDescriptionallowable-parenteuTModellnstancelnfonamed-by euDescriptionKey}；schema set name-binding uddiBinding602＝{#tmodel實例信息下面的實例細節描述name＝euTmodellnstanceDetailsDescription-euTModellnstancelnfoeuTmodellnstanceDetailsDescriptionallowable-parenteuTModel Instancel nfonamed-by euDescriptionKey}；schema set name-binding uddiBinding603＝{#tmodel實例信息下面的概述文檔描述name＝euOverviewDocDescription-euTModellnstancelnfoeuOverviewDocDescription allowable-parenteuTModelinstanceinfonamed-by euDescriptionKey}；
由於能夠在不偏離本發明的必要特徵的實質的前提下以各種形式實施本發明，應當理解，上述實施例不是為了限制本發明(除非專門指出)，而是應當在所附權利要求限定的公開內容的實質和範圍內進行廣義的解釋。各種修改和等同方案均應被包含在本公開和所附權利要求的實質和範圍內。
權利要求
1.一種為WEB服務結構中的對象產生關鍵字的方法，包括確定對象是否具有定義的第一關鍵字；如果對象具有定義的第一關鍵字，則為該對象提供定義的第一關鍵字，並且如果對象不具有定義的第一關鍵字，則為該對象提供第二關鍵字。
2.如權利要求1所述的方法，其中UUID(全局唯一標識)算法被用來為對象提供第二關鍵字。
3.如權利要求1所述的方法，其中每個關鍵字是唯一的。
4.如權利要求1所述的方法，其中所提供的第二關鍵字是單調增加的。
5.如權利要求1所述的方法，其中每個對象具有定義的關鍵字和第二關鍵字中的至少一個。
6.一種包含計算機可執行代碼的計算機記錄介質，所述計算機可執行代碼用於為WEB服務結構中的對象產生關鍵字，包括用於確定對象是否具有定義的第一關鍵字的代碼；用於在對象具有定義的第一關鍵字的情況下為該對象提供定義的第一關鍵字的代碼；和用於在對象不具有定義的第一關鍵字的情況下為該對象提供第二關鍵字的代碼。
7.如權利要求6所述的計算機記錄介質，其中UUID(全局唯一標識)算法被用來為對象提供第二關鍵字。
8.如權利要求6所述的計算機記錄介質，其中每個關鍵字是唯一的。
9.如權利要求6所述的計算機記錄介質，其中所提供的第二關鍵字是單調增加的。
10.如權利要求6所述的計算機記錄介質，其中每個對象具有定義的關鍵字和第二關鍵字中的至少一個。
全文摘要
一種產生WEB服務方案中對象的關鍵字的方法包含確定對象是否具有定義的第一關鍵字，以及如果對象具有定義的第一關鍵字，則為該對象提供定義的第一關鍵字，並且如果對象不具有定義的第一關鍵字，則為該對象提供第二關鍵字。
文檔編號H04L29/06GK1678993SQ03820308
公開日2005年10月5日 申請日期2003年8月25日 優先權日2002年8月26日
發明者理察·哈維, 蒂莫西·本特利 申請人:計算機聯合思想公司