原文地址：http://www.ibm.com/developerworks/cn/webservices/ws-featuddi/

2002 年 7 月 01 日

統一描述、發現和集成（Universal Description, Discovery, and Integration，UDDI）項目繼續豐富企業用于在 UDDI 業務注冊中心表示 Web 服務并建立其模型的工具集。本文將介紹 UDDI 和它在 Web 服務發展過程中所起到的促進作用。您可以了解到 UDDI 的工作原理，并發現 UDDI 規范新的即將出現的功能。

何為 UDDI？

UDDI 項目鼓勵 Web 服務相互操作和相互采用。它是一種工商界居于領先地位的企業之間的伙伴關系，這種關系最早是由 IBM、Ariba 和 Microsoft 建立的。現在參加的公司已逾 300 家。UDDI 提供了一組基于標準的規范用于描述和發現服務，還提供了一組基于因特網的實現。UDDI 繼續快速發展，并贏得了業界的支持。這一規范之所以發展很快，是因為有快速實現在背后提供支持，不僅證明了思想，而且為進一步完善規范提供了豐富的實踐基礎。

UDDI 解決了企業遇到的大量問題。首先，它能幫助拓展商家到商家（B2B）交互的范圍并能簡化交互的過程。對于那些需要與不同顧客建立許多種關系的廠家來說，每家都有自己的一套標準與協議，UDDI 支持一種適應性極強的服務描述，幾乎可以使用任何接口。對于一家地處澳洲的花店，雖然很希望能進入世界上的所有市場，但苦于不知道怎樣才能成功，UDDI 提供了一種能實現這一目標的辦法。規范允許企業在注冊中心中發布它所提供的服務，這樣發現企業及服務就變得高效而且簡單了。

對于 B2B 交易場所提供者，他們需要獲得這一行業內的供應商的分類數據，以及它們與計費服務、包裝商、運輸商、保險公司等之間的關系，UDDI 允許動態發現相關的 Web 服務并將其集成到聚合的業務過程中。UDDI 提供一站式搜索有關企業和電子化服務的信息。在 UDDI 中發布企業與服務信息使其它企業能大范圍的訪問到這些信息。

UDDI 基于現成的標準，如可擴展標記語言（Extensible Markup Language，XML）和簡單對象訪問協議（Simple Object Access Protocol，SOAP）。UDDI 的所有兼容實現都支持 UDDI 規范。公共規范是機構成員在開放的、兼容并蓄的過程中開發出來的。目的在于先生成并實現這個規范的三個連續版本，之后再把將來開發得到的成果的所有權移交給一個獨立的標準組織。UDDI 版本 1 規范于 2000 年 9 月發布，版本 2 于 2001 年 6 月發布。版本 3 還在開發中，預計到 2002 年年中發布。版本 1 打下了注冊中心的基礎，版本 2 則添加了企業關系等功能，版本 3 接下去要解決正在進行的 Web 服務開發中的重要領域內的問題，如安全性、改善了的國際化、注冊中心之間的互操作性以及為進一步改進工具而對 API 進行的各種改進。


圖 1. UDDI 的分層 Web 服務協議棧
UDDI 的分層 Web 服務協議棧

如 圖 1中所示，UDDI 包含于完整的 Web 服務協議棧之內，而且是協議棧基礎的主要部件之一，支持創建、說明、發現和調用 Web 服務。

UDDI 構建于網絡傳輸層和基于 SOAP 的 XML 消息傳輸層之上。諸如 Web 服務描述語言（Web Services Description Language，WSDL）之類的服務描述語言提供了統一的 XML 詞匯（與交互式數據語言（Interactive Data Language，IDL）類似）供描述 Web 服務及其接口使用。您可以通過添加分層的功能搭起整個基礎，比如使用 Web 服務流程語言（Web Services Flow Language，WSFL）的 Web 服務工作流描述、安全性、管理和服務質量功能，從而解決系統可靠性和可用性問題。


回頁首


UDDI 的工作原理

UDDI 注冊中心包含了通過程序手段可以訪問到的對企業和企業支持的服務所做的描述。此外，還包含對 Web 服務所支持的因行業而異的規范、分類法定義（用于對于企業和服務很重要的類別）以及標識系統（用于對于企業很重要的標識）的引用。UDDI 提供了一種編程模型和模式，它定義與注冊中心通信的規則。UDDI 規范中所有 API 都用 XML 來定義，包裝在 SOAP 信封中，在 HTTP 上傳輸。


圖 2. UDDI 消息在客戶機和注冊中心之間的流動
UDDI 消息在客戶機和注冊中心之間的流動

