導語：通用報文交換平臺設(shè)計論文一文來源于網(wǎng)友上傳，不代表本站觀點，若需要原創(chuàng)文章可咨詢客服老師，歡迎參考。

2005年9月,農(nóng)發(fā)行綜合業(yè)務系統(tǒng)順利上線運行,全系統(tǒng)的業(yè)務經(jīng)營活動實現(xiàn)了數(shù)據(jù)大集中。同時隨著業(yè)務經(jīng)營范圍的不斷拓展,業(yè)務部門對增加科技支撐力度也提出了更高的要求。在新形勢下,如何既快速高效、又安全平穩(wěn)地滿足業(yè)務部門的需求,是農(nóng)發(fā)行科技部門面臨的一個重要課題。筆者認為,在綜合業(yè)務系統(tǒng)前端,開發(fā)部署一個通用的、穩(wěn)定的、可擴展的通用報文交換平臺是適應業(yè)務發(fā)展、滿足業(yè)務需求變化和規(guī)避技術(shù)風險的一個有效舉措。

通用報文交換平臺(UniversalMessageExchangingPlat)簡稱UMEP,是按照標準化的原則,為處理異步報文交換業(yè)務而設(shè)計的通用平臺。在當前數(shù)據(jù)大集中的環(huán)境下,設(shè)計通用報文交換平臺能有效的解決綜合業(yè)務系統(tǒng)的通用性和擴展性問題,從而高效安全地滿足業(yè)務變化的需求。本文將就農(nóng)發(fā)行UMEP的分析與設(shè)計作一闡述。

一、平臺的軟件基礎(chǔ)

UMEP選用Tuxedo作為基礎(chǔ)軟件平臺來進行設(shè)計和部署。Tuxedo是BEA公司的一個商品化的交易中間件軟件產(chǎn)品,從軟件最初推出至今已經(jīng)經(jīng)歷了9個版本的升級變遷,廣泛應用于金融、電信、郵政、航空等領(lǐng)域,是業(yè)內(nèi)歷史最久、應用最廣的中間件產(chǎn)品。

農(nóng)發(fā)行從電子聯(lián)行系統(tǒng)開始,就引入了Tuxedo中間件產(chǎn)品,直至在綜合業(yè)務系統(tǒng)中更為全面地使用。在多年的開發(fā)維護工作中,農(nóng)發(fā)行不僅積累了大量的經(jīng)驗,而且還培養(yǎng)了一批技術(shù)人才。選用Tuxedo作為UMEP的基礎(chǔ)軟件平臺,做到核心系統(tǒng)相一致,不單單是為了減輕系統(tǒng)維護的工作量,降低系統(tǒng)故障的風險,更重要的是考慮到在其基礎(chǔ)上設(shè)計出來的UMEP,可以具備較高的可靠性、通用性、安全性和可擴展性。

二、平臺的總體設(shè)計

根據(jù)報文交換類業(yè)務的處理流程,UMEP在總體的邏輯結(jié)構(gòu)上設(shè)計為三層:前置機接口層、通訊平臺層和核心服務層。其結(jié)構(gòu)圖如下:

外接系統(tǒng)匯入的報文,由前置機通過外接系統(tǒng)提供的接口API(應用程序接口)獲取后,發(fā)送至UMEP,再轉(zhuǎn)發(fā)至核心服務進行業(yè)務處理。行內(nèi)系統(tǒng)匯出的報文,由核心系統(tǒng)發(fā)送至UMEP,再轉(zhuǎn)發(fā)到前置機,通過外接系統(tǒng)接口API發(fā)送給外接系統(tǒng)。前置機和UMEP的通信,以及UMEP與核心系統(tǒng)的通信,均是以Tuxedo服務調(diào)用的方式進行的,并且使用Tuxedo的事務管理功能,保證報文傳送的準確性和唯一性。

三、前置機接口層的設(shè)計

在一個外接系統(tǒng)的前置機上,一般都會部署兩套接口軟件。一套是行內(nèi)系統(tǒng)的接口軟件,功能就是通過外接系統(tǒng)API進行報文的收發(fā)工作。另一套就是由外接系統(tǒng)提供的API接口。兩者之間是調(diào)用與被調(diào)用的關(guān)系。

為了保證行內(nèi)接口的通用性,我們把行內(nèi)接口軟件設(shè)計為兩層結(jié)構(gòu),一層是穩(wěn)定的,一層是不穩(wěn)定的。

穩(wěn)定的一層稱之為UMEPClient,由兩個定時啟動的守護進程uploadMsg和downloadMsg組成,分別實現(xiàn)報文接收和報文發(fā)送的功能。之所以稱之為穩(wěn)定的,是因為這兩個守護進程可以在任何外接系統(tǒng)的前置機上使用,并不需要針對不同的外接系統(tǒng)重寫代碼,體現(xiàn)了行內(nèi)接口的通用性。

