ESB案例解析和综合项目实施经验分享.doc

ESB案例解析和项目实施经验分享
导读：本文从业务角度列举了航空企业商务体系建设中对ESB经典需求举例，并介绍了航空企业ESB总体方案、组件模型、接口设计、物理布署和包含到IBM软件产品。
关键词：ESB 企业服务总线 ESB案例 物理布署
　　本文是一个由3部分内容组成系列文章，在前2部分，介绍了两个企业ESB处理方案设计案例，这两个案例分别来自于交通运输行业和制造行业，我们针对不一样行业业务和应用特点设计了不一样ESB处理方案。第3部分内容我们将向您介绍ESB项目实施部分方法论和经验。
　　序言
　　一个实际ESB项目实施成败，不仅要求我们把产品用熟用好，即熟悉ESB产品配置、开发及优化操作，还需要制订正确、量体裁衣式处理方案，而且需要借助科学项目实施方法论，从需求分析、方案设计、产品开发、测试、上线运行等各个方面进行全方面考虑。本系列文章将分为三部分，第1部分和第2部分将结合两个不一样行业案例来介绍两个含有鲜明行业特点ESB处理方案，第3部分则将针对ESB项目标实施过程给出部分提议。
　　航空企业ESB案例解析
　　经过企业服务总线、接口适配器、服务注册管理等整合技术，实现将企业内部现有各应用系统之间信息共享，提升企业内部应用系统数据共享和交换效率，提升企业在市场上综合竞争力和用户服务质量，是全部企业一个经典需求。本文将以航空企业案例为基础，说明采取IBM ESB相关产品整合航空企业电子商务、常旅客、航班动态、呼叫中心等系统处理方案。
　　航空企业ESB需求举例
　　和其它行业一样，在民航业，国际和中国关键航空企业内部也分布着众多已建和在建用以支撑业务运行IT系统，这些系统之间缺乏对信息共享性、系统兼容性和接口标准规范统一考虑，造成系统之间连接比较困难，应用和数据无法得到全方面共享，系统间“蜘蛛网状”连接普遍存在。伴随新系统不停建设，在业务和步骤方面整合将会因系统和业务领域间信息沟通障碍而面临越来越多困难，对航空企业整体发展战略带来制约。
下面我们就来列举多个民航业现实状况，以此说明对企业进行业务整合必需性。
现实状况一：业务系统间数据共享需求强烈
　　总体来看，航空企业IT分为商务、航务、机务和管控四大致系，其中商务体系中包含定座系统、电子客票销售系统、离港系统、电子商务系统、常旅客系统、大用户系统、呼叫中心系统、运价收益管理系统、地面服务系统等。在这个庞大体系结构中，存在着巨大系统间数据集成和共享需求。关键存在以下三类信息共享：
　　航班数据共享：
　　航班数据包含航班计划、航班动态、飞机参数等数据，是保障航空企业正常运行最基础信息，而航空企业内部通常全部会有超出10个系统需要获取航班数据，其中包含：电子商务系统、呼叫中心系统、常旅客系统、地服系统、联盟组员系统等。现在，航班数据源数据系统（通常来自航空企业运控AOC系统）和其它业务系统之间数据交换和共享全部是经过点对点单独开发接口形式实现，比如经过数据库视图紧耦合方法实现，这在增加各个系统接口复杂性同时也增加了系统开发周期和费用，而且各业务系统无法从统一渠道获取航班数据，造成了各业务系统之间数据不一致，以下图所表示：

图1. 航空企业航班数据共享
用户主数据共享：
　　依据不一样直销、分销渠道和不一样用户属性，航空企业用户信息通常被分散地存放在多个不一样用户服务系统中，其中包含常旅客系统、大用户系统、电子商务系统等，这些现有系统或多或少地经过点到点星型结构接口方法进行了部分互连，在一定程度上实现了用户数据共享，不过仍普遍存在连接混乱、各系统间数据更新频率不一致、各系统内同一旅客基础信息不统一等问题，借鉴其它行业在用户主数据管理方面发展趋势和最好实践，所以航空企业需要对用户主数据进行统一存放和一致性管理，这就需要完成呼叫中心、电子商务、大用户、常旅客等系统和用户主数据系统之间集成，期望经过ESB技术实现上述系统间数据实时同时，以下图所表示：

