面向服務(wù)體系和遺留系統(tǒng)

Patagonia

　　

這篇文章首次出現(xiàn)在
IEEE軟件
雜志上。
IEEE軟件
對當前戰(zhàn)略性技術(shù)問題提供可靠的、業(yè)內(nèi)同行的評述信息。為了應(yīng)對可靠、靈活地運行企業(yè)的挑戰(zhàn)，IT管理者和技術(shù)領(lǐng)導(dǎo)者需要依靠IT 專家來獲得最先進的解決方案信息。

企業(yè)系統(tǒng)已經(jīng)從單片孤島（monolithic silos）快速發(fā)展為使用機制靈活、面向服務(wù)的分布式應(yīng)用系統(tǒng)。為了跟上這一趨勢，IT組織必須近乎實時地調(diào)整他們的遺留系統(tǒng)，以面對商業(yè)變化的挑戰(zhàn)，這一機會稍縱即逝。面向服務(wù)的體系（SOAs）已經(jīng)演進成可靈活進行操作，并能連接業(yè)務(wù)進程和底層系統(tǒng)。Nicolas Serrano、Josune Hernantes和Gorka Gallardo提供了當前SOA技術(shù)的概述以及如何在遺留環(huán)境中去演進。我很期待聽到來自讀者和這個領(lǐng)域具有前瞻性的專欄作家的見解，以及你們更多想知道的東西。— Christof Ebert
今天的業(yè)務(wù)必須能夠靈活、快速地適應(yīng)市場需求，但是即使很小的處理變化也會引起多個IT系統(tǒng)的重新返工，因為它們原本是設(shè)計成應(yīng)用孤島（application silos）的。為了保持它的競爭力，維護性的開發(fā)工作必須減少，然而IT系統(tǒng)卻必須持續(xù)地演進。面向服務(wù)的體系（SOA）可以使基于孤島（silo-based）的系統(tǒng)演進到面向服務(wù)的系統(tǒng)。它的設(shè)計思想包括松耦合、底層邏輯抽象、靈活性、重用和可發(fā)現(xiàn)性（discoverability）。1,2在
SOA Manifesto
中還描述了其它一些指導(dǎo)原則。

SOA初級知識中，最新奇之處在于它的基礎(chǔ)框架設(shè)計是基于服務(wù)的，而不是聚焦在整個應(yīng)用上。服務(wù)是小的、離散的軟件單元，能提供特定的功能并在多個應(yīng)用間被重用。SOA應(yīng)用了松耦合的設(shè)計理念，這意味每個服務(wù)都是分割的實體，它們對其它共享資源的依賴是有限的，如數(shù)據(jù)庫、遺留應(yīng)用或者API。它在生產(chǎn)者和消費者之間幫助提供一個抽象層，從而有利于在不影響消費者的情況下來靈活改變服務(wù)的實現(xiàn)。SOA對業(yè)務(wù)提供了許多益處，但它也不是靈丹妙藥，可以包治百病。SOA的優(yōu)勢在于：
    使用自然地方法來對復(fù)雜系統(tǒng)建模，即不依賴于技術(shù)和平臺、可以對來自不同提供商的服務(wù)進行集成；
    推動使用松耦合，這對其與遺留系統(tǒng)的接口設(shè)計有幫助；
    通過應(yīng)用重用來提高效率，以減少成本和開發(fā)時間；
    提高靈活性和擴展性，這樣通過將現(xiàn)有應(yīng)用集成，可以比較容易地開發(fā)出多種業(yè)務(wù)；
    可以減少維護成本；
    使系統(tǒng)間使用基于標準的互操作；
    提供位置無關(guān)的數(shù)據(jù)訪問，這可以通過任何通道，如智能手機、平板或筆記本；并且
    允許使用增量的方法來快速滿足客戶需求，即通過增加一個新的服務(wù)來滿足特定的商業(yè)需求。然而，SOA不足之處在于：
    在應(yīng)用間很難實現(xiàn)異步通信；
    SOA實現(xiàn)實時響應(yīng)和高數(shù)據(jù)傳輸時會非常有挑戰(zhàn)，這是因為XML強調(diào)地是健壯而非速度（盡管還可以選擇其它方案，如JSON）；
    SOA有很多安全性缺陷，這是由于應(yīng)用和系統(tǒng)使用了進程共享；并且
    在邏輯上分離的系統(tǒng)間交互時，SOA會涉及到復(fù)雜的事務(wù)管理。

