Service Interface（服務接口）

上下文

您正在設計企業應用程序，并且需要能夠通過網絡使用其部分功能。此功能需要能夠被各類系統使用，因此互操作性是設計的重要方面。除互操作性之外，可能還需要支持不同的通信協議，并適應多變的操作要求。

問題

如何確保部分應用程序功能可為其他應用程序使用，同時確保分隔接口機制與應用邏輯？

影響因素

設計應用程序時，必須考慮下列影響因素：

• 盡量將應用程序業務邏輯的負責元素與通信協議、數據轉換和服務合約履行的負責元素分隔開來。這樣即可推進問題分隔的總體設計目標。

• 應用程序使用者可能希望響應根據特定使用方案進行優化。例如，有些使用者可能希望響應根據直接用戶顯示進行優化，而其他使用者可能希望響應根據軟件處理進行優化。

• 應用程序使用者可能希望使用不同技術與應用程序進行通信。例如，公司外部使用者可能希望通過 Internet 利用 SOAP 訪問應用程序，而公司內部使用者則可能希望通過 .NET Remoting 處理訪問應用程序。

• 應用程序本身對不同使用者可能有不同的運行要求。例如，應用程序可能有這樣的安全性要求，即授權公司內部使用者可以執行更新和刪除操作，而公司外 部使用者只 能得到授權執行只讀操作。或者又如，不同的使用者可能需要來自應用程序的不同事務支持。對于一些客戶端，特定事務的發生上下文并不重要，而其他客戶端則可 能需要精確控制事務上下文。然后根據需要，此上下文的句柄可能傳遞至應用程序的其他元素。

• 如果業務邏輯更改與使用者和應用程序進行交互的所用機制是分隔的，則應用程序及時響應業務環境更改的能力將極大提高。例如，假設自定義構建組件中實現了一組特定業務邏輯，這組邏輯然后實現為打包解決方案的包裝器，在理想情況下，這種情況不應影響應用程序使用者。

解決方案

將應用程序設計為軟件服務集合，每個服務都有一個服務接口，應用程序使用者可以通過這些接口與該服務進行交互。

軟件服務是不連續的應用邏輯單元，這些邏輯單元應當公開適合由其他應用程序訪問的、基于消息的接口。[Microsoft02-2] 每個軟件服務都有一個可供使用者使用的關聯接口。此接口負責在服務使用者和服務提供者之間定義并實現合約。此合約及其關聯實現稱為服務接口。

圖 1 顯示了使用服務接口所供服務的服務網關。這兩個元素間的協作由合約管理。

圖 1:服務元素

Service Interface

如圖 1 所示，Service Interface 提供了入口點，使用者可以使用此入口點訪問應用程序所提供的功能。Service Interface 通常為網絡可尋址，因此使用者可以通過特定類型通信網絡對其進行訪問。網絡地址可以是眾所周知的位置，也可以從服務目錄（如 UDDI）獲取。

設計服務接口的一個重要方面是將和其他系統通信所需的實現與應用程序業務邏輯分隔開來。服務接口提供了更粗粒度的接口，同時保留了應用程序邏輯的語義和細粒度。服務接口還提供了屏障，允許更改應用程序邏輯而不影響接口使用者。

服務接口用于實現使用者和提供者之間的合約。此合約使得它們即使在不同的系統上也能夠交換信息。服務接口負責實現在執行這種通信時所需的所有細節。這些細節包括但不限于以下內容：

• 網絡協議。服務接口應該封裝使用者和服務通信時所使用的網絡協議的所有方面。例如，假設某服務通過 TCP/IP 網絡上的 HTTP 向使用者提供。您可以將該服務接口實現為 ASP.NET 組件，并將其發布到一個眾所周知的 URL。ASP.NET 組件接收 HTTP 請求、提取服務處理請求時所需的信息、調用服務實現、對服務響應打包，然后將響應作為 HTTP 響應發送給使用者。從服務角度來看，唯一了解 HTTP 的組件是服務接口。服務實現有自己的、與服務接口通信的合約，并且不應當依賴于使用者用來與服務接口通信的技術細節。

