http://www-128.ibm.com/developerworks/cn/webservices/ws-featuddi/
跟上規(guī)范的不斷發(fā)展
Tom Bellwood
資深技術人員, IBM
2002 年 7 月
統(tǒng)一描述、發(fā)現(xiàn)和集成（Universal Description, Discovery, and Integration，UDDI）項目繼續(xù)豐富企業(yè)用于在 UDDI 業(yè)務注冊中心表示 Web 服務并建立其模型的工具集。本文將介紹 UDDI 和它在 Web 服務發(fā)展過程中所起到的促進作用。您可以了解到 UDDI 的工作原理，并發(fā)現(xiàn) UDDI 規(guī)范新的即將出現(xiàn)的功能。
何為 UDDI？
UDDI 項目鼓勵 Web 服務相互操作和相互采用。它是一種工商界居于領先地位的企業(yè)之間的伙伴關系，這種關系最早是由 IBM、Ariba 和 Microsoft 建立的。現(xiàn)在參加的公司已逾 300 家。UDDI 提供了一組基于標準的規(guī)范用于描述和發(fā)現(xiàn)服務，還提供了一組基于因特網的實現(xiàn)。UDDI 繼續(xù)快速發(fā)展，并贏得了業(yè)界的支持。這一規(guī)范之所以發(fā)展很快，是因為有快速實現(xiàn)在背后提供支持，不僅證明了思想，而且為進一步完善規(guī)范提供了豐富的實踐基礎。
UDDI 解決了企業(yè)遇到的大量問題。首先，它能幫助拓展商家到商家（B2B）交互的范圍并能簡化交互的過程。對于那些需要與不同顧客建立許多種關系的廠家來說，每家都有自己的一套標準與協(xié)議，UDDI 支持一種適應性極強的服務描述，幾乎可以使用任何接口。對于一家地處澳洲的花店，雖然很希望能進入世界上的所有市場，但苦于不知道怎樣才能成功，UDDI 提供了一種能實現(xiàn)這一目標的辦法。規(guī)范允許企業(yè)在注冊中心中發(fā)布它所提供的服務，這樣發(fā)現(xiàn)企業(yè)及服務就變得高效而且簡單了。
對于 B2B 交易場所提供者，他們需要獲得這一行業(yè)內的供應商的分類數(shù)據(jù)，以及它們與計費服務、包裝商、運輸商、保險公司等之間的關系，UDDI 允許動態(tài)發(fā)現(xiàn)相關的 Web 服務并將其集成到聚合的業(yè)務過程中。UDDI 提供一站式搜索有關企業(yè)和電子化服務的信息。在 UDDI 中發(fā)布企業(yè)與服務信息使其它企業(yè)能大范圍的訪問到這些信息。
UDDI 基于現(xiàn)成的標準，如可擴展標記語言（Extensible Markup Language，XML）和簡單對象訪問協(xié)議（Simple Object Access Protocol，SOAP）。UDDI 的所有兼容實現(xiàn)都支持 UDDI 規(guī)范。公共規(guī)范是機構成員在開放的、兼容并蓄的過程中開發(fā)出來的。目的在于先生成并實現(xiàn)這個規(guī)范的三個連續(xù)版本，之后再把將來開發(fā)得到的成果的所有權移交給一個獨立的標準組織。UDDI 版本 1 規(guī)范于 2000 年 9 月發(fā)布，版本 2 于 2001 年 6 月發(fā)布。版本 3 還在開發(fā)中，預計到 2002 年年中發(fā)布。版本 1 打下了注冊中心的基礎，版本 2 則添加了企業(yè)關系等功能，版本 3 接下去要解決正在進行的 Web 服務開發(fā)中的重要領域內的問題，如安全性、改善了的國際化、注冊中心之間的互操作性以及為進一步改進工具而對 API 進行的各種改進。
圖 1. UDDI 的分層 Web 服務協(xié)議棧
如 圖 1中所示，UDDI 包含于完整的 Web 服務協(xié)議棧之內，而且是協(xié)議棧基礎的主要部件之一，支持創(chuàng)建、說明、發(fā)現(xiàn)和調用 Web 服務。
UDDI 構建于網絡傳輸層和基于 SOAP 的 XML 消息傳輸層之上。諸如 Web 服務描述語言（Web Services Description Language，WSDL）之類的服務描述語言提供了統(tǒng)一的 XML 詞匯（與交互式數(shù)據(jù)語言（Interactive Data Language，IDL）類似）供描述 Web 服務及其接口使用。您可以通過添加分層的功能搭起整個基礎，比如使用 Web 服務流程語言（Web Services Flow Language，WSFL）的 Web 服務工作流描述、安全性、管理和服務質量功能，從而解決系統(tǒng)可靠性和可用性問題。
UDDI 的工作原理
UDDI 注冊中心包含了通過程序手段可以訪問到的對企業(yè)和企業(yè)支持的服務所做的描述。此外，還包含對 Web 服務所支持的因行業(yè)而異的規(guī)范、分類法定義（用于對于企業(yè)和服務很重要的類別）以及標識系統(tǒng)（用于對于企業(yè)很重要的標識）的引用。UDDI 提供了一種編程模型和模式，它定義與注冊中心通信的規(guī)則。UDDI 規(guī)范中所有 API 都用 XML 來定義，包裝在 SOAP 信封中，在 HTTP 上傳輸。
圖 2. UDDI 消息在客戶機和注冊中心之間的流動
圖 2 說明了 UDDI 消息的傳輸，通過 HTTP 從客戶機的 SOAP 請求傳到注冊中心節(jié)點，然后再反向傳輸。注冊中心服務器的 SOAP 服務器接收 UDDI SOAP 消息、進行處理，然后把 SOAP 響應返回給客戶機。就注冊中心條例而言，客戶機發(fā)出的要修改數(shù)據(jù)的請求必須確保是安全的、經過驗證的事務。
圖 3. UDDI 工作原理
圖 3說明了如何往 UDDI 注冊中心送入數(shù)據(jù)，顧客又如何能發(fā)現(xiàn)和使用這一信息。UDDI 注冊中心建立在顧客提供的數(shù)據(jù)的基礎之上。要使數(shù)據(jù)能在 UDDI 中物盡其用需要幾個步驟。如第 1 步中所示，在軟件公司和標準組織定義關于在 UDDI 中注冊的行業(yè)或企業(yè)的規(guī)范時，開始向注冊中心發(fā)布有用的信息。這些規(guī)范叫做技術模型或者更常見的說法是 tModel 。
在第 2 步中，公司還會注冊關于其業(yè)務及其提供的服務的描述。如第 3 步中所示，UDDI 注冊中心會給每個實體指定一個在程序中唯一的標識符，叫做唯一通用標識符（Unique Universal Identifier，UUID）鍵，從而能隨時了解所有這些實體的情況。UUID 鍵必須是唯一的，并且在一個 UDDI 注冊中心中從來都不會變化。這些鍵看上去象格式化好的十六進制隨機字符串（例如 C0B9FE13-179F-413D-8A5B-5004DB8E5BB2）。可以利用這些鍵來引用與之相關聯(lián)的實體。在一個注冊中心中創(chuàng)建的 UUID 鍵只在該注冊中心的上下文中有效。
在第 4 步，諸如電子交易場所（e-Marketplace）和搜索引擎等其它類型的客戶機與商業(yè)應用程序（例如，基于工作流聚合起來的 Web 服務）使用 UDDI 注冊中心來發(fā)現(xiàn)它們感興趣的服務。接著，另外的企業(yè)就可以調用這些服務，簡便的進行動態(tài)集成，如第 5 步中所述。
UDDI 注冊中心里的數(shù)據(jù)從概念上可以分為四類，每一類表示 UDDI 最上層的一種實體。每個這樣的實體都指定有自己的 UUID，利用這個標識符總能在 UDDI 注冊中心的上下文中找到它：
- 技術模型（Technical model）
- 企業(yè)（Business）
- 企業(yè)服務（Business service）
- 服務綁定（Service binding）
我們可以把企業(yè)與服務的注冊信息分成以下三組：白頁、黃頁和綠頁。
白頁表示有關企業(yè)的基本信息，如企業(yè)名稱、經營范圍的描述、聯(lián)系信息等等。它還包括該企業(yè)任何一種標識符，如 Dun & Bradstreet D-U-N-S? 號碼。
黃頁信息通過支持使用多種具有分類功能的分類法系統(tǒng)產生的類別劃分，使您能夠在更大的范圍內查找在注冊中心注冊的企業(yè)或服務。這樣的類別劃分不僅可以關聯(lián)企業(yè)及其服務，還可以關聯(lián) tModel。單提供白頁和黃頁中的一種或者這兩種都提供，那么對于通過程序發(fā)現(xiàn)和使用服務，注冊中心的條目的價值就很有限。為此，有關怎樣、哪里能通過程序的方式調用服務的信息就很有必要了，而綠頁就提供了這樣的信息。
綠頁是指與服務相關聯(lián)的綁定信息，并提供了指向這些服務所實現(xiàn)的技術規(guī)范的引用和指向基于文件的 URL 的不同發(fā)現(xiàn)機制的指針。
UDDI 注冊中心由 UDDI 規(guī)范的一種或多種實現(xiàn)組成，它們可以互操作以共享注冊中心數(shù)據(jù)。有一種特殊的 UDDI 注冊中心是由一組對外公開訪問的叫做節(jié)點的 UDDI 實現(xiàn)構成。它們互操作以共享注冊中心數(shù)據(jù)，合在一起就形成了 UDDI 業(yè)務注冊中心。該注冊中心免費向大眾開放。在所有的運營商（Operator）站點上都冗余的放著 UDDI 業(yè)務注冊中心的全部條目，但只有在創(chuàng)建條目的站點才能對條目進行更改。
IBM 和 Microsoft 共同經營第 1 版的 UDDI 業(yè)務注冊中心節(jié)點，這兩個公司以及 HP 和 SAP 目前正在經營能支持大部分的第 2 版 UDDI 規(guī)范的 beta 測試站點。這四家公司計劃于 2002 年年中支持版本 2 生產注冊中心。每家公司都支持由 UDDI 規(guī)范定義的 SOAP API。通過商務合同來確保一致。幾家公司可以自由提供超出規(guī)范所要求的服務范圍之外的附加服務，比如，基于瀏覽器的用戶界面（所有公司都做到了這一點）。
UDDI 規(guī)范一窺
UDDI 規(guī)范是由一些文檔組成的。API 規(guī)范描述允許您執(zhí)行發(fā)現(xiàn)和發(fā)布操作的 SOAP API。還描述了請求／響應語義和錯誤處理。此外，還有大量關于約定和用法的信息。附帶的文檔包括數(shù)據(jù)結構規(guī)范（Data Structure specification）和 API Schema，它們定義了消息和數(shù)據(jù)語義。
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 在數(shù)據(jù)模型內定義了四種核心數(shù)據(jù)元素：
- businessEntity（建立企業(yè)信息模型）
- businessService（描述服務）
- tModel（描述規(guī)范、分類或標識）
- binding Template（在 businessService 和描述其技術特征的 tModel 集之間進行映射）
除這些核心元素之外，版本 2 添加了建立企業(yè)之間的關系模型的支持。
UDDI 規(guī)范和 UDDI 業(yè)務注冊中心提供了一組參考實現(xiàn)，它們之間互操作共享注冊、依據(jù)客戶機需要啟用支持設計時或運行時發(fā)現(xiàn)服務的編程模型。IBM Web 服務倡議（Web Services Initiative）的即時集成價值取向加上其它重要的使能技術（例如 WSDL）允許機構執(zhí)行在運行時動態(tài)發(fā)現(xiàn)和綁定 Web 服務。
UDDI 規(guī)范一直以來的不斷發(fā)展解決了關鍵領域內的問題（例如數(shù)據(jù)完整性、訪問控制、身份識別、認證、互操作性、改進的數(shù)據(jù)建模能力、查詢和本地化）進一步增加了 UDDI 注冊中心的價值。
|
- 瀏覽器模式需要使用查找操作，查找操作允許您在瀏覽條目時使用不同類型的標準，例如分類法類別、標識符或利用
find_xxx API 查找不完整的名稱信息。
- 逐步深入模式涉及到獲得有關您已經找到的條目的詳細信息。
get_xxx API 支持這一功能。
- 調用模式是最后一種模式。調用服務需要使用綁定模板信息，通常客戶機將這一信息放在緩存區(qū)以供重復使用，不需要客戶機在每次需要時再回到注冊中心去獲取同樣的信息。如果綁定信息變化了，那么一旦無法獲得或使用服務，客戶機就會返回到注冊中心以更新這一信息。這被稱為調用模式。
雖然每個頂層實體都可以被保存和刪除（利用 save_xxx 和 delete_xxx API），而且主要是自動說明的，但是應該注意，通常 UDDI 中的保存操作的行為具有破壞性。舉個例子，再次保存同一個服務，但信息有所不同，結果以前代表該服務的那個實體會被完全替換掉。
與 authTokens 有關的操作要求您向某個 UDDI 業(yè)務注冊中心節(jié)點預注冊，提供確認發(fā)布者身份所必需的憑證。這些憑證用于獲取用于執(zhí)行發(fā)布操作（利用 save_xxx API）的 authToken 。如果我們假定 authToken 沒有過期，在緊緊相隨的發(fā)布操作期間有一小段時間內它是可以重用的。運營商制訂的規(guī)定將決定 authToken 的內容和壽命。
UDDI 版本 2 中有哪些新內容？
UDDI 版本 2 引入了一些很關鍵的功能，有了這些功能可以提高版本 1 規(guī)范 UDDI 注冊中心的使用質量和效率。下面會分幾部分描述版本 2 中的新功能：
- 為復雜機構提供建模支持
- 更強大的客戶機分類和標識符支持
- 增強的查詢
- 國際化功能
- 基于對等的復制
支持建模
有關支持建模的更新主要目的在于幫助大的機構更高效的建立其企業(yè)和服務的模型。從牽涉到不同種類的風險的大型集團企業(yè)到集中精力經營一種業(yè)務而且希望按它們服務的地理區(qū)域來劃分其 Web 產品的公司，許多都希望它們在 Web 上表現(xiàn)為獨立卻相互關聯(lián)的企業(yè)。在 UDDI 版本 1 中，對于這些情況，唯一的選擇就是保持企業(yè)獨立但卻毫無關系。版本 2 允許您定義企業(yè)之間的關系，例如 父－子關系、 伙伴－伙伴關系和 等同關系。這樣，您就能根據(jù)具體情況為有下屬子公司、外部業(yè)務伙伴或者內部的各種部門的公司建立模型。任意兩個企業(yè)（據(jù)其獨一無二的企業(yè)鍵的定義）之間都可能會形成關系。新建的 Business Relationship 類型的規(guī)范的 tModel 支持這一能力，而且還有一些新的發(fā)布 API，允許您定義、刪除和請求關系的狀態(tài)，如 清單 2 中所示。
名叫 find_relatedBusinesses 的新查詢 API 使您能就給定的公司匿名搜索涉及到它的關系。 清單 2 中的其它新的發(fā)布 API 都與特定的發(fā)布者創(chuàng)建并擁有的關系有關，并且這些關系都不能通過匿名查詢來訪問。一個企業(yè)關系由一對相同的關系斷言組成，每個關系斷言都會將這兩家企業(yè)連在一起，并標志所建立的特定關系。為了形成外部可見的企業(yè)關系，所涉及的兩家企業(yè)每家必須聲明相同的關系斷言。只有那些匹配的關系斷言才會作為 find_relatedBusinesses() 查詢結果返回。
下面的示例展示了關系怎樣形成，日后怎樣發(fā)現(xiàn)關系。首先，您會得到一個發(fā)布授權令牌：
清單 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>
|
接著，您建立一個企業(yè)斷言將企業(yè) A 和企業(yè) B 聯(lián)系起來，在此我們不使用典型的 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>
|
一旦企業(yè) B 的主人也建立了一個相同的斷言，就能在注冊中心中看到一個對大眾公開可見的企業(yè)關系。然后，您可以利用 find_relatedBusinesses() API 執(zhí)行一個簡單的查詢：
<find_relatedBusinesses generic="2.0"
xmlns="urn:uddi-org:api_v2">
<businessKey>"businessKeyA"</businessKey>
</find_relatedBusinesses>
|
清單 3 展示了返回的 XML。更加細粒度的查詢可能會包括一個標識正在查找的特定關系的 keyedReference 。
版本 2 中為支持大企業(yè)的建模需求而新增的另一項重要功能叫做服務投影（Service Projection），它允許一家企業(yè)創(chuàng)建對另一家企業(yè)擁有的服務的引用。這在有些情況下是很有用的，例如，對于在兩個或以上的行業(yè)內提供相同的服務的公司和通用服務（例如過夜運輸）都很有用，有許多企業(yè)都想要把某個通用服務鏈接到它們自己提供的服務上來鼓勵使用這種服務。
投影的服務引用的功能不過如此。服務投影的創(chuàng)建者不能改變所引用的真正服務，但在其它所有方面，這個服務都好象真的是創(chuàng)建投影的企業(yè)所擁有一樣。服務是 get_businessDetail() 或 get_serviceDetail() API 調用返回的一部分。通過與服務相關聯(lián)的具有所有權的企業(yè)鍵，您可以把投影服務與真正的服務區(qū)分開來。這個鍵始終與擁有服務的真正企業(yè)相匹配，而不是與創(chuàng)建服務投影的企業(yè)相配。
強大的分類功能
在版本 1 中提供了三種內置的分類法供為企業(yè)和服務分類使用。它們是 NAICS 行業(yè)分類法、UNSPC 項目和服務分類法和 ISO-3166-2 地理分類法。UDDI 注冊中心會在內部檢查這些分類法的使用情況；試圖保存無效的代碼會遭到拒絕。在 UDDI 中有針對性的分類法的重要性再怎么強調也不會過分。既然查找感興趣的有用信息功能最為強大的方法只有這一種，那么提高業(yè)界創(chuàng)建和控制新的分類法的能力將繼續(xù)占有較高的優(yōu)先級。
版本 2 新增的能力使機構能定義新的外部檢查的分類法，可以在 UDDI 中提供這些分類法供大眾使用。這些外部分類法提供者必須支持 validate_values Web 服務，并使 UDDI 業(yè)務注冊中心能夠訪問該服務，以支持對客戶機想要與它們在注冊中心中的條目相關聯(lián)的分類法值進行外部檢查和驗證。這是一個受控的過程。只有得到 UDDI 業(yè)務注冊中心運營商的批準，外部驗證的分類法才能完成注冊。
這個驗證新功能允許分類法提供者以靈活的方式來保證使用它們的分類法客戶機只能保存那些有效的分類法值。當客戶機請求使用提供者的分類法的時候，提供者在驗證請求者是否是合法使用分類法之外，還可以選擇進行有上下文的驗證。更為常見的無上下文方案也支持將分類法數(shù)據(jù)緩存在 UDDI 業(yè)務注冊中心以減少對提供者的外部分類法服務的依賴。
增強的查詢
版本 2 在以前提供的查詢能力的基礎上添加了一些強大的功能來按更復雜的要求進行查詢。為了增強現(xiàn)有的 find_xxx 查詢 API 添加了幾種新的過濾條件（查找限定符），包括 orLikeKeys 、 orAllKeys 、 combineCategoryBags 、 serviceSubset 和 andAllKeys 。其中，我們特別感興趣的有 combineCategoryBags 、 serviceSubset 和 orLikeKeys 。
combineCategoryBags 限定符允許您將與一個企業(yè)相關聯(lián)的所有分類法數(shù)據(jù)以及該企業(yè)所包含的所有服務（包括任何服務投影）分在一個集合內，然后就對這個集合執(zhí)行搜索。這個限定符有用的原因在于，通過同時查看企業(yè)和它所包括的服務減少了查找感興趣的企業(yè)的步驟。
同樣， serviceSubset 過濾器允許您使用分類法標準來搜索企業(yè)，只對與構成企業(yè)的服務相關聯(lián)的分類進行這樣的測試。在這種搜索方法中不包括與企業(yè)本身相關聯(lián)的分類。
最后， orLikeKeys 限定符特別有用，因為它支持復雜的偽碼查詢。例如，您可以查找位于美國、墨西哥或者加拿大同時提供冷藏服務或一般的運輸服務的企業(yè)。這使您可以搜索分在不同特征級別的類別中的企業(yè)，同時允許一個查詢條件引用多種不同分類法。
國際化
一直以來都在努力改進 UDDI 的國際化程度，現(xiàn)在已經添加了一些新功能。已經給 businessEntity 和 businessService 增加了對多個名字和 xml:lang 代碼的支持。雖然您必須提供至少一個名字，但是也可以提供多個名字（每個名字使用一種不同的語言代碼）。
版本 2 中的另一個國際化功能是新增了一類分類法，叫做 postalAddress ，它能讓您創(chuàng)建描述本地化郵政地址的 tModel，然后把它們與在業(yè)務實體中找到的地址相關聯(lián)。
復制
雖然 UDDI 客戶機不能直接看到，但版本 2 已經對注冊中心運營商之間的復制操作做了重大改進。UDDI 版本 1 僅支持基于文件的復制模式，隨參與到 UDDI 注冊中心中的注冊中心節(jié)點實現(xiàn)數(shù)目的增長，其復雜程度以 n 的平方增長。版本 2 能滿足數(shù)目更多的參與節(jié)點，它們相互復制。復制可以以一種基于對等的方式進行，在任何一個節(jié)點上都可以獲得在其它所有節(jié)點上發(fā)生的注冊中心更新。現(xiàn)在由于定義了一組允許處理更改和過程管理的 API，復制得到了更進一步的支持。
下一步
UDDI 規(guī)范的下一版本計劃在 2002 年年中推出，重點在安全性、高級數(shù)據(jù)管理以及進一步的國際化上。通過增強訪問控制、身份標識和認證提高 UDDI 數(shù)據(jù)完整性從而使安全性問題得以解決。這要包括支持如 W3C 和 OASIS 這樣的機構提供的現(xiàn)有的和新興的安全性技術。高級數(shù)據(jù)管理功能將繼續(xù)增強搜索能力以提供更為精確和命中率更高的查詢、更好的解釋查詢結果、對企業(yè)和服務更為豐富且更有意義的描述的捕捉能力以及更好管理現(xiàn)有數(shù)據(jù)。對國際化的改進將包括支持跨國公司描述其在國際業(yè)務分支所進行全球操作，還將解決 UDDI 數(shù)據(jù)和服務的本地化問題。
結束語
UDDI 繼續(xù)快速發(fā)展。由多家 UDDI 業(yè)務注冊中心運營商于 2001 年提供 UDDI 版本 2 對公眾開放測試版實現(xiàn)。隨著這個規(guī)范的版本 3 將于 2002 年年中出現(xiàn)，注冊中心會繼續(xù)添加通過 Web 做生意、解決安全性和逐步提高的國際化等領域的問題所需要的功能，及一些附加功能以支持使用注冊中心和互操作性。
參考資料
關于作者
 Tom Bellwood 是在 IBM 工作的一位資深技術人員，很多年都從事技術方面的工作，范圍從半導體設計領域和設計自動化到開發(fā)系統(tǒng)和應用程序。他是一位 UDDI 和 UDDI 如何支持不斷發(fā)展的 Web 服務世界方面的專家。他還是 IBM UDDI 業(yè)務注冊中心的技術主管，曾多次在技術會議上發(fā)言。 |