圖 2 說明了 UDDI 消息的傳輸，通過 HTTP 從客戶機的 SOAP 請求傳到注冊中心節點，然后再反向傳輸。注冊中心服務器的 SOAP 服務器接收 UDDI SOAP 消息、進行處理，然后把 SOAP 響應返回給客戶機。就注冊中心條例而言，客戶機發出的要修改數據的請求必須確保是安全的、經過驗證的事務。


圖 3. UDDI 工作原理
UDDI UDDI 工作原理

圖 3說明了如何往 UDDI 注冊中心送入數據，顧客又如何能發現和使用這一信息。UDDI 注冊中心建立在顧客提供的數據的基礎之上。要使數據能在 UDDI 中物盡其用需要幾個步驟。如第 1 步中所示，在軟件公司和標準組織定義關于在 UDDI 中注冊的行業或企業的規范時，開始向注冊中心發布有用的信息。這些規范叫做技術模型或者更常見的說法是 tModel 。

在第 2 步中，公司還會注冊關于其業務及其提供的服務的描述。如第 3 步中所示，UDDI 注冊中心會給每個實體指定一個在程序中唯一的標識符，叫做唯一通用標識符（Unique Universal Identifier，UUID）鍵，從而能隨時了解所有這些實體的情況。UUID 鍵必須是唯一的，并且在一個 UDDI 注冊中心中從來都不會變化。這些鍵看上去象格式化好的十六進制隨機字符串（例如 C0B9FE13-179F-413D-8A5B-5004DB8E5BB2）。可以利用這些鍵來引用與之相關聯的實體。在一個注冊中心中創建的 UUID 鍵只在該注冊中心的上下文中有效。

在第 4 步，諸如電子交易場所（e-Marketplace）和搜索引擎等其它類型的客戶機與商業應用程序（例如，基于工作流聚合起來的 Web 服務）使用 UDDI 注冊中心來發現它們感興趣的服務。接著，另外的企業就可以調用這些服務，簡便的進行動態集成，如第 5 步中所述。

UDDI 注冊中心里的數據從概念上可以分為四類，每一類表示 UDDI 最上層的一種實體。每個這樣的實體都指定有自己的 UUID，利用這個標識符總能在 UDDI 注冊中心的上下文中找到它：

  • 技術模型（Technical model）
  • 企業（Business）
  • 企業服務（Business service）
  • 服務綁定（Service binding）

 

我們可以把企業與服務的注冊信息分成以下三組：白頁、黃頁和綠頁。

白頁表示有關企業的基本信息，如企業名稱、經營范圍的描述、聯系信息等等。它還包括該企業任何一種標識符，如 Dun & Bradstreet D-U-N-S® 號碼。

黃頁信息通過支持使用多種具有分類功能的分類法系統產生的類別劃分，使您能夠在更大的范圍內查找在注冊中心注冊的企業或服務。這樣的類別劃分不僅可以關聯企業及其服務，還可以關聯 tModel。單提供白頁和黃頁中的一種或者這兩種都提供，那么對于通過程序發現和使用服務，注冊中心的條目的價值就很有限。為此，有關怎樣、哪里能通過程序的方式調用服務的信息就很有必要了，而綠頁就提供了這樣的信息。

綠頁是指與服務相關聯的綁定信息，并提供了指向這些服務所實現的技術規范的引用和指向基于文件的 URL 的不同發現機制的指針。

UDDI 注冊中心由 UDDI 規范的一種或多種實現組成，它們可以互操作以共享注冊中心數據。有一種特殊的 UDDI 注冊中心是由一組對外公開訪問的叫做節點的 UDDI 實現構成。它們互操作以共享注冊中心數據，合在一起就形成了 UDDI 業務注冊中心。該注冊中心免費向大眾開放。在所有的運營商（Operator）站點上都冗余的放著 UDDI 業務注冊中心的全部條目，但只有在創建條目的站點才能對條目進行更改。

IBM 和 Microsoft 共同經營第 1 版的 UDDI 業務注冊中心節點，這兩個公司以及 HP 和 SAP 目前正在經營能支持大部分的第 2 版 UDDI 規范的 beta 測試站點。這四家公司計劃于 2002 年年中支持版本 2 生產注冊中心。每家公司都支持由 UDDI 規范定義的 SOAP API。通過商務合同來確保一致。幾家公司可以自由提供超出規范所要求的服務范圍之外的附加服務，比如，基于瀏覽器的用戶界面（所有公司都做到了這一點）。


回頁首


UDDI 規范一窺

