英文原文：Service-Oriented Architecture and Legacy Systems

　　企業系統已經從單片孤島（monolithic silos）快速發展為使用機制靈活、面向服務的分布式應用系統。為了跟上這一趨勢，IT組織必須近乎實時地調整他們的遺留系統，以面對商業變化的挑戰，這一機會稍縱即逝。面向服務的體系（SOAs）已經演進成可靈活進行操作，并能連接業務進程和底層系統。Nicolas Serrano、Josune Hernantes和Gorka Gallardo提供了當前SOA技術的概述以及如何在遺留環境中去演進。我很期待聽到來自讀者和這個領域具有前瞻性的專欄作家的見解，以及你們更多想知道的東西。— Christof Ebert

　　今天的業務必須能夠靈活、快速地適應市場需求，但是即使很小的處理變化也會引起多個IT系統的重新返工，因為它們原本是設計成應用孤島（application silos）的。為了保持它的競爭力，維護性的開發工作必須減少，然而IT系統卻必須持續地演進。面向服務的體系（SOA）可以使基于孤島（silo-based）的系統演進到面向服務的系統。它的設計思想包括松耦合、底層邏輯抽象、靈活性、重用和可發現性（discoverability）。^1,2在SOA Manifesto 中還描述了其它一些指導原則。

　　SOA初級知識中，最新奇之處在于它的基礎框架設計是基于服務的，而不是聚焦在整個應用上。服務是小的、離散的軟件單元，能提供特定的功能并在多個應用間被重用。SOA應用了松耦合的設計理念，這意味每個服務都是分割的實體，它們對其它共享資源的依賴是有限的，如數據庫、遺留應用或者API。它在生產者和消費者之間幫助提供一個抽象層，從而有利于在不影響消費者的情況下來靈活改變服務的實現。SOA對業務提供了許多益處，但它也不是靈丹妙藥，可以包治百病。SOA的優勢在于：

• 使用自然地方法來對復雜系統建模，即不依賴于技術和平臺、可以對來自不同提供商的服務進行集成；
• 推動使用松耦合，這對其與遺留系統的接口設計有幫助；
• 通過應用重用來提高效率，以減少成本和開發時間；
• 提高靈活性和擴展性，這樣通過將現有應用集成，可以比較容易地開發出多種業務；
• 可以減少維護成本；
• 使系統間使用基于標準的互操作；
• 提供位置無關的數據訪問，這可以通過任何通道，如智能手機、平板或筆記本；并且
• 允許使用增量的方法來快速滿足客戶需求，即通過增加一個新的服務來滿足特定的商業需求。然而，SOA不足之處在于：
• 在應用間很難實現異步通信；
• SOA實現實時響應和高數據傳輸時會非常有挑戰，這是因為XML強調地是健壯而非速度（盡管還可以選擇其它方案，如JSON）；
• SOA有很多安全性缺陷，這是由于應用和系統使用了進程共享；并且
• 在邏輯上分離的系統間交互時，SOA會涉及到復雜的事務管理。

　　向SOA邁進并不容易，有此意愿的企業必須意識到困難和固有的那些問題。無需多言，每個IT組織在SOA實現時都會經歷許多權衡和折中，而且每條道路的距離也不盡相同。為了效率和靈活性，我們推薦在遺留環境中用增量方法來遷移到SOA。

　　Web服務（Web Services）

　　對于大多數組織來說，Web服務是實現松耦合體系最簡單的方式。通過一組基于XML的公開標準，如WSDL、SOAP和UDDI，就可以具有互操作的能力，這些標準提供了定義、發布和使用Web服務的通用方法。

　　Web服務是從Web應用演進而來的，實際上，它們是簡化版的Web應用。Web服務不再提供用戶接口及其數據，而僅僅提供數據接口；呈現信息給用戶的任務轉而由客戶端的應用程序來負責。因此，Web服務是實現SOA最通用的方法，實際上，許多系統使用了Web服務但并沒有把自己定義成SOA。

　　SOA（和Web服務）的主要優勢在于相同的服務可以被不同的客戶端來使用。原先為Web應用設計的數據仍會被任何類型的客戶端使用而無需更改。這其中的例子包括從服務器獲取數據而無需提供顯示SQL數據庫查詢的桌面應用，或者是那些從SOA服務獲取數據的付費或公眾的信息客戶端。

　　遺留系統可以封裝成SOA服務并對HTTP協議直接做出響應，或者它工作在代理服務器的后面，代理服務器負責將請求翻譯成遺留系統的語言。最終，HTTP中的消息是明文的，它可以來自任何系統或編程語言。

　　技術（Technologies）

　　當需要創建靈活的應用時SOA是一個好的選項，但如何去選擇正確的技術來實現則依賴于你的需求和環境。為了那些愿意在自己的業務處理中選擇SOA的組織，讓我們一起來回顧那些最相關的技術考量。

　　SOAP和REST的對比

　　當設計Web服務時，我們需要定義一組規則用來交換信息。當前最適合完成這個任務的工具是SOAP和REST。³SOAP是個老一點的協議，它是類似CORBA這樣已有技術在互聯網環境下的實現。SOAP可以利用多種傳輸協議（HTTP、SMTP等等），這給了它更多的靈活性。由于數據是在XML中交換的，所以當信息量和傳輸的消息較大時會有性能問題。SOAP可以和Web服務安全（Web Services Security）一起使用，后者是個簽名和加密消息的協議，它為消息交換提供了更多的安全性。⁴

