1． 引言
2005年中國人民銀行、國家稅務總局和財政部啟動了以國庫為中心的稅（稅務）、庫（國庫）、銀（銀行）橫向聯(lián)網(wǎng)建設工程。其中橫向聯(lián)網(wǎng)系統(tǒng)的實時交易處理流程主要有兩種：
第一種為從稅務發(fā)起的實時扣稅：
(1)?納稅人到稅務大廳，或者通過稅務網(wǎng)上自助納稅系統(tǒng)，發(fā)起納稅，納稅人等候處理結(jié)果；
(2)?稅務征管系統(tǒng)接收到納稅請求后，將扣稅報文發(fā)送到人民銀行國庫信息處理系統(tǒng)（Treasury Information Processing? System ， 以下簡稱TIPS）；
(3)?TIPS進行信息校驗，并存儲扣稅信息，然后將扣稅信息轉(zhuǎn)發(fā)到納稅人的開戶銀行；
(4)?開戶銀行按照扣稅指令，進行校驗后，對指定賬戶進行扣款，將扣款回執(zhí)傳回TIPS；
(5)?TIPS進行信息匹配，并更改扣稅狀態(tài)，將扣稅回執(zhí)轉(zhuǎn)發(fā)給稅務征管系統(tǒng)；
(6)?稅務征管系統(tǒng)匹配扣稅回執(zhí)，將扣稅結(jié)果，反饋給納稅大廳，或者網(wǎng)上納稅系統(tǒng)；
(7)?納稅人獲知納稅結(jié)果。
第二種為從銀行發(fā)起的繳稅：
(1)?納稅人到銀行大廳，或者通過網(wǎng)上銀行，發(fā)起繳稅請求，納稅人等候處理結(jié)果；
(2)?銀行后臺系統(tǒng)接收到繳稅請求后，將繳稅請求報文發(fā)送到TIPS；
(3)?TIPS存儲繳稅請求信息后，將繳稅請求信息轉(zhuǎn)發(fā)到稅務征管系統(tǒng)；
(4)?稅務征管系統(tǒng)檢索納稅信息，將扣稅報文發(fā)送至TIPS；
(5)?TIPS存儲扣稅報文，并返回銀行系統(tǒng)；
(6)?銀行系統(tǒng)收到扣稅報文后，匹配繳款請求，并反饋給銀行對公大廳，或者網(wǎng)上銀行；
(7)?納稅人確認納稅項目和金額；
(8)?銀行后臺系統(tǒng)收到扣稅確認后，從指定賬戶扣款，將扣款回執(zhí)傳回TIPS；
(9)?TIPS進行信息匹配，并更改扣稅狀態(tài)，將扣稅回執(zhí)轉(zhuǎn)發(fā)給稅務征管系統(tǒng)；
(10)?稅務征管系統(tǒng)按照扣稅回執(zhí)，更改納稅信息狀態(tài)。
2．?系統(tǒng)分析
在上述兩種業(yè)務流程中，納稅人無論在稅務端發(fā)起，還是在銀行端發(fā)起，都要等待處理結(jié)果，系統(tǒng)平均響應時間應不超過5秒，最大響應時間不超過20秒。如果響應時間超過20秒，業(yè)務發(fā)起端就要自動發(fā)起沖正指令，取消此筆交易。
其中聯(lián)網(wǎng)稅務節(jié)點包括32個省級國稅、32個省級地稅、600余個地市級國地稅，總數(shù)將達到700個左右。聯(lián)網(wǎng)銀行節(jié)點包括14個全國性商業(yè)銀行，100余個城市商業(yè)銀行，100余個城市和農(nóng)村信用社，總數(shù)將達到300余個左右。在納稅高峰期，TIPS需要每秒鐘轉(zhuǎn)接處理報文1000筆。這就要求橫向聯(lián)網(wǎng)系統(tǒng)必須具有高性能、高可用和高擴展性，是對系統(tǒng)實時處理的挑戰(zhàn)。
在整個聯(lián)網(wǎng)交易中，存在四種角色，即交易發(fā)起者（人機交互界面）、數(shù)據(jù)交換服務發(fā)起者、數(shù)據(jù)交換服務中轉(zhuǎn)者和數(shù)據(jù)交換服務響應者。如圖1所示。
?
??????????????????????????????????????
????????????????????????????????????? ?圖1發(fā)起/請求/中轉(zhuǎn)/響應模式示意圖
交易發(fā)起者，具體是指征管系統(tǒng)前臺操作員操作征管軟件發(fā)起納稅；或者納稅人操作網(wǎng)上自助納稅系統(tǒng)納稅；或者銀行柜臺操作員操作銀行系統(tǒng)前臺發(fā)起納稅；或者納稅人操作網(wǎng)上銀行自助納稅。
數(shù)據(jù)交換服務發(fā)起者，包括構(gòu)造請求報文，并將請求報文發(fā)送至數(shù)據(jù)交換服務中轉(zhuǎn)者；接收響應/回執(zhí)報文，以及對響應/回執(zhí)報文的解析和其他后續(xù)處理。
數(shù)據(jù)交換服務中轉(zhuǎn)者，負責請求報文和響應/回執(zhí)數(shù)據(jù)包的轉(zhuǎn)發(fā)，及數(shù)據(jù)處理。
數(shù)據(jù)交換服務響應者，負責接收、解析、處理請求報文，根據(jù)處理結(jié)果構(gòu)造響應/回執(zhí)報文，并將響應/回執(zhí)報文轉(zhuǎn)發(fā)給數(shù)據(jù)交換服務中轉(zhuǎn)者。
按照客戶端/服務器模型，可以將上述4個角色，劃分成3對客戶端/服務器關(guān)系。交易發(fā)起者和數(shù)據(jù)交換服務發(fā)起者之間，交易發(fā)起者（人機交互界面）為客戶端，數(shù)據(jù)交換服務發(fā)起者為服務器端。數(shù)據(jù)交換服務發(fā)起者和數(shù)據(jù)交換服務中轉(zhuǎn)者之間，數(shù)據(jù)交換服務發(fā)起者為客戶端，數(shù)據(jù)交換服務中轉(zhuǎn)者為服務器端。數(shù)據(jù)交換服務中轉(zhuǎn)者和數(shù)據(jù)交換服務響應者之間，數(shù)據(jù)交換服務中轉(zhuǎn)者為客戶端，數(shù)據(jù)交換服務響應者為服務器端。客戶端和服務器端處理模式分同步和異步兩種模式[1]。同步模式表示客戶端向服務器端發(fā)起請求后，等待服務器處理完請求并返回結(jié)果。異步模式表示客戶端向服務器端發(fā)起請求后，不等待服務器返回結(jié)果。
由于存在從稅務發(fā)起和銀行發(fā)起兩種實時交易流程。因此稅務系統(tǒng)既有可能為數(shù)據(jù)交換發(fā)起者，又有可能為數(shù)據(jù)交換服務響應者；銀行系統(tǒng)既有可能為數(shù)據(jù)交換服務響應者，又有可能為數(shù)據(jù)交換服務發(fā)起者。這樣便意味著稅務系統(tǒng)、TIPS和銀行系統(tǒng)均有可能成為服務器端。
3． 聯(lián)網(wǎng)體系架構(gòu)設計
?????????????????????????????????????????????? 圖2 聯(lián)網(wǎng)體系架構(gòu)示意圖
如圖2所示，TIPS、稅務、銀行通過消息中間件建立起數(shù)據(jù)交換通道。TIPS中心由數(shù)據(jù)庫、基于J2EE架構(gòu)的交易服務和數(shù)據(jù)交換平臺三部分組成。外部通訊網(wǎng)關(guān)、企業(yè)服務總線和內(nèi)部通訊網(wǎng)關(guān)通過基于消息中間件的集群技術(shù)[2]整合成一個相互獨立、可平行擴展的統(tǒng)一整體。外部通訊網(wǎng)關(guān)通過消息中間件和稅務、銀行連接；企業(yè)服務總線（ESB）[3]負責對報文預處理，并進行消息路由的操作，ESB通過內(nèi)外通訊網(wǎng)關(guān)分別與交易服務和稅務、銀行系統(tǒng)進行消息交互。交易服務通過JMS/MDB[4]方式實現(xiàn)對消息中間件的操作。
以稅務發(fā)起實時扣稅交易為例，消息的流轉(zhuǎn)過程為：
（1） 稅務征管系統(tǒng)提交請求報文，發(fā)送到外部通訊網(wǎng)關(guān)；
（2）?通訊網(wǎng)關(guān)通過消息中間件的集群機制將請求報文轉(zhuǎn)發(fā)到ESB；
（3）?ESB系統(tǒng)收到請求報文，進行預處理，然后通過內(nèi)部通訊網(wǎng)關(guān)轉(zhuǎn)發(fā)到交易服務；
（4）?交易服務通過JMS/MDB與內(nèi)部通訊網(wǎng)關(guān)進行交互，進行業(yè)務處理后，將請求報文通過內(nèi)部通訊網(wǎng)關(guān)轉(zhuǎn)發(fā)給ESB，并通知ESB將請求報文轉(zhuǎn)給商業(yè)銀行；
（5）?轉(zhuǎn)發(fā)的請求報文經(jīng)過外部通訊網(wǎng)關(guān)到達商業(yè)銀行；
（6）?商業(yè)銀行進行相應的業(yè)務處理后，發(fā)送回執(zhí)信息；
（7）?回執(zhí)信息經(jīng)過外部通訊網(wǎng)關(guān)，到達ESB；
（8）?ESB系統(tǒng)進行回執(zhí)報文的預處理，然后通過內(nèi)部通訊網(wǎng)關(guān)轉(zhuǎn)發(fā)給交易服務；
（9）?交易服務進行業(yè)務處理后，將回執(zhí)報文通過內(nèi)部通訊網(wǎng)關(guān)轉(zhuǎn)發(fā)給ESB，并通知ESB將回執(zhí)報文發(fā)送給稅務；
（10）?回執(zhí)報文經(jīng)過外部通訊網(wǎng)關(guān)，到達稅務，扣稅交易結(jié)束。
4．?基于消息中間件的通訊實現(xiàn)
IBM MQSeries（以下簡稱MQ）提供一個具有工業(yè)標準、安全、可靠的消息傳輸系統(tǒng)。MQ的關(guān)鍵功能之一是確保信息可靠傳輸，同時，MQ是靈活的應用程序通信方案[5]。
TIPS與稅務、商業(yè)銀行通過配置MQ Server的通道實現(xiàn)通訊。在創(chuàng)建通道時，需要設置隊列管理器名稱、服務器連接通道名稱、主機名或IP地址、偵聽端口、發(fā)送通道名稱、接收通道名稱、發(fā)送隊列名稱、接收隊列名稱、字符集等配置項。
稅務、TIPS和商業(yè)銀行都配置發(fā)送和接收2個通道。為了滿足實時交易流程要求，將MQ通道屬性設置成非持久（即內(nèi)存方式Non-Persistent），同時設置消息的過期時間，如10秒，這樣消息有一定的生命周期。同時再輔助以沖正流程設計，保證交易的完整性。
數(shù)據(jù)交換服務發(fā)起者和數(shù)據(jù)交換服務中轉(zhuǎn)者，都存在報文匹配的要求。存在兩種報文匹配機制。第一種為基于報文內(nèi)容的匹配（異步模式），即從接收通道接收報文后，根據(jù)業(yè)務關(guān)鍵字組合，從存儲數(shù)據(jù)庫查找原發(fā)起報文，實現(xiàn)與原發(fā)起報文的匹配；第二種為利用消息中間件提供的同步模式下的消息過濾和匹配機制?；趫笪膬?nèi)容的匹配（異步模式），適合數(shù)據(jù)交換服務中轉(zhuǎn)者采用；利用消息中間件提供的同步模式下的消息過濾和匹配機制，適合數(shù)據(jù)交換服務發(fā)起者采用。
利用消息中間件提供的消息過濾和匹配機制如圖3所示。
????????????????????????????????????????????圖3 消息過濾和匹配機制圖
其中同步模式匹配機制為：
(1) 人機交互界面向交易請求服務發(fā)起交易申請，阻塞等待；
(2)?交易請求服務得到交易申請后，首先將交易申請轉(zhuǎn)換成MQ消息報文，并將MQ的CorrelId屬性值設為約定值，如“REQ”。然后會將MQ消息報文發(fā)送至MQ隊列。在報文發(fā)送成功后，程序會保存MQ返回的MsgId；
(3)?交易請求服務按照CorrelId屬性值為MsgId從接收隊列中捕獲回執(zhí)報文，并將處理結(jié)果返回人機交互界面。
異步模式匹配機制：
(1)?交易響應服務從接收隊列接收到報文，進行業(yè)務處理，如果需要匹配其他業(yè)務，直接根據(jù)業(yè)務關(guān)鍵字，基于數(shù)據(jù)庫進行檢索匹配；
(2)?將回執(zhí)報文中的CorrelId設為對應請求報文中MsgId的值，將回執(zhí)報文發(fā)送到發(fā)送隊列。
5.結(jié)論
2006年2月15日系統(tǒng)成功地在北京、湖南、貴州三省市上線運行，參加試運行的單位包括北京地稅、湖南國稅等12家稅務局，工、農(nóng)、中、建等14家全國性商業(yè)銀行和北京銀行、貴州省農(nóng)聯(lián)社等8家地方性金融機構(gòu)，以及13個國庫部門。
經(jīng)過幾個月的運行表明，在聯(lián)網(wǎng)實時交易中，采用消息中間件，實時性可以滿足設計要求。當因為網(wǎng)絡、交易處理異常等各種原因引起超時的時候，數(shù)據(jù)交換服務發(fā)起者發(fā)起沖正交易，同時每隔一定時間，以數(shù)據(jù)交換中轉(zhuǎn)者為基準進行對賬，可以保證交易完整性。
?
6.參考文獻
[1] S Goel; H Sharda; D Taniar, Messaging in distributed systems , International Journal of Computer Systems Science & Engineering , 2003(6), 339-355
[2] 邱巖; 王衛(wèi)兵，消息中間件的集群技術(shù)，計算機工程，2003(2)，107-108,200．
[3] Christy Bass,??J.Michael Lee. Building a Business Case for EAI. EAI Journal．2002(1),18-20．
[4] Richard MonsonHaefelEnterprise Java beans O′Reilly & associates 2001.
[5] 王小霞，消息中間件在數(shù)據(jù)交換中的應用研究及其面臨的挑戰(zhàn)，電子技術(shù)應用，2005(1)，1-4.
?