不穩(wěn)定的一層稱之為BranchInterfaceAPI(簡稱BIA),由一組API函數(shù)組成,以庫文件的方式提供,被UMEPClient調(diào)用。之所以稱之為不穩(wěn)定的,是因為它是對外接系統(tǒng)提供的API接口函數(shù)的封裝,需要針對不同的外接系統(tǒng)改寫代碼。BIA被設(shè)計為10個API函數(shù),分別處理非實時通訊和實時通訊兩種情況:

BIA不僅封裝了外接系統(tǒng)的API函數(shù),還有一個重要的工作就是負責報文格式的轉(zhuǎn)換。不同的外接系統(tǒng),其報文的描述格式各有不同。為了行內(nèi)系統(tǒng)能夠以同樣的方式處理,就需要對報文用統(tǒng)一的格式進行重新描述,轉(zhuǎn)換為行內(nèi)系統(tǒng)使用的標準報文。同樣,行內(nèi)發(fā)出的標準報文也需要由經(jīng)BIA轉(zhuǎn)換后,再發(fā)送給外接系統(tǒng)。這種將報文格式轉(zhuǎn)換功能由通信平臺實現(xiàn)改為由前置機實現(xiàn)的設(shè)計方式,不僅是實現(xiàn)UMEP通用性的需要,也是為了充分利用前置機的運算功能,減輕通訊平臺的運算壓力,使其集中資源處理報文轉(zhuǎn)發(fā)的功能,提高平臺的處理能力。

前置機接口層的系統(tǒng)結(jié)構(gòu)如圖:

在前置機端引入BIA的設(shè)計模式的另一個優(yōu)點是,可以最大限度地降低總行科技部門的開發(fā)工作量。一個新系統(tǒng)的接入,總行不再需要集中開發(fā)行內(nèi)接口軟件(全國性系統(tǒng)仍可由總行統(tǒng)一開發(fā)),只要由分行按照UMEP的報文標準和API標準,自行組織開發(fā)一套相應的BIA,以庫文件的方式提供給UMEP使用,然后就可以通過UMEP順利接入核心系統(tǒng)。另外由于BIA層的開發(fā)工作并不涉及到Tuxedo技術(shù),因此對于分行而言,也降低了技術(shù)開發(fā)的難度。同時,這樣的分層設(shè)計也為分行特色業(yè)務的開展提供了技術(shù)上的便利條件。

UMEPClient在部署之前,附帶的BIA是一個完全由空API函數(shù)編譯后獲得的庫文件。部署到前置機以后,只要將這個文件替換為相應外接系統(tǒng)的BIA庫文件,即可完成系統(tǒng)對接功能。由此可見,UMEPClient在前置機上的安裝部署也是相對簡單靈活的。此外,由于Tuxedo的跨平臺性,可以使得我們的UMEPClient不僅可以部署在HPUX/AIX/SCOUnix/Linux等Unix或類Unix平臺上,而且可以運行在AS400或Windows平臺上。換句話說,無論外接系統(tǒng)前置機采用的是什么樣的操作系統(tǒng)平臺,我們的UMEPClient都可以正常部署使用。這也從一個側(cè)面體現(xiàn)了UMEP的通用性。

四、通訊平臺層的設(shè)計

UMEP通訊平臺層的設(shè)計,使用了Tuxedo服務程序和Tuxedo客戶端程序相結(jié)合的方式。兩個Tuxedo服務程序名為uploadMsgSvc和downloadMsgSvc,分別被前置機端UMEPClient的up-loadMsg和downloadMsg進程調(diào)用,用于平臺的報文接收和發(fā)送。兩個Tuxedo客戶端程序名為uploadKernel和download-Kernel,是兩個定時啟動的守護進程,分別負責上傳平臺報文至核心系統(tǒng)和下載核心系統(tǒng)報文至平臺。其系統(tǒng)結(jié)構(gòu)圖如下:

在UMEP的平臺設(shè)計中,我們引入了數(shù)據(jù)庫的內(nèi)容。這主要是考慮到UMEP平臺將被設(shè)計為一個擁有較高處理能力的報文交換平臺。如果單純的依靠核心服務完成業(yè)務處理后,再寫入核心應用數(shù)據(jù)庫,勢必會增加調(diào)用端的等待時間,影響平臺的處理效率和吞吐量。此外,使用數(shù)據(jù)庫對報文進行暫存,可以減少報文傳送過程中因網(wǎng)絡通訊問題而導致的報文丟失現(xiàn)象,保證報文的正確傳輸。在報文的上行過程中,平臺服務uploadMsgSvc收到前置機發(fā)來的標準報文后,不作任何處理,直接寫入數(shù)據(jù)庫并返回,完成平臺的報文接收工作。平臺上的uploadKernel進程啟動后,負責從數(shù)據(jù)庫中讀取報文信息,并根據(jù)共享內(nèi)存中存放的XML標準報文格式描述文件,將報文中的業(yè)務要素解析出來,轉(zhuǎn)換為Tuxe-do服務調(diào)用所需的FMLBuffer格式,再通過Tuxedo服務調(diào)用,上傳給核心系統(tǒng)完成業(yè)務處理。

