基于面向服務架構的遺留系統集成研究與實現

王靖娜，張建華

（1.陜西廣播電視大學，西安,710119；2.西安科技大學，西安，710054）

0 引言

企業在構建新的信息統時，如何有效重用遺留系統（Legacy System，LS）是一個必須考慮的問題，然而由于遺留系統自身存在的一些問題，傳統的重用機制并不能很好應對這些情況。近年來隨著SOA技術迅速發展，業界普遍將這種思想引入遺留系統的集成領域。

面向服務架構（Service-oriented architecture，SOA）是基于請求/響應模式的分布式設計范型的一種演化，一個應用程序的業務邏輯（Business logic）或某些單獨的功能被模塊化并作為服務呈現給消費者或客戶端。SOA思想實現的關鍵在于如何建立一套程序到程序的通信模型，而Web Service用現有的和新興的一組協議建立了一套平臺無關、語言無關、通用的通信模型，成為目前最為流行的SOA實現。目前，包括IBM，Microsoft，Sun，Oracle和BEA等在內的各大公司紛紛宣布在他們的產品中支持Web服務。現有的Web Servic Platforme平臺主要有IBM WebSphere，HP Web Services，Sun ONE，Microsoft Dot NET。然而這些產品更適合開發新的服務而非集成遺留系統，所以從一個實際項目的需求出發，結合遺留子系統較多且松散分布及對系統安全穩定性能的要求，本文提出了基于SOA的系統信息集成框架，較好地解決了傳統信息集成技術構建的集成系統不易維護、缺乏擴展性及動態調整性以及應用范圍狹窄等方面的缺陷。

1 遺留系統集成技術分析

如何將遺留系統遷移到新的企業應用平并不是一個新鮮的問題，在過去幾十年間人們嘗試了很多方法來提高遺留系統集成效率，歸納起來主要有以下幾種：

重新開發（Redevelopment）：利用新的硬件平臺、架構、工具、數據庫等從頭開始實現遺留系統所提供的服務。

包裝（Wrapping）：圍繞已有數據、獨立程序、應用系統及接口用新接口進行包裝以便于其它系統訪問。

遷移（Migration）：在保留原有系統的數據和功能的前提下，利用新技術將遺留系統移植到新的平臺中。

圖1顯示了常用的遺留系統集成方法。由于維護（Maintenance）也是軟件生命周期中的一部分，所以出于完整性考慮將其加入其中。這當然不影響上文的分類，因為如果一個軟件系統的在可接受的預算范圍內被維護，它也不能被稱為遺留系統。如圖所示每種方法的風險和代價是不同的，其中重新開發代價最大，而包裝對遺留系統最小，在實際的應用中重新開發的策略也很少被用于遺留系統的集成。

在業界的實際應用中，先后出現了基于公共請求代理體系（CORBA），遠程方法調用（RMI），分布式組件對象（DCOM）以及Agent等分布式對象技術。由于這些技術自身的一些缺點,導致它們在遺留系統的現代化領域均未流行開來。RMI的實現要求通信的兩端都具有Java環境，從根本上阻止了它的推廣；CORBA雖然定義了一種語言無關的通信方式，但企業防火墻通常會阻止對象請求代理（Object RequestBroker，ORB）的通信；基于COM，DCOM遺留系統的集成要求集成環境中的計算機節點都支持Windows系統；基于Agent的遺留系統信息集成充分考慮了遺留系統的特點，但對于一個擁有眾多遺留系統的企業，要實現各個遺留子系統Agent之間的互相通信和協同操作，困難很大。與此同時，作為一種松散藕合及可復用的分布式計算模型，面向服務的架構也越來越多地被用于遺留系統集成。已有的方法都從重用的角度不同程度的實現了遺留系統的服務集成，但就其方法的實質來說，都沒有超出上文所述的三種形式，尤其是包裝和遷移。

2 集成框架

2.1 遺留系統集成的基本要求

