基于XML的校园一卡通银校转账系统架构与实现

王 超，方诗虹

(1.西南民族大学信息与教育技术中心，四川 成都 610041；2.西南民族大学计算机科学与技术学院，四川 成都 610041)

近年来，随着信息技术的迅猛发展，高校在智慧化校园的建设中，通过对校园一卡通系统的实际应用，在构建校内基础数据平台的同时，利用一卡通所具有的身份识别与金融消费两大功能，实现了全校范围内数据标准的统一与资源共享，以及校内消费的刷卡支付与财务结算的智能化管理[1].

校园一卡通系统建设初期，卡内金额的充值完全由人工现场完成，但随着一卡通业务范围的扩展，用户人数的逐渐增多，单纯依靠人工充值的方式，已无法满足校内用户方便、快捷的充值需求.银行作为专业的金融服务机构，拥有大量的现金存取设备、人工业务办理场所，以及完备的资金结算流程[2].校园一卡通充值业务可与银行现有平台进行深度融合，利用其行业优势解决一卡通人工充值所带来的各种问题.

1 校园一卡通银校转账系统总体框架

银校转账系统总体框架如图1所示，该系统主要由银校双方各自拥有的前置服务器、应用管理平台、数据库，以及各类终端设备组成.通过校园一卡通银校转账系统的建设，将现金的存取业务交由银行处理，用户既可使用和一卡通绑定的银行卡在校外进行社会消费，又可利用银校转账系统的专用设备或应用软件向校园一卡通充值，然后通过校园一卡通管理平台实现校内刷卡消费，以及财务自动结算[3].基于校内应用需求与银行金融规范综合考虑，既要在保证实时数据交互的同时，还需保障数据传输过程中，各个应用系统与校内用户的资金安全.因此，银校转账系统设计为单向交易处理架构模式，即仅限于用户资金由银行卡向一卡通内转入(圈存业务)，而无一卡通向银行卡转出渠道(圈取业务)[4].银行卡并不介入校园一卡通校内应用范围内的交易，而校园一卡通也不具备在校外金融消费功能.

1.1 银校转账系统功能架构

将一卡通用户银行卡内的部分金额，通过专有设备划转至校园一卡通系统IC卡电子钱包中的过程称为“圈存”[5].银校转账系统，即通过校园前置服务器网卡A经网络运营商的SDH(Synchronous Digital Hierarchy，同步数字体系)电路传输服务与银行前置服务器网卡B链接，采用Socket通信机制作为系统的数据通道，把银行前置机设置为Socket Server，启动监听服务，校园前置机设置为 Socket Client，主动连接Server.校园前置服务器网卡B与校内网络相连，通过以校园网为主干线路的一卡通网络，采用专网或VLAN(Virtual Local Area Network，虚拟局域网)的划分方式，将一卡通管理平台、一卡通数据库、圈存设备管理系统彼此进行链接，待交易完成后，可根据转账金额对数据库内用户的一卡通余额进行改写.而圈存服务器则通过校园网管理着部署在校内各个场所的圈存设备.为保证数据传输的快捷、可靠，以及用户的资金安全，还可将圈存系统中的专用机具采用MAC+IP在一卡通管理平台注册的方式，使其设备在逻辑上与物理上均与校内其他设备进行有效隔离[6].

图1 系统总体框架Fig.1 System overall framework

每个交易日，由校园前置服务器远程登录银行前置机，在登录成功后，开始进行校银签约.首先由校方生成签约报文，报文经过密钥加密后，将其发送至银行前置服务器，银行方对其解密处理，然后送至综合业务管理平台，平台根据用户需求进行相应处理，处理成功后返回校园前置机交易代码，最后开始处理批量签约结果文件[7].操作完成后，开始日常一卡通银校圈存转账业务工作.一卡通银校转账系统业务流程如图2所示.运行结束后，在银、校双方约定的时间，停止交易，由银行综合业务管理平台生产交易明细文件，银行前置机将其取得后，生成对账报文，放在其预设的目录之下，由校园前置机通过FTP下载，进行每日对账流程.

1.2 银校转账系统业务流程

1)用户放入一卡通卡片，读卡器读取卡片ID后，提示输入一卡通账号、密码;

2)在网络畅通的状态下，由一卡通应用系统判断其用户身份是否有效;

3)根据用户操作请求生成数据报文，加工处理后，经校园前置机发送至银行前置机;

