航空公司ESB 案例解析通过企业服务总线、接口适配器、服务注册管理等整合技术，实现将企业内部现有的各应用系统之间的信息共享，提高企业内部应用系统的数据共享和交换效率，提升企业在市场上的综合竞争力和客户服务质量，是所有企业的一个典型需求。

本文将以航空公司的案例为基础，说明采用IBM ESB 相关产品整合航空公司电子商务、常旅客、航班动态、呼叫中心等系统的解决方案。

与其他行业一样，在民航业，国际和国内的主要航空公司内部也分布着众多已建和在建的用以支撑业务运行的IT 系统，这些系统之间缺乏对信息共享性、系统兼容性和接口标准规范的统一考虑，造成系统之间的连接比较困难，应用和数据无法得到全面共享，系统间“蜘蛛网状”的连接普遍存在。

随着新系统的不断建设，在业务与流程方面的整合将会因系统和业务领域间的信息沟通障碍而面临越来越多的困难，对航空公司的整体发展战略带来制约。

下面我们就来列举几个民航业的现状，以此说明对企业进行业务整合的必要性。

现状一：业务系统间数据共享需求强烈总体来看，航空公司的IT 分为商务、航务、机务和管控四大体系，其中商务体系中包括定座系统、电子客票销售系统、离港系统、电子商务系统、常旅客系统、大客户系统、呼叫中心系统、运价收益管理系统、地面服务系统等。

在这个庞大的体系结构中，存在着巨大的系统间数据集成和共享的需求。

主要存在以下三类信息的共享：航班数据共享：航班数据包括航班计划、航班动态、飞机参数等数据，是保障航空公司正常运营的最基本信息，而航空公司内部通常都会有超过10 个的系统需要获取航班数据，其中包括：电子商务系统、呼叫中心系统、常旅客系统、地服系统、联盟成员系统等。

目前，航班数据的源数据系统( 一般来自航空公司运控AOC 系统) 与其他业务系统之间的数据交换和共享都是通过点对点单独开发接口的形式实现的，比如通过数据库视图的紧耦合的方式实现，这在增加各个系统接口复杂性的同时也增加了系统开发的周期和费用，而且各业务系统无法从统一的渠道获取航班数据，造成了各业务系统之间数据不一致，如下图所示：图 1. 航空公司航班数据共享客户主数据共享：根据不同的直销、分销渠道以及不同的客户属性，航空公司的客户信息通常被分散地存储在多个不同的客户服务系统中，其中包括常旅客系统、大客户系统、电子商务系统等，这些现有系统或多或少地通过点到点的星型结构的接口方式进行了一些互连，在一定程度上实现了客户数据共享，但是仍普遍存在连接混乱、各系统间数据更新频率不一致、各系统内同一旅客基本信息不统一等问题，借鉴其他行业在客户主数据管理方面的发展趋势和最佳实践，因此航空公司需要对客户主数据进行统一存储和一致性管理，这就需要完成呼叫中心、电子商务、大客户、常旅客等系统与客户主数据系统之间的集成，希望通过ESB 技术实现上述系统间数据的实时同步，如下图所示：图 2. 航空公司客户数据共享客票销售和客户服务信息共享：在航空公司的直销渠道中，电子商务与呼叫中心是非常重要的两大直销渠道，各自拥有独立的业务支持系统，以这两个系统为例，国内各个航空公司拥有的电子商务与呼叫中心这两个应用系统之间后台基本没有任何数据共享，在业务和应用上完全独立，如下图：图 3. 呼叫中心和电子商务系统渠道分离而实际上这两个系统之间存在着非常多的来自业务的数据共享需求。

例如：当客户在互连网上完成了全部订座功能，希望能够在呼叫中心完成改期升舱、退票退款等操作；而如果客户在呼叫中心渠道上完成了全部订座功能，或者在呼叫中心完成改期升舱、退票、退款操作后，也希望能够在互连网上进行状态查询，如下图所示：图 4. 呼叫中心和电子商务系统间数据共享因此这两个系统希望共享客票销售数据、客票服务数据( 对于升舱、改期、退票、退款、订单追踪、邮寄行程单等客票服务流程的相关数据) 以及销售业绩管理等进行共享，从而实现航空公司的两大直销渠道之间在销售与服务流程上的统一和客户体验的统一，增加客户满意度和客户服务水平。

现状二：缺乏技术先进的、统一的、标准的IT 集成架构在以往各个系统的建设当中，都是采用传统的点对点的联接方式，导致了一个复杂的网状结构，其弊端在于系统接口众多，系统间造成密切的耦合性，某一个系统接口的修改导致其他所有系统的修改；系统没有扩展性，每新增一个系统就需要开发该系统和其他相关所有系统的接口；系统的后期维护成本过高。

没有建立起统一的数据交换平台和数据交换标准。

各系统之间根据自己的需要获取数据，存在着格式上、内容上、或者统计口径上的差异。