考慮到遺留系統自身的特點，實現遺留系統信息集成會受到多方面的限制，在實現技術方面應滿足以下基本要求：①遺留系統的信息集成應該是遺留系統具體應用的集成，應支持業務正常運轉所需信息的正常交互，而不是遺留系統簡單的互連及信息交換。②集成是動態的，能根據企業經營策略及需求變化來及時調整集成方式；③應充分考慮新業務對安全穩定運行的要求，保證遺留子系統在集成后仍能保持單獨運行時的安全穩定性；④遺留系統的信息集成應該是對原有遺留子系統功能的擴展和延伸，而不是推倒遺留子系統原有的所有功能。

2.2 體系結構

基于遺留系統集成的基本要求和SOA架構的思想，考慮將遺留系統中需要暴露的功能包裝成Web服務，這樣遺留系統間既可以Web服務的形式進行信息交互，又保證了遺留系統的功能、安全性、穩定性不受影響。

圖2所示的筆者提出的遺留系統服務集成分層體系結構，其主要由業務層、服務層、包裝層三個層次組成。業務層是服務的使用者或客戶，它與服務層以服務的WSDL作為交互契約，通過SOAP消息進行交互。服務層主要負責處理來自業務層的各種服務調用請求以及服務提供者的響應，該層主要包括：服務容器和服務代理。處于最下層的是包裝層，它為各種遺留系統生成服務代理，其主要由服務包裝器組成。

服務容器：服務提供者與服務使用者之間的橋梁，它監聽服務請求端口，處理所有來自于客戶的服務調用請求以及服務運行結果的發送。

服務代理：屏蔽不同遺留系統所提供服務由于實現技術上的不同而造成的服務調用上的差異，完成實際服務的轉調工作。主要有兩種形式的服務代理：①Python腳本，它可以是對遺留系統服務的轉調代碼，也可以是實際的服務。②Python擴展，它是用C/C++寫成的一種特殊的動態鏈接庫，在某些情況下Python對所需服務不能直接支持或效率方面不能達到業務需求就要通過效率更高C/C++提供支持，而Python擴展恰好在二者之間架起了橋梁。

服務包裝器：負責生成遺留系統的服務代理，遺留系統的提供服務并不直接進入SOA體系，而是經過包裝也即生成代理及WSDL文件后成為Web服務才融入到整個企業的業務流程中。它中要由以下模塊組成：①包裝對象模式庫即一組針對基于不同實現技術的遺留系統服務包裝的內置對象，它是遺留系統服務包裝的控制器。②服務元信息模型，遺留系統服務信息的內存模型，它主要包括：遺留系統對外所提供服務的接口定義、服務實現技術類型的描述信息、以及服務的運行時信息。③代碼生成器，根據服務元信息為包裝器生成產生服務代理的各種中間代碼。④make文件生成器，為包裝器生成編譯Python擴展所需的make文件。

2.3 服務包裝流程分析

服務集成的一個關鍵步驟就是將遺留系統所提供服務包裝為Web服務，在集成框架中這一過程由服務包裝器來完成。服務包裝器包裝服務的典型過程分為五個階段：元信息獲取、產生代理代碼、生成臨時工程、生成make文件、生成服務代理。

元信息獲取：集成人員通過用戶界面將遺留系統服務元信息送入元信息文檔對象，輸入內容形式有兩種：一種是詳細的服務元信息；另一種包含服務元信息的數據文件。

產生代理代碼：接著將包含有服務信息的元信息文檔對象傳入相應類型的服務集成對象，包裝器為不同類型的遺留系統提供了不同包裝對象。有了服務的元信息，包裝對象就為該遺留系統生成代理代碼并將之填入元信息文檔對象的適當子對象。

生成臨時工程：包裝對象以元信息文檔對象作為基礎調用代碼生成器生成用于編譯的服務代理臨時工程及其配置文件，臨時工程包含了生成最終Python擴展的所有文件，而配置文件包含的對于編譯器有價值的配置信息。

生成make文件：包裝對象將臨時工程配置文件送入make文件生成器為臨時工程生成用于自動編譯的make文件。

生成服務代理：包裝器將make文件作為輸入，調用編譯器提供的make工具編譯臨時工程生成服務代理。

3 關鍵技術

服務元信息模型