向SOA邁進并不容易，有此意愿的企業(yè)必須意識到困難和固有的那些問題。無需多言，每個IT組織在SOA實現(xiàn)時都會經(jīng)歷許多權(quán)衡和折中，而且每條道路的距離也不盡相同。為了效率和靈活性，我們推薦在遺留環(huán)境中用增量方法來遷移到SOA。
Web服務(wù)（Web Services）
對于大多數(shù)組織來說，Web服務(wù)是實現(xiàn)松耦合體系最簡單的方式。通過一組基于XML的公開標準，如WSDL、SOAP和UDDI，就可以具有互操作的能力，這些標準提供了定義、發(fā)布和使用Web服務(wù)的通用方法。

Web服務(wù)是從Web應(yīng)用演進而來的，實際上，它們是簡化版的Web應(yīng)用。Web服務(wù)不再提供用戶接口及其數(shù)據(jù)，而僅僅提供數(shù)據(jù)接口；呈現(xiàn)信息給用戶的任務(wù)轉(zhuǎn)而由客戶端的應(yīng)用程序來負責。因此，Web服務(wù)是實現(xiàn)SOA最通用的方法，實際上，許多系統(tǒng)使用了Web服務(wù)但并沒有把自己定義成SOA。
SOA（和Web服務(wù)）的主要優(yōu)勢在于相同的服務(wù)可以被不同的客戶端來使用。原先為Web應(yīng)用設(shè)計的數(shù)據(jù)仍會被任何類型的客戶端使用而無需更改。這其中的例子包括從服務(wù)器獲取數(shù)據(jù)而無需提供顯示SQL數(shù)據(jù)庫查詢的桌面應(yīng)用，或者是那些從SOA服務(wù)獲取數(shù)據(jù)的付費或公眾的信息客戶端。
遺留系統(tǒng)可以封裝成SOA服務(wù)并對HTTP協(xié)議直接做出響應(yīng)，或者它工作在代理服務(wù)器的后面，代理服務(wù)器負責將請求翻譯成遺留系統(tǒng)的語言。最終，HTTP中的消息是明文的，它可以來自任何系統(tǒng)或編程語言。
技術(shù)（Technologies）
當需要創(chuàng)建靈活的應(yīng)用時SOA是一個好的選項，但如何去選擇正確的技術(shù)來實現(xiàn)則依賴于你的需求和環(huán)境。為了那些愿意在自己的業(yè)務(wù)處理中選擇SOA的組織，讓我們一起來回顧那些最相關(guān)的技術(shù)考量。
SOAP和REST的對比
當設(shè)計Web服務(wù)時，我們需要定義一組規(guī)則用來交換信息。當前最適合完成這個任務(wù)的工具是SOAP和REST。3SOAP是個老一點的協(xié)議，它是類似CORBA這樣已有技術(shù)在互聯(lián)網(wǎng)環(huán)境下的實現(xiàn)。SOAP可以利用多種傳輸協(xié)議（HTTP、SMTP等等），這給了它更多的靈活性。由于數(shù)據(jù)是在XML中交換的，所以當信息量和傳輸?shù)南�息較大時會有性能問題。SOAP可以和Web服務(wù)安全（Web Services Security）一起使用，后者是個簽名和加密消息的協(xié)議，它為消息交換提供了更多的安全性。4
REST是新的協(xié)議，它也用HTTP作為傳輸協(xié)議，但它可以處理更多的數(shù)據(jù)格式，如XML、JSON等等，它依賴于特定的URL而不是XML。REST是SOAP輕量級的替代者。REST在實現(xiàn)上沒有那么多約束，所以他的靈活性更高，也更輕，對文檔的依賴更少。與SOAP只能使用POST方法不同，REST可以使用Get方法，所以緩存不僅可以在業(yè)務(wù)設(shè)計中去實現(xiàn)，也可以通過基礎(chǔ)框架來完成。
具體選擇REST或SOAP取決于組織需求和限制條件。一些時候，我們會選擇企業(yè)應(yīng)用能力更強的SOAP，另一些時候，我們則選擇更好性能和更輕量的替代者，如REST。因為SOAP有更好的安全和故障處理能力，大多數(shù)企業(yè)級的IT商家都會把它作為優(yōu)選的Web服務(wù)實現(xiàn)。而REST則具有簡易、性能好以及實現(xiàn)上不那么嚴格的特性，這些使它成為Internet業(yè)務(wù)中實現(xiàn)協(xié)同工作API的優(yōu)選。
遺留系統(tǒng)的更新改造（Legacy Modernization）
盡管SOA體系是無縫連接企業(yè)系統(tǒng)并減少協(xié)議5和平臺陣痛的最好選項，但大多數(shù)人仍需要同現(xiàn)存的框架來打交道。當你試圖采納SOA體系來改造遺留系統(tǒng)時，并不存在一個完美方案，這是因為涉及到方方面面的因素。你需要對當前的技術(shù)堆棧進行考量，然后基于全局性的成本風險分析進行最優(yōu)的系統(tǒng)遷移。
因為遺留系統(tǒng)通常都在支持關(guān)鍵性的業(yè)務(wù)處理，所以必須采取step-by-step方式的改造計劃，并設(shè)計可行的演進方案使現(xiàn)有系統(tǒng)通過混合方法（hybrid approach）變?yōu)橥耆�的SOA體系。這里有幾種策略可以使遺留系統(tǒng)轉(zhuǎn)化為SOA體系。
第一個方法是將當前遺留系統(tǒng)用另一個或一組系統(tǒng)替換。通常，如果當前商用現(xiàn)貨系統(tǒng)（COTS）能夠滿足遺留系統(tǒng)的需求和功能，那么這種替換就是個好辦法。這個方案減少了維護但增加了未來修改的成本。第二種選項是用中間件來封裝現(xiàn)有遺留系統(tǒng)并通過Web服務(wù)來提供遺留系統(tǒng)的接口。用這種方法，遺留系統(tǒng)功能被封裝在服務(wù)層里面并插接在SOA環(huán)境里面。這可能解決不了一些問題：遺留應(yīng)用可以集成不同的幾種服務(wù)，這時就不能象期望的那樣對它們解耦。然而，當重寫遺留系統(tǒng)代價太大、遺留系統(tǒng)可以重用，并需要性價比好的解決方案時，這也是個好辦法。最后，也是第三個選項是重寫開發(fā)和編碼現(xiàn)有的遺留系統(tǒng)。這是個非常好的辦法，因為你可以對應(yīng)用的架構(gòu)施加作用并得到最優(yōu)的解耦層級。但是，遺留應(yīng)用通常是關(guān)鍵性的，而且因為涉及到之前的技術(shù)以及缺乏文檔，有些時候修改它們會非常困難或代價很高，這種修改可能會引起一些問題并增加項目風險。這種情況下，正確的評估涉及的所有風險是必不可少的。
企業(yè)應(yīng)用集成（Enterprise Application Integration）
當在任何SOA行動中計劃應(yīng)用集成時，許多供應(yīng)商的產(chǎn)品可以幫助你來簡化這種遷移。然而，不同的產(chǎn)品在能力和復(fù)雜性上有所不同，所以選擇正確的方案對于成功至關(guān)重要。你可以將這些選項基于集成的復(fù)雜性級別劃分為三個不同的組（看圖1）

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


