英國電信設計模式最佳實踐
——層次化的SOA架構
作者：崔曉波 BEA系統（中國）有限公司資深技術顧問
典型的企業SOA平臺連接許多企業應用資源和用戶，並且可以把企業應用資源分成服務提供者和服務消費者兩種類型。可以通過把服務劃分爲不同的層次來得到良好的管理效果。一個服務層次用來使後臺系統（BES）資源可用，而另一個服務層次連接前端系統（FES）到SOA平臺，第三個服務層次組裝第一個服務層次的基本服務並連接業務用戶在一起成爲複雜的複合類型服務。
類似的服務分組做法可以有效的闡述SOA平臺分層管理的特點。對於每個層次來講，都有對應的不同的技術，開發模式，測試裝置，部署配置和系統管理制度等等。
一、層次劃分
分層架構是最靈活的實現方法。簡單來說，SOA可以僅僅由基本的存取服務來組成。這些存取服務直接封裝由BES提供的一組接口。
然而，這組服務並不能滿足最基本的整合項目的整合需求。在大多數實際項目中，整合不同後端系統的邏輯是需要的。這個整合邏輯也可以被看作一組服務，此服務有良好定義的對外發布接口。這些服務是更高水平的服務，它利用更低水平的BES存取服務。這些服務實現是通過編排或協調的方式。
最後，在一個企業整合環境中，這些更高水平協調服務或更低水平存取服務的大多數消費應用將不直接支持對外的服務接口。因此，另一組服務被要求包裝服務到每個FES可以方便使用的形式。
於是提出了分層架構的基礎，如圖所示：
這個架構中有三層。每層都有相應的一組技術需求和作用。
q 存取服務層負責發佈一組BES的接口作爲一個標準的服務。
q 組裝服務層重新分組服務來實現整合邏輯。
q 消費服務負責使FES可以訪問其它兩層發佈的服務，這些服務通常是FES不能直接進行調用的。
一個獨立的企業信息系統（EIS）能夠執行FES或BES角色中的一個或兩個，它可以通過存取層暴露服務，也通過消費層調用服務。
另外非常重要的一點是任何層的服務能夠被FES調用，你不必通過架構中的所有層來進行。
（1） 存取服務層
存取服務層提供由SOA平臺其餘層次服務調用的基礎服務。該層關鍵架構的中心是設計和管理服務的重用。設計和開發存取服務需要應用訪問異構資源的技術（如WTC、JCOM、Web Service等），適配器開發設置技術、消息中間件技術。
存取服務層是通過訪問BEA發佈的服務來提供單一的接口，主要目標是在平臺上實現最大化的重用。其它層通過控件或通過一個發佈接口來訪問這些服務。它最簡化的形式僅僅是一個通過控件來暴露的BES。例如一個J2EE連接架構適配器（J2EECA）數據庫適配器被安裝和設置來把一個特殊的系統和每個需要的SQL語句所產生的服務連接到一起。然後這能夠通過整合應用視圖控件來存儲。
什麼服務屬於這一層?
這一層主要考慮所有發佈的接口是基於BES設計的，並非是每個FES或同層的需要。實現對BES多個調用的複合服務將是這層的一部分。
例如，爲了產生一個給定BES的用戶，有必要產生用戶ID，然後是用戶名，再然後是用戶地址等。每個部分都作爲一個不同的調用，然後一個“產生用戶”複合服務將被實現綁定所有這些調用。這種複合的原因是更方便的、更大程度的重用BES提供的服務。
總體來說，一個適合存取的流程將滿足以下幾點：
q 僅僅連接一個BES
q 接口的所有者和服務的實現和BES在一起
（2） 組裝服務層
組裝服務層主要是完成傳遞新的服務的功能，這些新的服務是對存取服務層提供服務的一個重新組織。本層的主要架構特點是靈活性。組裝服務層通過正確實現數據集中、流程定義、以及創建理想服務的工作流工具實現了這種靈活性。設計和實施組裝服務需要精通集成業務流程和規則，並在數據集成、流程建模、工作流開發上有豐富開發技巧的專家。
在這層中需要實現各種的集成邏輯，併發布成爲一個完整的服務。本層利用訪問存取層向FES提供有意義的服務。
本層中需要包含哪些服務？
任何利用多於一個EIS系統的服務都需要納入到這一層中來。對於通過worklist實現人爲交互的服務也需要納入到本層中來。正如上文中對於訪問存取層的描述，一些協作層中的服務可能僅訪問一個BES系統。如果這些服務需要完成功能包含集成的需求而不僅僅是來自單個BES系統，他們也同樣應臺包含在協作服務層中。適用於本層的一個簡單原則：任何不屬於消費層或訪問存取層的服務都屬於協作服務層。
獨立的數據集成服務，如提供數據轉換、數據映射（包括主鍵映射）、數據依賴路由的服務需要駐留在協作層。這些服務可能不會通過訪問存取層訪問BES系統。
（3）消費服務層
消費服務層的主要目的是負責平臺和應用服務請求者（例如FES系統）之間的連接，本層服務提供：
q 協議映射——映射爲服務發佈接口協議：JMS和Web Services。
q Paradigm映射——同步到異步以及vice-versa。
q 數據映射——數據格式映射，聚集等。
服務請求者包括基於多種架構的應用，還有包括胖客戶端、消息系統、套接字協議等在內的遺留系統服務請求者。一般都需要協議解釋服務。對於支持諸如Portal，B2B服務，多渠道等平臺協議，paradigm和數據格式的請求者，可以與平臺直接接口。將服務請求者集成到SOA平臺需要對特定服務請求者的技術有豐富的知識，此外還需要數據轉換的技巧。
消費服務層應當包含哪些服務？
消費服務層重組了特定存取服務層和協調服務層的各項服務。重新組裝的目的是爲了讓服務能夠以更方便的形式被FES調用，典型的如把一個JPD流程包裝成一個Web Service就是如此。另外把一個JPD對應的前端的Page Flow包裝成一個Portlet，也可以更方便的讓前端的Portlet系統進行組裝和調用。
例如一個消費層服務收到某個FES發出的事件，但是這個事件不具備足夠的信息來調用相應的協作層，請求服務層的服務將完成接收事件，並向FES查詢相關信息的功能。這是一個明顯的功能加強，這類場景適合於消費服務層。當然，如果這個強化的過程需要向一個獨立的系統進行查詢，則意味着通過一個集成過程後成爲請求服務層的一個獨立服務。
二、端到端的視角
值得指出的一點是在審視從FES到BES系統之間的端到端通信時，這些層次都不是強制必須實現的。正如前文所講述的，請求服務層僅當需要提供對SOA平臺的標準接口技術進行訪問時纔是必要的。若一個FES本身支持SOA平臺的標準，那麼FES就可以直接訪問其提供的服務，而跳過請求服務層。同樣的，對於一些簡單的集成需求，如查詢獨立系統中的可用數據就不需要進行服務的重組。當然，我們推薦的方式是永遠不要忽略訪問存取層，它保證了BES提供的各種服務在整個平臺中保持一致性和靈活性。它還避免了跳過所有層次的設計場景的出現，因此可以保證滿足平臺管理原則。
還有一點值得一提，在一個集成場景中，很多系統既是BES又是FES，當然也不排除一些純前端系統（如Portal）和固有後端系統（如數據庫）的存在。當進行雙向松耦合通信（如使用JMS）時，一個雙向的集成需求可以轉爲實施兩個單向的通信。這是一個在相同業務流程中既作FES又做BES系統的例子。
三、服務資源庫
需要建立一個服務資源庫來記錄有關服務的信息，籍此可以實現不同項目之間服務的易重用性。這個資源庫不需要是一個自動的運行時系統（類似UDDI），而多用於設計和開發階段的系統參考。這個資源庫可以簡單到一個共享文件夾的形式，或者依靠文檔管理工具來完成。資源庫中服務的定義最少需要包含以下服務相關信息：
q 服務名稱和版本。
q 服務功能和意圖的概要。
q 功能和非功能性需求。
q 服務駐留的層次以及層次之間的粒度。
q 服務詳細的接口描述。包括髮布的和/或私有的接口，以及對接口諸如URL，方法，參數類型以及所需的值和使用方式的詳細描述。
q 服務所有者。是指負責維護服務的獨立個體或組織（更常見的一種情形）。