使用 UDDI 的 Web 服務描述和發現(第一部分)[轉自微軟]

來源:互聯網
上載者:User
web|微軟 使用 UDDI 的 Web 服務描述和發現(第一部分)
Karsten Januszewski
Microsoft Corporation
2001年10月3日

查看和下載本文的原始碼(英文)。 簡介
到目前為止, At Your Service 專欄已經介紹了如何建立 Web 服務的實際案例:從最初的設計文檔到業務關聯,直至最終的部署。下一步就是要考慮如何發布 Web 服務,以便感興趣的客戶能夠輕鬆地發現該服務並將其應用到自己的應用中。現在已經有了實現這種要求的發現機制:通用說明、發現和整合 (UDDI),這是業界支援跨技術、跨平台的 Web 服務發現的第一步。
At Your Service 的作者誠懇地邀請我為專欄撰文,介紹 UDDI 及其註冊步驟,我非常樂於接受這項工作。首先我將從技術和業務兩方面來介紹 UDDI 的含義。隨後我將討論一下 UDDI 和 Web 服務說明語言 (WSDL) 之間的關係。最後,我將帶您體驗 UDDI 的註冊過程,並介紹一些充分發揮 UDDI 潛力所需考慮的問題。在下一期專欄,即本文的第二部分中,我將介紹 At Your Service 小組是如何充分利用 UDDI 的。 UDDI - Web 服務的全球註冊表
UDDI 是一個公用的註冊表,旨在以一種結構化的方式來儲存有關各公司及其服務的資訊。通過 UDDI,人們發行就緒和發現有關某個公司及其 Web 服務的資訊。這些資料使用標準的分類法進行分類,因此可以按分類來查詢資訊。最重要的是,UDDI 包含有關公司服務的技術介面的資訊。通過一套基於 SOAP 的 XML API 呼叫,使用者可以在設計時和運行時與 UDDI 進行互動以發現技術資料,從而調用和使用這些服務。通過這種方法,UDDI 可以用作基於 Web 服務的軟體系統的基礎結構。
為何使用 UDDI?為何需要這種註冊表?當我們面對具有數千甚至數百萬個 Web 服務的軟體系統時,將面臨以下的嚴峻挑戰:
  • 如何發現 Web 服務?
  • 如何按照某種合理的方式分類資訊?
  • 對本地化有什麼影響?
  • 對專用技術有什麼影響?如何保障發現機制的互通性?
  • 當應用依賴於某項 Web 服務時,如何在運行時與該發現機制進行互動?

