學習如何為企業開發面向服務的體系結構（Service Oriented Architecture，SOA）移植策略，該企業的 IT 基礎架構包括業務筒倉（silo）的單獨業務線，并擁有許多集成的遺留應用程序來支持業務目標。本文包括開發成功的 SOA 移植策略所需行為的工作細化結構范例，最終生成符合 IBM 客戶合約中 SOA 原則的實際應用程序。
SOA 介紹
自從 Gartner Group [1]提出面向服務的體系結構（Service Oriented Architecture，SOA）和企業服務總線（Enterprise Service Bus，ESB）以來，這些術語已經用了好幾年了。然而，應用 SOA 解決方案的實際細節僅僅是最近才出現的。
那么，準確地說面向服務的體系結構是什么呢？“SOA 是一種組件模型，它通過應用程序功能單元（稱為服務）之間定義完善的接口和契約，來聯系應用程序中的不同服務。”[2]。通過以上的定義，當提取應用程序作為服務時，SOA 是在應用程序之間構建企業級集成層的模式集。SOA 解決方案提倡使用開放標準，然而當集成應用程序時，在某些地方還是需要使用專有技術。
SOA 依賴于將應用程序功能發布為服務，這些服務可被外部各方調用。通常，對 SOA 服務定義的一致觀點是[3]：
- 服務通過明確的、與實現無關的接口來定義。
- 服務被松散綁定，并且可以通過強調位置透明性和互操作性的通信協議進行調用。
- 服務封裝了可重用的業務功能。
服務可存在于不同的級別上，并提供不同的粒度。通常認為有以下服務級別[4]：
- 技術功能（例如，日志記錄）
- 業務功能（例如，getCustomerInfo）
- 業務事務（例如，openAccount）
- 業務流程（例如，processOrder）
每一個粒度級別可能都需要一些合成度。在每個粒度級別上，服務定義以可復用的方式封裝其功能是很重要的。
將應用程序功能發布成服務使應用程序可以高效解耦，這是 SOA 的一種需求。通過接口將功能發布成服務，該接口將針對這項功能創建會話虛包（fa?ade）。可以通過直接修改應用程序或者通過創建適配器（將請求轉換成特定于應用程序的調用）來創建這樣的接口。
當應用程序功能作為服務公開時，創建服務消費者和提供者之間路由消息的機制是很重要的。SOA 解決方案通過使用企業服務總線（Enterprise Services Bus，ESB）來滿足此需求。企業服務總線是為各種服務請求者和服務提供者提供連接層的一種消息代理，它確保二者之間合適的消息路由。服務請求者是組件，它調用由服務提供者發布的服務來實現內部邏輯。
雖然 ESB 最重要的任務是提供連接框架，但它也提供現代 IT 所需要的合適的服務級別和可管理性。實質上，ESB 允許在基于 SOA 的架構中集成服務，并提供“服務請求者和服務提供者之間使用分布式中介功能的單一管理點”[4]。
ESB 在服務請求者和提供者之間提供松耦合，允許用一個服務實現來替換另一個，而且不會對該服務的消費者造成影響。
在 ESB 提供了服務之間連接性的同時，其他 SOA 組件也提供了對發布、發現和調用服務的支持。這些組件包括業務服務目錄、業務服務編排和 ESB 網關。然而，這些組件的部署需要根據實際的業務需求來決定。舉個例子，許多較小的企業可能發現他們實際上并不需要 ESB 網關，因此，將不必建立這些網關，導致架構過于復雜。
業務服務目錄提供 ESB 所依賴的服務路由信息，同時支持服務請求者和提供者之間的通信。然而，業務服務目錄的主要任務是提供服務細節，這些服務細節可用于執行基礎架構所支持的業務功能。實質上，業務服務目錄是服務消費者尋找支持他們操作的服務的地方。
在業務服務目錄提供關于現有服務的信息的同時，業務服務編排組件允許通過現有的低級服務組成新的服務。例如，可以通過定義包含幾個較低級別業務功能的工作流來創建新的業務事務。這樣的工作流成為新的服務，并發布在業務服務目錄中。
開發 SOA 移植策略
許多提供多種服務的大企業如今發現，他們的 IT 已經被嚴重拆分。主要是因為許多企業選擇允許每個業務部門維護它自己的 IT 需求，而不是依賴于集中管理的 IT 組織。因此，許多部門只創建與自身相關的應用程序。通常，公司可能有一些賬單、帳目管理以及類似的支持不同業務方面的系統。而且，許多公司希望安裝“最佳”軟件，而不考慮同其它應用程序的集成。后來他們發現，將新的應用程序加入 基礎架構時經常需要特定的方案。下面的圖 1 正是目前一些企業中 IT 基礎架構的例子：
圖 1.常見的遺留企業 IT 基礎架構
從上圖中可以注意到一個 IT 難題，那就是大多數應用程序之間直接相互通信。當應用程序需要修改或淘汰時，這種依賴便成為一個實際問題。任何修改都可能會按其自身的方式更新每條唯一的通信線路。因此，這種變更可能代價高昂。這種情況被稱為應用程序間的緊耦合，也逐漸成為讓一些企業頭疼的問題。
另一方面，SOA 將松耦合作為成功的企業級應用程序集成的一個主要原則。與緊耦合相反，松耦合是：
限制請求者應用程序代碼和提供者應用程序代碼的相互了解。如果耦合的服務任何方面有所變化，那么，請求者或提供者的應用程序代碼（更可能是兩者同時）必須改變。如果任何一方（請求者、提供者或中介基礎架構）對解耦的服務任何方面作出改變，那么其它幾方不必隨之改變。[5]
圖 1
也示例了當在幾個業務區域內部署具有所需功能的應用程序時（例如，應用程序 1 和應用程序 1'），一些企業所采用的實踐行動。通常，用每個部署稍微修改應用程序以滿足特定業務區域的獨特需求。雖然讓多個應用程序具有相同功能并沒有明顯的缺點，但它們的存在可能表明：
- 企業中可能存在數據副本，這會影響操作數據的準確性。這是由以下原因造成的：大部分此種應用程序依賴于相同的數據源， 且為了性能或其他原因，一部分數據被本地存儲。
- 維護多個應用程序比支持單個解決方案需要更高的花費。
- 當對這些應用程序進行合并，以減少對那些與被淘汰的方案互相依賴的應用程序的影響時，需要特別注意。
通過采用 SOA 原則在企業級別上成功集成應用程序可解決這些問題。
值得注意的是，當企業還未被深入劃分時，應用 SOA 是合理的。然而，當公司內 IT 部門的數量很多，而且它們托管的應用程序數量更多時，實現基于 SOA 的企業體系結構將是一項具有挑戰性的工作，需要精心規劃。
將復雜的深入劃分的企業分割成一些單獨的域，事情可能會變得容易很多。第一，通過 ESB 發布特殊的應用程序服務，每一個域可以與企業其余部分解耦。第二，以后域內的應用程序可以啟用 SOA，而不會影響企業其余部分。
按照業務功能（例如，銷售、賬戶管理、客戶服務等等）或實現（比如大型機和 Unix 服務器）來對域的劃分進行組織。然而，實質上，域將包含更緊密連接的應用程序，因此，相比它們與企業的其余部分的關系，這些應用程序彼此之間將具有更嚴重的依賴性。
如果一組服務屬于單獨的域，那么可用下列準則來定義：
-
功能域是基于業務功能選擇的。這些域中的服務消費域外部的有限數量的服務，并對外部公開有限數量的服務。
-
基于技術的域根據所利用的一系列技術來選擇。這些可能包括大型機應用程序、分布式應用程序等等。
-
基于應用程序的域是緊耦合的應用程序集合。共享相同數據庫的電子商務應用程序或大型機應用程序的集合是這種劃分的一個例子。
域的初始劃分也可以是純概念上的，對那些需要作為服務向企業其余部分公開的應用程序功能進行確認。
一旦確認了服務，需要通過使用網關和防火墻建立明確的邊界，從而使域彼此分離。這種分離提供了對應用程序交互的更好的控制，并可進一步對應用程序進行靈活的變更，而不會對企業其余部分產生重大影響。這種分離可通過幾種不同的方法實現：
- 將公開域功能的業務功能定義為粗粒度服務：業務功能由企業需求驅動，而并非內部的實現細節。業務功能可以在域內部調用細粒度的技術服務，對外部消費者提供服務。定義業務功能的主要目的是限制域之間的交互。
- 添加網關可以將一個域設定轉換為另一個域設定：通過添加更好的控制功能，網關也允許在外部實體間（例如業務伙伴）建立明確的界限。通常，網關可與業務功能合成為一個邏輯實體。然而，添加網關是由業務需求決定的，如果域共享相同的設定就不需要添加網關。使用下列方法之一可以實現網關：
- 透明/代理網關以消費者認為能直接與業務功能進行交互的方式公開域服務。這種網關也可以基于企業基礎架構需求對輸入和輸出的消息進行轉換。當域數據以非常特殊的格式（與企業級約定完全不同）存儲時，需要進行轉換。例如，按照企業策略，特定于域的二進制數據可能需要轉換成 XML。
- 防火墻允許增強對域的封裝。盡管，防火墻不去執行任何轉換，但是它們限制消費者僅能訪問域邊界內預先定義的點。而且，防火墻的引入提供了對不遵循域的封裝規則的服務進行檢測。
分析發布到域外部的應用程序功能時，會發現實際的服務是細粒度功能的結合。將應用程序功能編制為業務服務的一種機制是引入本地服務總線（Local Service Bus，LSB），將服務編排組件添加到這些域。
本地服務總線是為單個域提供連接支持的企業服務總線的實例。通過服務編排組件進行擴展，使域可以組成 ESB 可消費的更高級別的業務功能。
下面，圖 2 演示了以上步驟生成的基礎架構：
圖 2.已定義并分離的 IT 域
一旦封裝了所有的域并公開了業務功能，通過 ESB 對其集成，并采用業務編排來創建更高級別的業務流程和事務就變得更加容易。一旦 ESB 是到位并且企業正在使用，就可以對域內遺留應用程序進行移植，且對企業其余部分影響很小。
下面（表 1）的工作細化結構范例描述了企業將遺留基礎架構移植到基于 SOA 的企業體系結構所需要采取的主要步驟。盡管實際的任務清單是特定于對具體企業的，但是下面的清單為需要考慮的內容提供了一種思路。
表 1. 工作細化結構
|
ID
|
任務名稱
|
| 1 |
SOA 移植規劃 |
| 2 |
? ? ? ? ? ?管理 |
| 3 |
? ? ? ? ? ? ? ? ? ? ? ?項目管理 |
| 4 |
? ? ? ? ? ? ? ? ? ? ? ?技術管理 |
| 5 |
? ? ? ? ? ?實現活動 |
| 6 |
? ? ? ? ? ? ? ? ? ? ? ?收集信息 |
| 7 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?協商 |
| 8 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文檔分析 |
| 9 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 10 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 11 |
? ? ? ? ? ? ? ? ? ? ? ?分析 |
| 12 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?功能方面 |
| 13 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息 |
| 16 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建信息 |
| 17 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 18 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?技術方面 |
| 19 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息 |
| 22 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 23 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 24 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?應用程序方面 |
| 25 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?收集信息 |
| 26 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?協商 |
| 27 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?文檔分析 |
| 28 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 29 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 30 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?域方面 |
| 31 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?信息分析 |
| 32 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 33 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 34 |
? ? ? ? ? ? ? ? ? ? ? ?規劃變更 |
| 35 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ESB 規劃 |
| 36 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?開發 ESB 組織原則 |
| 37 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?工作量估計 |
| 38 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 39 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 40 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?LSB 規劃 |
| 41 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 開發 LSB 組織原則 |
| 42 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 工作量估計 |
| 43 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 創建文檔 |
| 44 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 評審 |
| 45 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?相關性規劃 |
| 46 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?相關性分析 |
| 47 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 48 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
| 49 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?接口規劃 |
| 50 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?接口開發 |
| 51 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?創建文檔 |
| 52 |
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?評審 |
|
|
結束語
基于 SOA 的企業體系結構的方法使得在對企業 IT 基礎架構進行變更時，相關的移植風險更小。通常，公司認識到支持舊的基礎架構是代價高昂的；然而，劇烈的變化是很有風險的。將企業劃分為多個域，并引入本地服務總線（Local Service Bus）的概念可以減輕風險，并可用良好可控制步驟來將其移植到新的基礎架構中。
請記住解決方案只可以被有效地應用于不同類的環境中，這點非常有用。同類環境不太可能從這種策略中獲益。