上下文
您正在設計企業應用程序，該程序需要使用由其他應用程序提供的服務。該服務定義了一個合約，所有服務使用者要訪問該服務都必須遵守該合約。該合約定義了與此服務通信所需的技術、通信協議和消息定義等內容。要與該服務通信，應用程序需要按合約中的詳細說明履行其責任。
問題
如何將該服務所規定的履行合約責任的細節與應用程序的其餘部分分隔開來？
影響因素
在設計使用由其他應用程序提供的服務的應用程序時，必須考慮下列影響因素：
履行使用者的合約責任需要實現安全和通信機制，例如驗證、封送、加密和消息路由。這些機制通常以不同於應用程序業務邏輯的速率和原因發生更改。
該 合約指定的數據格式可能與應用程序的內部表示形式不同。如果是這樣，則必須轉換數據。有時這種轉換非常簡單，就如重命名字段或轉換數據類型，但有時這種轉 換涉及複雜的結構和語義轉換。例如，大多數服務都會公開粗粒度的、基於類型的接口，以優化它們在分佈式環境中的使用。因此，從面向對象的應用程序調用對服 務的操作時，來自多個應用程序細粒度對象的信息通常需要進行聚合，並轉換爲合約所指定的格式。同樣，來自該操作的響應通常需要打散，然後再映射回細粒度對 象。
您的組織可能無法控制由服務指定的合約。如果合約發生更改，將需要儘可能減少應用程序代碼所受的影響。
可以在應用程序與服務之間提供連接的通信通道通常會向該應用程序公開常規的、低級別的應用程序編程接口 (API)。此 API 可能包括 SendData 等常規函數。在大多數情況下，應用程序需要通過 ValidateCreditCard 或 GetCustomerAddress 等方法來處理語義更加豐富的接口。
某些合約可能會指定異步消息傳遞，即它們可能不會立即返回結果。而服務使用者必須準備接收來自該服務的單獨結果消息。處理這些來自服務的傳入消息所需要的事件驅動編程技術可能會極大提高應用程序的複雜程度。
解決方案
將實現合約使用者部分的代碼封裝到它自己的 Service Gateway 組件中。服務網關在訪問服務時的作用類似於數據訪問組件在訪問應用程序數據庫時的作用。二者都是作爲其他服務的代理，封裝連接源服務的細節，並執行所有必要轉換。
Service Gateway 是特殊類型的 Martin Fowler 的 Gateway 模式 [Fowler03]，此模式適合在面向服務的體系結構中使用，因此其主要任務是封裝使用服務的應用程序對外部系統的訪問。Service Gateway 通常與 Remote Facade [Fowler03] 交互，而不直接與外部系統進行交互。Remote Facade 可封裝提供服務的應用程序中的複雜功能，並將該功能作爲一個簡單接口向使用服務的應用程序公開。Service Interface 是特殊類型的 Remote Facade，適合在面向服務的體系結構中使用。在面向服務的體系結構中，使用服務的應用程序的服務網關通常與提供服務的應用程序所公開的服務接口進行協作。下圖說明了這種關係。
圖 1:使用服務接口的服務的 Service Gateway
Service Gateway 組件封裝了與服務進行通信的低級別細節。這些細節包括但不僅限於以下內容：
通信通道。 Service Gateway 封裝了與服務進行通信所需的所有低級別網絡通信功能。例如，Service Gateway 隱藏了所有使用 SOAP over HTTP 與 Web Service 進行通信的細節。
數據格式。 Service Gateway 可 以在應用程序中內部信息組織與服務的通信合約所規定的格式之間建立映射。例如，應用程序可能由一組相互協作的細粒度對象組成，但其所用 Web Service 可能需要將 XML 文檔作爲輸入內容，並且提供 XML 文檔作爲結果。網關負責在細粒度對象接口和 XML 文檔之間進行轉換。
服務發現。對於簡單情形或不太複雜的情形，Service Gateway 應該封裝發現適當服務的過程。這可能包括在配置文件中查找服務的網絡地址，或使用 UDDI 等服務儲存庫。對於複雜的情形，例如需要根據不斷變化的數據動態決定調用適當服務，服務發現功能可能會封裝在它自己的服務網關組件中。
進程適應器。 Service Gateway 應該適應應用程序的業務進程，以便與該服務一起工作。例如，對服務網關的單個調用可能會導致多次調用一個或多個服務操作。因此，服務網關嚮應用程序所提供的接口應該參照應用程序的進程，而不是參照通信和安全性協議。
異步和同步調 用語義。 Service Gateway 將根據合約指定的調用語義調整使用服務的應用程序的調用語義（異步或同步）。例如，使用服務的應用程序的設計可能不支持合約中指定的異步調用語義。這時，使用服務的應用程序的服務網關必須將該應用程序的同步調用轉換爲合約中所指定的異步協議。
無需將 Service Gateway 實現爲一個對象。實際上，將某些功能分隔到單獨對象中可能更加有利。例如，如果使用單獨對象，使用代碼生成方法來創建網關的某些部分可能更爲簡單。如果服 務提供者發佈了描述所需數據格式（例如，以 WSDL 或 XML 架構的形式）的元數據，用於實現內部應用程序格式與服務期望格式之間的映射數據的代碼則是這種映射的理想選擇。此元數據可用於生成封裝這種映射的強類型 類。
測試考慮事項
Service Gateway 可以明顯提高系統的可測試性。服務網關會將訪問服務的所有細節封裝到一個組件中，並將該組件隱藏在不直接依賴於基礎通信通道的接口之後。因此可以在測試過程中將網關替換爲 Service Stub [Fowler03]。Service Stub 根本不會訪問外部系統，但會將用於模擬外部系統的結果直接返回給應用程序邏輯。Service Stub 還可用於模擬錯誤情況，例如不可用的外部服務。
結果上下文
使用服務網關組件將應用程序和與服務通信細節隔離開來，具有下列優缺點：
優點
通過將服務訪問邏輯與應用程序的其他部分分隔開來，可以輕鬆更改應用程序所訪問的服務。例如，您可能希望更換爲相同服務的較新版本，或使用其他供應商提供的服務級別保證更好的服務。如果可以自動生成進行數據映射的代碼，則切換到其他服務更加容易。
Service Gateway 可隱藏從應用程序訪問服務的複雜性。這樣就提高了應用程序組件和服務訪問組件的重用性。應用程序不直接引用服務，因此不受任何實現細節和服務位置的影響。 將服務訪問邏輯封裝到一個單獨的層中還會提高訪問邏輯的重用性，因爲只要使用相同的傳輸和驗證機制，就能爲多個服務調用所使用。
Service Gateway 是提供公用功能（如異步調用、緩存和錯誤處理）的理想工具。
缺點
Service Gateway 增加了複雜性，這對於簡單解決方案可能並無必要。特別是當您的組織將僅訪問幾個相對靜態的服務，則可以不需要支持映射組件自動生成所需的工作和基礎結構。
一個特定服務網關負責與一個服務交互。如果要協調多個服務，則必須由另一個組件處理，例如 Three-Layered Services Application中指定的業務過程組件。
服 務網關通常包含在一個應用程序中。因此可能導致代碼重複，前提是：如果多個應用程序訪問同一服務，則兩個應用程序可能重複網關功能。開發可重用服務網關組 件是一個備選方法。另一個解決方案是，將公用功能提取到在組織內本地部署的該公用功能自己的服務中。在這種情況下，還可使用前一章討論的某些分佈式計算解 決方案（例如 Remote Facade）。