论文部分内容阅读
摘 要：为了应对航空运输高速发展态势给我们空管带来的挑战，空管系统的建设方向应随着业务的发展及业务模式的改变提出前瞻性的建设规划。就空管信息系统建设而言，大数据集中处理、信息协同共享、分布式构架已经是建设的趋势。针对空管系统结构的合理规划，架构设计是重中之重，在保证安全性、稳定性的前提下还需考虑到整体系统可扩展性、前瞻性；本文使用IBM Websphere MQ V7.0、MB V7.0消息中间件来有效的构建整体系统的架构平台，并通过示范应用有效的验证了该方案的可行性，符合未来空管系统建设发展的要求，同时也为其他类似系统的建设提供了一种可行的解决方案。
关键词：MQ；MB；中间件；发布订阅；路由
中图分类号：TM923.5 文献标识码：A
1 引言（Introduction）
通过近几年对空管系统的研发和投产的实践来看，实际的管制用户需求不再局限于传统的航班计划、动态、统计等信息的获取上，而是强调围绕航班对象为目标、涉及整个航班生命周期管理中的各类信息的产生和使用，这对空管而言是一个全新的课题。
在当前IT水平高速发展的形式下，各个领域的信息化建设都是朝着大型的、集约式的、平台化的模式发展，建立集中数据处理中心，为各种专业化的生产系统提供数据服务。
未来空管系统的建设方向应随着业务的发展及业务模式的改变提出前瞻性的建设规划，而不是一味被动式进行系统改造、升级及新建，最后形成的局面将是用户和维护人员面前一堆屏显、系统与系统之间盘枝错综、系统本身也是一大堆补丁。国外的民航系统的建设和实践及国内近期的建设理念已经给了我们很大的参考和思路，并且当前的业务发展方向（未来10—20年）也是可预见的，就信息系统建设而言，数据大集中处理，信息协同共享、分布式部署应用已经是建设的趋势。
针对空管系统结构的合理规划，架构设计是重中之重，在保证安全性、稳定性的前提下还需考虑到整体系统可扩展性、前瞻性；本文使用IBM Websphere MQ V7.0、MB V7.0消息中间件来有效的构建整体系统的架构平台，使得系统升级灵活，兼容新老系统过渡，并使用基于内容的消息路由，提供发布订阅通信模式以满足动态需求，提供点对点通信模式满足高可用，既能满足强时序性又能提供分布式，也提供负载均衡模式，以适应未来空管系统的构建和发展。
2 系统平台需要解决的问题（To solve the problem
of system platform）
伴随着世界经济的发展，国际航空运输量在21世纪初有了大幅度的增加，以信息、通信技术为代表的新科技的广泛应用，使空中交通运输和世界经济领域的其他活动一起形成了快速全球化的发展态势。国际民航组织（ICAO）提出“全球空管运行”的新概念，其主要特点是建立共享、交互集成平台，使民航运输参与各方在安全的前提下，提升系统绩效。在此概念基础上，世界许多国家依据自身情况和未来预期开始规划和建立新一代空中交通管理系统，以适应新趋势的发展要求。为了应对航空运输高速发展态势给我们空管带来的全面挑战，除了全面提升传统的保障能力外，还必须加快新技术、新系统的研究和应用，同时还必须逐步把飞行信息服务功能拓展和延伸到各航空相关保障和服务单位。因此，在信息化系统变迁的过程中，传统的系统设计架构已难以适应空管大型运行系统的设计要求，新的系统架构应解决以下问题：
（1）兼容新老系统过渡，系统升级灵活
把未来的新信息系统有机地包容到现有系统中，使现在和未来能自然而有机地结合在一起，实现新老系统的无缝过渡。
（2）可靠的、标准化的通信交互模式
空管的系统种类繁多如电报、雷达、气象、情报、飞行计划等，不同系统的信息交互格式、方式差异很大，无法进行有机地整合，新系统架构平台应提供一套统一、完善、准确的数据交互规范，并从可靠性、安全性、冗余性等方面充分考虑。
（3）减少系统之间的复杂度
面对现有系统“点对点”式的系统架构，若想要增加或移除一些应用功能，真可谓“牵一发动全身”，举步维艰，所以新系统架构就需要具备松耦合，灵活扩展的特点，减少整体系统的复杂度。
（4）使系统之间交互模式由数据共享向服务共享转化
类似于硬件的虚拟化概念，其基础无非就是设备群、数据群、服务群等一层层向上，最终用户并不知道数据源在哪里、那台设备正在为其服务、那个应用服务正在相应他的操作。系统架构平台上的每个子系统或应用模块仅将业务专业部分的功能做专做精，通过服务的订阅能够消费其他系统应用功能服务，降低开发成本和资源。
结合以上问题我们希望能够利用一种成熟、有效的中间件技术，加以二次开发，根据空管业务实际特点，构建一套科学、合理的系统架构平台设计方案，本文选取了IBM Websphere MQ V7.0、MB V7.0消息中间件来有效的构建整体系统的架构平台，并通过实践应用以验证其可行性，为空管系统的建设和发展提供技术依据和服务。
3 WebsphereMQ MB的概述（Overview of
WebsphereMQ MB）
MQ（Message Queue）是IBM消息中间件的一款拳头产品，目的是使得任意两个分布式进程之间能够异步可靠的进行消息传输。MQ是一种以自己的复杂来换取企业应用简单化的基础平台软件。MQ能够支持目前绝大多数的操作系统，Unix、Linux、Windows等，也提供丰富的编程接口（API）包括VB、C、C 、C#、Java、JMS等。MQ提供了基于消息队列的存储转发机制，在7.0版本之后也提供了较为完善的基于主题的发布订阅机制[1]。
MB（Message Broker）是在MQ的基础上发展出来的企业服务总线，其能完成各系统之间的联通性，提供方便的格式转换，具备可配置可编程的智能路由，且能支持基于内容的发布订阅机制。MB安装部署简易，在开发部署上提供友好的图形化界面，通过拖放标准化组件能够快速编程，使用ESQL能够完成简易的逻辑，也可同使用Java来完成复杂逻辑编程。MB支持广泛的通信协议，包括MQ、JMS、HTTP、WebServices；支持广泛的数据格式例如XML、SOAP、CSV、Binary等；无缝集成标准商业数据库Oracle、DB2、SQL Server等[2]。 如果把MQ比作网线，那么MB就相当于路由器，除了有MQ端口之外，还有各种各样的其他接入端口。使用MQ这种业界成熟的消息中间件产品，和MB这样领先的企业服务总线[3]，使得我们能快速的解决信息孤岛的问题。
MQ支持目前主流的两种消息方式，既点对点通信（PTP）与发布订阅通信（Pub/Sub）[4]。
4 MQ/MB在空管系统中的应用（Application of
MQ/MB in air traffic control system）
航班运行协同决策（CDM）系统是民航发展背景下应运而生的新生空管信息系统，其是基于资源共享和信息交互的多主体（空管、机场、航空公司等）联合协同运行的理念，用于创造透明、高效的航班运行环境，是科学管理和决策航班机场放行，提高航班运行正常率的有效技术手段。在该系统中我们将基于MQMB平台的搭建新的系统架构，作为整个系统的基石。
4.1 基于MQ的设计与应用
4.1.1 模型设计
新建协同决策集成平台（MQ： QM_CDM_MEP_01）用于连接各机场，各航空公司，还有现有的空管信息集成平台（MQ： MQ_ATC_MEP_01），关系如图1所示。
针对每个系统为其创建两个队列，一个是输入队列，一个是输出队列，队列的命名规则为ATC/APT/CMP.XXXX.IN.LQ/RQ/TQ与ATC/APT/CMP.XXXX.OUT.LQ/RQ/TQ，ATC开头表示空管，APT开头的表示机场，CMP开头的表示航空公司，XXXX表示空管系统名称、机场代码、航空公司代码，IN表示输入队列，OUT表示输出队列，LQ表示本地队列，RQ表示远程队列，TQ表示传输队列。
而协同决策平台与现有的空管信息集成平台之间通过建立发送方通道与接收方通道来连通。通过远程队列访问对方的本地队列，其中远程队列要访问对端的本地队列需要先通过传输队列。而传输队列又通过自己的发送方通道将消息发送到远端对应的接收方通道。
首先创建一个队列管理器，命名为QM_CDM_MEP_01。
以下给出部分创建命令。
在CMD控制台上，使用命令RUNMQSC QM_CDM_MEP_01连接该队列管理器。
#创建本地队列
DEFINE QLOCAL（APT.ZSPD.IN.LQ）
DEFINE QLOCAL（APT.ZSPD.OUT.LQ）
……
#创建传输队列
DEFINE QLOCAL（ATC.CDM.OUT.TQ）USAGE（XMITQ）TRIGDATA（TO.QM_ATC_MEP_01）INITQ（SYSTEM.CHANNEL.INITQ）
#创建远程队列
DEFINE QREMOTE（ATC.CDM.OUT.RQ）RNAME（CDM.MEP.LQ） RQMNAME（QM_ATC_MEP_01）XMITQ（ATC.CDM.OUT.TQ）
#创建服务器连接通道
DEFINE CHANNEL（SVRCONN）CHLTYPE（SVRCONN）
#创建发送方通道
DEFINE CHANNEL（TO.QM_ATC_MEP_01）CHLTYPE（SDR）CONNAME（‘QM_ATC_MEP_01的IP地址（侦听端口号）’）XMITQ（ATC.CDM.OUT.TQ）
#创建接收方通道
DEFINE CHANNEL（TO.QM_CDM_MEP_01）CHLTYPE（RCVR）
在空管信息集成平台中也需创建对应的发送方通道与接收方通道（方法同上）
4.1.2 验证测试
（1）通信测试
测试两个队列管理器之间的通信。先启动QM_CDM_MEP_01中的发送方通道TO.QM_ATC_MEP_01，然后在ATC_CDM_OUT_RQ中手动放入测试消息，放入成功后，在QM.ATC_MEP_01队列管理器中的CDM.MEP.LQ队列中就能看到刚才放入的测试信息。
（2）性能测试
模拟空管系统、机场系统和航空公司的通信，模拟的消息大小为4kB—8kB。
场景一：航空公司向空管提起请求航班起飞时间，空管系统回复航班起飞时间。
场景二：机场系统实时向空管系统提供航班准备情况，停机位情况。
场景三：空管系统实时发布限制情况。不间断模拟收发7*24小时。
测试结果显示MQ中平均每秒消息流量能够达到5000多条，如图3所示是MQ队列管理器所在服务器在某一时刻的Windows任务管理器的网络流量截图。该消息传输性能足以满足信息交换要求。
4.1.3 小结
本方案不仅为空管、机场和航空公司间的信息集成提供了切实可行的解决方案，也演示了在MQ中如何创建队列管理器、本地＼传输＼远程队列、服务器连接＼发送方＼接收方通道，并通过实际测试证明了该方案是一套高性能、超稳定能够满足生产系统7*24小时持续运行的信息集成平台，从集成平台架构看具备松耦合，灵活扩展的特点，减少整体系统的复杂度，并提供了统一的数据标准。
4.2 基于MB的设计与应用
4.2.1 模型设计
我们重点使用MB基于消息内容的路由、发布订阅机制，模拟三大系统在空管内部的消息交互，主要包括流量系统、塔台系统、CDM平台系统。对于空管信息集成平台而言有三个输入队列FLOW.IN.LQ，CDM.MEP.LQ，TOWER.IN.LQ；每个系统有各自的接收队列FLOW.OUT.LQ，ATC.CDM.RQ，TWR.XXXX.OUT.LQ，其中XXXX为塔台所在机场的ICAO代码。接收队列所订阅的主题详见表1。 首先我们创建队列管理器QM_ATC_MEP_01，并在其中创建队列与预订。预订是在MQ7.0版本才新增的概念，是指预先订阅某种主题（或主题字符串）的消息，将所订阅到的消息放到一个目的队列中。
系统间传输的消息的格式使用XML，为了便于读者理解，在此我们简明定义以下消息格式，发送方在发送的时候需要在DST字段填入目的系统的名字。
下面我们使用MB来完成基于内容的消息路由，路由的依据就是消息中的DST字段。
（1）创建消息流项目
打开MB开发工具Toolkit，在选择菜单栏中的文件→新建→消息流项目，新建消息流项目的名称为ATC_MEP。
（2）创建消息流
选中已建好的消息流项目ATC_MEP，右键选择新建消息流，新建的消息流名称为ROUTE。
首先我们为消息流选择输入队列。在右侧的选用板中的WebSphereMQ栏目中拖入MQInput控件，命名FLOW.IN.LQ。双击MQInput控件FLOW.IN.LQ，在基本一栏中的队列名称中输入FLOW.IN.LQ，在输入消息解析一栏中的消息域中选择XMLNSC。用同样的方法处理CDM.MEP.LQ和TOWER.IN.LQ。
下一步选择消息处理组件和消息发布组件。变换一栏中拖入Compute组件，在其中可以使用ESQL语言用来进行简单的编程；在路由一栏中拖入Publication组件，该组件是用来发布消息到某个特定主题的。
使用连线工具将各个组件连接起来，连接方式如图4所示。
（3）创建代理及发布消息流
在Toolkit左下角Brokers区域中选择新建本地代理，输入代理名称MB_ATC_MEP_01，队列管理器名称QM_ATC_MEP_01，操作系统用户名及密码。在创建代理时需要注意用户名不要超过12个字节，否则会出现发布失败的错误。
创建代理成功之后，将消息流ROUTE拖放到代理MB_ATC_MEP_01下的默认执行组default中，就完成了消息流的发布。此时可以看到在队列管理器QM_ATC_MEP_01下的三个输入队列FLOW.IN.LQ、TOWER.IN.LQ、CDM.MEP.LQ的打开输入计数变为1，表示此时MB已连接这三个队列，从其中取消息。
4.2.2 验证测试
在那三个测试队列中放入测试消息，可以在TWR.ZSPD.OUT.LQ队列中发现该消息，说明消息路由成功。
测试消息：ZSPD Test Message
在多数中间件中如果使用了发布订阅模型，那么消息的消费者希望做负载均衡往往效果不尽如人意。例如浦东塔台的处理程序要是简单的订阅了ZSPD的主题，以后随着浦东的航班量不断地增加，那么原先的处理程序要是出现性能瓶颈想通过多部署一个程序来扩容就有问题了。首先这个新加的程序为了收到同样的数据也需要订阅ZSPD的主题，那么同样一条发送给浦东塔台的数据就会同时发送给了这两个程序，这样一来每个程序处理的量并没有减少，没法起到负载均衡的作用。而我们所做的设计刚好能够解决这类问题，就是利用MQ自身的订阅功能，将订阅到的消息先存放的队列里面，处理程序直接从队列中取数据处理，根据PTP模型的特性，多个程序从队列中消费数据，第一个程序取走后第二个程序就收不到了，假设浦东塔台起了N个处理程序，那么每个程序就只处理了1/N的消息量，快速稳定地实现了处理程序的负载均衡。
4.2.3 小结
该设计方案有以下三大明显优势。
（1）便捷的负载均衡。因为各个塔台系统需要向流量系统提交请求，导致流量系统原先处理程序处理量巨大，我们可以在流量系统的接收队列上起多份相同的程序，以起到负载均衡的作用。
（2）动态增加删除预订。如果浦东塔台测试系统希望收到与正式系统一致的数据，以满足业务测试，在以前则需要去修改我们的路由代码，让其多发一份数据给测试环境，并重新部署，而现在只需要在MQ的预订中新增一条主题ZSPD到队列TWR.ZSPD.TEST.OUT.LQ的预订即可，测试完成后直接删除该预订，不会对其他系统造成任何影响。
（3）快速集成新系统。如果现在有新的一个塔台需要加入到该空管信息集成平台中，那么只需新建一个队列，新增一个预订即可，无需在平台上做任何修改。
5 结论（Conclusion）
本文阐述了MQ、MB的核心概念，以民航空管信息系统建设为背景，使用两种不同的方式展现了多系统跨平台跨语言的信息集成。通过基于MQ/MB中间件进行系统构架平台的设计和应用，有效的验证了该方案的可行性，并符合未来空管系统建设发展的要求，同时也为其他类似实时运行系统的建设提供了一种可行的解决方案。
参考文献（References）
[1] 陈宇翔.精通WebSphere MQ[M].合肥：安徽科学技术出版社，
2004：1-105.
[2] 陈宇翔.精通Websphere Message Broker[M].北京：水利水电出
版社，2007：1-400.
[3] IBM公司.Connecting Your Business Using WebSphere Message
Broker V7 as an ESB[M].2010：1-536.
[4] 许骏，柳泉波，李玉顺.面向服务的网格计算：新型分布式计算
体系与中间件[M].北京：科学出版社，2009：1-340.
作者简介：
蔡永福（1985-），男，本科，助理工程师.研究领域：航空计算
机信息管理.
陈晓建（1966-），男，硕士，高级工程师.研究领域：航空计算
机信息管理.
曹烨琇（1983-），女，本科，工程师.研究领域：航空计算机信
息管理.
关键词：MQ；MB；中间件；发布订阅；路由
中图分类号：TM923.5 文献标识码：A
1 引言（Introduction）
通过近几年对空管系统的研发和投产的实践来看，实际的管制用户需求不再局限于传统的航班计划、动态、统计等信息的获取上，而是强调围绕航班对象为目标、涉及整个航班生命周期管理中的各类信息的产生和使用，这对空管而言是一个全新的课题。
在当前IT水平高速发展的形式下，各个领域的信息化建设都是朝着大型的、集约式的、平台化的模式发展，建立集中数据处理中心，为各种专业化的生产系统提供数据服务。
未来空管系统的建设方向应随着业务的发展及业务模式的改变提出前瞻性的建设规划，而不是一味被动式进行系统改造、升级及新建，最后形成的局面将是用户和维护人员面前一堆屏显、系统与系统之间盘枝错综、系统本身也是一大堆补丁。国外的民航系统的建设和实践及国内近期的建设理念已经给了我们很大的参考和思路，并且当前的业务发展方向（未来10—20年）也是可预见的，就信息系统建设而言，数据大集中处理，信息协同共享、分布式部署应用已经是建设的趋势。
针对空管系统结构的合理规划，架构设计是重中之重，在保证安全性、稳定性的前提下还需考虑到整体系统可扩展性、前瞻性；本文使用IBM Websphere MQ V7.0、MB V7.0消息中间件来有效的构建整体系统的架构平台，使得系统升级灵活，兼容新老系统过渡，并使用基于内容的消息路由，提供发布订阅通信模式以满足动态需求，提供点对点通信模式满足高可用，既能满足强时序性又能提供分布式，也提供负载均衡模式，以适应未来空管系统的构建和发展。
2 系统平台需要解决的问题（To solve the problem
of system platform）
伴随着世界经济的发展，国际航空运输量在21世纪初有了大幅度的增加，以信息、通信技术为代表的新科技的广泛应用，使空中交通运输和世界经济领域的其他活动一起形成了快速全球化的发展态势。国际民航组织（ICAO）提出“全球空管运行”的新概念，其主要特点是建立共享、交互集成平台，使民航运输参与各方在安全的前提下，提升系统绩效。在此概念基础上，世界许多国家依据自身情况和未来预期开始规划和建立新一代空中交通管理系统，以适应新趋势的发展要求。为了应对航空运输高速发展态势给我们空管带来的全面挑战，除了全面提升传统的保障能力外，还必须加快新技术、新系统的研究和应用，同时还必须逐步把飞行信息服务功能拓展和延伸到各航空相关保障和服务单位。因此，在信息化系统变迁的过程中，传统的系统设计架构已难以适应空管大型运行系统的设计要求，新的系统架构应解决以下问题：
（1）兼容新老系统过渡，系统升级灵活
把未来的新信息系统有机地包容到现有系统中，使现在和未来能自然而有机地结合在一起，实现新老系统的无缝过渡。
（2）可靠的、标准化的通信交互模式
空管的系统种类繁多如电报、雷达、气象、情报、飞行计划等，不同系统的信息交互格式、方式差异很大，无法进行有机地整合，新系统架构平台应提供一套统一、完善、准确的数据交互规范，并从可靠性、安全性、冗余性等方面充分考虑。
（3）减少系统之间的复杂度
面对现有系统“点对点”式的系统架构，若想要增加或移除一些应用功能，真可谓“牵一发动全身”，举步维艰，所以新系统架构就需要具备松耦合，灵活扩展的特点，减少整体系统的复杂度。
（4）使系统之间交互模式由数据共享向服务共享转化
类似于硬件的虚拟化概念，其基础无非就是设备群、数据群、服务群等一层层向上，最终用户并不知道数据源在哪里、那台设备正在为其服务、那个应用服务正在相应他的操作。系统架构平台上的每个子系统或应用模块仅将业务专业部分的功能做专做精，通过服务的订阅能够消费其他系统应用功能服务，降低开发成本和资源。
结合以上问题我们希望能够利用一种成熟、有效的中间件技术，加以二次开发，根据空管业务实际特点，构建一套科学、合理的系统架构平台设计方案，本文选取了IBM Websphere MQ V7.0、MB V7.0消息中间件来有效的构建整体系统的架构平台，并通过实践应用以验证其可行性，为空管系统的建设和发展提供技术依据和服务。
3 WebsphereMQ MB的概述（Overview of
WebsphereMQ MB）
MQ（Message Queue）是IBM消息中间件的一款拳头产品，目的是使得任意两个分布式进程之间能够异步可靠的进行消息传输。MQ是一种以自己的复杂来换取企业应用简单化的基础平台软件。MQ能够支持目前绝大多数的操作系统，Unix、Linux、Windows等，也提供丰富的编程接口（API）包括VB、C、C 、C#、Java、JMS等。MQ提供了基于消息队列的存储转发机制，在7.0版本之后也提供了较为完善的基于主题的发布订阅机制[1]。
MB（Message Broker）是在MQ的基础上发展出来的企业服务总线，其能完成各系统之间的联通性，提供方便的格式转换，具备可配置可编程的智能路由，且能支持基于内容的发布订阅机制。MB安装部署简易，在开发部署上提供友好的图形化界面，通过拖放标准化组件能够快速编程，使用ESQL能够完成简易的逻辑，也可同使用Java来完成复杂逻辑编程。MB支持广泛的通信协议，包括MQ、JMS、HTTP、WebServices；支持广泛的数据格式例如XML、SOAP、CSV、Binary等；无缝集成标准商业数据库Oracle、DB2、SQL Server等[2]。 如果把MQ比作网线，那么MB就相当于路由器，除了有MQ端口之外，还有各种各样的其他接入端口。使用MQ这种业界成熟的消息中间件产品，和MB这样领先的企业服务总线[3]，使得我们能快速的解决信息孤岛的问题。
MQ支持目前主流的两种消息方式，既点对点通信（PTP）与发布订阅通信（Pub/Sub）[4]。
4 MQ/MB在空管系统中的应用（Application of
MQ/MB in air traffic control system）
航班运行协同决策（CDM）系统是民航发展背景下应运而生的新生空管信息系统，其是基于资源共享和信息交互的多主体（空管、机场、航空公司等）联合协同运行的理念，用于创造透明、高效的航班运行环境，是科学管理和决策航班机场放行，提高航班运行正常率的有效技术手段。在该系统中我们将基于MQMB平台的搭建新的系统架构，作为整个系统的基石。
4.1 基于MQ的设计与应用
4.1.1 模型设计
新建协同决策集成平台（MQ： QM_CDM_MEP_01）用于连接各机场，各航空公司，还有现有的空管信息集成平台（MQ： MQ_ATC_MEP_01），关系如图1所示。
针对每个系统为其创建两个队列，一个是输入队列，一个是输出队列，队列的命名规则为ATC/APT/CMP.XXXX.IN.LQ/RQ/TQ与ATC/APT/CMP.XXXX.OUT.LQ/RQ/TQ，ATC开头表示空管，APT开头的表示机场，CMP开头的表示航空公司，XXXX表示空管系统名称、机场代码、航空公司代码，IN表示输入队列，OUT表示输出队列，LQ表示本地队列，RQ表示远程队列，TQ表示传输队列。
而协同决策平台与现有的空管信息集成平台之间通过建立发送方通道与接收方通道来连通。通过远程队列访问对方的本地队列，其中远程队列要访问对端的本地队列需要先通过传输队列。而传输队列又通过自己的发送方通道将消息发送到远端对应的接收方通道。
首先创建一个队列管理器，命名为QM_CDM_MEP_01。
以下给出部分创建命令。
在CMD控制台上，使用命令RUNMQSC QM_CDM_MEP_01连接该队列管理器。
#创建本地队列
DEFINE QLOCAL（APT.ZSPD.IN.LQ）
DEFINE QLOCAL（APT.ZSPD.OUT.LQ）
……
#创建传输队列
DEFINE QLOCAL（ATC.CDM.OUT.TQ）USAGE（XMITQ）TRIGDATA（TO.QM_ATC_MEP_01）INITQ（SYSTEM.CHANNEL.INITQ）
#创建远程队列
DEFINE QREMOTE（ATC.CDM.OUT.RQ）RNAME（CDM.MEP.LQ） RQMNAME（QM_ATC_MEP_01）XMITQ（ATC.CDM.OUT.TQ）
#创建服务器连接通道
DEFINE CHANNEL（SVRCONN）CHLTYPE（SVRCONN）
#创建发送方通道
DEFINE CHANNEL（TO.QM_ATC_MEP_01）CHLTYPE（SDR）CONNAME（‘QM_ATC_MEP_01的IP地址（侦听端口号）’）XMITQ（ATC.CDM.OUT.TQ）
#创建接收方通道
DEFINE CHANNEL（TO.QM_CDM_MEP_01）CHLTYPE（RCVR）
在空管信息集成平台中也需创建对应的发送方通道与接收方通道（方法同上）
4.1.2 验证测试
（1）通信测试
测试两个队列管理器之间的通信。先启动QM_CDM_MEP_01中的发送方通道TO.QM_ATC_MEP_01，然后在ATC_CDM_OUT_RQ中手动放入测试消息，放入成功后，在QM.ATC_MEP_01队列管理器中的CDM.MEP.LQ队列中就能看到刚才放入的测试信息。
（2）性能测试
模拟空管系统、机场系统和航空公司的通信，模拟的消息大小为4kB—8kB。
场景一：航空公司向空管提起请求航班起飞时间，空管系统回复航班起飞时间。
场景二：机场系统实时向空管系统提供航班准备情况，停机位情况。
场景三：空管系统实时发布限制情况。不间断模拟收发7*24小时。
测试结果显示MQ中平均每秒消息流量能够达到5000多条，如图3所示是MQ队列管理器所在服务器在某一时刻的Windows任务管理器的网络流量截图。该消息传输性能足以满足信息交换要求。
4.1.3 小结
本方案不仅为空管、机场和航空公司间的信息集成提供了切实可行的解决方案，也演示了在MQ中如何创建队列管理器、本地＼传输＼远程队列、服务器连接＼发送方＼接收方通道，并通过实际测试证明了该方案是一套高性能、超稳定能够满足生产系统7*24小时持续运行的信息集成平台，从集成平台架构看具备松耦合，灵活扩展的特点，减少整体系统的复杂度，并提供了统一的数据标准。
4.2 基于MB的设计与应用
4.2.1 模型设计
我们重点使用MB基于消息内容的路由、发布订阅机制，模拟三大系统在空管内部的消息交互，主要包括流量系统、塔台系统、CDM平台系统。对于空管信息集成平台而言有三个输入队列FLOW.IN.LQ，CDM.MEP.LQ，TOWER.IN.LQ；每个系统有各自的接收队列FLOW.OUT.LQ，ATC.CDM.RQ，TWR.XXXX.OUT.LQ，其中XXXX为塔台所在机场的ICAO代码。接收队列所订阅的主题详见表1。 首先我们创建队列管理器QM_ATC_MEP_01，并在其中创建队列与预订。预订是在MQ7.0版本才新增的概念，是指预先订阅某种主题（或主题字符串）的消息，将所订阅到的消息放到一个目的队列中。
系统间传输的消息的格式使用XML，为了便于读者理解，在此我们简明定义以下消息格式，发送方在发送的时候需要在DST字段填入目的系统的名字。
下面我们使用MB来完成基于内容的消息路由，路由的依据就是消息中的DST字段。
（1）创建消息流项目
打开MB开发工具Toolkit，在选择菜单栏中的文件→新建→消息流项目，新建消息流项目的名称为ATC_MEP。
（2）创建消息流
选中已建好的消息流项目ATC_MEP，右键选择新建消息流，新建的消息流名称为ROUTE。
首先我们为消息流选择输入队列。在右侧的选用板中的WebSphereMQ栏目中拖入MQInput控件，命名FLOW.IN.LQ。双击MQInput控件FLOW.IN.LQ，在基本一栏中的队列名称中输入FLOW.IN.LQ，在输入消息解析一栏中的消息域中选择XMLNSC。用同样的方法处理CDM.MEP.LQ和TOWER.IN.LQ。
下一步选择消息处理组件和消息发布组件。变换一栏中拖入Compute组件，在其中可以使用ESQL语言用来进行简单的编程；在路由一栏中拖入Publication组件，该组件是用来发布消息到某个特定主题的。
使用连线工具将各个组件连接起来，连接方式如图4所示。
（3）创建代理及发布消息流
在Toolkit左下角Brokers区域中选择新建本地代理，输入代理名称MB_ATC_MEP_01，队列管理器名称QM_ATC_MEP_01，操作系统用户名及密码。在创建代理时需要注意用户名不要超过12个字节，否则会出现发布失败的错误。
创建代理成功之后，将消息流ROUTE拖放到代理MB_ATC_MEP_01下的默认执行组default中，就完成了消息流的发布。此时可以看到在队列管理器QM_ATC_MEP_01下的三个输入队列FLOW.IN.LQ、TOWER.IN.LQ、CDM.MEP.LQ的打开输入计数变为1，表示此时MB已连接这三个队列，从其中取消息。
4.2.2 验证测试
在那三个测试队列中放入测试消息，可以在TWR.ZSPD.OUT.LQ队列中发现该消息，说明消息路由成功。
测试消息：
在多数中间件中如果使用了发布订阅模型，那么消息的消费者希望做负载均衡往往效果不尽如人意。例如浦东塔台的处理程序要是简单的订阅了ZSPD的主题，以后随着浦东的航班量不断地增加，那么原先的处理程序要是出现性能瓶颈想通过多部署一个程序来扩容就有问题了。首先这个新加的程序为了收到同样的数据也需要订阅ZSPD的主题，那么同样一条发送给浦东塔台的数据就会同时发送给了这两个程序，这样一来每个程序处理的量并没有减少，没法起到负载均衡的作用。而我们所做的设计刚好能够解决这类问题，就是利用MQ自身的订阅功能，将订阅到的消息先存放的队列里面，处理程序直接从队列中取数据处理，根据PTP模型的特性，多个程序从队列中消费数据，第一个程序取走后第二个程序就收不到了，假设浦东塔台起了N个处理程序，那么每个程序就只处理了1/N的消息量，快速稳定地实现了处理程序的负载均衡。
4.2.3 小结
该设计方案有以下三大明显优势。
（1）便捷的负载均衡。因为各个塔台系统需要向流量系统提交请求，导致流量系统原先处理程序处理量巨大，我们可以在流量系统的接收队列上起多份相同的程序，以起到负载均衡的作用。
（2）动态增加删除预订。如果浦东塔台测试系统希望收到与正式系统一致的数据，以满足业务测试，在以前则需要去修改我们的路由代码，让其多发一份数据给测试环境，并重新部署，而现在只需要在MQ的预订中新增一条主题ZSPD到队列TWR.ZSPD.TEST.OUT.LQ的预订即可，测试完成后直接删除该预订，不会对其他系统造成任何影响。
（3）快速集成新系统。如果现在有新的一个塔台需要加入到该空管信息集成平台中，那么只需新建一个队列，新增一个预订即可，无需在平台上做任何修改。
5 结论（Conclusion）
本文阐述了MQ、MB的核心概念，以民航空管信息系统建设为背景，使用两种不同的方式展现了多系统跨平台跨语言的信息集成。通过基于MQ/MB中间件进行系统构架平台的设计和应用，有效的验证了该方案的可行性，并符合未来空管系统建设发展的要求，同时也为其他类似实时运行系统的建设提供了一种可行的解决方案。
参考文献（References）
[1] 陈宇翔.精通WebSphere MQ[M].合肥：安徽科学技术出版社，
2004：1-105.
[2] 陈宇翔.精通Websphere Message Broker[M].北京：水利水电出
版社，2007：1-400.
[3] IBM公司.Connecting Your Business Using WebSphere Message
Broker V7 as an ESB[M].2010：1-536.
[4] 许骏，柳泉波，李玉顺.面向服务的网格计算：新型分布式计算
体系与中间件[M].北京：科学出版社，2009：1-340.
作者简介：
蔡永福（1985-），男，本科，助理工程师.研究领域：航空计算
机信息管理.
陈晓建（1966-），男，硕士，高级工程师.研究领域：航空计算
机信息管理.
曹烨琇（1983-），女，本科，工程师.研究领域：航空计算机信
息管理.