UDDI 規范是由一些文檔組成的。API 規范描述允許您執行發現和發布操作的 SOAP API。還描述了請求／響應語義和錯誤處理。此外，還有大量關于約定和用法的信息。附帶的文檔包括數據結構規范（Data Structure specification）和 API Schema，它們定義了消息和數據語義。

UDDI API 屬于 Inquiry 或 Publishing 類別。第 1 版支持 API 操作，如 清單 1 中所示。


清單 1. UDDI V1 API 綜述
Inquiry Operations:      Publishing Operations:
            Find                      Save
            find_business             save_business
            find_service              save_service
            find_binding              save_binding
            find_tModel               save_tModel
            Get details               Delete
            get_businessDetail        delete_business
            get_serviceDetail         delete_service
            get_bindingDetail         delete_binding
            get_tModelDetail          delete_tModel
            get_registeredInfo        get_registeredInfo
            Security
            get_authToken
            discard_authToken

查詢 API 把自身歸為三種查詢模式：

UDDI 版本 2.0

UDDI 在數據模型內定義了四種核心數據元素：

  • businessEntity（建立企業信息模型）
  • businessService（描述服務）
  • tModel（描述規范、分類或標識）
  • binding Template（在 businessService 和描述其技術特征的 tModel 集之間進行映射）
除這些核心元素之外，版本 2 添加了建立企業之間的關系模型的支持。

UDDI 規范和 UDDI 業務注冊中心提供了一組參考實現，它們之間互操作共享注冊、依據客戶機需要啟用支持設計時或運行時發現服務的編程模型。IBM Web 服務倡議（Web Services Initiative）的即時集成價值取向加上其它重要的使能技術（例如 WSDL）允許機構執行在運行時動態發現和綁定 Web 服務。

UDDI 規范一直以來的不斷發展解決了關鍵領域內的問題（例如數據完整性、訪問控制、身份識別、認證、互操作性、改進的數據建模能力、查詢和本地化）進一步增加了 UDDI 注冊中心的價值。

 

  • 瀏覽器模式需要使用查找操作，查找操作允許您在瀏覽條目時使用不同類型的標準，例如分類法類別、標識符或利用 find_xxx API 查找不完整的名稱信息。
  • 逐步深入模式涉及到獲得有關您已經找到的條目的詳細信息。 get_xxx API 支持這一功能。
  • 調用模式是最后一種模式。調用服務需要使用綁定模板信息，通常客戶機將這一信息放在緩存區以供重復使用，不需要客戶機在每次需要時再回到注冊中心去獲取同樣的信息。如果綁定信息變化了，那么一旦無法獲得或使用服務，客戶機就會返回到注冊中心以更新這一信息。這被稱為調用模式。

 

雖然每個頂層實體都可以被保存和刪除（利用 save_xxx 和 delete_xxx API），而且主要是自動說明的，但是應該注意，通常 UDDI 中的保存操作的行為具有破壞性。舉個例子，再次保存同一個服務，但信息有所不同，結果以前代表該服務的那個實體會被完全替換掉。

與 authTokens 有關的操作要求您向某個 UDDI 業務注冊中心節點預注冊，提供確認發布者身份所必需的憑證。這些憑證用于獲取用于執行發布操作（利用 save_xxx API）的 authToken 。如果我們假定 authToken 沒有過期，在緊緊相隨的發布操作期間有一小段時間內它是可以重用的。運營商制訂的規定將決定 authToken 的內容和壽命。





回頁首


UDDI 版本 2 中有哪些新內容？

UDDI 版本 2 引入了一些很關鍵的功能，有了這些功能可以提高版本 1 規范 UDDI 注冊中心的使用質量和效率。下面會分幾部分描述版本 2 中的新功能：

  • 為復雜機構提供建模支持
  • 更強大的客戶機分類和標識符支持
  • 增強的查詢
  • 國際化功能
  • 基于對等的復制

 


回頁首


支持建模

有關支持建模的更新主要目的在于幫助大的機構更高效的建立其企業和服務的模型。從牽涉到不同種類的風險的大型集團企業到集中精力經營一種業務而且希望按它們服務的地理區域來劃分其 Web 產品的公司，許多都希望它們在 Web 上表現為獨立卻相互關聯的企業。在 UDDI 版本 1 中，對于這些情況，唯一的選擇就是保持企業獨立但卻毫無關系。版本 2 允許您定義企業之間的關系，例如 父－子關系、 伙伴－伙伴關系和 等同關系。這樣，您就能根據具體情況為有下屬子公司、外部業務伙伴或者內部的各種部門的公司建立模型。任意兩個企業（據其獨一無二的企業鍵的定義）之間都可能會形成關系。新建的 Business Relationship 類型的規范的 tModel 支持這一能力，而且還有一些新的發布 API，允許您定義、刪除和請求關系的狀態，如 清單 2 中所示。