• 數據格式。服務接口負責對使用者數據格式和服務所希望的數據格式這二者進行相互轉換。例如，在公司外部的使用 者可能提供數據，并且希望答復數據采用符合行業標準 XML 架構的 XML 格式。公司內部的使用者可能想使用針對這種特殊服務進行了優化的 XML 格式。服務接口負責以服務可以使用的格式對兩種數據格式進行轉換和映射。服務實現完全不必知道服務接口可能用于與使用者通信的具體數據格式。

• 安全性。服務接口應該被看作它自己的信任邊界。不同的使用者可能有不同的安全性要求，因此應該由服務接口來實 現這些使用者特定的要求。例如，公司外部使用者比公司內 部使用者通常具有更加嚴格的安全要求。外部使用者可能有很強的驗證要求，并且可能只得到授權執行一些操作，這些操作只是授權給內部使用者的操作中的一個很 有限的子集。內部使用者可能已經得到了顯式信任，可以執行大多數的操作，只要求對于最敏感的操作進行授權。

• 服務級別協議。服務接口在保證服務滿足它向一組具體使用者所作的服務級別承諾方面起著非常重要的作用。服務接口可能會實現緩存，以縮短響應時間并減少帶寬消耗。可以在一組有負荷平衡功能的處理節點上部署多個服務接口實例，以達到可伸縮性、可用性和故障容錯的要求。

將服務接口數量減少到最低

一 般情況下，對于每個唯一的使用方案、技術堆棧、服務級別協議或操作要求來說，都需要一個服務接口。但是，您的應用程序支持的服務接口越多，構建和維護實現 時所涉及的工作也就越多。因此，您應該嘗試將應用程序需要支持的服務接口數量減少到最低。例如，某個應用程序可能提供了兩個用于訪問其功能的服務接口。第 一個服務接口可能已針對公司外部使用者進行了優化。它可能指定了使用 SOAP over HTTP 通信技術的一組粗粒度請求和響應對，并且提出了非常嚴格的安全性要求。第二個服務接口可能已針對公司內部的使用者進行了優化。它指定的請求和響應對的數量 可能較多，而且它們不具有第一個服務接口中指定的請求和響應對那樣的粗粒度，并且強調性能要求比安全要求更重要。

測試考慮事項

Service Interface 封裝了提供服務的所有細節，并且將它與應用邏輯分隔開來。這種分隔使您能夠將應用邏輯替換為模擬 [Mackinnon00] 實現。這些模擬實現會將真正的應用程序代碼替換為模擬真實代碼的模糊實現。使用模擬實現使您能夠編寫驗證代碼是否工作的測試，同時不必依賴于實際的應用程 序代碼。您還可以擴展模擬實現以模擬錯誤情況，這些情況可能很難或者不可能使用真實代碼進行模擬。

結果上下文

使用 Service Interface 模式會導致下面的優缺點：

優點

• 服務接口機制與應用邏輯分隔。這種分隔使您能夠輕松地添加新的接口以及更改基礎應用程序的實現，同時對使用者的影響最小。

• 通過將服務接口代碼與服務實現代碼分隔開來，您就能夠在不同層上部署這兩部分代碼，這樣有可能提高解決方案的部署靈活性。

缺點

• 很多平臺使公開應用程序功能變得很簡單。但是，這可能會導致作出粒度方面的錯誤決定。如果接口粒度太細，可能會導致最后必須很多次調用服務，才能執行特定操作。您需要對服務接口進行相應設計，使其適合網絡通信或過程外通信。

• 服務所提供的每個新增服務接口都會增加在更改服務所公開的功能時所需的工作量。

Service Interface 模式增加了復雜性和性能開銷，這對于很簡單的面向服務的應用程序來說可能不是很合適。

轉載于:https://blog.51cto.com/lijianfeng10223/1677458

總結

以上是生活随笔為你收集整理的第6章 服务模式 Service Interface（服务接口）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。