SOA擴展Web服務的前景(二)

Web 服務使用了相似的方法。XML 是一種通用數據表達法。在使用不同程序語言編寫的程序和執行不同的機器指令之間，可以使用 XML 作為交換媒介。XML 是所有 Web 服務技術的基礎，并且是互操作性的關鍵，每個 Web 服務規范都是基于 XML。特別是，SOAP 使 XML 所編寫信息的交換規范化，WSDL 使用 XML 詞匯描述 SOAP 的細節。

本文的第一部分中，定義了面向服務的體系結構（SOA）以及它的一些特征，并解釋了它同 Web 服務技術的關系。從那里可以了解到 SOA 是一種由應用程序所組成服務的體系結構樣式，并且封裝了應用程序功能以提高可重用性。

我將 Web 服務描述為一套新興規范，Web 服務是目前實現 SOA 的最好方法。關于 Web 服務的文章有很多，因此我將依據其他文章來解釋這些細節。當我分析 SOA 的體系結構概念時，你會看到一些明顯同 Web 服務重復的內容，但是本文的著重點是 SOA 擴展 Web 服務的前景。

服務工作角色

同 Web 服務一樣，面向對象的體系結構（SOA）中有兩個關鍵角色：服務請求者和服務提供者。一個或多個提供者應用程序通過發送請求消息并處理響應消息來提供服務，請求者應用程序調用這些服務。

圖 1 .服務請求者和服務提供者

一些服務提供者同時也是服務請求者：它們聚集其他服務提供者的功能來構造復合的更高級別的服務。通過使用 java、C# 或者象業務流程執行語言（BPEL）那樣的特殊編排語言來完成這種組合。

圖 2. 聚合的服務請求者

一些像 UDDI 和 WS-Trust 的 SOA 技術提出了第三種角色，叫做服務代理（service broker）。 服務代理是服務提供者和服務請求者之間的中介 -- 服務本地化，代理托管方案等等。

圖 3.作為中介的服務代理

使用這三種角色建模的實體使用服務調用（Service Invocation，例如 SOAP 消息）來通信。

服務調用

W3C SOAP 1.2 規范在服務請求者和服務提供者之間定義使用 XML 格式的消息進行通信。將應用程序請求（在 XML 中）放入 SOAP 信封中（也是 XML ），并從請求者到提供者發送應用程序請求，提供者發回的響應也采用相同的形式。市場上的大部分產品支持早期的 SOAP 1.1 規范，但是在未來產品發布中將支持 SOAP1.2。由于已經有許多關于 SOAP 的內容，進一步內容請參閱參考資料中列出的出版物。

圖 4. 使用 SOAP 的服務請求

因為 SOAP 是平臺無關和廠商無關的標準，因此在帶有單獨 IT 基礎架構的合作伙伴之間的松耦合互操作中，SOAP 是支持服務調用的最好方法。然而，SOA 不需要使用 SOAP。

例如，在 SOAP 之前，一些公司使用 IBM® WebSphere® MQ 來給其他的計算機發送 XML 文檔，其他計算機依據這些文檔執行應用程序操作。使用 HTTPS 接口的 eBey XML 以相似的方式來傳遞用于拍賣的物品條目。雖然由于沒有使用 SOAP 而不能調用 Web 服務，但是仍然可以在 SOA 中調用服務。當然，目前 WebSphere MQ 也對 SOAP 消息提供了直接支持。

只要所有的實體是用 Java 語言編寫，那么就可以僅僅使用 J2EE 中的可用功能來創建 SOA。然而，這種方法不能為非 Java 應用程序的互操作性提供令人滿意的解決方案。

在企業內部需要為 IT 系統控制代碼的地方，可以考慮使用 SOAP 之外的服務調用方法，這些方法可能沒有構建并解析 XML 內容。這就會有更好的性能，并且可以避免圍繞現有功能編寫 SOAP 封裝代碼。出于對簡單性的需求，能夠使用其他協議調用服務的單一調用 API 樣式是一個很好的實踐。

