通用報文交換平臺的構想與設計

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

2、準化的原則,為處理異步報文交換業(yè)務而設計的通用平臺。在當前數(shù)據(jù)大集中的環(huán)境下,設計通用報文交換平臺能有效的解決綜合業(yè)務系統(tǒng)的通用性和擴展性問題,從而高效安全地滿足業(yè)務變化的需求。本文將就農發(fā)行UMEP的分析與設計作一闡述。一、平臺的軟件基礎UMEP選用Tuxedo作為基礎軟件平臺來進行設計和部署。Tuxedo是BEA公司的一個商品化的交易中間件軟件產(chǎn)品,從軟件最初推出至今已經(jīng)經(jīng)歷了9個版本的升級變遷,廣泛應用于金融、電信、郵政、航空等領域,是業(yè)內歷史最久、應用最廣的中間件產(chǎn)品。農發(fā)行從電子聯(lián)行系統(tǒng)開始,就引入了Tuxedo中間件產(chǎn)品,直至在綜合業(yè)務系統(tǒng)中更為全面地使用。在多年的開發(fā)維護工作中,

3、農發(fā)行不僅積累了大量的經(jīng)驗,而且還培養(yǎng)了一批技術人才。選用Tuxedo作為UMEP的基礎軟件平臺,做到核心系統(tǒng)相一致,不單單是為了減輕系統(tǒng)維護的工作量,降低系統(tǒng)故障的風險,更重要的是考慮到在其基礎上設計出來的UMEP,可以具備較高的可靠性、通用性、安全性和可擴展性。二、平臺的總體設計根據(jù)報文交換類業(yè)務的處理流程,UMEP在總體的邏輯結構上設計為三層:前置機接口層、通訊平臺層和核心服務層。其結構圖如下:外接系統(tǒng)匯入的報文,由前置機通過外接系統(tǒng)提供的接口API(應用程序接口)獲取后,發(fā)送至UMEP,再轉發(fā)至核心服務進行業(yè)務處理。行內系統(tǒng)匯出的報文,由核心系統(tǒng)發(fā)送至UMEP,再轉發(fā)到前置機,通過外接

4、系統(tǒng)接口API發(fā)送給外接系統(tǒng)。前置機和UMEP的通信,以及UMEP與核心系統(tǒng)的通信,均是以Tuxedo服務調用的方式進行的,并且使用Tuxedo的事務管理功能,保證報文傳送的準確性和唯一性。三、前置機接口層的設計在一個外接系統(tǒng)的前置機上,一般都會部署兩套接口軟件。一套是行內系統(tǒng)的接口軟件,功能就是通過外接系統(tǒng)API進行報文的收發(fā)工作。另一套就是由外接系統(tǒng)提供的API接口。兩者之間是調用與被調用的關系。為了保證行內接口的通用性,我們把行內接口軟件設計為兩層結構,一層是穩(wěn)定的,一層是不穩(wěn)定的。穩(wěn)定的一層稱之為UMEP Client,由兩個定時啟動的守護進程uploadMsg和downloadMsg

5、組成,分別實現(xiàn)報文接收和報文發(fā)送的功能。之所以稱之為穩(wěn)定的,是因為這兩個守護進程可以在任何外接系統(tǒng)的前置機上使用,并不需要針對不同的外接系統(tǒng)重寫代碼,體現(xiàn)了行內接口的通用性。不穩(wěn)定的一層稱之為Branch Interface API(簡稱BIA),由一組API函數(shù)組成,以庫文件的方式提供,被UMEPClient調用。之所以稱之為不穩(wěn)定的,是因為它是對外接系統(tǒng)提供的API接口函數(shù)的封裝,需要針對不同的外接系統(tǒng)改寫代碼。BIA被設計為10個API函數(shù),分別處理非實時通訊和實時通訊兩種情況:BIA不僅封裝了外接系統(tǒng)的API函數(shù),還有一個重要的工作就是負責報文格式的轉換。不同的外接系統(tǒng),其報文的描述格

