【IT168 专稿】
1.概述
现代机场信息化建设中存在多则几十个不同的业务系统，不同的业务系统往往由不同的公司采用不同的标准、不同的接口开发而成，这些业务系统之间存在大量的数据交换，在涉及不同业务系统之间数据交换时，就必须用到EAI技术，在当前SOA架构下的EAI与传统的EAI又有所不同，SOA下的EAI技术是采用企业服务总线ESB的方式，并采用统一的标准接口连接不同的业务系统。
在机场信息化建设中有两个主要的业务模型，一类是发布/订阅，另一类是请求回复，针对这类业务模型，我们选用IBM公司的ESB产品WebSphere Message Broker和WebSphere MQ来构建机场信息化建设的企业服务总线（ESB）平台，并介绍设计过程。
2.企业服务总线ESB的演变
企业服务总线ESB来源于EAI技术，EAI发展到ESB经历过三个阶段：
2.1定制连接，两两互连
最早期的EAI解决方案就是将企业中需要互通信息，共享数据的系统两两桥接起来。桥接的技术也是为两个特定系统专门定制通讯链路来转换这两个系统的接口，协议以及数据格式等差异。
图 1 传统点对点模式
缺点：全部使用专门为两个特定系统定制的连接，在企业系统众多的情况下连接急剧增加，难以开发，后期维护更加困难。剧Gartner Group在2003年4月发布的调查结果显示，大约有35%的企业软件预算用于维护大量已经存在的点对点应用连接上。CIO Insight在2003年2月也提出了类似观点，他们发现维护和管理这些点对点连接平均用去企业IT预算的29%。由于这些专用连接完全互相独立，其只能满足系统两两互连通讯的需求，无法实现涉及多个应用系统的复杂业务流程。
2.2星型(Hub/Spoke)架构
图2
由于两两互连方式具有上述明显缺陷，星型架构的解决方案应运而生。该方式提供一个应用集成中心（hub），这个中心具有自己的连接协议，所有需要集成的系统（spoke）都和该中心相连，同时，该集成中心往往通常也作为某个核心业务系统。原来用户每集成一个系统，都要考虑改系统和其他所有系统的点对点连接的协议数据结构的转换，而在星型架构下，用户只需要考虑系统和集成中心的点对点连接上转换。这样，原来n个系统之间的n * (n-1) / 2个点对点连接减 少为n个连接。
缺点：集中式的结构容易造成效率瓶颈，同时存在单点失效的问题。一旦Server崩溃后，整个系统就都不能运行了。在这种模式下，要达到系统的可扩展性只有通过加入多集成Server，这样就造成了附加的结构和管理上的复杂度。同时，对Hub、适配器、工作流的编程与管理较为昂贵，且重用性较低。
2.3总线型架构
随着IT技术的发展，企业应用集成的需求急剧增加，上述朴素的星型结构已不能很好的满足这些需求，总线型企业服务总线（Enterprise Service Bus）的体系结构逐渐浮出水面。这种体系结构继承了星型（hub-spoke）式体系结构将各个系统点对点连接转化为多个系统对中心的连接的理念。但在这种体系结构中，集成中心被扩展成可以分布在多个物理节点上的总线，从而有效解决了中心——辐条模式的单点失效和效率问题。
图 3总线型架构[ESB/EAI解决方案]
ESB技术并不仅仅是简单的将集成中心被扩展成总线。企业服务总线本身提供各种消息路由，数据转换等各种EAI模式的支持。这种总线一般以成熟的应用集成中间件作为其物理消息传递背板，保证消息在分布式环境下可靠高效的传输。同时，企业服务总线作为应用集成系统的基础框架，大多数采用面向组件的技术，这实际上是SOA的雏形。
与Hub-and-Spoke结构相比，总线结构的可扩展性更好，并且能提供更好的性能表现。由于采用总线形结构，当要集成进一个新的应用时，只要加上一个Adapte插入总线即可，可以做到类似即插即用的功能。对于消息的传送来说，集成Server只是起到一个控制的作用，真正的传输是在信息总线上，这样集成Server的负荷就轻了许多。
另外，ESB体系机构中往往包含商业流程管理（BPM）和商业活动监控（BAM）模块的实现。BPM作为ESB的消费者，可以将总线上的各个服务（或组 件，适配器等）按照用户需要的商业逻辑组装起来，使这些服务按照业务逻辑顺序执行，从而实现用户完整的业务功能。而BAM提供对整个ESB，ESB上的服 务和BPM的运行状态进行监控和管理。
SOA（面向服务的体系架构）
图 4 面向服务的体系架构
面向服务的体系架构（Service Oriented Architecture）是目前EAI领域非常先进的体系结构。实际上，SOA的提出在很大程度上就是为了更好的满足企业应用集成的需求。SOA强调复用和松偶合，注重接口及其标准化描述，这些都为企业应用集成规划了非常好的框架体系结构。除了具有前面ESB结构的优点之外，基于SOA的应用集成系统具有 更好的可扩展性和灵活性，用户可以在对已有系统影响最小的情况下开发应用新的业务模块（服务）或修改已有模块，从而快速满足业务需求的变化。
本质上说，SOA架构对应用集成的基本要求有以下几点：
SOA在相对较粗的粒度上对应用服务或业务模块进行封装与重用。这是对服务提供者本身的要求。
服务间保持松散耦合，基于开放的标准，服务的接口描述与具体实现无关。这是从服务消费者的角度应该看到（了解）的服务提供者的样子。
灵活的架构-服务的实现细节，服务的位置乃至服务请求的底层协议都应该透明。这是对服务消费者消费服务提供者提供的服务的方式的要求。基于SOA架构的EAI产品一般使用企业服务总线（ESB）来满足（实现）这一要求。
可以看到，SOA的体系结构一般来说也需要企业服务总线的支撑，只是它对总线上的服务和总线本身的作用和位置有着更加明确的要求。
好的符合SOA的EAI系统也同样整合了对BPM和BAM的支持。这里特别要指出的是，在符合SOA的EAI系统中对BPM的支持具有更多优点。在传统 ESB系统中，BPM往往是厂家相关的专门模块，这一模块存在于ESB之上并且是不可替换的。而在符合SOA的EAI系统中，BPM模块也作为一种服务 （编排服务）其本质上和其他服务没有差别，这使得用户选择多种服务编排方式（即不同的BPM实现）成为可能。
3.现代机场信息化建设需求
现代民航机场信息化建设的需求越来越紧迫，纵观国内整个民航业的各个主要环节，机场的信息化程度相对较差。从2006年起，机场对于信息化建设的水准更加重视，开始重视市场营销，通过整合电子商务、离港、旅客、气象等系统的数据，提升调配资源和管理水平。2006年呈现的趋势表明，机场信息化的建设正在从运营信息化向管理信息化发展，其中一个标志就是机场的数据整合正在逐渐展开，即通过企业服务总线把机场各系统中的分散的数据整合起来，从而为提升管理信息化的水平打下基础。
机场ESB信息建设需要整合的系统有生产系统、航显系统、离港系统、安检系统、广播系统、闭路电视系统、内通系统、楼控系统、停车场系统、Internet系统、时钟系统、行李系统、机场GIS系统、气象系统、电子商务系统。这些系统的建设年代、所用的技术标准、应用程序接口方式和数据格式都存在不统一的问题，各信息系统成为一个个的信息孤岛，为提高机场运行效率，这些IT系统需要进行信息整合，利用IBM WebSphere Message Broker V6.x可以很好地满足这种需求，实现如下几个功能：
协议转换
数据格式转换
数据路由
事件与事务的支持
4.机场信息ESB的设计
4.1概述
根据机场信息化应用的具体需求，我们设计了两种ESB功能应用，分别是PUB/SUB和请求/回复，根据这种应用，ESB架构设计如图5所示
图 5 ESB平台总体架构
整个ESB的功能架构在逻辑上分为两层，即信息交互层，应用整合层。
其中：
信息交互层：采用ESB适配器针对企业现有的大量应用和数据，提供接入服务，简单的说就是为各应用系统、弱电子系统、外部系统提供与ESB的接口。具体实现拟采用消息中间件Websphere MQ 6.0作为ESB平台的基础平台。
应用整合层：在信息交互层能够满足机场内各类交互的基础之上，进一步对机场各应用系统、弱电子系统、外部系统在信息、应用上进行整合，完成各类信息在交互过程中涉及的格式转换、内容路由等问题，在提高信息交互层性能的同时，基于面向服务的思想构建信息流程，为机场实施业务流程整合以及门户整合预留接口。其实现主要通过IBM中间件IBM WebSphere Message Broker，其应用模式主要采用发布/订阅(PUB/SUB)模式，请求/应答模式(REQ/RESP)以及可定制的服务单元模式。
4.2实现模式
发布/订阅模式
发布/订阅模式是消息应用程序的一种，在这种模式下消息的发布者与消息的订阅者之间的关系是松耦合的。在发布/订阅系统中，发布者不需要知道谁会来使用它所提供的信息，而且订阅者也不需要知道谁来提供它需要的信息源。而对比其它应用模式，发送消息的应用程序需要知道消息所发往的目的地。所以说，在发布/订阅模式下，可以使系统动态地增长或缩减。
通过WEBSPHER MESSAGE BROKER实现PUB/SUB主要涉及到以下几个概念：
发布者（Publisher）：信息的提供者被叫做发布者。发布者为每个消息都赋予一个主题，但他并不知道目的应用对哪种主题的消息感兴趣。
订阅者（Subscriber）：订阅者决定它对哪种主题的信息感兴趣，然后接收该主题的消息。每个订阅者可以从多个消息发布者得到消息，他们收到消息也可以发布给其他的订阅者。
主题（Topic）：发布者和订阅者之间通过主题来建立联系。用于PUB/SUB目的的消息都要求有一个主题。
代理（Broker）：代理负责发布者和订阅者之间的交互工作。它从发布者那里接收消息，从订阅者那里得到订阅消息的请求，然后负责把消息从前者到后者的路由。
在一个大的系统中的某些子系统，在不确定从何处接收消息或发送消息的时候，在复杂的应用场合中，通讯程序之间不仅是一对一的关系，还可以是一对多或多对一，甚至是多对多的关系，那么在这样复杂的情况下，通讯的连接增加了程序复杂性，所以可以在系统中使用发布/订阅模式，来对用户屏蔽掉多变的连接的情况，使应用程序更为简单，屏蔽掉了网络的变化，并且提供了更大的网络独立性。而且由于减少了通讯连接，那么也使系统更加容易来管理。
PUB/SUB的原理是：一个发布会被发布者发送到代理上，一个订阅会从订阅者发送到代理上，并且发布也会从代理上发送到订阅者上。而且在一个典型的发布/订阅系统是包含有多个发布者和多个订阅者的，甚至有多个代理（这是考虑到连接性能的时候需要的），还有可能一个应用既是发布者又是订阅者，那么在这种情况下，发布/订阅的系统架构一般是下面图所示：
图 6 发布/订阅模式
该应用模式是机场内各类应用系统信息交互的主要应用模式，以航班动态发布为例：
生产系统应用程序通过适配器将航班动态消息发送至信息交互层，而无需指定消息的使用者；
航显、行李等其它应用系统可通过信息交互层向应用整合层订阅航班计划，一旦订阅成功，则每当生产系统发布了航班动态，航显、行李等系统将会自动接收到该航班动态信息的副本，而对于这些系统也无需知道该消息的源头。
请求/回复模式
请求/回复模式包括两个过程：一是发送消息并期待回复（换言之，就是发送请求消息，也可通过发布过程发送请求），另一则是在收到请求消息后发送回复消息。系统或应用程序发出请求消息并等待回复消息。响应方使用请求消息，生成一个回复消息，再将其送回发起方。发起方收到回复消息时就标志着消息流的完成。
请求/回复模式在本架构的应用，MQSeries 提供了利用关联性ID 识别请求消息及其回复消息的便利。关联性ID 由发出请求消息的应用程序进行设置。生成回复消息的应用程序将关联性ID 从请求消息中拷贝到回复消息中，并将其送回原先发出请求消息的应用程序。发送请求消息的应用程序可以利用关联性ID 将回复消息映射到请求早先发出的消息上。
在这个模式中，请求和响应是单个请求／答复操作内定义的两条消息，并作为两个独立无关的传输层传送发送。
图 7 请求/回复模式
该应用模式作为发布/订阅模式的补充，将有效解决特定情况下可能产生的消息丢失或信息不同步而给应用系统带来的影响。以航班状态为例，生产系统针对当天的某一航班会根据航班状态发布多条状态信息，此时，对于当前的应用系统（如航显）即可逐条接收航班状态信息，也可通过请求的方式向信息交互层发送请求信息，生产系统收到该请求信息后，将会把该航班的最新的航班动态发送至该应用系统。该模式可有效解决机场内各应用系统数据不同步等问题。
4.3可定制的服务单元模式
为了使机场业务环境具有灵活的基础架构和处理环境，EAI平台还需要支持面向SOA扩展的能力，为此，自需求分析、信息交互平台的设计、消息格式的定义都必须考虑到未来的扩展，达到机场各应用系统之间最大程度的松耦合，我们可运用WebSphere MB高效的消息格式转化、消息路由等功能，采用面向服务的设计思想，将现有业务定义为一个个独立的“原子服务”（最小功能集），通过对“原子服务”进行组合构造“组合服务”，通过“服务字典”查询相关服务的定义，随着业务的更改或者客户对服务需求的变更，原先定义的原子服务并不需要变更，只需将变化后的服务重新组装、或在现有组合服务的基础之上修改成为新的“组合服务”既可。
如：将生产系统的进港航班和出港航班动态发布分别定义为一个独立的原子服务，航班动态发布定义为一个包含进港航班和出港航班的组合服务。对于只关心出港航班的应用系统（如行李系统）只需请求一个原子服务，即出港航班动态发布，而对于即关心出港，又关心进港航班的应用系统（如航显系统）在请求时，指定请求的是“航班动态”，请求发送后，EAI应用集成平台会通过查询服务字典获得这项组合服务的定义，然后并行的通过两条数据传输消息流将其所需要的进港及出港航班动态信息获得并传输给航显系统。
图 8 可订制的服务单元应用架构
4.4功能组件
信息交互层
信息交互层采用IBM Websphere MQ开发，MQ是IBM功能强大的消息传送中间件产品，它以其成熟的技术和世界领先的产品向我们提供了在今天异构网络环境中实现消息传送的经济、可靠且易于使用的解决方案。它是目前唯一能保证您的数据稳定可靠而且无丢失或重发的产品，曾被PC MAGAZINE誉为：MQ是世界上最成功的软件之一。目前市场占有率为 消息类中间件的87%，已经成为事实上的行业标准。在企业的各类应用中承担了可靠的信息数据传输的基础支撑。
MQ基本由一个信息传输系统和一个应用程序接口组成，其资源是信息和队列(Messaging and Queuing)。
信息:一个信息包含两个因素：信息描述(用于定义诸如信息传输目标等)和数据信息(如应用程序数据或数据库查询等)。程序之间的通讯通过传递信息而非直接调用程序。
队列:一个安全的信息存储区。因为信息存放在队列中，所以应用程序可以相 互独立的运行，以不同的速度，在不同的时间，在不同的地点。
信息传输系统：用于确保队列之间的信息提供，包括网络中不同系统上的远程队列之间的信息提供。并保证网络故障或关闭后的恢复。
应用程序接口：应用程序和信息系统之间通过MQSeriesAPI实现的接口MQSeriesAPI在所有MQSeries平台上是一致的。API只有11个调用，2个关键动词：发送(PUT)和接收(GET)。
在信息交互层各应用系统采用客户端/服务器的模式与Websphere MQ 服务器相连，客户端使用MQ动态链接库开发或采用相应的适配器，通过MQI，或JMS接口访问Websphere MQ Server上的消息队列。如下图所示。
图 9 MQ客户端/服务器应用
应用整合层
应用整合层主要通过IBM WebSphere Message Broker 实现， MESSAGE BROKER采用WebSphere MQ提供的可靠消息服务（不丢失，不复传）在应用系统之间通过基于消息的异步方式集成各应用系统。针对不同系统所处理的消息格式各不相同的特点，MESSAGE BROKER 提供了专门的格式代码转换器(Formatter)在不同的消息格式之间按照预先定义好的转换规则进行自动的格式转换，然后将结果自动路由到目标应用系统。在消息转换的过程中MESSAGE BROKER能够识别XML，C结构，JMS，SOAP等多种消息格式；对消息的各种操作包括消息的来源、消息的目标应用、所期望的消息格式等通过定义各种操作规则(Rules)进行。其功能组件如下图所示：
图 10 应用整合层功能组件
MESSAGE BROKER TOOLKIT[工具集]：MESSAGE BROKER TOOLKIT是开发与部署消息流、消息集应用程序的工具集，它与配置管理器进行通信，以将消息流和消息集部署到一个或者多个BROKER上。
BROKER DOMAIN[代理域]：可以将代理分组为代理域，每个代理域由一个配置管理器协调。
BROKER [代理]：作为应用整合层的核心组件，同时也是作为WEBSPHERE MB的核心组件，主要是基于消息流和消息集处理消息，消息流描述在将入局消息发送到最终目的地之间要在其上执行的操作以及执行的顺序；消息流在执行组上运行。代理可以存在多个。
USER NAME SERVER[用户名称服务器]：是一个可选组件，主要用在PUB/SUB模式下，通过它可以设定应用程序是否具备发布或者订阅某个主题的权限，其主要是提供主题一级的权限控制。
CONFIG MANAGER[配置管理器]：由系统管理员在服务器上创建，主要用来协调MESSAGE BROKER TOOLKIT与其域中的代理之间进行通信、监控部署在BROKER上的消息流的状态。每个配置管理器都有相应的存储单元以存储BROKER DOMAIN的相关配置管理信息。
EXECUTE GROUP[执行组]：可以通过执行组将一个BROKER上的多个消息流组织在一起，一个执行组作为Broker 上的一个进程，可以将多个消息流部署在同一个执行组上以提高效率。
ODBC[ODBC连接器]：作为应用整合层与数据库之间的连接器，可以通过ESQL或者JAVA编程接口与数据库进行交互。
上述各类组件之间通过MQ进行连接并通信，同时，MB与各应用系统之间的通信也可通过MQ进行连接。
5.总结
利用基于IBM WebSphere Message Broker V6.x和WebSphere MQ 6.x可以很好地实现现代民航机场信息化企业服务总线建设需求，WebSphere Message Broker除了在本文中应用所提到的实现PUB/SUB、请求/回复数据路由等基本ESB的功能，还具备强大的数据格式的转换能力，如实现机场与海关等其他单位之间不同报文的转换。
