XML Web Services 基本概念

發行項
04/03/2007

Roger Wolter
Microsoft Corporation

2001 年 12 月

總結： 開發人員的 XML Web 服務價值概觀，其中包含 SOAP、WSDL 和 UDDI 簡介。 (6 個列印的頁面)

什麼是 XML Web 服務？

XML Web 服務是移至網際網路上分散式運算的基本建置組塊。開放標準和著重于人員與應用程式之間的通訊和共同作業，已建立 XML Web 服務成為應用程式整合平臺的環境。不論應用程式位於何處或實作方式為何，應用程式都是使用各種來源的多個 XML Web 服務來建構。

XML Web Service 的定義可能和有公司一樣多，但幾乎所有定義都有下列常見專案：

XML Web 服務會透過標準 Web 通訊協定向 Web 使用者公開有用的功能。在大部分情況下，使用的通訊協定是 SOAP。
XML Web 服務提供一種方式來詳細描述其介面，讓使用者能夠建置用戶端應用程式來與其通訊。此描述通常會在稱為 Web 服務描述語言的 XML 檔中提供， (WSDL) 檔。
XML Web 服務已註冊，讓潛在使用者可以輕鬆地找到它們。這是透過通用探索描述和整合 (UDDI) 來完成。

我將在本文中涵蓋這三種技術，但首先我想要說明為何您應該關心 XML Web 服務。

XML Web 服務架構的主要優點之一是，它允許在不同平臺上以不同語言撰寫的程式以標準為基礎的方式彼此通訊。您一段時間後已與產業有關的人現在說：「請稍候一分鐘！我沒有聽到 CORBA 和該 DCE 之前的相同承諾嗎？這有何不同？」第一個差異在於 SOAP 比先前的方法更為複雜，因此符合標準之 SOAP 實作的進入障礙明顯較低。 Paul Kulchenko 會維護 SOAP 實作的清單： http://www.soapware.org/directory/4/implementations 最後計數包含 79 個專案。您會發現大部分大型軟體公司的 SOAP 實作，如您所預期，但您也會發現許多由單一開發人員所建置和維護的實作。 XML Web 服務對先前的工作有另一個重要優點是，它們使用標準 Web 通訊協定，也就是 XML、HTTP 和 TCP/IP。許多公司已經有 Web 基礎結構，而且擁有維護其知識與經驗的人員，因此，XML Web 服務的進入成本明顯小於先前的技術。

我們已透過 SOAP 將 XML Web 服務定義為在網路上公開的軟體服務，如 WSDL 檔案所述，並在 UDDI 中註冊。下一個邏輯問題為。「我可以使用 XML Web 服務做什麼？」第一個 XML Web 服務通常是您可以輕鬆地納入應用程式的資訊來源，也就是股票報價、氣象預測、運動分數等。您可以輕鬆地想像一個可建置的整個應用程式類別，以分析並匯總您關心的資訊，並以各種方式呈現給您;例如，您可能有一個 Microsoft® Excel 試算表，摘要說明整個財務圖片：股票、401K、銀行帳戶、貸款等等。如果這項資訊可透過 XML Web 服務取得，Excel 可以持續更新。有些資訊是免費的，有些可能需要訂用帳戶才能使用服務。大部分的資訊現在都可在 Web 上取得，但 XML Web 服務會以程式設計方式存取它，使其更容易且更可靠。

將現有的應用程式公開為 XML Web 服務，可讓使用者建置使用 XML Web 服務作為建置組塊的新、更強大的應用程式。例如，使用者可能會開發購買應用程式來自動從各種廠商取得價格資訊、允許使用者選取廠商、提交訂單，然後追蹤出貨直到收到為止。除了在網路上公開其服務之外，廠商應用程式可能也會使用 XML Web 服務來檢查客戶的點數、向客戶的帳戶收取費用，以及向貨運公司設定出貨。

未來，某些最有趣的 XML Web 服務將支援使用 Web 來執行目前無法完成的工作的應用程式。例如，XML Web 服務可以執行的其中一項服務是行事曆服務。如果您的活頁簿和機械透過此 XML Web 服務公開其行事曆，您可以排程一行的約會，或者您可以視需要排程約會，直接在您的行事曆中清除和例行維護。想像一下，您可以想像數百個應用程式，一旦您能夠程式設計 Web，就可以建置這些應用程式。

如需 XML Web 服務和它們將協助您建置之應用程式的詳細資訊，請參閱 MSDN XML Web Services 開發人員中心。

SOAP

Soap 是 XML Web 服務的通訊協定。當 SOAP 描述為通訊協定時，大部分的人都會思考 DCOM 或 CORBA，並開始詢問「SOAP 如何啟用物件？」或「SOAP 使用的命名服務為何？」雖然 SOAP 實作可能會包含這些專案，但 SOAP 標準不會指定它們。 SOAP 是一種規格，可定義訊息的 XML 格式，以及該規格所需部分的 XML 格式。如果您有以幾個 SOAP 元素括住的格式正確的 XML 片段，您就會有 SOAP 訊息。簡單不是嗎？