4)报文解密，由银行综合业务系统判定用户身份、用户权限是否有效，查询用户银行卡余额，账户扣款成功后，返回交易成功代码;

5)校园前置机接收到银行报文，根据银行交易代码，由一卡通平台为用户增款，若失败，则提示交易失败，并向银行返回错误代码，根据其生产的交易流水号，产生交易回退事件，银行进行冲正处理;

6)交易完成后，提示用户取卡，业务流程结束.

图2 系统业务流程Fig.2 System business process

1.3 银校转账系统XML数据报文

报文是指通讯双方应遵循的一种数据组织形式，它所包含的各类数据信息通过封装、拆解进行数据格式的转变与信息的交互[8].当前应用较为广泛的数据报文有 8583、MDB、DBF、XML、自定义等几种类型.8583作为银行传统的标准报文格式，最多由128个字段域组成，每个域皆为行业内部约定的标准描述，如交易代码、交易金额、交易时间、以及服务类型等，但因其字段数量限制，带来扩充不便等缺点[9].MDB与DBF作为关系型数据库报文格式，有着需严格遵循的数据格式与长度规范，但因其个体尺寸较大，不适应于需大量实时交换数据的应用场景[10].而自定义报文格式，虽格式灵活多变，扩充自由，但无行业标准可供遵循，通讯双方的报文格式、数据类型缺少约束条件，平台没有定义的全局数据字典，因而无法保证不同交易平台在处理中的一致性.

XML(eXtensible Markup Language，可扩展标记语言)是 W3C(World Wide Web Consortium，World Wide Web Consortium，万维网联盟)发布的一种元标记语言.作为SGML(Standard Generalized Language，标准通用标记语言)的子集，XML可根据用户的自身需求，自己定义赋有内涵的标记，通过这些标记来精确地表述事件中所含信息的各类意义[11].XML运用Unicode标准编码，采用树状结构，利用文本文件的格式对各种信息进行存储.树状结构的每一个节点均为事件中的每一个对象，而对象则可映射为相应的元素(Element)，元素是标记(Tag)与内容的集合.作为半结构化的语言，XML通过元素之间的嵌套关系对信息进行描述，因其树状化、层次化的文本结构，在应用时无需使用数据库系统[12].

总体而言，XML具有的自身特性为异构平台的数据交互提供了可能.首先，XML具有较强的精准性.XML在严格要求标记配对嵌套的基础上，内容描述与显示方式相分离，用户可分别针对内容或显示形式进行修改，两者之间互不影响，从而使得整体结构清晰，便于用户阅读与维护[13].其次，XML具有优秀的可扩展性.XML作为元标记语言，用户可根据自身需求定义标记，以充分表述文件内容.同时还可依据DTD(Document Type Definition，文档类型定义)或XML Schema的验证机制，规范元素与属性格式，避免命名之间的冲突，以保证信息在多种异构平台的延伸.最后，XML具有良好的开放性.XML基于纯文本的标记语言，语法规则简单易用，元素定义短小精干，在支持各类语言，以及多种编译工具的前提下，可在不同的平台系统中使用.因此，XML作为当今社会通用的数据交互模式，它与语义的无关性、结构的无关性、平台的无关性，将会为异构系统之间的数据集成带来极大的便利[14].通过以上描述，XML数据报文具有在异构平台之间准确、实时交互信息的基本特性，一卡通银校转账系统可采用XML文档作为报文格式描述文件.

一卡通银校转账平台根据其学校自身情况，可采用“一对一”或“一对多”业务关系，即一所高校一卡通转账系统，可同时与一家或多家银行进行数据交互，其采用的模式为：以HTTP传输协议为基础，利用规范的XML报文格式对每一条报文进行描述，按平台预先设定的统一标准接入方式接入，即可实现在多个异构系统运行的前提下，平台数据的实时交互[15].此类XML数据报文，可利用文档脚本描述其数据结构与属性内容.即用元素描述数据字段信息，结构嵌套中的子元素描述组数据，用元素的属性描述数据字段的相关内容[16].