图2. 航空企业用户数据共享
客票销售和用户服务信息共享：
　　在航空企业直销渠道中，电子商务和呼叫中心是很关键两大直销渠道，各自拥有独立业务支持系统，以这两个系统为例，中国各个航空企业拥有电子商务和呼叫中心这两个应用系统之间后台基础没有任何数据共享，在业务和应用上完全独立，以下图：

图3. 呼叫中心和电子商务系统渠道分离
而实际上这两个系统之间存在着很多来自业务数据共享需求。比如：当用户在互连网上完成了全部订座功效，期望能够在呼叫中心完成改期升舱、退票退款等操作；而假如用户在呼叫中心渠道上完成了全部订座功效，或在呼叫中心完成改期升舱、退票、退款操作后，也期望能够在互连网上进行状态查询，以下图所表示：

图4. 呼叫中心和电子商务系统间数据共享
所以这两个系统期望共享客票销售数据、客票服务数据（对于升舱、改期、退票、退款、订单追踪、邮寄行程单等客票服务步骤相关数据）和销售业绩管理等进行共享，从而实现航空企业两大直销渠道之间在销售和服务步骤上统一和用户体验统一，增加用户满意度和用户服务水平。
　　现实状况二：缺乏技术优异、统一、标准IT集成架构
　　在以往各个系统建设当中，全部是采取传统点对点联接方法，造成了一个复杂网状结构，其弊端在于系统接口众多，系统间造成亲密耦合性，某一个系统接口修改造成其它全部系统修改；系统没有扩展性，每新增一个系统就需要开发该系统和其它相关全部系统接口；系统后期维护成本过高。没有建立起统一数据交换平台和数据交换标准。各系统之间依据自己需要获取数据，存在着格式上、内容上、或统计口径上差异。
　　以航空企业电子商务系统为例，电子商务系统和周围业务系统集成需求以下：

　　表1. 航空企业电子商务和外围系统集成举例
　　上表中，我们粗略列举了航空企业电子商务系统和其各关键相关系统间交换业务数据内容，和通讯协议和数据格式，我们能够看出其复杂性，假如没有一个统一集成平台支撑，那么数据格式转换、通讯适配器开发、传输可靠性确保等问题全部需要依靠于自主开发，其风险是不言而喻。
　　航空企业商务体系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和其它应用系统集成。
　　基于接口通讯协议不一样，和ESB相关系统能够分为以下四类：
　　基于Web Services系统：基于Web Services系统，比如现在呼叫中心和电子商务系统全部能够提供这种方法，能够使用SOAP/HTTP（S）和ESB实现整合。
　　基于FTP/Socket应用系统：需要经过FTP交换数据系统，如FFP系统等，ESB能够直接支持FTP方法。ESB缺省提供文件适配器，其中就能够支持当地文件和远程文件经过FTP方法读写。
　　基于数据库应用系统：基于数据库系统，如大用户系统、数据仓库系统，能够经过JDBC适配器和ESB集成。
　　基于传统应用连接系统：对于这类系统能够经过定制Adapter和ESB和其它应用实现整合，该Adapter能够以Java实现。其次，也能够经过XML/MQ实现和ESB集成，这时，这些传统应用系统将调整为面向消息方法。使用MQ作为一个通用Adapter和ESB和其它应用实现整合，消息格式能够逐步由现有专有报文转变为基于XML标准报文。
　　ESB物理布署
　　整个ESB方案物理布署配置举例以下：

图9. 航空企业ESB物理布署示例
提议采取两个节点同时安装WebSphere Message Broker和WSRR。其中将WebSphere Message Broker配置为Cluster，将WSRR配置为HA方法，采取一台PC Server或PC机作为监控管理服务器，安装Tivoli Omegamon for Messaging，实现对Message Broker监控。未来需要步骤集成时，能够采取两个节点安装WebSphere Process Server组成Cluster。
　　小结
　　本文从业务角度列举了航空企业商务体系建设中对ESB经典需求举例，并介绍了航空企业ESB总体方案、组件模型、接口设计、物理布署和包含到IBM软件产品，介绍了怎样利用ESB将呼叫中心、电子商务、常旅客、大用户、航班动态公布平台等应用系统进行高效整合，达成航班信息、旅客信息、客票销售信息等关键业务数据共享，从而提升航空企业用户服务水平。
　　相关作者
　　娄丽军，IBM软件部软件架构技术支持，曾参与交通运输、电信等行业多个SOA软件项目标设计和实施。