王靖娜，張建華

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

0 引言

企業(yè)在構(gòu)建新的信息統(tǒng)時(shí)，如何有效重用遺留系統(tǒng)（Legacy System，LS）是一個(gè)必須考慮的問題，然而由于遺留系統(tǒng)自身存在的一些問題，傳統(tǒng)的重用機(jī)制并不能很好應(yīng)對(duì)這些情況。近年來隨著SOA技術(shù)迅速發(fā)展，業(yè)界普遍將這種思想引入遺留系統(tǒng)的集成領(lǐng)域。

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

1 遺留系統(tǒng)集成技術(shù)分析

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

重新開發(fā)（Redevelopment）：利用新的硬件平臺(tái)、架構(gòu)、工具、數(shù)據(jù)庫等從頭開始實(shí)現(xiàn)遺留系統(tǒng)所提供的服務(wù)。

包裝（Wrapping）：圍繞已有數(shù)據(jù)、獨(dú)立程序、應(yīng)用系統(tǒng)及接口用新接口進(jìn)行包裝以便于其它系統(tǒng)訪問。

遷移（Migration）：在保留原有系統(tǒng)的數(shù)據(jù)和功能的前提下，利用新技術(shù)將遺留系統(tǒng)移植到新的平臺(tái)中。

圖1顯示了常用的遺留系統(tǒng)集成方法。由于維護(hù)（Maintenance）也是軟件生命周期中的一部分，所以出于完整性考慮將其加入其中。這當(dāng)然不影響上文的分類，因?yàn)槿绻粋€(gè)軟件系統(tǒng)的在可接受的預(yù)算范圍內(nèi)被維護(hù)，它也不能被稱為遺留系統(tǒng)。如圖所示每種方法的風(fēng)險(xiǎn)和代價(jià)是不同的，其中重新開發(fā)代價(jià)最大，而包裝對(duì)遺留系統(tǒng)最小，在實(shí)際的應(yīng)用中重新開發(fā)的策略也很少被用于遺留系統(tǒng)的集成。

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

2 集成框架

2.1 遺留系統(tǒng)集成的基本要求

考慮到遺留系統(tǒng)自身的特點(diǎn)，實(shí)現(xiàn)遺留系統(tǒng)信息集成會(huì)受到多方面的限制，在實(shí)現(xiàn)技術(shù)方面應(yīng)滿足以下基本要求：①遺留系統(tǒng)的信息集成應(yīng)該是遺留系統(tǒng)具體應(yīng)用的集成，應(yīng)支持業(yè)務(wù)正常運(yùn)轉(zhuǎn)所需信息的正常交互，而不是遺留系統(tǒng)簡單的互連及信息交換。②集成是動(dòng)態(tài)的，能根據(jù)企業(yè)經(jīng)營策略及需求變化來及時(shí)調(diào)整集成方式；③應(yīng)充分考慮新業(yè)務(wù)對(duì)安全穩(wěn)定運(yùn)行的要求，保證遺留子系統(tǒng)在集成后仍能保持單獨(dú)運(yùn)行時(shí)的安全穩(wěn)定性；④遺留系統(tǒng)的信息集成應(yīng)該是對(duì)原有遺留子系統(tǒng)功能的擴(kuò)展和延伸，而不是推倒遺留子系統(tǒng)原有的所有功能。

2.2 體系結(jié)構(gòu)

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

圖2所示的筆者提出的遺留系統(tǒng)服務(wù)集成分層體系結(jié)構(gòu)，其主要由業(yè)務(wù)層、服務(wù)層、包裝層三個(gè)層次組成。業(yè)務(wù)層是服務(wù)的使用者或客戶，它與服務(wù)層以服務(wù)的WSDL作為交互契約，通過SOAP消息進(jìn)行交互。服務(wù)層主要負(fù)責(zé)處理來自業(yè)務(wù)層的各種服務(wù)調(diào)用請(qǐng)求以及服務(wù)提供者的響應(yīng)，該層主要包括：服務(wù)容器和服務(wù)代理。處于最下層的是包裝層，它為各種遺留系統(tǒng)生成服務(wù)代理，其主要由服務(wù)包裝器組成。