银校转帐系统数据报文由基本信息、报文头、报文体三大部分组成：①基本信息(Message_Inf)，即客户端与服务器之间，数据通讯所需的基础信息，主要是对通讯报文的基本属性进行描述，包括系统版本号(version)，格式设置为1.0.时间标识(time)，格式设置为 YYYY：MM：DD：HH：MIN：SS;②报文头(Message_Header)包含通讯双方用户身份信息，分别为报文发送方与报文响应方，其元素名称(name)即报文的发送方或接收方，如XX大学或XX银行，用户角色(role)定义为该条报文的交易发起者，或交易接收者.ID号是银校转账系统中是标识每个机构身份信息的数字编码，具有唯一性，且固定不变;③报文体(Message_Body)，根据用户需求的不同，其内容分别为请求信息或响应信息，请求信息中包含一卡通用户个人基本信息，以及行为操作等内容，如交易代码，以此用于对其操作动作进行区分，例如可设置为00006转账，00007查询余额等.每一条交易数据均会自动产生一条流水号，用于每日对账，以及数据存储与数据检索.数据组中包含了用户的校园卡卡号、身份证号、转账金额等内容.响应信息主要包含银行方返回的交易代码，用于表示交易状态成功或失败.若交易失败，则会根据银行业务系统所提供的数据，显示失败原因，如个人信息不符，卡内余额不足，账户状态异常等等.报文信息描述如下：

1.4 银校转账系统XML数据报文加密

银校转账系统中的XML数据报文在网络中传送，其安全性问题需要着重关注.传统的SSL/TSL虽然能够实现端到端的通讯安全保护，但加密方式需对整个文档进行加密，这将导致在某个时间段内传送大量数据会产生性能方面的问题.而XML安全机制则可提供多种加密粒度以供用户选择，即既可加密整个文档内容，也可加密单个元素，或者加密元素内容.同时，XML加密过程不会改变文档格式，加密后的密文依旧是格式良好的XML文档[17].在本案研究中，因元素Message_Body内包含有用户卡号、密码，以及操作行为等涉及个人金融安全的内容，需针对Message_Body进行加密.以下是加密Message_Body元素后的X ML文档.

根据以上文档将加密数据封装于EncryptedData元素中以实现对XML报文加密.EncryptionMethod使用URI唯一标识中所采用的加密算法，以保证银行、学校双方在算法上的一致.在本案例中，URI使用tripledes进行加密，并通过CBC填充.CipherData则作为加密后的密文，CipherValue用于封装实际的加密数据.

1.5 银校转账系统XML配置文件

在系统实际运行过程中，还需考虑校内各个职能部门今后对一卡通银校转账系统新的需求，以及整个业务平台的功能扩展或升级改造.为体现其开放兼容性与灵活扩展性，平台需提供统一标准的数据接口，以供接入双方使用[18].为方便应用程序跨平台的存取与调用，一般将数据接口的配置参数存放于XML文件中，当每天服务启动时，系统将首先读取配置文件中的参数内容，根据接口参数去获取相关信息.XML配置文件部分内容如下：

2 实验验证系统

2.1 实验环境

硬件部分包括：Intel(R)Xeon(R)2.6GHZ 2CPU，内存为32G.HUAWEI16口光纤交换机，银、校双方采用SDH连接.

软件部分包括：操作系统Windows Server 2008 R2 Enterprise，FTP服务器软件 Serv-U，数据库MySQL Server 5.0，JDK1.6与 Jboss4.2.

实验场景选取：国内某大学，一卡通用户数4万余人，人工充值点位5个，自助圈存终端16个.年充值金额1.3亿元.

2.2 实验结果

系统上线5个月内，对全校用户产生的人工充值与自助圈存的交易金额、交易次数进行记录，如表1所示.根据表1数据，将人工充值与自助圈存每个点位一天的交易次数进行计算

全校用户在使用银校转账系统后，人工充值金额及次数大幅下降，每个人工充值点由最初的311笔/天，下降至27笔/天.而每台自助圈存终端则由最初的13笔/天，上升至166笔/天.其趋势如图3所示.

表1 数据记录Table 1 Data record

图3 每月日均交易数Fig.3 Daily average transaction per month

3 结语

本文提出了一种基于XML的一卡通银校转账系统架构，并较为详细的阐述了其业务流程.同时，利用XML所具有的精准性、可扩展性、开放性等特质，实现了在学校与银行这两个异构平台之间安全、可靠、实时的传送XML数据报文.应用结果验证了此系统降低了学校在一卡通充值方面的人力开销，提高了数据实时交互的工作效率，能够满足一卡通用户方便、快捷的自助圈存需求.但是，该系统在处理数据报文的封装与解析上，耗时较长，未来还将针对此问题进行优化，提高其运行效率.