在報文的下行過程中,通過平臺上定時啟動的downloadKernel進程,調(diào)用核心系統(tǒng)的相關(guān)服務,獲取下傳報文信息,再根據(jù)XML報文格式描述文件,轉(zhuǎn)換為標準報文后寫入數(shù)據(jù)庫。平臺服務downloadMsgSvc由前置機端的down-loadMsg進程定時調(diào)用。每次調(diào)用時,該服務從數(shù)據(jù)庫中讀取待發(fā)送的報文,返回給前置機。

行內(nèi)標準報文的格式解析和打包是通過XML報文格式描述文件來完成的。不同外接系統(tǒng)所使用的報文集,都會用行內(nèi)的標準格式重新加以定義,體現(xiàn)為一個XML描述文件。這個XML文件作為BIA的一部分,由BIA的開發(fā)者按照標準編寫完成后,提供給UMEP平臺使用。平臺啟動時,將裝載所有外接系統(tǒng)的XML描述文件到共享內(nèi)存中,供uploadKernel和downloadKernel處理標準報文解析和打包時使用。鑒于XML強大的擴展性和良好的易用性,這樣的設(shè)計必然使我們的平臺具備優(yōu)秀的報文兼容性,同樣也保證了UMEP的通用性。

五、核心服務層的設(shè)計

UMEP的核心服務層采用了面向服務的設(shè)計模式,每一種業(yè)務類型的處理都被細化為一個或多個核心服務來完成。每個核心服務只完成某一種特定的功能,服務與服務之間的耦合關(guān)系遵循“松散”的原則。這種“松散”的耦合關(guān)系,大大的增加了核心服務的可重用性,為業(yè)務的變更和擴展帶來巨大的靈活性和便利性。

在核心服務的外圍,部署了一類管理調(diào)度服務,稱為TxDispatcher。TxDis-patcher不僅能夠管理報文交換類交易的服務請求,而且可以管理聯(lián)機實時交易的服務請求,并根據(jù)不同類型的交易,按照事先定義好的業(yè)務處理流程,調(diào)度相應的核心服務處理。

核心服務層的結(jié)構(gòu)示意圖如下:

在服務的調(diào)用者和核心服務之間引入TxDispatcher管理服務層,使得核心業(yè)務系統(tǒng)對業(yè)務需求的變更或調(diào)整,具備快速投產(chǎn)的能力。因為在核心服務具有較高可重用性的基礎(chǔ)之上,僅僅通過定制合理的業(yè)務處理流程,組合不同的核心服務,就有可能完成新業(yè)務功能的開發(fā)工作。

六、安全模塊的設(shè)計

UMEP中安全模塊的設(shè)計,仍然采用原有的PKI證書模式。因為基于PKI證書的安全技術(shù)是目前安全級別較高,并且是國家有關(guān)安全部門認可的一種加密認證技術(shù)。這種技術(shù)在業(yè)界被廣泛使用,也是農(nóng)發(fā)行綜合業(yè)務系統(tǒng)目前正在使用的安全技術(shù)措施之一。

在使用PKI證書的安全模式下,UMEP服務器和外接系統(tǒng)前置機均需要獲得由總行CA中心簽發(fā)的IC卡,作為自己合法身份的唯一標識。報文上行時,前置機使用自己的IC卡私鑰對報文進行加密簽名,然后上傳UMEP服務器。UMEP服務器使用該前置機證書中的公鑰解密并核驗簽名,確認報文的合法性。報文下行時,UMEP服務器使用自己的IC卡私鑰,對下傳報文加密簽名后發(fā)送前置機。前置機收到報文后,使用UMEP服務器的證書公鑰進行解密并核驗簽名,核驗通過后再發(fā)送給外接系統(tǒng)。UMEP的安全體系結(jié)構(gòu)如下圖所示:

需要強調(diào)的是,在UMEP的設(shè)計過程中,通用性是整個平臺的核心原則。只有具備了通用性能力的業(yè)務平臺,才能最大程度的避免因業(yè)務變化帶來的系統(tǒng)運行風險。

鑒于UMEP本身建構(gòu)在基于服務的基礎(chǔ)軟件平臺之上,并且核心服務采用了分布式結(jié)構(gòu)的設(shè)計,因此在物理部署上UMEP能夠支持異地多機集群方式部署,具有高度的可靠性和靈活的可擴展性。此外,多層結(jié)構(gòu)的設(shè)計思想,也使得UMEP具備了良好的伸縮性,既可以部署在總行中心,也可以部署在省級分行,如有需要甚至可以部署在二級分行乃至網(wǎng)點。先進的PKI證書安全技術(shù),可以有效地阻止非法報文的進入和防范數(shù)據(jù)在傳輸過程中被非法篡改,保證了平臺系統(tǒng)的安全性。

綜上所述,UMEP是一個基于分布式服務設(shè)計的具備通用性、高可靠性、高擴展性、高安全性,并具有良好的伸縮性和跨平臺能力的通用報文交換平臺。