　　REST是新的協議，它也用HTTP作為傳輸協議，但它可以處理更多的數據格式，如XML、JSON等等，它依賴于特定的URL而不是XML。REST是SOAP輕量級的替代者。REST在實現上沒有那么多約束，所以他的靈活性更高，也更輕，對文檔的依賴更少。與SOAP只能使用POST方法不同，REST可以使用Get方法，所以緩存不僅可以在業務設計中去實現，也可以通過基礎框架來完成。

　　具體選擇REST或SOAP取決于組織需求和限制條件。一些時候，我們會選擇企業應用能力更強的SOAP，另一些時候，我們則選擇更好性能和更輕量的替代者，如REST。因為SOAP有更好的安全和故障處理能力，大多數企業級的IT商家都會把它作為優選的Web服務實現。而REST則具有簡易、性能好以及實現上不那么嚴格的特性，這些使它成為Internet業務中實現協同工作API的優選。

　　遺留系統的更新改造（Legacy Modernization）

　　盡管SOA體系是無縫連接企業系統并減少協議⁵和平臺陣痛的最好選項，但大多數人仍需要同現存的框架來打交道。當你試圖采納SOA體系來改造遺留系統時，并不存在一個完美方案，這是因為涉及到方方面面的因素。你需要對當前的技術堆棧進行考量，然后基于全局性的成本風險分析進行最優的系統遷移。

　　因為遺留系統通常都在支持關鍵性的業務處理，所以必須采取step-by-step方式的改造計劃，并設計可行的演進方案使現有系統通過混合方法（hybrid approach）變為完全的SOA體系。這里有幾種策略可以使遺留系統轉化為SOA體系。

　　第一個方法是將當前遺留系統用另一個或一組系統替換。通常，如果當前商用現貨系統（COTS）能夠滿足遺留系統的需求和功能，那么這種替換就是個好辦法。這個方案減少了維護但增加了未來修改的成本。第二種選項是用中間件來封裝現有遺留系統并通過Web服務來提供遺留系統的接口。用這種方法，遺留系統功能被封裝在服務層里面并插接在SOA環境里面。這可能解決不了一些問題：遺留應用可以集成不同的幾種服務，這時就不能象期望的那樣對它們解耦。然而，當重寫遺留系統代價太大、遺留系統可以重用，并需要性價比好的解決方案時，這也是個好辦法。最后，也是第三個選項是重寫開發和編碼現有的遺留系統。這是個非常好的辦法，因為你可以對應用的架構施加作用并得到最優的解耦層級。但是，遺留應用通常是關鍵性的，而且因為涉及到之前的技術以及缺乏文檔，有些時候修改它們會非常困難或代價很高，這種修改可能會引起一些問題并增加項目風險。這種情況下，正確的評估涉及的所有風險是必不可少的。

　　企業應用集成（Enterprise Application Integration）

　　當在任何SOA行動中計劃應用集成時，許多供應商的產品可以幫助你來簡化這種遷移。然而，不同的產品在能力和復雜性上有所不同，所以選擇正確的方案對于成功至關重要。你可以將這些選項基于集成的復雜性級別劃分為三個不同的組（看圖1）

圖1 三種企業應用集成的框架

• 集成框架（Integration frameworks）是所有選項中最輕的，它基本由不同開發環境中的API實現庫組成。集成框架的例子有Apache Camel、JAVA環境下的Spring Integration以及.NET下的 NServiceBus。
• 企業服務總線（Enterprise Service Bus）產品提供集成框架的能力以及部署、管理和運行時監控的工具。ESP支持在服務生產者和消費者之間的連接，因此在提供工具上具有優勢，它可以顯著減少成本和復雜性并且能在更高的抽象層來解決集成的問題。ESB產品的例子包括Oracle Service Bus和Mule ESB。
• 集成套件（Integration suites）提供全套的軟件棧，它不僅提供ESB的能力，而且提供更多特定業務的工具，比如業務過程管理、業務活動監控、主數據管理和一個知識庫。所有這些特性可以幫助你快速響應變化。一層層去理解這些競爭性的方案是比較困難的，所以表1對這三種集成方案做了一個對比。

表1:三種集成方案的對比

　　做出選擇

　　很明顯，做出最好的選項依賴于特定的需求和復雜性。首先，你先得決定框架是否已足夠滿足需求。例如，當你只有兩個應用要連接或者你可以只用單個技術（如REST）就能滿足需求時，你就可選擇最簡單的方法（集成框架）而不用考慮它對工具和支持的缺乏；如果不是，那么ESB是一個不錯的選擇。但是，如果需要更多的特性，你就最好用一個更多能力和更復雜的棧，比如集成套件。

　　繼續向前，下一個演進的步驟將是如何使SOA匯聚和使云計算變得容易。云的出現給企業帶來的益處包括：云計算可以按需來提供資源，以容納數據、服務和進程。

　　如此，在云上進行集成就成為企業今天要面對的一項主要挑戰。在這樣的場景下，iPaaS（integration platform as a service）作為可以滿足廣泛集成需求的適合選項就應運而生了。iPaaS作為云服務套件，可以使戶創建、管理并治理連接廣泛應用和數據源的集成流（integration flows），而無需安裝或管理任何的硬件或中間件。

　　展望未來，調研咨詢公司Gartner預測到2016年，全世界至少35%的大中型組織將會使用一個或多個某種形式的iPaaS產品。然而，專家們以為iPaaS并不能取代SOA，對于復雜集成場景傳統的SOA仍然是需要的，比如企業內部或企業間的低延遲消息系統和數據密集交易系統。

　　參考

1. N. Gold et al.， “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
2. S. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
3. S. Mumbaikar and P. Padiya, “Web Services Based on SOAP and REST Principles,” Int’l J. Scientific and Research Publications, vol. 3, no. 5, 2013, pp. 1–4.
4. P. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
5. S. Vinoski, “REST Eye for SOA Guy，” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.