以航空公司电子商务系统为例，电子商务系统与周边业务系统的集成需求如下：表 1. 航空公司电子商务与外围系统集成举例需要集成的系统待交换的数据通讯协议数据格式定座/ 离港(GDS/DCS)•Booking•Fare Query•Available QueryTTL: TCP/IPOthers:TCP/IP**TTL: MATIPOthers: XML**运价管理系统•Fare Query JMS N/A常旅客系统•SSO•User information•Award Redemption HTTP SOAP (WebServices)电子支付系统•Authorization HTTP XML•Payment•CancelFare Management* •Fare Rule N/A N/A呼叫中心系统•Booking•SearchingHTTP/MQ XML/SOAP国际联盟系统•Dynamic FlightInformation HTTP SOAP (WebServices)客户主数据系统•Customer information Web Service XML/SOAP上表中，我们粗略列举了航空公司电子商务系统与其各主要相关系统间交换的业务数据内容，以及通讯协议和数据格式，我们可以看出其复杂性，如果没有一个统一的集成平台的支撑，那么数据格式转换、通讯适配器的开发、传输可靠性保证等问题都需要依赖于自主开发，其风险是不言而喻的。

航空公司商务体系ESB 整合方案总体方案概述SOA （面向服务的架构）是当今国外各大航空公司率先考虑的方法论并成为提升下一代提升航空运输服务的能力引擎，它使IT 部门可以搭建灵活的可配置体系以支持随需应变的航空业务。

鉴于航空公司商务体系建设中存在的这些问题，以及业界的最佳实践，我们提出采用ESB 整合航空公司的商务体系，其总体架构如下图所示：图 5. 航空公司商务体系集成架构总体系统架构主要由展现层、核心应用层和SOA 核心能力层组成，其中通过门户实现统一用户接入，该模块主要包含用户帐户信息管理和存储、用户登录身份认证和访问请求负载均衡等部分。

核心应用层包括电子商务系统、呼叫中心系统、常旅客系统、大客户系统等商务体系中的所有重要的业务系统。

SOA 核心能力层由企业服务总线、服务管理和注册库以及组合服务运行引擎三部分组成。

其中，企业服务总线(ESB) 是SOA 核心能力层的一个中心组件，它负责接入各种服务资源，通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问，以星形结构替代了原来各服务之间的点对点结构，极大地优化了系统连接架构，降低了系统集成的复杂度。

企业服务总线下方连入的各个应用系统是航空公司内部的各个业务系统，而右边是要连接的一些外部系统。

组合服务运行引擎通常运行在标准的流程引擎之上，例如BPEL 流程引擎，不是本文的重点，在此就不再赘述了。

ESB 的组件及产品映射模型。

ESB 组件模型及产品映射模型如图6：图 6. 航空公司ESB 组件模型其中包括ESB 组件、服务注册和管理组件以及ESB 的监控和管理组件3 部分组成。

ESB 组件：实现消息传递、服务路由、格式转换、交易完整性保证、数据解析和处理、安全传输、应用适配、协议转换等功能，可以由WebSphere Message Broker 实现。

服务注册和管理：为ESB 提供服务管理容器，借助科学的方法论，对航空公司的业务需求进行分析，对其商务体系的业务流程进行梳理，建立起航空公司商务体系的服务目录和服务库，对这些服务以及服务的元数据进行定义和存储，以便进行服务的查找、发布、注册和管理。

该组件可以由WebSphere Service Registry and Repository（WSRR）来实现，将所暴露的服务注册在WSRR 中，便于其他系统发现和调用。

ESB 监控和管理：ESB 是应用集成的枢纽，各个应用之间的信息和服务共享都将通过ESB 来进行，因此，ESB 平台本身的监控和管理的重要性是不言而喻的。

全面、及时的服务监控功能除了能够辅助快捷的故障诊断，还能够提供完整的服务质量评估报告，以衡量现有的应用系统效率，并为优化、升级提供指导。

服务监控需要包括服务、操作等级别的调用/ 失败次数、响应时间等信息，并且在超过设定值的情况下能够报警。

该组件由Tivoli Omegamon XE for Messaging 实现，Tivoli Omegamon XE for Messaging 能够实现对IBM WebSphere Message Broker 以及底层MQ 的资源的自动发现并进行自动监控，帮助管理员及时发现故障和故障隐患。

组件交互模型以前面描述的电子商务系统和呼叫中心之间的订单交互为例，其组件交互模型如下：图7. 航空公司ESB 组件交互模型该模型描述了客户在呼叫中心预定了机票（产生订单），然后通过电子商务(B2C) 系统修改订单时通过ESB 实现系统间订单交互的场景。

ESB 的接口设计图8. 航空公司ESB 接口设计在上图中，我们给出了某航空公司的一个示例。

在这个例子中，我们看到其电子商务系统、航班信息发布系统、客户主数据系统都是采用Web Service/ 实时/XML 接口；呼叫中心采用socket/实时/文本、WebService/实时/XML 接口；常旅客系统采用FTP/批量/ 文本、WebService/实时/XML 的接口；大客户系统采用Database 的接口形式。

基于接口的数据格式的不同，与ESB 相关的系统可以分为以下两类：基于XML 报文的应用系统：基于XML 报文交互是比较理想的方式，是目前业界较为推荐的标准方式。

需要说明的是，尽管都采用XML 标准，由于各个系统的需求的差别已经建设周期的不同，不同的应用系统采用的XML 消息很难完全兼容。

这需要由ESB 实现相应的转换。

基于专有报文/自定义报文的应用系统：基于专有报文的应用系统，如国内的定座系统，可以先保留现有的报文格式，由ESB 实现现有格式与其他报文格式以及XML 格式之间的转换。

随着未来条件的成熟，这些系统逐步过度到通过XML 实现与ESB 以及其他应用系统的集成。