名叫 find_relatedBusinesses 的新查詢 API 使您能就給定的公司匿名搜索涉及到它的關系。 清單 2 中的其它新的發布 API 都與特定的發布者創建并擁有的關系有關，并且這些關系都不能通過匿名查詢來訪問。一個企業關系由一對相同的關系斷言組成，每個關系斷言都會將這兩家企業連在一起，并標志所建立的特定關系。為了形成外部可見的企業關系，所涉及的兩家企業每家必須聲明相同的關系斷言。只有那些匹配的關系斷言才會作為 find_relatedBusinesses() 查詢結果返回。

下面的示例展示了關系怎樣形成，日后怎樣發現關系。首先，您會得到一個發布授權令牌：


清單 2. 得到一個 authToken
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
            <Body>
            <get_authToken generic="2.0"
            xmlns="urn:uddi-org:api_v2"
            userID="businessA_UserId"
            cred="businessA_Password" />
            </Body>
            </Envelope>

其返回內容如下：


清單 3. 得到 authToken 的響應
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
            <Body>
            <authToken generic="2.0"
            operator="www.ibm.com/services/uddi"
            xmlns="urn:uddi-org:api_v2" >
            <authInfo>businessA_AuthToken</authInfo>
            </authToken>
            </Body>
            </Envelope>

接著，您建立一個企業斷言將企業 A 和企業 B 聯系起來，在此我們不使用典型的 UUID 格式，而是把它們的 businessKeys 分別簡寫為 businessKeyA和 businessKeyB 。為了簡潔起見，我們不再展示 SOAP 信封。 

<add_publisherAssertions generic="2.0"
            xmlns="urn:uddi-org:api_v2">
            <authInfo>businessA_AuthToken</authInfo>
            <publisherAssertion>
            <fromKey>"businessKeyA"</fromKey>
            <toKey>"businessKeyB"</toKey>
            <keyedReference keyValue="parent-child"
            keyName="Subsidiary"
            tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"/>
            </publisherAssertion>
            </add_publisherAssertions>

一旦企業 B 的主人也建立了一個相同的斷言，就能在注冊中心中看到一個對大眾公開可見的企業關系。然后，您可以利用 find_relatedBusinesses() API 執行一個簡單的查詢： 

<find_relatedBusinesses generic="2.0"
            xmlns="urn:uddi-org:api_v2">
            <businessKey>"businessKeyA"</businessKey>
            </find_relatedBusinesses>

清單 3 展示了返回的 XML。更加細粒度的查詢可能會包括一個標識正在查找的特定關系的 keyedReference 。

版本 2 中為支持大企業的建模需求而新增的另一項重要功能叫做服務投影（Service Projection），它允許一家企業創建對另一家企業擁有的服務的引用。這在有些情況下是很有用的，例如，對于在兩個或以上的行業內提供相同的服務的公司和通用服務（例如過夜運輸）都很有用，有許多企業都想要把某個通用服務鏈接到它們自己提供的服務上來鼓勵使用這種服務。

投影的服務引用的功能不過如此。服務投影的創建者不能改變所引用的真正服務，但在其它所有方面，這個服務都好象真的是創建投影的企業所擁有一樣。服務是 get_businessDetail() 或 get_serviceDetail() API 調用返回的一部分。通過與服務相關聯的具有所有權的企業鍵，您可以把投影服務與真正的服務區分開來。這個鍵始終與擁有服務的真正企業相匹配，而不是與創建服務投影的企業相配。





回頁首


強大的分類功能

在版本 1 中提供了三種內置的分類法供為企業和服務分類使用。它們是 NAICS 行業分類法、UNSPC 項目和服務分類法和 ISO-3166-2 地理分類法。UDDI 注冊中心會在內部檢查這些分類法的使用情況；試圖保存無效的代碼會遭到拒絕。在 UDDI 中有針對性的分類法的重要性再怎么強調也不會過分。既然查找感興趣的有用信息功能最為強大的方法只有這一種，那么提高業界創建和控制新的分類法的能力將繼續占有較高的優先級。

版本 2 新增的能力使機構能定義新的外部檢查的分類法，可以在 UDDI 中提供這些分類法供大眾使用。這些外部分類法提供者必須支持 validate_values Web 服務，并使 UDDI 業務注冊中心能夠訪問該服務，以支持對客戶機想要與它們在注冊中心中的條目相關聯的分類法值進行外部檢查和驗證。這是一個受控的過程。只有得到 UDDI 業務注冊中心運營商的批準，外部驗證的分類法才能完成注冊。