表1:三種集成方案的對比
做出選擇
很明顯，做出最好的選項依賴于特定的需求和復(fù)雜性。首先，你先得決定框架是否已足夠滿足需求。例如，當你只有兩個應(yīng)用要連接或者你可以只用單個技術(shù)（如REST）就能滿足需求時，你就可選擇最簡單的方法（集成框架）而不用考慮它對工具和支持的缺乏；如果不是，那么ESB是一個不錯的選擇。但是，如果需要更多的特性，你就最好用一個更多能力和更復(fù)雜的棧，比如集成套件。
繼續(xù)向前，下一個演進的步驟將是如何使SOA匯聚和使云計算變得容易。云的出現(xiàn)給企業(yè)帶來的益處包括：云計算可以按需來提供資源，以容納數(shù)據(jù)、服務(wù)和進程。
如此，在云上進行集成就成為企業(yè)今天要面對的一項主要挑戰(zhàn)。在這樣的場景下，iPaaS（integration platform as a service）作為可以滿足廣泛集成需求的適合選項就應(yīng)運而生了。iPaaS作為云服務(wù)套件，可以使戶創(chuàng)建、管理并治理連接廣泛應(yīng)用和數(shù)據(jù)源的集成流（integration flows），而無需安裝或管理任何的硬件或中間件。
展望未來，調(diào)研咨詢公司Gartner預(yù)測到2016年，全世界至少35%的大中型組織將會使用一個或多個某種形式的iPaaS產(chǎn)品。然而，專家們以為iPaaS并不能取代SOA，對于復(fù)雜集成場景傳統(tǒng)的SOA仍然是需要的，比如企業(yè)內(nèi)部或企業(yè)間的低延遲消息系統(tǒng)和數(shù)據(jù)密集交易系統(tǒng)。
參考
    N. Gold et al., “Understanding ServiceOriented Software,” IEEE Software, vol. 21, no. 2, 2004, pp. 71–77.
    S. Jones, “Toward an Acceptable Definition of Service,” IEEE Software, vol. 22, no. 3, 2005, pp. 87–93.
    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.
    P. Louridas, “SOAP and Web Services,” IEEE Software, vol. 23, no. 6, 2006, pp. 62– 67.
    S. Vinoski, “REST Eye for SOA Guy,” IEEE Internet Computing, vol. 11, no. 1, 2007, pp. 82–84.