服務(wù)容器：服務(wù)提供者與服務(wù)使用者之間的橋梁，它監(jiān)聽服務(wù)請(qǐng)求端口，處理所有來自于客戶的服務(wù)調(diào)用請(qǐng)求以及服務(wù)運(yùn)行結(jié)果的發(fā)送。

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

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

2.3 服務(wù)包裝流程分析

服務(wù)集成的一個(gè)關(guān)鍵步驟就是將遺留系統(tǒng)所提供服務(wù)包裝為Web服務(wù)，在集成框架中這一過程由服務(wù)包裝器來完成。服務(wù)包裝器包裝服務(wù)的典型過程分為五個(gè)階段：元信息獲取、產(chǎn)生代理代碼、生成臨時(shí)工程、生成make文件、生成服務(wù)代理。

元信息獲?。杭扇藛T通過用戶界面將遺留系統(tǒng)服務(wù)元信息送入元信息文檔對(duì)象，輸入內(nèi)容形式有兩種：一種是詳細(xì)的服務(wù)元信息；另一種包含服務(wù)元信息的數(shù)據(jù)文件。

產(chǎn)生代理代碼：接著將包含有服務(wù)信息的元信息文檔對(duì)象傳入相應(yīng)類型的服務(wù)集成對(duì)象，包裝器為不同類型的遺留系統(tǒng)提供了不同包裝對(duì)象。有了服務(wù)的元信息，包裝對(duì)象就為該遺留系統(tǒng)生成代理代碼并將之填入元信息文檔對(duì)象的適當(dāng)子對(duì)象。

生成臨時(shí)工程：包裝對(duì)象以元信息文檔對(duì)象作為基礎(chǔ)調(diào)用代碼生成器生成用于編譯的服務(wù)代理臨時(shí)工程及其配置文件，臨時(shí)工程包含了生成最終Python擴(kuò)展的所有文件，而配置文件包含的對(duì)于編譯器有價(jià)值的配置信息。

生成make文件：包裝對(duì)象將臨時(shí)工程配置文件送入make文件生成器為臨時(shí)工程生成用于自動(dòng)編譯的make文件。

生成服務(wù)代理：包裝器將make文件作為輸入，調(diào)用編譯器提供的make工具編譯臨時(shí)工程生成服務(wù)代理。

3 關(guān)鍵技術(shù)

服務(wù)元信息模型

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

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

接口描述信息是遺留系統(tǒng)對(duì)外提供服務(wù)的詳細(xì)接口定義，集成框架以這些定義為基礎(chǔ)，生成接口的服務(wù)的代理接口及WSDL文件。

3.1 Python擴(kuò)展

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

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

將模塊的名字作為參數(shù)送入BOOST_PYTHON_MODULE宏定義擴(kuò)展模塊。

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

以類名作為參數(shù)使用class宏定義要導(dǎo)出的C++類。

3.3 make文件產(chǎn)生器

當(dāng)包裝獲取到足夠的關(guān)于服務(wù)元信息后，集成人員就應(yīng)該不需要再介入包裝過程，而實(shí)現(xiàn)這一目標(biāo)的關(guān)鍵步驟就是Python擴(kuò)展的自動(dòng)編譯。生成Python擴(kuò)展主要元素：代理接口定義、代理接口實(shí)現(xiàn)和Boost.Python擴(kuò)展定義通過代碼生成器都可以產(chǎn)生，這時(shí)只要使用編譯器對(duì)由以上元素組成的工程編譯即可生成Python擴(kuò)展，而此時(shí)自動(dòng)編譯的關(guān)鍵就是生成make工具所需的make文件。

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

4 總結(jié)

在研究了以往工作的基礎(chǔ)之上，本文提出了一種基于SOA的遺留系統(tǒng)的集成方案。它考慮了遺留系統(tǒng)的特點(diǎn)給出了特定類型服務(wù)的代理代碼自動(dòng)生成模式，給合SOA的通用通信模型解決了服務(wù)之間的松耦合的互操作問題，吸取了動(dòng)態(tài)語言Python的優(yōu)點(diǎn)簡化了服務(wù)容器的設(shè)計(jì)，提高了服務(wù)集成的擴(kuò)展性，很好的滿足了實(shí)際項(xiàng)目需求。

[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.