競賽數據交換平臺的研究與實現

許 靜，牟 艷，秦江龍

(河海大學常州校區計算機與信息學院，常州 213022)

1 引言

綜合型運動會競賽信息系統結構復雜，各子系統之間數據交流頻繁、數據交換需求量大且質量要求高，如何及時將處于不同環境、不同系統平臺、格式各異的數據轉化為可透明訪問的共享信息，并將這些信息進行發布、交換、傳輸和共享，使“信息孤島”能夠互聯互通，是競賽信息系統開發中的重點和難點。

早期綜合型運動會普遍采用傳統交換方式(也稱專用方式)，針對每一個具體的系統，開發對方專用的交換接口，各系統采用網狀式的組網結構。隨著綜合性運動會應用的增多，系統越來越復雜，這種交換方式的缺點越來越較明顯，主要表現在:接口太多，如果有N個系統，需要開發N*(N－1)個接口，工作量極大，耦合性太強，對數據交換的實現與維護困難［1］。

實現綜合型運動會競賽信息系統高效信息交換的一個行之有效的解決方案是建設競賽信息數據交換平臺，作為各子系統間信息交換的樞紐，提供信息交換服務。本文通過筆者參與設計開發的“第二十六屆世界大學生運動會賽事成績處理系統數據交換平臺(Data Exchange Manage，DXM，以下簡稱“DXM平臺”)”項目［2］，提出可管理、可配置的應用解決方案，剖析平臺系統的架構、設計和實現。

2 系統概述

2.1 競賽信息系統與DXM平臺

綜合型運動會競賽信息系統以競賽信息服務為主要線索，其主要運作流程需要經歷場館成績處理、綜合成績處理與競賽信息發布過程。其中場館成績處理作為競賽成績輸入系統，綜合成績系統作為競賽成績加工系統，信息發布作為競賽成績輸出系統，這些都分在競賽信息系統中分別對應于場館成績系統(Venue Result System，VRS)、中央成績系統(Central Result System，CRS)與信息發布系統(Information Distribution System，IDS)［3］。系統結構負雜，系統間存在大量頻繁的數據交換。

作為各子系統之間信息交換的紐帶，DXM平臺通過競賽系統網絡，實現各子系統間的實時消息通信。VRS、CRS、IDS均作為消息通信終端(以下簡稱業務終端)，通過DXM平臺交換數據。DXM平臺接收到業務終端的消息后，根據預定義的消息分發策略，將消息分發到指定的業務終端。例如CRS向DXM平臺發送原始競賽信息，再由DXM平臺分發給VRS、IDS。VRS向 DXM平臺發送場館成績數據，由DXM平臺轉發給CRS進行綜合處理，轉發給IDS對外發布，系統間數據流如圖1所示。

圖1 競賽信息系統與DXM平臺關系圖

2.2 DXM平臺系統結構

DXM平臺系統由分管理配置子系統、發中心子系統、業務終端接口系統、運行監控子系統和DXM平臺數據庫組成，系統結構如圖2所示。

圖2 DXM平臺系統結構圖

DXM平臺數據庫用于存儲管理與系統通信交換相關的數據信息;管理配置子系統用于配置管理消息類別、業務終端類別、業務終端、分發路由、分發中心的相關信息以及分發中心子系統。

提供面向業務終端的主動連接和消息的自動重分發服務;業務終端接口系統提供消息發送、在線狀態變化和接收消息的接口服務，為各業務終端開發商提供透明的消息發送與接收服務;運行監控子系統負責監控各分發中心服務器的運行狀態及各業務終端的連接狀態，DXM平臺系統管理員可以通過運行監控子系統實時地監測、管理和控制各分發中心。

3 DXM平臺工作流程

在系統運行之前，由管理配置子系統完成對DXM平臺運行參數的初始化設置，主要是完成消息分發策略的配置，將配置保存于DXM平臺數據庫中，數據庫中還保存了各業務終端和分發中心的相關信息。當DXM平臺啟動后，分發中心讀取平臺數據庫中業務終端和分發路由表，通過各個業務終端的接口系統與各終端建立連接，此處的接口系統是利用在業務終端集成中間件的方式完成接入功能的。中間件對分發中心的建立請求作出響應，同時標識連接成功或者失敗，將事件記錄到消息日志中，存于平臺數據庫，若連接成功，則加載消息，啟動發送或接收流程，并判斷是否遍歷所有終端;若連接失敗，繼續連接業務終端，完成分發中心的啟動服務，分發中心繼續判斷業務終端在線，接收消息，收到數據包并且驗證后即解析消息類別，查找消息路由表確定消息接收終端列表，遍歷所有業務終端。若在線，即發送消息，否則緩存消息，遍歷完成后結束任務。同時將消息分發的時間記錄到日志文件中，保存在平臺數據庫中，而業務終端的消息收發事件保存在本地日志文件中。在DXM平臺運行過程中，運行監控子系統與分發中心連接，負責監控各分發中心服務器的運行狀態及各業務終端的連接狀態，控制分發中心與業務終端的連接，還可以讀取數據庫中的日志文件，查詢消息收發事件。