關(guān)于作者

Nicolas Serrano是Navarra大學工程學院的計算機科學和軟件工程教授 。他的研究方向包括信息技術(shù)及其在個人和職業(yè)發(fā)展上的應(yīng)用�？梢酝ㄟ^
nserrano@tecnun.es
來聯(lián)系他。


Josune Hernantes是Navarra大學工程學院的計算機科學和軟件工程教授 。她的研究方向包括軟件工程和信息系統(tǒng)。Hernantes從Navarra大學工程學院得到了計算機科學博士學位�？梢酝ㄟ^
jhernantes@tecnun.es
來聯(lián)系他。


Gorka Gallardo是Navarra大學工程學院的信息系統(tǒng)教授 。他的研究方向主要是信息技術(shù)�？梢酝ㄟ^ggallardo@tecnun.es來聯(lián)系他。


這篇文章首次出現(xiàn)在
IEEE軟件
雜志上。
IEEE軟件
對當前戰(zhàn)略性技術(shù)問題提供可靠的、業(yè)內(nèi)同行的評述信息。為了應(yīng)對可靠、靈活地運行企業(yè)的挑戰(zhàn)，IT管理者和技術(shù)領(lǐng)導(dǎo)者需要依靠IT 專家來獲得最先進的解決方案信息。
查看英文原文：
Service-Oriented Architecture and Legacy Systems
轉(zhuǎn)自
http://www.infoq.com/cn/articles/service-oriented-architecture-and-legacy-systems?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global
                       
                               
                    
                               
                       
                       
                       
                                時間:2015-04-28 08:13
來源:Infoq
  作者:楚晗
  
原文鏈接

本文來自ChinaUnix新聞頻道，如果查看原文請點：http://news.chinaunix.net/opensource/2015/0428/3244002.shtml