多重協議服務調用

JAX-RPC 規范（也叫 JSR-101）定義了一個 Java API，使從 Java 程序中調用 Web 服務變得簡單。JAX-RPC 實現至少必須支持使用 HTTP 的 SOAP1.1。然而，為了服務調用它可能還支持其他的協議。多重協議服務調用能夠使用相同的 API 指定不同的協議，例如改變 URL。

WebSphere Application Server 當前版本中的 JAX-RPC 實現是 JSR-101-compliant，但允許簡單的通過將 URL 修改為對 JMS 服務器（比如 WebSphere MQ）尋址的形式來使用 JMS 上的 SOAP 調用。在不久的將來，這種多重協議樣式將允許使用 IIOP 上的 RMI 進行服務調用，以使 EJB 服務實現有效的互操作。

簡單性的關鍵是不考慮協議而使用相同的 API。讓這成為可能的是在 WSDL 中描述協議的能力，這些協議不同于 HTTP 上的 SOAP。

服務描述

Web 服務描述語言（WSDL）規范定義了一個 XML 詞匯表，該詞匯表依照請求和響應消息，在服務請求者和服務提供者之間定義了一種契約。你能夠將 Web 服務定義為軟件，這個軟件通過描述 SOAP 消息接口的 WSDL 文檔來提供可重用的應用程序功能，并使用標準的傳輸協議來進行傳遞。

WSDL描述包含必要的細節以便服務請求者能夠使用特定服務：

請求消息格式

響應消息格式

向何處發送消息

WSDL 是基于 XML 的，因此 WSDL 文檔是計算機可讀的（machine-readable）。這樣開發環境使用 WSDL 將集成服務的流程自動處理到請求者應用程序。例如 WebSphere Studio 產生一個 Java 的代理對象，它能夠像本地對象一樣實現服務，但是實際上代理對象僅僅處理請求的創建和響應消息的解析。不管服務是否用 Java，C# 或者其他的語言實現，生成的 Java 代理對象都能夠從 WSDL 描述中調用任何的 Web 服務。實際上，WSDL 不能像編程語言那樣描述實現細節。

圖 5. 使用 WSDL 文檔

WSDL 使用它的擴展功能并通過與 HTTP 上的 SOAP 不同的協議來支持服務定義。依據 SOA，你能夠將任何可以用 WSDL 描述接口的應用程序功能稱為服務。當 SOA 不特別的需要 WSDL 時 -- 你可以使用其他服務描述語言 -- 目前大部分廠商和產品都支持 WSDL。

信息交換模式

在流行的請求-響應（request-response）交換模式中，服務請求者向服務提供者（或端點）發送請求消息，處理完請求之后，提供者將響應消息發送給請求者。服務互操作可以是會話式的，由若干對請求-響應構成。然而，為了性能、設計的簡單性和從松耦合中獲得好處，設計粗粒度接口是一個好辦法，它能夠將事務需要的交換數量最小化。

圖 6. 請求-響應消息傳遞

除了請求-響應模式之外，WSDL還定義了以下內容：

將單向（one-way）消息發送到端點 -- 例如，不需要響應的請求：

圖 7. 單向請求

從端點發送的單向消息，叫做通知：

圖 8. 通知

要求-響應（Solicit-Response） 模型，端點通過它發送消息和接收響應：

圖 9. 要求-響應

目前 SOA 實現通常使用 HTTP，導致了同步通信 -- 在處理之前請求者等待響應。同步交換用于預期完成時間相對較短（幾秒或幾分鐘）的服務。

也可能有異步服務互操作，在異步服務互操作中服務請求者不等待響應，而是期望以后交付響應。這適合于長時間運行的事務。例如調用一個業務流程來請求指定的客機報價，流程包括許多合作伙伴或人的互操作，這要花幾天或是幾周來完成。使用異步交換能夠避免失去連接（因為服務器維護等等）以及因此而失去響應的風險。