4 系統關鍵技術

為了保證系統的靈活性，采用靈活的參數配置，使DXM平臺適應于不同業務、不同需要、不同場合。由DXM平臺的技術支持人員使用平臺提供的路由配置功能完成，無須人工干預，無須進行任何額外開發工作，當分發策略改變時，只需要重新調整設置分發路由表，即可接入平臺進行數據交換，并且通過設置消息緩存隊列，實現消息的自動重發功能，保證了傳輸的可靠性。

4.1 管理配置機制

管理配置子系統完成對DXM平臺運行參數的配置，關鍵是對比賽項目、消息類別、業務終端和分發策略的配置。

4.1.1 比賽的配置

通過對競賽項目信息的增加、刪除、修改等操作，負責體育競賽系統中比賽項目的維護。

4.1.2 消息類別的配置

消息類別是DXM平臺對消息進行分發策略的分類標準之一，它的合理設計，關系到DXM平臺和業務終端之間通信的效率問題。通過對消息類別進行增加、刪除、修改等操作，實時配置消息類別。

消息類別由類別編號和類別名稱區分，比如編號“M0011”代表“運動員及報項信息”，“M1011”代表賽事計劃。

4.1.3 業務終端的配置

通常將通信子系統進行分類，以方便進行分發策略的配置。通過對終端類別的增加、刪除、修改等操作，實時配置終端類別。業務終端類別也由類別編號和類別名稱區分，如分類CRS(中央成績)、VRS(場館成績)、INFO(信息發布)等類別。

4.1.4 分發策略的配置

管理配置最關鍵的就是實現消息分發路由的動態配置以滿足分發策略，使得系統有序的傳輸消息。DXM平臺根據消息類別與終端類別在不同的比賽項目中按照路由規則在各子系統中轉發消息。即比賽項目、消息類別、終端類別代碼共同決定消息分發的路由。當分發中心接收到業務終端發出的一條消息后，根據設定的消息類別、終端類別和比賽項目，計算出接收該條消息的合法業務終端隊列，即分發路由，其含義為哪些比賽項目的哪些消息會發送給哪些終端，然后將該消息發送到隊列中的各業務終端。

4.2 異步通信機制

DXM平臺為各子系統提供信息交換服務，要求其在數據通信中具有較高的可靠性，系統提供相應的保障機制，保障各子系統在數據交換中離線、網絡故障等情況下仍能保障數據信息不丟失，網絡通信恢復后仍能有效地傳輸數據。

基于這種可靠性要求，DXM平臺提供了異步通信服務。各業務終端離線時待發送的消息在本地緩存，待接收的消息在分發中心緩存，業務終端在線時DXM平臺自動完成消息的收發。業務終端與分發中心服務器均設置了本地緩存隊列，當網絡故障時，消息緩存在本地緩存隊列，待網絡恢復后，系統會自動載入緩存消息，向對方主機發送。消息緩存隊列的工作分三個方面:

作為發送消息的業務終端，其消息緩存隊列接收用戶要發送的消息，放入發送隊列，由發送線程掃描隊列，隊列中有消息并且該發送終端與分發中心相連，則啟動發送該消息，發送成功則把消息從隊列中移除。

分發中心子系統，為與之相連的每個業務終端建立單獨的發送隊列，分發中心收到業務終端發送來的數據，檢查分發路由，將數據根據路由放入對應的接收終端隊列，再由各個終端的發送線程掃描各自的消息緩存隊列，發現有數據并且與對應的接收終端連接則發送數據，發送成功后從隊列中移除該數據。

作為接收消息的業務終端，只需要等待接收，作出響應。

緩存隊列的工作流程如圖3所示。

圖3 消息緩存隊列工作流程

如圖3所示，DXM平臺系統啟動服務后，不管是分發中心還是業務終端，作為發送方，都是將要發送的消息緩存在相應的緩存隊列中，由發送線程掃描隊列，請求連接合法后發送消息，如果連接失敗則繼續請求連接，同時遍歷緩存。若消息發送成功，則從緩存中清除該數據，當遍歷完成，即緩存中已無數據時，則結束線程，若消息發送失敗，則斷開連接，將發送失敗的消息存入緩存隊列，循環請求發送，直至緩存隊列清空。遍歷緩存延時30ms，這個時間既不影響系統的正常運行，還能保證緩存的消息及時處理掉。