6、式各有不同。為了行內系統(tǒng)能夠以同樣的方式處理,就需要對報文用統(tǒng)一的格式進行重新描述,轉換為行內系統(tǒng)使用的標準報文。同樣,行內發(fā)出的標準報文也需要由經(jīng)BIA轉換后,再發(fā)送給外接系統(tǒng)。這種將報文格式轉換功能由通信平臺實現(xiàn)改為由前置機實現(xiàn)的設計方式,不僅是實現(xiàn)UMEP通用性的需要,也是為了充分利用前置機的運算功能,減輕通訊平臺的運算壓力,使其集中資源處理報文轉發(fā)的功能,提高平臺的處理能力。前置機接口層的系統(tǒng)結構如圖:在前置機端引入BIA的設計模式的另一個優(yōu)點是,可以最大限度地降低總行科技部門的開發(fā)工作量。一個新系統(tǒng)的接入,總行不再需要集中開發(fā)行內接口軟件(全國性系統(tǒng)仍可由總行統(tǒng)一開發(fā)),只要由分行按

7、照UMEP的報文標準和API標準,自行組織開發(fā)一套相應的BIA,以庫文件的方式提供給UMEP使用,然后就可以通過UMEP順利接入核心系統(tǒng)。另外由于BIA層的開發(fā)工作并不涉及到Tuxedo技術,因此對于分行而言,也降低了技術開發(fā)的難度。同時,這樣的分層設計也為分行特色業(yè)務的開展提供了技術上的便利條件。UMEP Client在部署之前,附帶的BIA是一個完全由空API函數(shù)編譯后獲得的庫文件。部署到前置機以后,只要將這個文件替換為相應外接系統(tǒng)的BIA庫文件,即可完成系統(tǒng)對接功能。由此可見,UMEP Client在前置機上的安裝部署也是相對簡單靈活的。此外,由于Tuxedo的跨平臺性,可以使得我們的U

8、MEP Client不僅可以部署在HPUX/AIX/SCO Unix/Linux等Unix或類Unix平臺上,而且可以運行在AS400或Windows平臺上。換句話說,無論外接系統(tǒng)前置機采用的是什么樣的操作系統(tǒng)平臺,我們的UMEP Client都可以正常部署使用。這也從一個側面體現(xiàn)了UMEP的通用性。四、通訊平臺層的設計UMEP通訊平臺層的設計,使用了Tuxedo服務程序和Tuxedo客戶端程序相結合的方式。兩個Tuxedo服務程序名為uploadMsgSvc和downloadMsgSvc,分別被前置機端UMEP Client的up-loadMsg和downloadMsg進程調用,用于平臺的報

9、文接收和發(fā)送。兩個Tuxedo客戶端程序名為uploadKernel和download-Kernel,是兩個定時啟動的守護進程,分別負責上傳平臺報文至核心系統(tǒng)和下載核心系統(tǒng)報文至平臺。其系統(tǒng)結構圖如下:本篇論文由網(wǎng)友投稿，3COME文檔只給大家提供一個交流平臺，請大家參考，如有版權問題請聯(lián)系我們盡快處理。在UMEP的平臺設計中,我們引入了數(shù)據(jù)庫的內容。這主要是考慮到UMEP平臺將被設計為一個擁有較高處理能力的報文交換平臺。如果單純的依靠核心服務完成業(yè)務處理后,再寫入核心應用數(shù)據(jù)庫,勢必會增加調用端的等待時間,影響平臺的處理效率和吞吐量。此外,使用數(shù)據(jù)庫對報文進行暫存,可以減少報文傳送過程中因網(wǎng)

10、絡通訊問題而導致的報文丟失現(xiàn)象,保證報文的正確傳輸。在報文的上行過程中,平臺服務uploadMsgSvc收到前置機發(fā)來的標準報文后,不作任何處理,直接寫入數(shù)據(jù)庫并返回,完成平臺的報文接收工作。平臺上的uploadKernel進程啟動后,負責從數(shù)據(jù)庫中讀取報文信息,并根據(jù)共享內存中存放的XML標準報文格式描述文件,將報文中的業(yè)務要素解析出來,轉換為Tuxe-do服務調用所需的FML Buffer格式,再通過Tuxedo服務調用,上傳給核心系統(tǒng)完成業(yè)務處理。在報文的下行過程中,通過平臺上定時啟動的downloadKernel進程,調用核心系統(tǒng)的相關服務,獲取下傳報文信息,再根據(jù)XML報文格式描述文