Web 服務尋址（WS-Addressing）規范將 reply-to 地址作為 SOAP 信封報頭元素的擴展。服務請求者將請求排隊放入 WSDL 文檔中指定的端口，但是不需要等待。相反，在響應到達之前，它做其他的工作。當服務提供者準備發送響應時，使用 SOAP 中的 reply-to 地址：請求消息的報頭。

圖 10. SOAP 中的 reply-to 地址

使用像 WebSphere MQ 這樣的消息隊列產品時，可以使用 JMS 來實現同步消息。請求者可以選擇為請求排隊但是不等待處理的完成。當執行其他工作時，要定時檢查響應隊列中的響應。

圖 11. 使用 JMS 的同步消息

你可以應用同步消息的方法來創建其他的交換模式，比如接收多重通知請求（例如在股票報價變更的通知）。

圖 12. 多重響應模式

服務發現

盡管服務調用和服務描述通常被認為是 SOA 的需求，但服務發現也是它的可選功能。UDDI（通用描述，發現和集成）為發布服務的可用性和發現所需服務定義了一個標準接口（基于 SOAP 消息）。UDDI 實現將發布和發現服務的 SOAP 請求解釋為用于基本數據存儲的數據管理功能調用。

為了發布和發現其他 Web 服務，UDDI 通過定義標準的 SOAP 消息來實現服務注冊（Service Registry）。注冊是一種服務代理，它是在 UDDI 上需要發現服務的請求者和發布服務的提供者之間的中介。一旦請求者決定使用特定的服務，開發者通常借助于開發工具（例如IBM WebSphere Studio 或者 Microsoft® Visual Studio .NET）并通過創建以發送請求并處理響應的方式訪問服務的代碼來綁定服務。

圖 13. UDDI 模式

發現用于構建 SOA 應用程序的服務，其結果就象電子黃頁一樣。你可以使用工具（比如 WebSphere 中的 UDDI Browser）在應用系統設計期間尋找合適的服務。SOA 不需要使用 UDDI，但由于 UDDI 是建立在 SOA 上來完成自身工作的，所以 UDDI 是服務發現的一個好的解決方案。

正如在 Steve Graham 的文章“Six Species of UDDI”（請參閱參考資料）中提到的，你能夠用多種不同的方法使用 UDDI。本文特別指出了在 IT 組織內 UDDI 的使用，主要是為了管理內部服務以提高可重用性以及進一步促進端點無關性。例如，應用程序中可能會緩存所需服務的位置。如果服務重新部署到不同的服務器當中，服務請求者能夠使用 UDDI 發現新的位置并將它緩存以備將來使用。當內部部署 UDDI 時，使用 UDDI 服務請求者應用程序將自動適應于服務部署的變更（例如，為維護負載平衡而做的變更）。

隨著 UDDI 的發展，它將廣泛的用于發現由市場模型中其他組織所提供的公共可用的（publicly-available）業務服務。正如我們將在關于服務編排的文章中所討論的，UDDI 在運行時對服務的 UDDI 動態選擇方面很有用的。

結束語

本文討論了 SOA 的基本元素以及它們相互發現和互操作的方法。你通過開發服務目錄（內部的或合作伙伴的）來創建基于 SOA 的 IT 體系結構，并編寫代碼使用這些服務來開發出新的應用程序。由于服務提供者能夠通過請求其他服務來完成自己的工作，在設計上就可以使用服務的分層結構。雖然簡單的請求-響應消息模型最為流行，但是你可以使用其他的消息模型靈活的設計系統。WSDL 文檔告訴你如何集成服務，UDDI 幫助你找到所需的服務。

參考資料

您可以參閱本文在 developerWorks 全球站點上的英文原文。(責任編輯：銘銘)