5 DXM平臺設計與實現

5.1 分發中心子系統

分發中心子系統是整個DXM平臺的核心，它包括了以下功能:提供面向業務終端的主動連接和消息的自動化分發服務、根據業務終端信息自動加載業務終端、根據路由配置自動完成消息分發、消息接收方終端離線時提供本地緩存、在線時依次發送緩存消息。

分發中心啟動服務后，讀取DXM平臺數據庫，加載業務終端和消息路由，主動與業務終端集成的代理中間件連接，連接并且驗證成功后標識業務終端在線，若失敗，返回超時，標識業務終端離線，并重連。若業務終端在線，則加載消息，啟動發送消息流程，或者啟動接收消息流程，最后判斷是否遍歷所有業務終端，若沒有，繼續連接業務終端，完成啟動服務。啟動服務流程如圖4所示。

圖4 分發中心啟動服務流程圖

分發中心系統判斷業務終端在線，接收消息，收到數據包并且驗證后即解析消息類別，查找消息路由表確定消息接收終端列表，遍歷所有業務終端，若在線，即發送消息，否則緩存消息，遍歷完成后結束任務。分發中心接收消息及分發處理流程如圖5所示。

5.2 業務終端中間件

DXM平臺通過集成組件(即中間件)方式，封裝數據通信協議，這樣做提高了系統的可集成性，對外屏蔽了通信協議，提高了協議的安全性，同時還減少了各業務終端開發商的工作量。數據通信協議包含的事件有啟動、停止、服務狀態、發送、接收和服務狀態切換。各相關子系統通過中間件實現與DXM平臺的數據交換，協議給出數據包格式和命令格式及網絡中通信節點的信息，實現競賽信息的統一分發。協議結構如表1所示。

圖5 接收消息及分發處理流程圖

表1 數據通信協議結構

由表1所示，由標識碼判定是否是本系統需要處理的消息;命令碼確定對此條消息做何種操作，比如命令碼“101”表明是建立連接，若是“102”表明斷開連接;消息碼決定消息任務的類型，比如這條消息需要從VRS傳輸至CRS;唯一標識符記錄消息的事件，具有唯一性，可保存在日志中，以便查看;消息體長度決定數據參數的字符數組大小，比如消息體長度為1024B，數據參數的字符數組大小就是1KB，可見數據參數的大小是可變的。

消息發送模塊根據數據通信協議將消息打包成消息數據包，完成數據包的消息重組工作。消息包含消息頭和N個消息子包，消息頭定義內容有消息開始標志、消息類型、壓縮標志、總包數、消息體長度(壓縮后)、數據消息類型、消息源類型、消息源關鍵字、大項代碼、消息標識號。消息子包定義內容有子包開始標志、消息標識號、子包序號、子包大小、子包內容。

業務終端中間件接收到分發中心的服務請求以后，啟動服務，連接成功后，發送/接收消息，通信完成后向宿主模塊拋出消息事件，服務始終記錄運行狀態和在線狀態變化報告，這些事件都保存在本地日志中，最后停止服務。

5.3 管理配置子系統

管理配置子系統由管理員完成對DXM平臺運行參數的配置，該子系統提供的功能有消息類別管理、業務終端類別管理、業務終端管理、消息分發路由管理和分發中心管理。

首先對比賽項目、消息類別、業務終端類別進行配置，組合三者計算出合理的消息分發路由，即哪些比賽項目的哪些消息會發送給哪些業務終端，還需要對分發負載(分發中心子系統正常運行時，連接的那些業務終端)進行相關通信參數的配置，以使分發中心與管理配置子系統協同運行。該子系統還設置了分發服務控制模塊，提供了對DXM平臺進行狀態監控和消息分發的功能以及日志分析模塊，它對DXM平臺的各項指標進行分析監控。

5.4 運行監控子系統

運行監控子系統負責監控各分發中心服務器的運行狀態及各業務終端的連接狀態。DXM平臺系統管理員可以通過該子系統實時地監測、管理和控制各分發中心。該子系統的客戶端與各分發中心通過中間件建立連接。

該子系統啟動后，讀取DXM平臺數據庫，查看DXM平臺有哪些分發中心及其詳細通信參數，以及分發負載的通信參數和狀態等，實時監測各分發中心運行狀態和各業務終端連接狀態，控制分發中心與業務終端的連接，同時記錄監控事件，保存于DXM平臺數據庫。

5.5 DXM平臺數據庫設計

DXM平臺數據庫用于存儲與管理系統通信交換相關的數據信息，系統采用集中式客戶機/服務器數據庫體系結構。數所庫采用SQL Server 2005企業版數據庫系統，DXM平臺數據庫服務器使用Microsoft Windows 2003 Server(64)位操作系統。DXM平臺數據庫中存儲的數據表的內容和作用如表2所示。