UDDI 的出現正是為了應對這些挑戰。為瞭解決這些問題,許多公司,其中包括 Microsoft、IBM、Sun、Oracle、Compaq、HP、Intel、SAP 以及三百多家其他公司(請參閱 UDDI: Community(英文)以獲得這些公司的完整列表),共同制定了一種基於開放式標準和非專用技術的規範。該規範的 Beta 版於 2000 年 12 月發布,正式產品於 2001 年 5 月推出。它是一個全球業務註冊表,建立在多個電訊廠商節點上,使用者可以通過這些節點免費搜尋和發布資訊。
通過 Web 服務的這種基礎結構,現在就能夠以一種通用的、與供應商完全無關的方式找到有關 Web 服務的資料,而且資料一致並且可靠。使用可擴充的分類系統和標識,使用者可以進行精確的分類查詢。運行時 UDDI 整合可以被合并到應用程式中去。因而大大繁榮了 Web 服務軟體環境。 工作原理
UDDI 資料存放在電訊廠商(即承諾運營一個公用節點的公司)節點上。這種公用節點遵循 UDDI.org 組織管理的規範。目前已經建立了兩個遵循 UDDI 規範版本 1 的公用節點:一個屬於 Microsoft;另一個屬於 IBM。HP 也承諾將建立一個遵循規範版本 2 的節點。資料寄存電訊廠商之間必須能通過安全通道複製資料,從而為整個 UDDI 雲團提供資料冗餘。將資料發布到一個節點上後,通過複製,就可以在另一個節點上發現這些資料。目前,每隔 24 小時就進行一次複製;在將來,由於有更多的應用程式要依賴 UDDI 資料,複製的時間間隔還將縮短。
值得一提的是,對於資料寄存電訊廠商實現其節點的方式,不存在一些專用的要求,只要節點遵循 UDDI 規範即可。例如,Microsoft 的節點 http://uddi.microsoft.com/default.aspx(英文)完全用 C# 寫成,並運行於 .NET Beta 2 通用語言執行平台環境下。其代碼基礎充分利用了 .NET 系統類別提供的本地 SOAP 支援和序列化。在後端,Microsoft 電訊廠商節點使用 Microsoft® SQL Server 2000 作為其資料倉儲。而 IBM 使用其他技術來運行其節點!但是,這兩個節點的行為是相同的,因為它們都遵循相同的一套基於 SOAP 的 XML API 呼叫。用戶端工具可以和這些節點進行無縫的互動操作。因此,UDDI 公用雲團是一個最佳方案,它展示了 XML Web 服務模型如何跨異類環境進行工作。
為了瞭解 UDDI,下一步我們來看看 UDDI 中儲存的資料及其儲存結構。UDDI 相對來說是輕量的,它被設計為“註冊表”,而不是“儲備庫”。兩者之間的差別很微妙,但卻很重要。註冊表將使用者重新導向至資源,而儲備庫則完全是一個資訊庫。我們以 Microsoft® Windows® 註冊表為例:它包含基本設定和參數,但最終把應用程式引導至資源或二進位代碼。基於 Prog ID 搜尋 COM 組件時,將引導至一個 Class ID,然後通過 Class ID 再引導至二進位代碼本身所在的位置。
UDDI 的行為與之類似:與 Windows 註冊表一樣,它依靠通用唯一識別碼 (GUID) 來搜尋並定位資源。UDDI 查詢最終指向一個介面(.WSDL、.XSD 和 .DTD 檔案等等),或指向其他伺服器上的實現(例如 .ASMX 或 .ASP 檔案)。UDDI 因此可以回答以下問題:
  • “已經發布了哪些基於 WSDL 並是為指定行業建立的 Web 服務介面?”
  • “哪些公司已經為其中一個介面寫好了實現?”
  • “目前提供的 Web 服務(以某種方式分類)有哪些?”
  • “某個公司提供了哪些 Web 服務?”
  • “如果要使用某個公司的 Web 服務,需要與誰聯絡?”
  • “某個 Web 服務的實現細節是什嗎?”
WSDL 和 UDDI
WSDL 已成為 Web 服務協議堆棧的重要組成部分。因此,有必要掌握 UDDI 和 WSDL 如何協同工作,以及每個協議如何解決介面和實現這兩個相對的概念。WSDL 和 UDDI 都是為清楚說明抽象的中繼資料和具體實現之間的關係而設計的,瞭解為什麼要這麼劃分是理解 WSDL 和 UDDI 的基礎。
例如,WSDL 明確區分訊息和連接埠:訊息(Web 服務所需的文法和語義)始終是抽象的,而連接埠(調用 Web 服務的網路地址)始終是具體的。在 WSDL 檔案中不需要提供連接埠資訊。WSDL 可以只包含抽象的介面資訊,而不提供任何具體的實現資料。這樣的 WSDL 檔案被認為是有效。這樣,WSDL 檔案便從實現中分離出來。
其重要意義之一在於:一個 WSDL 介面可以有多個實現。這種設計允許不同的系統為同一介面編寫自己的實現,從而保證系統之間能進行對話。如果三個不同的公司實現了相同的 WSDL 檔案,一個用戶端軟體根據這個 WSDL 介面建立了代理/存根代碼,那麼這個用戶端軟體就可以使用相同的代碼基礎與所有這三個實現進行通訊,只要更改訪問點即可。
UDDI 通過 tModel 的概念描繪了抽象和實現之間的這種區別。tModel 結構(“技術模型”的簡稱)代表了技術指紋、介面和中繼資料的抽象類別型。使用 tModel 的必然結果是綁定模板,它是一個或多個 tModel 的具體實現。在綁定模板內,要為 tModel 的特定實現註冊訪問點。如同 WSDL 架構允許分離介面和實現一樣,UDDI 也提供了相似的機制,因為 tModel 可以獨立於引用它的綁定模板而單獨發布。例如,某標準化組織或行業組織可能為特定行業發布規範介面,然後多個公司可以為該介面編寫實現。因此,各個公司的實現都需要引用同一個 tModel。WSDL 檔案是 UDDI tModel 的完美樣本。 用 UDDI 進行註冊
發布到 UDDI 是一個比較直接的過程。第一步是確定在 UDDI 上為公司及其服務建立模型所需的基本資料。之後便可以進行實際註冊。這可通過基於 Web 的使用者介面或編程兩種方法完成。最後測試您的註冊條目以確保註冊正確,並且在不同類型的搜尋和工具中都能按要求顯示。