服務元信息是集成框架進行包裝的信息基礎，集成框架用一組內建的元信息模型來存儲這些信息供包裝的不同階段使用。而元信息模型提供一組接口供客戶程序操作元信息，通過這組接口所有服務元信息就可以被添加到元信息模型中,反之亦可取出。元信息模型主要包含兩信息：服務包裝信息、接口信息。服務包裝信息中包含了一些關于服務實現的描述信息，接口信息則給出了服務接口定義。

服務包裝信息大體分為兩類：服務類型無關信息和服務類型相關信息。服務類型無關信息是各種不同類型遺留系統服務所共有的，如服務的名字、目標存放位置等。服務類型相關信息則由于各遺留系統服務實現技術的不同而不同，例如當遺留系統以COM組件形式提供服務時要對其進行包裝就需知道該組件的ProgID。包裝器根據這些信息為服務的接口生成不同的代理代碼。

接口描述信息是遺留系統對外提供服務的詳細接口定義，集成框架以這些定義為基礎，生成接口的服務的代理接口及WSDL文件。

3.1 Python擴展

雖然Python是一種功能強大的腳本語言，但是對于某些系統調用或庫函數，其語言本身是無能為力的，Python通過一種稱之為擴展(Extension)的機制來達到這一目的。它提供了一系列的C函數接口、宏、變量來暴露其運行時系統，結合待調用的庫函數或系統調用生成擴展動態鏈接庫就可以就可以將所需功能引入到Python環境之中，象普通模塊一樣調用。然而直接通過這些接口函數手動生成Python擴展是一種復雜易于出且重復性高的過程，因此在生成擴展模塊時，使用了Boost.Python庫。Boost.Python 庫是Python和C++之間的一個接口框架，它使用了先進的元編程技術來簡化用戶使用的語法，這樣用戶可以使用類似描述性的定義語言來快速、無縫的將C++中的函數和對象暴露給Python，反之亦然。它采用一種無侵入的設計方法，這樣包裝時就可以不對待包裝代碼做任何修改，這也使得Boost.Python成為一種理想的用于C++和Python接口的第三方庫。其使用的基本步驟如下：

3.2 引入Boost.Python所需頭文件及名字空間

將模塊的名字作為參數送入BOOST_PYTHON_MODULE宏定義擴展模塊。

將函數名字及函數指針傳入def宏定義要暴露的C++函數。

以類名作為參數使用class宏定義要導出的C++類。

3.3 make文件產生器

當包裝獲取到足夠的關于服務元信息后，集成人員就應該不需要再介入包裝過程，而實現這一目標的關鍵步驟就是Python擴展的自動編譯。生成Python擴展主要元素：代理接口定義、代理接口實現和Boost.Python擴展定義通過代碼生成器都可以產生，這時只要使用編譯器對由以上元素組成的工程編譯即可生成Python擴展，而此時自動編譯的關鍵就是生成make工具所需的make文件。

對make文件研究發現，其配置信息可抽取為兩類：Python擴展所需的特定工程配置及特定編譯器針對不同配置具體參數。工程配置信息由包裝產生，而編譯器配置參數則只要一次寫入文件后就可以重復利用。

4 總結

在研究了以往工作的基礎之上，本文提出了一種基于SOA的遺留系統的集成方案。它考慮了遺留系統的特點給出了特定類型服務的代理代碼自動生成模式，給合SOA的通用通信模型解決了服務之間的松耦合的互操作問題，吸取了動態語言Python的優點簡化了服務容器的設計，提高了服務集成的擴展性，很好的滿足了實際項目需求。

[1]Jesus Bisbal,Deirdre Lawless,Bing Wu,and Jane Grimson.Legacy Information Systems:Issues and Directions.IEEE Software,September/October 1999.

[2]Eric Newcomer,Greg Lomow.Understanding SOA with Web Services.Addison Wesley Professional,2004-12.

[3]Mark Endrei,Jenny Ang,Ali Arsanjani,Sook Chua,Philippe Comte,Pal Krogdahl,Min Luo,Tony Newling.Patterns:Service-Oriented Architecture and Web Services.IBM 2004-04,33.

[4]Jack Herrington.Code Generation in Action.Manning Publications Co.2003,28-34.

[5]Ethan Cerami.Web Services Essentials.O'Reilly,February 2002.