SOAP 規格的其他部分描述如何將程式資料表示為 XML，以及如何使用 SOAP 來執行遠端程序呼叫。規格的這些選擇性部分可用來實作 RPC 樣式應用程式，其中 SOAP 訊息包含可呼叫函式，以及要傳遞至函式的參數會從用戶端傳送，而伺服器會傳回具有執行之函式結果的訊息。 SOAP 的最新實作支援 RPC 應用程式，因為用來執行 COM 或 CORBA 應用程式的程式設計人員會瞭解 RPC 樣式。 SOAP 也支援檔樣式應用程式，其中 SOAP 訊息只是 XML 檔周圍的包裝函式。檔樣式的 SOAP 應用程式非常有彈性，而且許多新的 XML Web 服務會利用此彈性來建置難以使用 RPC 實作的服務。

SOAP 規格的最後一個選擇性部分會定義包含 SOAP 訊息的 HTTP 訊息外觀。此 HTTP 系結很重要，因為幾乎所有目前 OS 的 (都支援 HTTP，而且許多目前作業系統的) 。 HTTP 系結是選擇性的，但幾乎所有 SOAP 實作都支援它，因為它是 SOAP 的唯一標準化通訊協定。基於這個理由，SOAP 需要 HTTP 的常見誤解。某些實作支援 MSMQ、MQ 系列、SMTP 或 TCP/IP 傳輸，但幾乎所有目前的 XML Web 服務都使用 HTTP，因為它很普遍。由於 HTTP 是 Web 的核心通訊協定，大部分的組織都有支援 HTTP 的網路基礎結構，以及瞭解如何管理它的人員。 HTTP 的安全性、監視和負載平衡基礎結構目前已可供使用。

開始使用 SOAP 時，混淆的主要來源是 SOAP 規格與 SOAP 規格的許多實作之間的差異。大部分使用 SOAP 的人員不會直接寫入 SOAP 訊息，但使用 SOAP 工具組來建立和剖析 SOAP 訊息。這些工具組通常會將函式呼叫從某種語言轉譯為 SOAP 訊息。例如，Microsoft SOAP Toolkit 2.0 會將 COM 函式呼叫轉譯為 SOAP，而 Apache Toolkit 會將 JAVA 函式呼叫轉譯為 SOAP。函式呼叫的類型和支援的參數資料類型會隨著每個 SOAP 實作而有所不同，因此與一個工具組搭配運作的函式可能無法與另一個工具組搭配使用。這不是 SOAP 的限制，而是您使用的特定實作。

到目前為止，SOAP 最吸引人的功能是在許多不同的硬體和軟體平臺上實作。這表示 SOAP 可用來連結與沒有組織內的不同系統。過去有許多嘗試來提出可用於系統整合的常見通訊協定，但沒有任何一個嘗試具有 SOAP 所擁有的廣泛採用。這是為什麼？因為 SOAP 比許多先前的通訊協定更小型且更簡單。 DCE 和 CORBA 例如，實作需要數年的時間，因此只會發行幾個實作。不過，SOAP 可以使用現有的 XML 剖析器和 HTTP 程式庫來執行大部分的困難工作，因此 SOAP 實作可以在幾個月內完成。這就是為什麼有 70 個以上的 SOAP 實作可供使用。 SOAP 顯然不會執行 DCE 或 CORBA 所做的一切，但缺少對功能的複雜度，就是 SOAP 可供立即使用。

HTTP 的普遍性和 SOAP 的簡單性，讓它們成為實作幾乎可從任何環境呼叫之 XML Web 服務的理想基礎。如需 SOAP 的詳細資訊，請參閱 MSDN SOAP 首頁。

安全性呢？

SOAP 詢問的其中一個第一個問題是 SOAP 如何處理安全性。在開發初期，SOAP 被視為以 HTTP 為基礎的通訊協定，因此假設 HTTP 安全性適用于 SOAP。最後，目前有數千個使用 HTTP 安全性執行的 Web 應用程式，因此這確實適用于 SOAP。基於這個理由，目前的 SOAP 標準假設安全性是傳輸問題，而且在安全性問題上是無訊息的。

當 SOAP 擴充為在一些傳輸之上執行的更一般用途通訊協定時，安全性就會成為更大的問題。例如，HTTP 提供數種方式來驗證哪個使用者進行 SOAP 呼叫，但當訊息從 HTTP 路由傳送至 SMTP 傳輸時，該身分識別如何傳播？ SOAP 是設計為建置組塊通訊協定，因此幸運的是，在建置 SOAP 上已有一些規格，可為 Web 服務提供額外的安全性功能。 WS-Security 規格會定義完整的加密系統。

WSDL

WSDL (通常發音為 whiz-text) 代表 Web 服務描述語言。為了我們的目的，我們可以說 WSDL 檔案是一份 XML 檔，描述一組 SOAP 訊息，以及如何交換訊息。換句話說，WSDL 是 SOAP 什麼是 CORBA 或 COM 的 IDL。由於 WSDL 是 XML，所以它是可讀取和編輯的，但在大部分情況下，軟體會產生和取用它。