管理配置子系統的參數配置和各業務終端與分發中心的運行狀態和連接狀態變化事件都存儲在DXM平臺數據庫，而當各子系統啟動服務時，都需要從DXM平臺數據庫讀入相關數據。

5.6 系統物理架構

VRS、CRS、IDS都通過集成中間件與分發中心通信，管理配置子系統管理消息類別、業務終端類別、業務終端、消息路由、分發中心的相關信息。運行監控子系統實時監測、管理和控制各分發中心。

表2 數據表簡介

業務終端應用軟件部署在場館端的服務器上，業務終端服務器每場館1臺。分發中心部署在中央成績系統的服務器上，分發中心服務器的數量需要根據實際運行負載、競賽計劃和各個項目的消息通信數據量進行合理、動態的設置。DXM平臺系統物理架構如圖6所示。

圖6 DXM平臺系統物理架構圖

6 DXM平臺系統運行測試及性能分析

6.1 壓力測試

2011年4月1日，在深圳龍崗26屆大運會集成測試實驗室舉行了壓力測試，共有大運會17個大項，203個小項參加，事前準備了這些小項的全部場館成績系統(VRS)數據。主要測試了DXM平臺與中央成績系統(CRS)和信息發布系統(IDS)之間的端到端數據聯通與交換情況，測試歷時1小時40分鐘，共交換XML消息24萬余條，無遺漏與錯發現象。

6.2 系統聯合演練

2011年7月，舉行了包括注冊報名系統(ACR)、場館成績系統(VRS)、中央成績系統(CRS)與信息發布系統(IDS)的全系統聯合演練，演練共進行3天，每天10小時，全部24個大項參加，每個大項均選擇了賽事最多的3個比賽日，每天通過DXM平臺交換XML消息4萬－7萬條，無遺漏與錯發現象。

6.3 正式比賽運行

2011年8月12日至23日，第26屆世界大學生夏季運動會在深圳舉行，賽事共設24個大項、306個小項，注冊國家和地區147個，注冊總人數11310人，其中運動員7587人，隨隊官員3723人。賽會歷時12天，每天通過DXM平臺交換XML消息2萬－4萬條，無遺漏與錯發現象，完成了大運會數據交換任務。

6.4 系統性能分析

根據上述測試結果的分析，通信平臺能夠支持交換的數據量遠大于實際比賽中的數據量，已能夠滿足綜合型運動會競賽數據交換平臺的性能要求，甚至可以應用于今后更大規模的運動會競賽系統中。

7 結束語

數據交換平臺的實現是獨立于各業務系統之外的，所以它并不影響各部門業務系統的運作，同時也能方便加入后續系統。數據交換平臺技術使業務系統具有較強的擴展性，可以支持數據導出系統以及決策支持系統等等的擴展。隨著XML技術的深入發展，必將使數據交換平臺功能更強大，更易于實現。

我們結合具體應用對數據交換平臺及數據交換的關鍵技術進行了分析和應用，目的是探討能夠有效支持數據共享，提高系統互操作性的數據模型設計。根據我們的工作，表明該DXM平臺的設計思路是成功有效的，能夠用于綜合型運動會競賽信息系統的數據模型設計。

隨著體育賽事信息化的深入，競賽信息系統之間的協作、業務往來以及參與合作的數量會越來越多，對通用數據交換平臺的要求會越來越高，因此，需要研究更多的理論和技術，來不斷地完善和發展它。

［1］陳向峰，陳東浩，方峻峰.面向服務的數 據交換平臺的研究與實現［J］.上海信息化，2006(8):69－71.

［2］2010深圳大運會通信平臺系統架構［G］.國家體育總局體育信息中心，2010年9月8日.

［3］2010深圳大運會賽事成績系統技術方案［G］.國家體育總局體育信息中心，2009年12月18日.

［4］趙莉，杜思鋒.數據交換平臺中異構數據轉換技術的研究［J］.電子設計工程，2011，19(5):91 －93.

［5］屠曉蕓.基于 Web Service數據交換的研究與實現［D］.北京:北京化工大學，2007.

［6］倪志剛，洪玫，劉佳.基于服務數據對象的異構系統數據集成方案研究［J］.計算機應用，2007，27(6):21－23.

［7］BAKER F，FOSTER B，SHARP C.Cisco Systems，Cisco.Architecture for Lawful Intercept in IP Networks［S］.［S.l.］:Network Working Group，2004.

［8］David Campbell.Service Oriented Database Architecture;APP Service － Lite［J］.SIGMOD，2005:857－862.