步驟 1:為 UDDI 條目建立模型


考慮上述資料模型,在建立 UDDI 條目之前應準備好幾個關鍵資料。
  1. 確定 Web 服務實現所需使用的 tModel(WSDL 檔案)。
    與開發 COM 組件類似,開發 Web 服務時可以使用現有的介面,也可以使用自己設計的介面。如果 Web 服務基於現有 WSDL,則需要確定該 WSDL 檔案是否已經在 UDDI 上註冊。如果是,就需要記錄其名稱和 tModelKey,這是註冊 WSDL 檔案時 UDDI 所產生的 GUID。
    另一方面,如果 Web 服務所基於的 WSDL 檔案尚未在 UDDI 上註冊,就需要準備建立一個新的 tModel 來代表這個介面。此 tModel 應具有統一資源識別項 (URI) 格式 (MyCompany-com:SampleWebService-interface:v1) 的名稱,並指向 WSDL 檔案所在的位置。
    如果 Web 服務是 Microsoft® Visual Studio® .NET 服務,則可以使用 .ASMX 檔案(也就是:<http://www.mycompany.com/SampleWebService.asmx?wsdl>)中的查詢字串來產生 WSDL 說明。但是,Visual Studio .NET 產生的 WSDL 檔案與調用 Web 服務的訪問點緊密耦合在一起,如果 Web 服務介面有多個實現,訪問點可能就不適用了。如果不希望 WSDL 檔案有多個實現,這就不是問題。
  2. 如果需要,可以用多種語言確定公司的名稱和簡介,以及公司 Web 服務的主要聯絡方法。
    UDDI 支援 xml:lang 名稱空間,它允許公司用多種語言提供公司簡介。另外,UDDI 還允許列出連絡方式,包括電子郵件、電話和地址資訊。聯絡列表用於列出公司內與 Web 服務相關的資源。例如,如果有人想要使用您的 Web 服務,並需要聯絡相應的業務關係經理,應該聯絡誰?使用公司的 Web 服務時,有關技術問題和誰聯絡?該連絡人也應該列出。
  3. 為公司確定適當的分類和標識。
    通過 Microsoft UDDI 節點 http://uddi.microsoft.com/default.aspx(英文)瀏覽當前支援的 UDDI 分類法。當前支援的分類法有北美行業分類系統 (NAICS)、通用標準產品和服務代碼 (UNSPSC)、ISO 3166、標準行業分類 (SIC) 和 GeoWeb 地理分類。請選擇一種最適於您的公司的分類。
  4. 確定公司通過 UDDI 提供的 Web 服務。
    下一步,確定公司要在公用 UDDI 節點上註冊的 Web 服務。這項服務有多個訪問點嗎?是否要給使用此 Web 服務的客戶提供其他必要參數和資訊?
    注意,在 UDDI 上註冊 Web 服務並不意味著每個人都有訪問權。可以為 UDDI 註冊表條目依次設定安全、授權和身分識別驗證。僅知道 Web 服務的存在並不意味著就可以實際調用該服務。在授權訪問 Web 服務之前,公司之間通常需要進行一些額外的交流。
  5. 為服務確定適當的分類。
    如同可以將公司分類一樣,也可以將 Web 服務分類。因此,公司可能按商業層級被分類為 NAICS: Software Publisher (51121),而其旅館預約 Web 服務的服務等級可能被分類為 NAICS: Hotels and Motels (72111)

步驟 2:註冊 UDDI 條目


在完成建模之後,下一步就是註冊您的公司。您需要擷取一個可訪問 UDDI 註冊表的帳號,這不能通過編程來完成,因為必須要同意“使用規定”聲明。Microsoft 節點使用 Passport 進行驗證,您需要擷取一份 Passport (http://www.passport.com/Consumer/default.asp) (英文)來完成註冊。
這裡有兩種選擇:使用 Microsoft 節點提供的 Web 使用者介面,或者通過使用 SOAP API 呼叫節點自身以編程進行註冊。如果不希望更改註冊表條目,或條目相對簡單,則使用 Web 使用者介面就足夠了。但是,如果希望頻繁更新,或條目很複雜,請使用 Microsoft UDDI SDK 製作註冊過程的指令碼。另外,由於沒有針對其他語言對 Microsoft 使用者介面進行本地化,所以如果想利用 UDDI API 的多語言功能,需要通過編程的方法進行註冊。
注意:您可以在類比環境中練習註冊過程,地址是 http://test.uddi.microsoft.com/default.aspx(英文),這是實際投入使用節點的複本。這對於在正式使用之前熟悉註冊過程很有協助。

使用 Microsoft 的 Web 使用者介面


使用 Microsoft 的 Web 使用者介面來註冊是一個相對直觀的過程。首先導航至管理員頁面 http://uddi.microsoft.com/administer.aspx(英文)。登入後,將顯示註冊 tModel 和公司的選項。下面是繼續操作時需要瞭解的幾個事項:
  1. 在註冊服務之前,確保將 WSDL 檔案註冊為 tModel,因為在以後的過程中會需要 tModel。
  2. 將 WSDL 文檔註冊為 tModel 時,應該使用“UDDI 類型分類法”對 tModel 分類。至少應將 WSDL 分類為“Specification for a Web Service”(wsdlSpec)。
    使用這種分類方法,可以確保 tModel 的分類符合“Using WSDL in a UDDI Registry”最佳實務文檔(英文)的原則。因為 tModel 能包含對 WSDL 檔案以外的文檔的引用,所以給 tModel 提供一些分類是很重要的。很多工具(例如 Visual Studio .NET)靠這些分類來縮小查詢的結果集。
  3. 將 WSDL 介面註冊為 tModel 後,需要給公司業務添加相應的聯絡資訊以及分類資訊。只要您認為合適,可以添加任意多的分類。
  4. 繼續添加要通過 UDDI 公開的 Web 服務。因為服務可以有多種實現,所以需要給每個添加的服務添加一個綁定。對於每個綁定,需要提供 Web 服務的訪問點,即 <http://www.mycompany.com/SampleWebService.asmx>。
  5. 每個綁定都需要為所支援的介面建立一個引用。Microsoft UI 將這些作為“規範簽名”來調用。規範簽名就是包含 WSDL 介面的 tModel。Microsoft UI 會提供一個螢幕,允許您基於其 URN 來搜尋 tModel。這個 tModel 可以是在步驟 1 中註冊的,也可以是別人註冊的 WSDL 檔案的 tModel。
  6. 最後,系統會顯示選項,要求提供一個關於特定 Web 服務的概述文檔的 HTTP 地址,以及任何相關的執行個體參數。

使用 Microsoft UDDI .NET SDK 編程進行註冊


註冊過程的另一種選擇是通過編程進行註冊。使用 Microsoft UDDI SDK 可以輕而易舉地完成該過程。您必須使用 Web UI 擷取一個 UDDI 帳號。完成該任務後,其餘過程就交給指令碼來處理。首先,下載並安裝 UDDI SDK,地址是 http://www.microsoft.com/downloads/release.asp?ReleaseID=30880(英文)。然後,使用 Visual Studio .NET 建立一個新的 C# 控制台應用程式。添加一個對 Microsoft UDDI SDK dll 的引用,其預設安裝位置是 C:\Program Files\Microsoft UDDI SDK\VS7\Microsoft.Uddi.Sdk.dll。然後,在代碼頂部添加一些名稱空間引用:
using Microsoft.Uddi;using Microsoft.Uddi.Binding;using Microsoft.Uddi.Business;using Microsoft.Uddi.Service;using Microsoft.Uddi.ServiceType;

在 static void Main (string[] args) 函數中添加下列代碼:
// 您最好先運行這個程式,在 https://test.uddi.microsoft.com/publish// 上進行註冊測試Publish.Url = "https://uddi.microsoft.com/publish";Publish.User = "您的帳戶";Publish.Password = "************";

這將為您的帳戶建立身分識別驗證。下一步,添加以下代碼將 WSDL 檔案發布為 tModel:
// 建立 tModelSaveTModel stm = new SaveTModel();stm.TModels.Add();stm.TModels[0].Name = "此處插入 URN";stm.TModels[0].Descriptions.Add("zh","此處插入說明");stm.TModels[0].OverviewDoc.OverviewURL = "此處插入 WSDL 的 URL";// 下一行是給 tModel 正確分類所必需的stm.TModels[0].CategoryBag.Add ( "uddi-org:types","wsdlSpec","uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" );string sTModelKey = "";// 發送到 UDDItry{   TModelDetail tmd = stm.Send();   sTModelKey = tmd.TModels[0].TModelKey;         }catch (UddiException ue){   Console.WriteLine ( ue.Message );   return;}catch (Exception e){   Console.WriteLine ( e.Message );   return;}

成功儲存後,UDDI 將產生一個新的唯一的 tModelKey,以後在 Web 服務的綁定中需要用到它。下一步,建立公司條目:
// 建立公司SaveBusiness sb = new SaveBusiness();sb.BusinessEntities.Add();sb.BusinessEntities[0].Name = "此處插入公司名稱";sb.BusinessEntities[0].Descriptions.Add("zh","此處插入說明");// 建立公司服務sb.BusinessEntities[0].BusinessServices.Add();sb.BusinessEntities[0].BusinessServices[0].Name = "此處插入服務名稱";sb.BusinessEntities[0].BusinessServices[0].Descriptions.Add("zh","此處插入服務說明");// 建立綁定模板sb.BusinessEntities[0].BusinessServices[0].BindingTemplates.Add();sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].Description.Add("zh","此處插入綁定說明");sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].AccessPoint.Text = "此處插入訪問點";sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].AccessPoint.URLType = Microsoft.Uddi.Api.URLTypeEnum.Http;// 建立 tModel 執行個體資訊sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].TModelInstanceDetail.TModelInstanceInfos.Add();sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].TModelInstanceDetail.TModelInstanceInfos[0].Descriptions.Add("zh","此處插入說明");// 使用上面的 tModelKey 字串sb.BusinessEntities[0].BusinessServices[0].BindingTemplates[0].TModelInstanceDetail.TModelInstanceInfos[0].TModelKey = sTModelKey;// 發送到 UDDItry{   BusinessDetail bd = sb.Send();   // 顯示 xml   Console.WriteLine ( bd );}catch (UddiException ue){   Console.WriteLine ( ue.Message );   return;}catch (Exception e){   Console.WriteLine ( e.Message );   return;}

此時,WSDL 定義和公司資訊都已經儲存到了 UDDI 中。通過傳遞適當的鍵,以後您可以隨時編輯這些條目。

步驟 3:在 UDDI 中搜尋條目


在 UDDI 中註冊條目後,進行以下三種檢查是比較有意義的。第一,使用 Microsoft Web 使用者介面,根據名稱和分類來搜尋您的公司,確認其存在於返回的結果集中。第二,開啟 Visual Studio .NET 並確保它是通過“Add Web Reference”對話方塊顯示的。如果沒有顯示,則可能沒有正確使用上述的 uddi-org:types 分類法對您的 tModel 進行分類。您應該能將 Web 服務添加到工程中,並基於 WSDL 檔案組建代理程式代碼。第三,等待 24 小時,您的條目將複製到 IBM 節點上,這可以通過其 UI 來查詢,地址是 https://www-3.ibm.com/services/uddi/protect/find(英文)。 總結
UDDI 和 WSDL 作為免費的規範,可以協助建立基於 Web 服務的軟體系統。WSDL 提供了與供應商無關的正式方法來定義 Web 服務,這樣便可以實現下一代遠端程序呼叫。而 UDDI 提供了一種廣泛的、標準化的基礎結構,允許人們去描述和發現 Web 服務。這兩個標準的結合將帶來一個繁榮的 Web 服務生態系統。
下周的專欄將向大家介紹 At Your Service 小組是如何在 UDDI 中為 收藏服務(英文)進行建模和註冊的。

相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。