若要查看 WSDL 的值，假設您想要開始呼叫其中一個商務夥伴所提供的 SOAP 方法。您可以要求他提供一些範例 SOAP 訊息，並撰寫您的應用程式來產生及取用類似範例的訊息，但這可能會是容易出錯的。例如，您可能會看到 2837 的客戶識別碼，並假設它是整數，事實上它是字串。 WSDL 會指定要求訊息必須包含的內容，以及回應訊息在明確標記法中的外觀。

WSDL 檔案用來描述訊息格式的標記法是以 XML 架構標準為基礎，這表示它是程式設計語言中性與標準型，因此適合用來描述可從各種平臺和程式設計語言存取的 XML Web 服務介面。除了描述訊息內容之外，WSDL 還會定義服務可用的位置，以及用來與服務通訊的通訊協定。這表示 WSDL 檔案會定義撰寫程式以使用 XML Web 服務所需的所有專案。有數個工具可用來讀取 WSDL 檔案，並產生與 XML Web 服務通訊所需的程式碼。這些工具的其中一些最能用於 Microsoft Visual Studio® .NET。

許多目前的 SOAP 工具組包括從現有程式介面產生 WSDL 檔案的工具，但有一些工具可以直接撰寫 WSDL，而且 WSDL 的工具支援不如其應一樣完整。撰寫 WSDL 檔案的工具之前不應該太長，然後產生類似 COM IDL 工具的 Proxy 和存根，將會是大部分 SOAP 實作的一部分。此時，WSDL 會成為撰寫 XML Web 服務的 SOAP 介面的慣用方式。

WSDL 的絕佳描述可供使用，您可以在找到 WSDL 規格 http://www.w3.org/TR/wsdl 。

UDDI

通用探索描述和整合是 Web 服務的黃色頁面。如同傳統的黃色頁面，您可以搜尋提供所需服務的公司，請閱讀所提供的服務，並連絡某人以取得詳細資訊。當然，您可以提供 Web 服務而不在 UDDI 中註冊，就像您可以在您的公司中開啟企業，並依賴口語廣告，但如果您想要達到重要的市場，您需要 UDDI，讓您的客戶可以找到您。

UDDI 目錄專案是一個 XML 檔案，描述其提供的商務和服務。 UDDI 目錄中的專案有三個部分。「白頁」描述提供服務的公司：名稱、位址、連絡人等。「黃色頁面」包含以標準分類法為基礎的產業類別，例如北美洲產業分類系統和標準產業分類。「綠色頁面」會詳細說明服務的介面，以便有人撰寫應用程式以使用 Web 服務。定義服務的方式是透過稱為類型模型或 tModel 的 UDDI 檔。在許多情況下，tModel 包含一個 WSDL 檔案，描述 XML Web 服務的 SOAP 介面，但 tModel 具有足夠的彈性，可描述幾乎任何類型的服務。

UDDI 目錄也包含數種方式來搜尋建置應用程式所需的服務。例如，您可以在指定的地理位置或指定類型的商務中搜尋服務的提供者。 UDDI 目錄接著會提供資訊、連絡人、連結和技術資料，讓您評估哪些服務符合您的需求。

UDDI 可讓您尋找想要從中取得 Web 服務的企業。如果您已經知道想要與誰合作，但不知道提供哪些服務，該怎麼辦？ WS 檢查規格可讓您流覽特定伺服器上提供的 XML Web 服務集合，以找出哪些服務可能符合您的需求。

如需 UDDI 的詳細資訊，請參閱 http://www.uddi.org/about.html 。

什麼是左側？

到目前為止，我們已討論如何與 XML Web 服務通訊 (SOAP) 、如何描述 XML Web 服務 (WSDL) ，以及如何 (UDDI) 尋找 XML Web 服務。這些構成一組基準規格，可提供應用程式整合和匯總的基礎。從這些基準規格中，公司正在建置真正的解決方案，並從中取得真正的價值。

雖然已完成許多工作，讓 XML Web 服務成為實境，但需要更多工作。現今，人們成功使用 XML Web 服務，但仍有一些動作作為開發人員®的練習，例如安全性、作業管理、交易、可靠的傳訊。全域 XML Web 服務架構將透過提供一致的一般用途模型，協助將 XML Web 服務帶到下一個層級，以便將新的進階功能新增至模組化和可延伸的 XML Web 服務。

WS-Security 是全域 Web 服務架構中的其中一個規格。作業管理需求，例如在多部伺服器之間路由傳送訊息，以及動態設定這些伺服器以進行處理，也是全域 Web 服務架構的一部分，且符合 WS 路由規格和 WS 轉介規格。隨著全域 Web 服務架構的成長，將會引進這些和其他需求的規格。

如需詳細資訊，請參閱全域 XML Web 服務架構。

共用方式為