這個驗證新功能允許分類法提供者以靈活的方式來保證使用它們的分類法客戶機只能保存那些有效的分類法值。當客戶機請求使用提供者的分類法的時候，提供者在驗證請求者是否是合法使用分類法之外，還可以選擇進行有上下文的驗證。更為常見的無上下文方案也支持將分類法數據緩存在 UDDI 業務注冊中心以減少對提供者的外部分類法服務的依賴。


回頁首


增強的查詢

版本 2 在以前提供的查詢能力的基礎上添加了一些強大的功能來按更復雜的要求進行查詢。為了增強現有的 find_xxx 查詢 API 添加了幾種新的過濾條件（查找限定符），包括 orLikeKeys 、 orAllKeys 、 combineCategoryBags 、 serviceSubset 和 andAllKeys 。其中，我們特別感興趣的有 combineCategoryBags 、 serviceSubset 和 orLikeKeys 。

combineCategoryBags 限定符允許您將與一個企業相關聯的所有分類法數據以及該企業所包含的所有服務（包括任何服務投影）分在一個集合內，然后就對這個集合執行搜索。這個限定符有用的原因在于，通過同時查看企業和它所包括的服務減少了查找感興趣的企業的步驟。

同樣， serviceSubset 過濾器允許您使用分類法標準來搜索企業，只對與構成企業的服務相關聯的分類進行這樣的測試。在這種搜索方法中不包括與企業本身相關聯的分類。

最后， orLikeKeys 限定符特別有用，因為它支持復雜的偽碼查詢。例如，您可以查找位于美國、墨西哥或者加拿大同時提供冷藏服務或一般的運輸服務的企業。這使您可以搜索分在不同特征級別的類別中的企業，同時允許一個查詢條件引用多種不同分類法。





回頁首


國際化

一直以來都在努力改進 UDDI 的國際化程度，現在已經添加了一些新功能。已經給 businessEntity 和 businessService 增加了對多個名字和 xml:lang 代碼的支持。雖然您必須提供至少一個名字，但是也可以提供多個名字（每個名字使用一種不同的語言代碼）。

版本 2 中的另一個國際化功能是新增了一類分類法，叫做 postalAddress ，它能讓您創建描述本地化郵政地址的 tModel，然后把它們與在業務實體中找到的地址相關聯。





回頁首


復制

雖然 UDDI 客戶機不能直接看到，但版本 2 已經對注冊中心運營商之間的復制操作做了重大改進。UDDI 版本 1 僅支持基于文件的復制模式，隨參與到 UDDI 注冊中心中的注冊中心節點實現數目的增長，其復雜程度以 n 的平方增長。版本 2 能滿足數目更多的參與節點，它們相互復制。復制可以以一種基于對等的方式進行，在任何一個節點上都可以獲得在其它所有節點上發生的注冊中心更新。現在由于定義了一組允許處理更改和過程管理的 API，復制得到了更進一步的支持。


回頁首


下一步

UDDI 規范的下一版本計劃在 2002 年年中推出，重點在安全性、高級數據管理以及進一步的國際化上。通過增強訪問控制、身份標識和認證提高 UDDI 數據完整性從而使安全性問題得以解決。這要包括支持如 W3C 和 OASIS 這樣的機構提供的現有的和新興的安全性技術。高級數據管理功能將繼續增強搜索能力以提供更為精確和命中率更高的查詢、更好的解釋查詢結果、對企業和服務更為豐富且更有意義的描述的捕捉能力以及更好管理現有數據。對國際化的改進將包括支持跨國公司描述其在國際業務分支所進行全球操作，還將解決 UDDI 數據和服務的本地化問題。





回頁首


結束語

UDDI 繼續快速發展。由多家 UDDI 業務注冊中心運營商于 2001 年提供 UDDI 版本 2 對公眾開放測試版實現。隨著這個規范的版本 3 將于 2002 年年中出現，注冊中心會繼續添加通過 Web 做生意、解決安全性和逐步提高的國際化等領域的問題所需要的功能，及一些附加功能以支持使用注冊中心和互操作性。



參考資料



關于作者

作者

Tom Bellwood 是在 IBM 工作的一位資深技術人員，很多年都從事技術方面的工作，范圍從半導體設計領域和設計自動化到開發系統和應用程序。他是一位 UDDI 和 UDDI 如何支持不斷發展的 Web 服務世界方面的專家。他還是 IBM UDDI 業務注冊中心的技術主管，曾多次在技術會議上發言。