论文部分内容阅读
摘要： 结合企业数据通信系统功能等方面的要求，借助消息队列件（WebSphere MQ）技术确保大量商业数据文件的有效传输.以零售企业前、后台日常销售数据传输为例，设计方案并实现了典型零售业系统数据传输功能.
关键词： 数据传输技术； 零售业； 中间件； 消息队列技术
中图分类号： TN 919.3 文献标志码： A 文章编号： 10005137（2017）01000109
Abstract： Considering the requirements of enterprise data communication system functions，this article uses WebSphere message queue（MQ）technology to ensure effective data transmission for large amount of commercial files.Taking daily sales data transmission between foreground and background as example，we design and realize the typical retail data transmission function.
Key words： data transmission technology； retail trade； middleware； WebSphere message queue
消息队列技术（WebSphere MQ）是IBM的商业通讯中间件，它既简化了不同系统之间的数据传输，又兼容了各类异构的操作系统及网络，提供了标准的接口，依靠消息队列的存储-转发机制，确保企业能够进行可靠的、具备异步事务处理能力的跨平台数据传输.
本文作者通过分析零售业日常销售流程，借助WebSphere MQ，設计方案并实现了典型前、后台系统日常数据交互的基本功能.
1 概念准备
要使用WebSphere MQ进行开发，需要先明确以下几个基本概念[1]：
1）队列管理器：作为WebSphere系统中最上层的概念，队列管理器对所有消息队列进行管理并提供消息服务.
2）消息：一个信息单元，从广义上理解，各类数据文件或者应用发出的请求等都可以定义为消息.一条WebSphere MQ消息通常分为两块：消息描述符（用于定义消息传输目标等）和消息体（如应用程序数据等）.消息分为非永久性和永久性两种类型，此外，还使用逻辑消息和物理消息的概念对消息进行分段或合并处理.
3）队列：一个安全的存储消息的地方.队列存储和处理消息遵循先进先出的原则，并且异步传送和接收消息.由于消息存放在队列中，所以应用程序可以相互独立地运行，以不同的速度，在不同的时间和不同的地点进行可靠传递，不受网络或目标系统故障影响.
4）WebSphereMQ队列：包括本地队列、远程队列、别名队列等很多类型，分别根据系统需求起到不同的作用.
5）通道：一个逻辑概念，相当于在队列管理器之间传递消息的管道.在WebSphereMQ中主要有3种通道类型：消息通道、消息队列接口（MQI）通道和群集（Cluster）通道，分别应用于不同的场景中.
在系统X中有应用程序a和b，a向b发送了一条消息，如图1所示.但是这条消息不会直接到达b，而是先发送到队列Q1保存，直到b需要的时候，再从Q1上获取；当a需要向位于系统Y的应用程序c发送消息时，需要先将消息放入队列Q2，与在同一系统内的通信方式不同，a需要先将消息放入本地传输队列，此时，在系统X和Y之间建立了一条消息通道，为了便于对通道进行管理和监控，WebSphere MQ在通道的两端使用了消息通道代理.消息通道代理将会从传输队列中读取待传送的消息，再将消息放入Y中的Q2，在得到Y的收取消息确认后，消息将会从传输队列删除，否则将会被保存在传输队列中直到被成功传输到目标系统.消息通道代理通过对通道两端的消息序列号进行协同管理，能够防止消息的重复传递，确保消息一次且仅一次传递[1].
2 系统需求分析
2.1 零售业系统中日常销售数据传输场景分析
从零售企业日常业务种类的角度来看，一套完整的零售业系统数据传输，应当包含用户信息管理、物流运送管理、商品采购管理、线上交易等业务功能.由于篇幅限制，本文作者将仅讨论零售业日常的销售数据传输场景.
零售企业的日常销售场景包括：用户进入商场，选购商品，至收银台结账；若商品存在问题，则可能发生退换货行为；此外，还可能存在积分兑换、网络下单等行为.在这些场景当中，涉及到的数据有：用户数据（用户基本信息、积分、消费习惯分析等），商品信息（价格、库存、折扣等），相关费用信息等.
根据上述场景，本文作者设计了日常销售数据传输系统关系图，如图2所示.在销售过程中，由收银员操作收银机完成收银过程，发票信息（till）等数据被记录到销售终端（POS）服务器上的数据库（Microsoft SQL server，MSSQL）中，由企业服务总线（ESB）处理后发送给后台系统商场商品系统（MSST）、客户文件管理（CFM）和主要出纳（MC），各模块详细功能如表1所示.
2.2 数据传输过程中的需求分析
由于零售业本身的特性，决定了日常传输数据的多样性（不同类型、大小）.因此，数据传输的准确性和实时性是非常重要的.系统不仅需要保证数据在传输过程中保持一致，避免多个系统并发操作可能带来的误差；还要保证面对较大数据压力或时效性强的数据时，能够及时将之发送到目的系统.
企业也必须考虑信息传输的安全.从自身配置的角度，系统应当构建一套安全的传输路径，避免非法用户访问，并且可以赋予合法用户不同的权限[4]；从外界环境的角度，系统应当具备一定的防御策略，能够防范外部攻击对数据造成的影响，例如，破坏数据的完整性，破坏数据的私密性等[5]. 此外，完整的零售业系统往往结构复杂，不仅包括具有不同操作系统的各类系统（基于简便性、易维护性或性能的不同需求，企业可自由选择Windows、Linux或Unix服务器），还涉及不同数据库之间的数据传递（同样出于性能的考虑，不同系统可采用Oracle或MSSQL数据库进行数据管理）[6].同时，还应考虑系统后续无缝添加、删除一些功能模块.
2.3 系统运行环境需求
2.3.1 软件环境
根据图2，将整套系统简单划分为前台POS系统和后台系统（CFM、MSST、MC）.
对于前台系统，它的主要功能为日常销售以及与各个后台系统发生数据交互，故数据库系统选用MSSQL Server 2005，操作系统则采用Windows，ESB采用MB8.0（IBM公司），消息中间件使用WebSphere MQ 6.0（IBM公司）.
后台系统由于性能要求较高，数据库系统选用Oracle 11g，其他与前台系统相同.
2.3.2 硬件环境[1]
1）任何基于32位 Intel 处理器的IBM公司的 PC（或兼容机）.
2）支持 SNA LU 6.2、TCP/IP、NetBIOS 或 SPX 的通信硬件.
对于典型安装，WebSphere MQ至少需要大约 85 Mbyte（MB）的磁盘空间用于储存产品代码和数据（如果使用NTFS硬盘类型，至少需要20 MB作为运行空间）.而且安装进程需要在系统磁盘上占用30 MB的临时空间.
3 基本功能与实现
3.1 前、后台日常销售数据传输的基本模型
基于零售业系统数据传输过程中对传输准确性、实时性、安全性及可扩展性的要求，选择使用WebSphere MQ这一中间件技术为系统提供数据传输服务.
为了更好地理解數据传输的过程，抽取几个典型系统之间的数据传输过程，得出如图3所示的模型.
由图3可知，日常销售数据传输的基本流程包括：
1）在一笔交易完成后，安装在商场服务器上的ESB适配器（通常安装在源/目标系统服务器上，每个适配器使用ESB适配器表连接数据库并且只传输配置文件中定义的特定类型的消息），从POS 数据库中读取发票的信息，并且将之转换为MQ消息，并发送到用于分发消息的队列当中；
2）消息分发队列读取消息，根据事先定义的消息类型及队列名称，在配置数据库中获取对应的配置信息，将消息发往对应的队列；
3）目标队列收到信息后，根据事先的定义，将信息转化为目标系统能够读取的格式，并将信息路由到目标系统上；
4）源系统中的消息状态，在消息被处理后，会收到一条反馈消息，用于更新消息状态，并标识该数据是否被处理；
5）根据目标系统的不同，消息会进行不同的处理：若目标系统为集中式系统，数据会通过目标系统上的ESB适配器更新到目标数据库中；若目标系统为本地系统，数据会被转化为二进制大对象（BLOB）信息，并发送到相应队列中，以被ESB适配器写入文件.
3.2 队列命名规则及配置参数
3.2.1 前台端MQ命名规则
ESB适配器会从POS数据库中获取发票信息，并放入POS端的远程队列发送给后台系统，根据使用的适配器名称及系统名称，将POS端的队列命名为“esb_pos.1561100001.delivery”.
3.2.2 ESB端MQ命名规则
在ESB端，会有一个对应POS端的别名队列（与POS端的远程队列同名），将消息传送到本地分发队列，将分发队列命名为“esb.dispatcher_in.request”，根据事先定义的业务对象参数，系统会将传送的消息识别为发票信息，因此，将负责上传发票信息的队列命名为“esb.txiu（transaction invoice upload）_in”，根据事先定义的映射规则，代理（broker）会将数据转化为后台系统可以读取的格式，并发送到对应系统的远程队列上.
3.2.3 后台端MQ命名规则
参照前台端队列命名规则，由于后台涉及到3个系统，分别将队列命名为：“esb_msst_01（Excution Group no）.request”（由于MSST日常数据流量较大，为了减轻通道压力，通常配置多个EG进行数据传输），“esb_cfm.request”及“esb_mc.request”，这些队列都被定义为本地队列，与ESB端后台系统的远程队列同名.
此外，由于涉及到5个系统（POS，MSST，CFM，MC和ESB），为了便于管理，为整个系统定义5个队列管理器（Queue Manager），其命名规则为“MQSA.I（系统名称）”，如POS系统的QM名为“MQSA.IPOS”.主机名则为系统服务器对应IP地址，端口统一定义为1411，通道统一命名为“SYSTEM.DEF.SVRCONN”.
3.3 消息格式设计
选择使用XML格式来封装消息，同时依照前后台数据库表的内容来设计消息的具体内容.通常一条完整的WebSphereMQ消息分为两部分，消息描述符（Message Header）和消息体（Message Body），定义规则如下[7].
3.3.1 消息描述符
对于MQ的消息，使用消息队列规则格式头（MQRFH2）的消息头来实现消息安全控制.图4为一个典型的MQRFH2消息头的结构.
由图4可知，除了结构编号和版本以外，可以将大部分的消息，描述字段看作属性.依照实际日常业务需求，为消息头定义以下属性：
1） 源系统（SourceApplication）：本方案中源系统为POS系统. 2） ESB文件头版本（ESBHeaderVersion）：默认为1.0版本.
3） 服务（Service）：由于本方案主要讨论发票从源系统传送到目标系统的功能，故主要服务为发票上传（Invoice Upload）服务.
4） 消息版本（Version）：默认为V1版本.
5） 操作（Operation）：不同操作对应不同的转换文件，文件名依照具体操作命名.例如，添加发票记录的操作对应的转换文件名为addInvoiceRecord.xsd.
6） 国别（Country）：依照ISO Alpha2字符代码命名国家英文缩写.
7） 商场号（Store）：POS系统中的商场编号.
8） 全球唯一标识id（UUID）：由POS系统生成，格式通常表示为“POS_”.
9） 关联编号（CorrelationId）：對于请求的消息该参数的值必须与“UUID”相同.
10） 优先级（Priority）：消息优先级，默认定义为4（较低）.
11） 永久性（Persistence）：定义为2，即“永久性消息”.
12） 键值1，键值2，…，键值n（Key1，Key2，…，Keyn）：所有用来代表业务记录的唯一键值.例如：假设一张发票由3个键值，确定唯一标识（序列号，发票日期和发票时间），则键值可以表示为：
3.3.2 消息体
应用数据包含了日常业务数据，这些数据的格式同样由XML模式文件定义.在POS服务器上，处理过的数据会按照事先在配置文件中定义的路径，将数据文件移动到对应文件夹中，以表示这些数据被成功处理过；反之，如果数据处理失败，对应文件则会被移动到另外的文件夹，错误信息可以从服务器对应日志中获取.
当数据被成功传输到后台时，ESB适配器会生成一条反馈消息，发送给POS服务器，用于更新数据库中的数据处理状态列.
此外，由于前、后台文件系统的文件格式经常是不统一的（这由每个系统对数据的需求决定），还需要实现业务对象和文本格式双向转换的功能，这时候需要自定义一个数据处理器来实现这一功能.WebSphere MQ提供了具有用户友好的可视化界面的企业元数据发现（Enterprise Metadata Discovery）工具，可以方便地生成各系统中定义的各类元数据或函数，同时生成相应的接口文件[8].利用该工具，可以方便地定义业务对象中各类成员的属性，例如：成员名称、成员数据类型、默认值、成员出现次数、成员数据类型长度等[9].
3.4 功能概述
3.4.1 触发机制
当有数据插入POS_V1_INVOICE表（“V1”代表当前版本）的时候，触发安装在前台系统上的触发器，开始消息的传输.
3.4.2 源接口定义
在POS数据库中，数据由ESB适配器使用标准ESB事件生成和处理规则取出.在POS数据库中，定义了表ESB_TRANSPOS，表中保存了可能需要传送给后台系统的所有数据，适配器会访问ESB_TRANSPOS表的数据，以便将MQ消息发送到broker处理队列.
出于安全性及简便性的考虑，在适配器获取、插入数据的过程当中，只需要访问某些表的某些列，这里就使用了视图的概念.视图相当于一张逻辑表，并非真正的物理表，只从物理表中抽取目标系统需要用到的列组合成新表（又称为接口表），并且只有特定用户表（ESB_TRANSPOS）才能访问这些列，避免前、后台所有表（称为基表）暴露在所有用户面前.此外，基表相关的数据更新会实时同步到视图表中，保证了数据的准确性[10].
为了进行前台系统数据集成，构造了业务对象POS_V1_ESBTXInvoice，它定义了业务实体的结构、语法和语义（一系列相关的业务对象被实现和封装为可视化的、树状结构的类型树，可以在后面的数据转换设计中作为数据接口，在数据转换处理过程中和相应的数据源进行数据交互）.ESB适配器使用POS_V1_ESBTXInvoice业务对象来访问ESB_TRANSPOS表的视图如表2所示.
3.4.3 目标接口定义
同前台系统一样，在目标系统中同样使用视图的概念，数据在到达接口表后，根据事先设定好的程序，触发安装在后台系统上的触发器，数据会被插入对应的基表中.由于3个后台系统逻辑近似，在此仅举例CFM系统进行说明.
CFM系统使用ESB适配器，传输队列根据消息集CFM_V1_CC_INVOICE定义的格式生成所有输出数据.所有参数根据事先定义的映射规则生成，作为单一数据类型的一部分.ESB适配器会将数据更新到如表3所示的视图.
3.4.4 连通性
ESB broker是IBM的应用整合中间件，它的开发基于“应用程序集线器（ApplicationHub）”这一应用整合理念，为用户提供一个封装的标准信息通道，减少由于异构系统互联带来的复杂性.同时，它使用开放数据库连接（ODBC）技术与数据库连接，利用各种适配器，使用统一接口与各个系统无缝连接，按照预先定义的规则对消息进行处理（如格式转换等）后将其路由到目标系统[11].
在图3的场景中，只需要创建一个broker以及一个对应的数据库（用于存储各类业务对象及操作的定义），并赋予该broker用户相应的权限；此外，还要为这个broker创建一个对应的队列管理器，用于部署broker的配置信息并对broker进行初始化.
为日常销售数据传输定义消息流“InvoiceUpload”，InvoiceUpload流从POS系统接收数据并放入一个调度程序输入队列.基于消息中的一些特定数据（如消息集等），消息代理将收到的信息路由到输入队列，对消息进行必要的格式转换等处理后，根据事先配置好的定义路由每条消息，利用ESB适配器发送到后台系统中. 由于broker需要了解消息的结构才能对消息进行处理，消息的定义有助于验证消息结构，构建消息流以及构建Message Broker工具集中的映射关系.而消息集即对消息流处理的消息结构的定义，本系统设计为依照消息集定义对消息进行必要处理.消息集被编译为消息字典部署到broker上，为消息流验证消息提供了参考[12].
3.4.5 Log记录
InvoiceUpload流在broker当中会记录标准及特定信息的日志.
标准信息会在每条消息被传输的时候记录：
1） VALUE_1：“Whereclause：WHERE A.INPUT_BO_XSD_VERSION = MessageType AND A.INPUT_QUEUE = ESBstoreQueue”
2） VALUE_2：“Pub/Sub：Not activated”
3） VALUE_3：“FlowIn queue：XXXXXX”
特定信息則根据接收到的消息类型记录以下内容：
4） 如果输入消息类型是“POS_V1_INVOICE”，则发票号会被记录在VALUE_2中；
5） 如果输入消息类型是“POS_V1_INVOICE”以外的类型（如收营员换班信息等），则操作序列号（Sequence ID）会被记录在VALUE_2中.
4 结 论
设计了一种零售数据传输系统，较好地满足了零售企业的数据传输需求.由于采用了WebSphere MQ中间件技术，整个系统具备良好的可扩展性和兼容性，可以灵活应对系统功能或性能方面新的变化和要求.
当然，实际销售过程中，流程往往比上述模型复杂许多，且可能产生各种意外情况；同时由于整套分布式系统非常庞大，不同系统往往由不同的人负责，系统间信息更新滞后，可能会对数据的传输功能造成影响，这些问题都有待进一步研究和解决.
参考文献：
[1] 甘荃，娄丽军.IBM WebSphere MQ基础教程 [M].北京：电子工业出版社，2004.
Gan Q，Lou L J.IBM WebSphere MQ basic course [M].Beijing：Publishing House of Electronics Industry，2004.
[2] Falzone L，Ciabarra C.Pointofsale system：US20120066079 [P/OL].（20120315）[20161102].http：//www.google.com/patents/US20120066079.
[3] 董叶彤.企业服务总线在速递信息平台数据交换中的应用 [D].北京：北京邮电大学，2008.
Dong Y T.The application of enterprise service bus（ESB） on express mail service（EMS） platform [D].Beijing：Beijing University of Posts and Telecommunication，2008.
[4] 赵琳，黄玉文.网络化系统中权限控制技术研究 [J].科技信息，2010（22）：599.
Zhao L，Huang Y W.Research on privilegecontrol technology in networked system [J].Technology Information，2010（22）：599.
[5] 周峻锋.基于数据安全通信的分布式入侵防御系统研究 [D].成都：电子科技大学，2011.
Zhou J F.Research on distributed intrusion prevention system based on data secure communication [D].Chengdu：University of Electronic Science and Technology of China，2011.
[6] 刘春燕.连锁餐饮信息系统中数据通讯的设计与实现 [D].大连：大连理工大学，2014.
Liu C Y.Design and implementation of data communication in chain restaurants information systems [D].Dalian：Dalian University of Technology，2014.
[7] Ya X.WebSphere MQ消息在传递和排队期间的格式变化 [DB/OL].（20100311）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1001_xiao/1001_xiao.html.
Ya X.WebSphere MQ message format conversion during delivery and queueing [DB/OL].（20100311）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1001_xiao/1001_xiao.html
[8] 程国强.迭代开发：WebSphere adapters 7.0让您更灵活的开发元数据 [M/OL].（20100626）[20161102].http：//blog.itpub.net/14789789/viewspace666344. Cheng G Q.Iterative development：WebSphere adapters 7.0makes you develop metadata more flexibly [M/OL].（20100626）[20161102].http：//blog.itpub.net/14789789/viewspace666344.
[9] 王博，赵杰.WebSphere Adapter for Flat Files 通过自定义 Data Handler 实现对任意格式文件的支持 [DB/OL].（20110414）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1104_wangb_adapterdatahandle/1104_wangb_adapterdatahandle.html.
Wang B，Zhao J.WebSphere adapter for flat files implements support for any file format by custom data handler [DB/OL].（20110414）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1104_wangb_adapterdatahandle/1104_wangb_adapterdatahandle.html.
[10] 王成.SQLServer中基于多表的可更新視图的设计与实现 [J].发明与创新（综合版），2005（8）：26-26.
Wang C.Design and implementation of multitable based updateable views in SQL Server [J].Invention&Innovation（Integrated），2005（8）：26-26.
[11] 秦鼎.基于ESB的企业应用集成平台研究 [D].赣州：江西理工大学，2008.
Qin D.Research on ESB based enterprise application integration platform [D].Ganzhou：Jiangxi University of Science and Technology，2008.
[12] Davies S，Cowen L，Giddings C，et al.Websphere message broker basics [M].New York：IBM Corporation，2005.
（责任编辑：包震宇，冯珍珍）
关键词： 数据传输技术； 零售业； 中间件； 消息队列技术
中图分类号： TN 919.3 文献标志码： A 文章编号： 10005137（2017）01000109
Abstract： Considering the requirements of enterprise data communication system functions，this article uses WebSphere message queue（MQ）technology to ensure effective data transmission for large amount of commercial files.Taking daily sales data transmission between foreground and background as example，we design and realize the typical retail data transmission function.
Key words： data transmission technology； retail trade； middleware； WebSphere message queue
消息队列技术（WebSphere MQ）是IBM的商业通讯中间件，它既简化了不同系统之间的数据传输，又兼容了各类异构的操作系统及网络，提供了标准的接口，依靠消息队列的存储-转发机制，确保企业能够进行可靠的、具备异步事务处理能力的跨平台数据传输.
本文作者通过分析零售业日常销售流程，借助WebSphere MQ，設计方案并实现了典型前、后台系统日常数据交互的基本功能.
1 概念准备
要使用WebSphere MQ进行开发，需要先明确以下几个基本概念[1]：
1）队列管理器：作为WebSphere系统中最上层的概念，队列管理器对所有消息队列进行管理并提供消息服务.
2）消息：一个信息单元，从广义上理解，各类数据文件或者应用发出的请求等都可以定义为消息.一条WebSphere MQ消息通常分为两块：消息描述符（用于定义消息传输目标等）和消息体（如应用程序数据等）.消息分为非永久性和永久性两种类型，此外，还使用逻辑消息和物理消息的概念对消息进行分段或合并处理.
3）队列：一个安全的存储消息的地方.队列存储和处理消息遵循先进先出的原则，并且异步传送和接收消息.由于消息存放在队列中，所以应用程序可以相互独立地运行，以不同的速度，在不同的时间和不同的地点进行可靠传递，不受网络或目标系统故障影响.
4）WebSphereMQ队列：包括本地队列、远程队列、别名队列等很多类型，分别根据系统需求起到不同的作用.
5）通道：一个逻辑概念，相当于在队列管理器之间传递消息的管道.在WebSphereMQ中主要有3种通道类型：消息通道、消息队列接口（MQI）通道和群集（Cluster）通道，分别应用于不同的场景中.
在系统X中有应用程序a和b，a向b发送了一条消息，如图1所示.但是这条消息不会直接到达b，而是先发送到队列Q1保存，直到b需要的时候，再从Q1上获取；当a需要向位于系统Y的应用程序c发送消息时，需要先将消息放入队列Q2，与在同一系统内的通信方式不同，a需要先将消息放入本地传输队列，此时，在系统X和Y之间建立了一条消息通道，为了便于对通道进行管理和监控，WebSphere MQ在通道的两端使用了消息通道代理.消息通道代理将会从传输队列中读取待传送的消息，再将消息放入Y中的Q2，在得到Y的收取消息确认后，消息将会从传输队列删除，否则将会被保存在传输队列中直到被成功传输到目标系统.消息通道代理通过对通道两端的消息序列号进行协同管理，能够防止消息的重复传递，确保消息一次且仅一次传递[1].
2 系统需求分析
2.1 零售业系统中日常销售数据传输场景分析
从零售企业日常业务种类的角度来看，一套完整的零售业系统数据传输，应当包含用户信息管理、物流运送管理、商品采购管理、线上交易等业务功能.由于篇幅限制，本文作者将仅讨论零售业日常的销售数据传输场景.
零售企业的日常销售场景包括：用户进入商场，选购商品，至收银台结账；若商品存在问题，则可能发生退换货行为；此外，还可能存在积分兑换、网络下单等行为.在这些场景当中，涉及到的数据有：用户数据（用户基本信息、积分、消费习惯分析等），商品信息（价格、库存、折扣等），相关费用信息等.
根据上述场景，本文作者设计了日常销售数据传输系统关系图，如图2所示.在销售过程中，由收银员操作收银机完成收银过程，发票信息（till）等数据被记录到销售终端（POS）服务器上的数据库（Microsoft SQL server，MSSQL）中，由企业服务总线（ESB）处理后发送给后台系统商场商品系统（MSST）、客户文件管理（CFM）和主要出纳（MC），各模块详细功能如表1所示.
2.2 数据传输过程中的需求分析
由于零售业本身的特性，决定了日常传输数据的多样性（不同类型、大小）.因此，数据传输的准确性和实时性是非常重要的.系统不仅需要保证数据在传输过程中保持一致，避免多个系统并发操作可能带来的误差；还要保证面对较大数据压力或时效性强的数据时，能够及时将之发送到目的系统.
企业也必须考虑信息传输的安全.从自身配置的角度，系统应当构建一套安全的传输路径，避免非法用户访问，并且可以赋予合法用户不同的权限[4]；从外界环境的角度，系统应当具备一定的防御策略，能够防范外部攻击对数据造成的影响，例如，破坏数据的完整性，破坏数据的私密性等[5]. 此外，完整的零售业系统往往结构复杂，不仅包括具有不同操作系统的各类系统（基于简便性、易维护性或性能的不同需求，企业可自由选择Windows、Linux或Unix服务器），还涉及不同数据库之间的数据传递（同样出于性能的考虑，不同系统可采用Oracle或MSSQL数据库进行数据管理）[6].同时，还应考虑系统后续无缝添加、删除一些功能模块.
2.3 系统运行环境需求
2.3.1 软件环境
根据图2，将整套系统简单划分为前台POS系统和后台系统（CFM、MSST、MC）.
对于前台系统，它的主要功能为日常销售以及与各个后台系统发生数据交互，故数据库系统选用MSSQL Server 2005，操作系统则采用Windows，ESB采用MB8.0（IBM公司），消息中间件使用WebSphere MQ 6.0（IBM公司）.
后台系统由于性能要求较高，数据库系统选用Oracle 11g，其他与前台系统相同.
2.3.2 硬件环境[1]
1）任何基于32位 Intel 处理器的IBM公司的 PC（或兼容机）.
2）支持 SNA LU 6.2、TCP/IP、NetBIOS 或 SPX 的通信硬件.
对于典型安装，WebSphere MQ至少需要大约 85 Mbyte（MB）的磁盘空间用于储存产品代码和数据（如果使用NTFS硬盘类型，至少需要20 MB作为运行空间）.而且安装进程需要在系统磁盘上占用30 MB的临时空间.
3 基本功能与实现
3.1 前、后台日常销售数据传输的基本模型
基于零售业系统数据传输过程中对传输准确性、实时性、安全性及可扩展性的要求，选择使用WebSphere MQ这一中间件技术为系统提供数据传输服务.
为了更好地理解數据传输的过程，抽取几个典型系统之间的数据传输过程，得出如图3所示的模型.
由图3可知，日常销售数据传输的基本流程包括：
1）在一笔交易完成后，安装在商场服务器上的ESB适配器（通常安装在源/目标系统服务器上，每个适配器使用ESB适配器表连接数据库并且只传输配置文件中定义的特定类型的消息），从POS 数据库中读取发票的信息，并且将之转换为MQ消息，并发送到用于分发消息的队列当中；
2）消息分发队列读取消息，根据事先定义的消息类型及队列名称，在配置数据库中获取对应的配置信息，将消息发往对应的队列；
3）目标队列收到信息后，根据事先的定义，将信息转化为目标系统能够读取的格式，并将信息路由到目标系统上；
4）源系统中的消息状态，在消息被处理后，会收到一条反馈消息，用于更新消息状态，并标识该数据是否被处理；
5）根据目标系统的不同，消息会进行不同的处理：若目标系统为集中式系统，数据会通过目标系统上的ESB适配器更新到目标数据库中；若目标系统为本地系统，数据会被转化为二进制大对象（BLOB）信息，并发送到相应队列中，以被ESB适配器写入文件.
3.2 队列命名规则及配置参数
3.2.1 前台端MQ命名规则
ESB适配器会从POS数据库中获取发票信息，并放入POS端的远程队列发送给后台系统，根据使用的适配器名称及系统名称，将POS端的队列命名为“esb_pos.1561100001.delivery”.
3.2.2 ESB端MQ命名规则
在ESB端，会有一个对应POS端的别名队列（与POS端的远程队列同名），将消息传送到本地分发队列，将分发队列命名为“esb.dispatcher_in.request”，根据事先定义的业务对象参数，系统会将传送的消息识别为发票信息，因此，将负责上传发票信息的队列命名为“esb.txiu（transaction invoice upload）_in”，根据事先定义的映射规则，代理（broker）会将数据转化为后台系统可以读取的格式，并发送到对应系统的远程队列上.
3.2.3 后台端MQ命名规则
参照前台端队列命名规则，由于后台涉及到3个系统，分别将队列命名为：“esb_msst_01（Excution Group no）.request”（由于MSST日常数据流量较大，为了减轻通道压力，通常配置多个EG进行数据传输），“esb_cfm.request”及“esb_mc.request”，这些队列都被定义为本地队列，与ESB端后台系统的远程队列同名.
此外，由于涉及到5个系统（POS，MSST，CFM，MC和ESB），为了便于管理，为整个系统定义5个队列管理器（Queue Manager），其命名规则为“MQSA.I（系统名称）”，如POS系统的QM名为“MQSA.IPOS”.主机名则为系统服务器对应IP地址，端口统一定义为1411，通道统一命名为“SYSTEM.DEF.SVRCONN”.
3.3 消息格式设计
选择使用XML格式来封装消息，同时依照前后台数据库表的内容来设计消息的具体内容.通常一条完整的WebSphereMQ消息分为两部分，消息描述符（Message Header）和消息体（Message Body），定义规则如下[7].
3.3.1 消息描述符
对于MQ的消息，使用消息队列规则格式头（MQRFH2）的消息头来实现消息安全控制.图4为一个典型的MQRFH2消息头的结构.
由图4可知，除了结构编号和版本以外，可以将大部分的消息，描述字段看作属性.依照实际日常业务需求，为消息头定义以下属性：
1） 源系统（SourceApplication）：本方案中源系统为POS系统. 2） ESB文件头版本（ESBHeaderVersion）：默认为1.0版本.
3） 服务（Service）：由于本方案主要讨论发票从源系统传送到目标系统的功能，故主要服务为发票上传（Invoice Upload）服务.
4） 消息版本（Version）：默认为V1版本.
5） 操作（Operation）：不同操作对应不同的转换文件，文件名依照具体操作命名.例如，添加发票记录的操作对应的转换文件名为addInvoiceRecord.xsd.
6） 国别（Country）：依照ISO Alpha2字符代码命名国家英文缩写.
7） 商场号（Store）：POS系统中的商场编号.
8） 全球唯一标识id（UUID）：由POS系统生成，格式通常表示为“POS_
9） 关联编号（CorrelationId）：對于请求的消息该参数的值必须与“UUID”相同.
10） 优先级（Priority）：消息优先级，默认定义为4（较低）.
11） 永久性（Persistence）：定义为2，即“永久性消息”.
12） 键值1，键值2，…，键值n（Key1，Key2，…，Keyn）：所有用来代表业务记录的唯一键值.例如：假设一张发票由3个键值，确定唯一标识（序列号，发票日期和发票时间），则键值可以表示为：
3.3.2 消息体
应用数据包含了日常业务数据，这些数据的格式同样由XML模式文件定义.在POS服务器上，处理过的数据会按照事先在配置文件中定义的路径，将数据文件移动到对应文件夹中，以表示这些数据被成功处理过；反之，如果数据处理失败，对应文件则会被移动到另外的文件夹，错误信息可以从服务器对应日志中获取.
当数据被成功传输到后台时，ESB适配器会生成一条反馈消息，发送给POS服务器，用于更新数据库中的数据处理状态列.
此外，由于前、后台文件系统的文件格式经常是不统一的（这由每个系统对数据的需求决定），还需要实现业务对象和文本格式双向转换的功能，这时候需要自定义一个数据处理器来实现这一功能.WebSphere MQ提供了具有用户友好的可视化界面的企业元数据发现（Enterprise Metadata Discovery）工具，可以方便地生成各系统中定义的各类元数据或函数，同时生成相应的接口文件[8].利用该工具，可以方便地定义业务对象中各类成员的属性，例如：成员名称、成员数据类型、默认值、成员出现次数、成员数据类型长度等[9].
3.4 功能概述
3.4.1 触发机制
当有数据插入POS_V1_INVOICE表（“V1”代表当前版本）的时候，触发安装在前台系统上的触发器，开始消息的传输.
3.4.2 源接口定义
在POS数据库中，数据由ESB适配器使用标准ESB事件生成和处理规则取出.在POS数据库中，定义了表ESB_TRANSPOS，表中保存了可能需要传送给后台系统的所有数据，适配器会访问ESB_TRANSPOS表的数据，以便将MQ消息发送到broker处理队列.
出于安全性及简便性的考虑，在适配器获取、插入数据的过程当中，只需要访问某些表的某些列，这里就使用了视图的概念.视图相当于一张逻辑表，并非真正的物理表，只从物理表中抽取目标系统需要用到的列组合成新表（又称为接口表），并且只有特定用户表（ESB_TRANSPOS）才能访问这些列，避免前、后台所有表（称为基表）暴露在所有用户面前.此外，基表相关的数据更新会实时同步到视图表中，保证了数据的准确性[10].
为了进行前台系统数据集成，构造了业务对象POS_V1_ESBTXInvoice，它定义了业务实体的结构、语法和语义（一系列相关的业务对象被实现和封装为可视化的、树状结构的类型树，可以在后面的数据转换设计中作为数据接口，在数据转换处理过程中和相应的数据源进行数据交互）.ESB适配器使用POS_V1_ESBTXInvoice业务对象来访问ESB_TRANSPOS表的视图如表2所示.
3.4.3 目标接口定义
同前台系统一样，在目标系统中同样使用视图的概念，数据在到达接口表后，根据事先设定好的程序，触发安装在后台系统上的触发器，数据会被插入对应的基表中.由于3个后台系统逻辑近似，在此仅举例CFM系统进行说明.
CFM系统使用ESB适配器，传输队列根据消息集CFM_V1_CC_INVOICE定义的格式生成所有输出数据.所有参数根据事先定义的映射规则生成，作为单一数据类型的一部分.ESB适配器会将数据更新到如表3所示的视图.
3.4.4 连通性
ESB broker是IBM的应用整合中间件，它的开发基于“应用程序集线器（ApplicationHub）”这一应用整合理念，为用户提供一个封装的标准信息通道，减少由于异构系统互联带来的复杂性.同时，它使用开放数据库连接（ODBC）技术与数据库连接，利用各种适配器，使用统一接口与各个系统无缝连接，按照预先定义的规则对消息进行处理（如格式转换等）后将其路由到目标系统[11].
在图3的场景中，只需要创建一个broker以及一个对应的数据库（用于存储各类业务对象及操作的定义），并赋予该broker用户相应的权限；此外，还要为这个broker创建一个对应的队列管理器，用于部署broker的配置信息并对broker进行初始化.
为日常销售数据传输定义消息流“InvoiceUpload”，InvoiceUpload流从POS系统接收数据并放入一个调度程序输入队列.基于消息中的一些特定数据（如消息集等），消息代理将收到的信息路由到输入队列，对消息进行必要的格式转换等处理后，根据事先配置好的定义路由每条消息，利用ESB适配器发送到后台系统中. 由于broker需要了解消息的结构才能对消息进行处理，消息的定义有助于验证消息结构，构建消息流以及构建Message Broker工具集中的映射关系.而消息集即对消息流处理的消息结构的定义，本系统设计为依照消息集定义对消息进行必要处理.消息集被编译为消息字典部署到broker上，为消息流验证消息提供了参考[12].
3.4.5 Log记录
InvoiceUpload流在broker当中会记录标准及特定信息的日志.
标准信息会在每条消息被传输的时候记录：
1） VALUE_1：“Whereclause：WHERE A.INPUT_BO_XSD_VERSION = MessageType AND A.INPUT_QUEUE = ESBstoreQueue”
2） VALUE_2：“Pub/Sub：Not activated”
3） VALUE_3：“FlowIn queue：XXXXXX”
特定信息則根据接收到的消息类型记录以下内容：
4） 如果输入消息类型是“POS_V1_INVOICE”，则发票号会被记录在VALUE_2中；
5） 如果输入消息类型是“POS_V1_INVOICE”以外的类型（如收营员换班信息等），则操作序列号（Sequence ID）会被记录在VALUE_2中.
4 结 论
设计了一种零售数据传输系统，较好地满足了零售企业的数据传输需求.由于采用了WebSphere MQ中间件技术，整个系统具备良好的可扩展性和兼容性，可以灵活应对系统功能或性能方面新的变化和要求.
当然，实际销售过程中，流程往往比上述模型复杂许多，且可能产生各种意外情况；同时由于整套分布式系统非常庞大，不同系统往往由不同的人负责，系统间信息更新滞后，可能会对数据的传输功能造成影响，这些问题都有待进一步研究和解决.
参考文献：
[1] 甘荃，娄丽军.IBM WebSphere MQ基础教程 [M].北京：电子工业出版社，2004.
Gan Q，Lou L J.IBM WebSphere MQ basic course [M].Beijing：Publishing House of Electronics Industry，2004.
[2] Falzone L，Ciabarra C.Pointofsale system：US20120066079 [P/OL].（20120315）[20161102].http：//www.google.com/patents/US20120066079.
[3] 董叶彤.企业服务总线在速递信息平台数据交换中的应用 [D].北京：北京邮电大学，2008.
Dong Y T.The application of enterprise service bus（ESB） on express mail service（EMS） platform [D].Beijing：Beijing University of Posts and Telecommunication，2008.
[4] 赵琳，黄玉文.网络化系统中权限控制技术研究 [J].科技信息，2010（22）：599.
Zhao L，Huang Y W.Research on privilegecontrol technology in networked system [J].Technology Information，2010（22）：599.
[5] 周峻锋.基于数据安全通信的分布式入侵防御系统研究 [D].成都：电子科技大学，2011.
Zhou J F.Research on distributed intrusion prevention system based on data secure communication [D].Chengdu：University of Electronic Science and Technology of China，2011.
[6] 刘春燕.连锁餐饮信息系统中数据通讯的设计与实现 [D].大连：大连理工大学，2014.
Liu C Y.Design and implementation of data communication in chain restaurants information systems [D].Dalian：Dalian University of Technology，2014.
[7] Ya X.WebSphere MQ消息在传递和排队期间的格式变化 [DB/OL].（20100311）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1001_xiao/1001_xiao.html.
Ya X.WebSphere MQ message format conversion during delivery and queueing [DB/OL].（20100311）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1001_xiao/1001_xiao.html
[8] 程国强.迭代开发：WebSphere adapters 7.0让您更灵活的开发元数据 [M/OL].（20100626）[20161102].http：//blog.itpub.net/14789789/viewspace666344. Cheng G Q.Iterative development：WebSphere adapters 7.0makes you develop metadata more flexibly [M/OL].（20100626）[20161102].http：//blog.itpub.net/14789789/viewspace666344.
[9] 王博，赵杰.WebSphere Adapter for Flat Files 通过自定义 Data Handler 实现对任意格式文件的支持 [DB/OL].（20110414）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1104_wangb_adapterdatahandle/1104_wangb_adapterdatahandle.html.
Wang B，Zhao J.WebSphere adapter for flat files implements support for any file format by custom data handler [DB/OL].（20110414）[20161102].http：//www.ibm.com/developerworks/cn/websphere/library/techarticles/1104_wangb_adapterdatahandle/1104_wangb_adapterdatahandle.html.
[10] 王成.SQLServer中基于多表的可更新視图的设计与实现 [J].发明与创新（综合版），2005（8）：26-26.
Wang C.Design and implementation of multitable based updateable views in SQL Server [J].Invention&Innovation（Integrated），2005（8）：26-26.
[11] 秦鼎.基于ESB的企业应用集成平台研究 [D].赣州：江西理工大学，2008.
Qin D.Research on ESB based enterprise application integration platform [D].Ganzhou：Jiangxi University of Science and Technology，2008.
[12] Davies S，Cowen L，Giddings C，et al.Websphere message broker basics [M].New York：IBM Corporation，2005.
（责任编辑：包震宇，冯珍珍）