11、件,轉換為標準報文后寫入數(shù)據(jù)庫。平臺服務downloadMsgSvc由前置機端的down-loadMsg進程定時調用。每次調用時,該服務從數(shù)據(jù)庫中讀取待發(fā)送的報文,返回給前置機。行內標準報文的格式解析和打包是通過XML報文格式描述文件來完成的。不同外接系統(tǒng)所使用的報文集,都會用行內的標準格式重新加以定義,體現(xiàn)為一個XML描述文件。這個XML文件作為BIA的一部分,由BIA的開發(fā)者按照標準編寫完成后,提供給UMEP平臺使用。平臺啟動時,將裝載所有外接系統(tǒng)的XML描述文件到共享內存中,供uploadKernel和downloadKernel處理標準報文解析和打包時使用。鑒于XML強大的擴展性和良好

12、的易用性,這樣的設計必然使我們的平臺具備優(yōu)秀的報文兼容性,同樣也保證了UMEP的通用性。五、核心服務層的設計UMEP的核心服務層采用了面向服務的設計模式,每一種業(yè)務類型的處理都被細化為一個或多個核心服務來完成。每個核心服務只完成某一種特定的功能,服務與服務之間的耦合關系遵循“松散”的原則。這種“松散”的耦合關系,大大的增加了核心服務的可重用性,為業(yè)務的變更和擴展帶來巨大的靈活性和便利性。在核心服務的外圍,部署了一類管理調度服務,稱為TxDispatcher。TxDis-patcher不僅能夠管理報文交換類交易的服務請求,而且可以管理聯(lián)機實時交易的服務請求,并根據(jù)不同類型的交易,按照事先定義好的

13、業(yè)務處理流程,調度相應的核心服務處理。核心服務層的結構示意圖如下:在服務的調用者和核心服務之間引入TxDispatcher管理服務層,使得核心業(yè)務系統(tǒng)對業(yè)務需求的變更或調整,具備快速投產(chǎn)的能力。因為在核心服務具有較高可重用性的基礎之上,僅僅通過定制合理的業(yè)務處理流程,組合不同的核心服務,就有可能完成新業(yè)務功能的開發(fā)工作。六、安全模塊的設計UMEP中安全模塊的設計,仍然采用原有的PKI證書模式。因為基于PKI證書的安全技術是目前安全級別較高,并且是國家有關安全部門認可的一種加密認證技術。這種技術在業(yè)界被廣泛使用,也是農發(fā)行綜合業(yè)務系統(tǒng)目前正在使用的安全技術措施之一。在使用PKI證書的安全模式下,

14、UMEP服務器和外接系統(tǒng)前置機均需要獲得由總行CA中心簽發(fā)的IC卡,作為自己合法身份的唯一標識。報文上行時,前置機使用自己的IC卡私鑰對報文進行加密簽名,然后上傳UMEP服務器。UMEP服務器使用該前置機證書中的公鑰解密并核驗簽名,確認報文的合法性。報文下行時,UMEP服務器使用自己的IC卡私鑰,對下傳報文加密簽名后發(fā)送前置機。前置機收到報文后,使用UMEP服務器的證書公鑰進行解密并核驗簽名,核驗通過后再發(fā)送給外接系統(tǒng)。UMEP的安全體系結構如下圖所示:需要強調的是,在UMEP的設計過程中,通用性是整個平臺的核心原則。只有具備了通用性能力的業(yè)務平臺,才能最大程度的避免因業(yè)務變化帶來的系統(tǒng)運行風險。鑒于UMEP本身建構在基于服務的基礎軟件平臺之上,并且核心服務采用了分布式結構的設計,因此在物理部署上UMEP能夠支持