竞赛数据交换平台的研究与实现

许 静，牟 艳，秦江龙

(河海大学常州校区计算机与信息学院，常州 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.