ESB案例解析和项目实施经验分享docWord文件下载.docx
《ESB案例解析和项目实施经验分享docWord文件下载.docx》由会员分享，可在线阅读，更多相关《ESB案例解析和项目实施经验分享docWord文件下载.docx（61页珍藏版）》请在冰豆网上搜索。
图1.航空公司航班数据共享
客户主数据共享：
根据不同的直销、分销渠道以及不同的客户属性，航空公司的客户信息通常被分散地存储在多个不同的客户服务系统中，其中包括常旅客系统、大客户系统、电子商务系统等，这些现有系统或多或少地通过点到点的星型结构的接口方式进行了一些互连，在一定程度上实现了客户数据共享，但是仍普遍存在连接混乱、各系统间数据更新频率不一致、各系统内同一旅客基本信息不统一等问题，借鉴其他行业在客户主数据管理方面的发展趋势和最佳实践，因此航空公司需要对客户主数据进行统一存储和一致性管理，这就需要完成呼叫中心、电子商务、大客户、常旅客等系统与客户主数据系统之间的集成，希望通过ESB技术实现上述系统间数据的实时同步，如下图所示：
图2.航空公司客户数据共享
客票销售和客户服务信息共享：
在航空公司的直销渠道中，电子商务与呼叫中心是非常重要的两大直销渠道，各自拥有独立的业务支持系统，以这两个系统为例，国内各个航空公司拥有的电子商务与呼叫中心这两个应用系统之间后台基本没有任何数据共享，在业务和应用上完全独立，如下图：
图3.呼叫中心和电子商务系统渠道分离
而实际上这两个系统之间存在着非常多的来自业务的数据共享需求。
例如：
当客户在互连网上完成了全部订座功能，希望能够在呼叫中心完成改期升舱、退票退款等操作；
而如果客户在呼叫中心渠道上完成了全部订座功能，或者在呼叫中心完成改期升舱、退票、退款操作后，也希望能够在互连网上进行状态查询，如下图所示：
图4.呼叫中心和电子商务系统间数据共享
因此这两个系统希望共享客票销售数据、客票服务数据（对于升舱、改期、退票、退款、订单追踪、邮寄行程单等客票服务流程的相关数据）以及销售业绩管理等进行共享，从而实现航空公司的两大直销渠道之间在销售与服务流程上的统一和客户体验的统一，增加客户满意度和客户服务水平。
现状二：
缺乏技术先进的、统一的、标准的IT集成架构
在以往各个系统的建设当中，都是采用传统的点对点的联接方式，导致了一个复杂的网状结构，其弊端在于系统接口众多，系统间造成密切的耦合性，某一个系统接口的修改导致其他所有系统的修改；
系统没有扩展性，每新增一个系统就需要开发该系统和其他相关所有系统的接口；
系统的后期维护成本过高。
没有建立起统一的数据交换平台和数据交换标准。
各系统之间根据自己的需要获取数据，存在着格式上、内容上、或者统计口径上的差异。
以航空公司电子商务系统为例，电子商务系统与周边业务系统的集成需求如下：
表1.航空公司电子商务与外围系统集成举例
需要集成的系统
待交换的数据
通讯协议
数据格式
定座/离港（GDS/DCS）
∙Booking
∙FareQuery
∙AvailableQuery
TTL:
TCP/IP
Others:
TCP/IP**
MATIP
XML**
运价管理系统
JMS
N/A
常旅客系统
∙SSO
∙Userinformation
∙AwardRedemption
HTTP
SOAP（WebServices）
电子支付系统
∙Authorization
∙Payment
∙Cancel
XML
FareManagement*
∙FareRule
呼叫中心系统
∙Searching
HTTP/MQ
XML/SOAP
国际联盟系统
∙DynamicFlightInformation
客户主数据系统
∙Customerinformation
WebService
上表中，我们粗略列举了航空公司电子商务系统与其各主要相关系统间交换的业务数据内容，以及通讯协议和数据格式，我们可以看出其复杂性，如果没有一个统一的集成平台的支撑，那么数据格式转换、通讯适配器的开发、传输可靠性保证等问题都需要依赖于自主开发，其风险是不言而喻的。
航空公司商务体系ESB整合方案
总体方案概述
SOA（面向服务的架构）是当今国外各大航空公司率先考虑的方法论并成为提升下一代提升航空运输服务的能力引擎，它使IT部门可以搭建灵活的可配置体系以支持随需应变的航空业务。
鉴于航空公司商务体系建设中存在的这些问题，以及业界的最佳实践，我们提出采用ESB整合航空公司的商务体系，其总体架构如下图所示：
图5.航空公司商务体系集成架构
总体系统架构主要由展现层、核心应用层和SOA核心能力层组成，其中通过门户实现统一用户接入，该模块主要包含用户帐户信息管理和存储、用户登录身份认证和访问请求负载均衡等部分。
核心应用层包括电子商务系统、呼叫中心系统、常旅客系统、大客户系统等商务体系中的所有重要的业务系统。
SOA核心能力层由企业服务总线、服务管理和注册库以及组合服务运行引擎三部分组成。
其中，企业服务总线（ESB）是SOA核心能力层的一个中心组件，它负责接入各种服务资源，通过采用统一服务接口使得各种服务或应用与服务之间可以相互方便访问，以星形结构替代了原来各服务之间的点对点结构，极大地优化了系统连接架构，降低了系统集成的复杂度。
企业服务总线下方连入的各个应用系统是航空公司内部的各个业务系统，而右边是要连接的一些外部系统。
组合服务运行引擎通常运行在标准的流程引擎之上，例如BPEL流程引擎，不是本文的重点，在此就不再赘述了。
ESB的组件及产品映射模型
ESB组件模型及产品映射模型如图6：
图6.航空公司ESB组件模型
其中包括ESB组件、服务注册和管理组件以及ESB的监控和管理组件3部分组成。
ESB组件：
实现消息传递、服务路由、格式转换、交易完整性保证、数据解析和处理、安全传输、应用适配、协议转换等功能，可以由WebSphereMessageBroker实现。
服务注册和管理：
为ESB提供服务管理容器，借助科学的方法论，对航空公司的业务需求进行分析，对其商务体系的业务流程进行梳理，建立起航空公司商务体系的服务目录和服务库，对这些服务以及服务的元数据进行定义和存储，以便进行服务的查找、发布、注册和管理。
该组件可以由WebSphereServiceRegistryandRepository（WSRR）来实现，将所暴露的服务注册在WSRR中，便于其他系统发现和调用。
ESB监控和管理：
ESB是应用集成的枢纽，各个应用之间的信息和服务共享都将通过ESB来进行，因此，ESB平台本身的监控和管理的重要性是不言而喻的。
全面、及时的服务监控功能除了能够辅助快捷的故障诊断，还能够提供完整的服务质量评估报告，以衡量现有的应用系统效率，并为优化、升级提供指导。
服务监控需要包括服务、操作等级别的调用/失败次数、响应时间等信息，并且在超过设定值的情况下能够报警。
该组件由TivoliOmegamonXEforMessaging实现，TivoliOmegamonXEforMessaging能够实现对IBMWebSphereMessageBroker以及底层MQ的资源的自动发现并进行自动监控，帮助管理员及时发现故障和故障隐患。
组件交互模型
以前面描述的电子商务系统和呼叫中心之间的订单交互为例，其组件交互模型如下：
图7.航空公司ESB组件交互模型
该模型描述了客户在呼叫中心预定了机票（产生订单），然后通过电子商务（B2C）系统修改订单时通过ESB实现系统间订单交互的场景。
ESB的接口设计
图8.航空公司ESB接口设计
在上图中，我们给出了某航空公司的一个示例。
在这个例子中，我们看到其电子商务系统、航班信息发布系统、客户主数据系统都是采用WebService/实时/XML接口；
呼叫中心采用socket/实时/文本、WebService/实时/XML接口；
常旅客系统采用FTP/批量/文本、WebService/实时/XML的接口；
大客户系统采用Database的接口形式。
基于接口的数据格式的不同，与ESB相关的系统可以分为以下两类：
基于XML报文的应用系统：
基于XML报文交互是比较理想的方式，是目前业界较为推荐的标准方式。
需要说明的是，尽管都采用XML标准，由于各个系统的需求的差别已经建设周期的不同，不同的应用系统采用的XML消息很难完全兼容。
这需要由ESB实现相应的转换。
基于专有报文/自定义报文的应用系统：
基于专有报文的应用系统，如国内的定座系统，可以先保留现有的报文格式，由ESB实现现有格式与其他报文格式以及XML格式之间的转换。
随着未来条件的成熟，这些系统逐步过度到通过XML实现与ESB以及其他应用系统的集成。
基于接口的通讯协议的不同，与ESB相关的系统可以分为以下四类：
基于WebServices的系统：
基于WebServices的系统，例如目前的呼叫中心和电子商务系统都可以提供这种方式，可以使用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物理部署示例
建议采用两个节点同时安装WebSphereMessageBroker和WSRR。
其中将WebSphereMessageBroker配置为Cluster，将WSRR配置为HA的方式，采用一台PCServer或PC机作为监控管理服务器，安装TivoliOmegamonforMessaging，实现对MessageBroker的监控。
未来需要流程集成时，可以采用两个节点安装WebSphereProcessServer组成Cluster。
我们知道企业ESB实施的模式大致分为GlobalESB、ESBGateway、FederatedESB、BrokeredESB等若干种，IBM的ESB产品主要包括WebSphereMessageBroker、WebSpehereESB、WebSphereDataPower三种，并且在特定的用户需求下，我们需要将这三种产品组合使用，在本系列文章的第2部分，我们再为大家介绍一个制造业企业使用WebSphereDataPower和WebSphereMessageBroker作为企业级联邦ESB平台的案例和技术实现。
客户背景介绍
图1.系统交互图
图1给出了某制造行业客户现有各个系统间的系统交互图（SystemContextDiagram），通过系统交互图，我们可以清晰地了解到ESB平台和周边涉及到的系统之间交互的通信协议类型以及数据接口格式。
从上图1中我们可以看出，其合作伙伴以多种方式调用该企业内部的后台服务，包括标准的SOAP/HTTP方式、XML/MQ的方式、EDI/MQ的方式甚至FTP的方式等；
该企业内部的一个主要核心业务系统运行在IBM大型主机上，对外的接口方式采用WebSphereMQ，数据格式采用传统的COBOLCopyBook的方式，除了该主机系统之外，该企业的其他一些内部应用会以SOAP/HTTP和XML/MQ的方式与外界交互。
DataPower/MessageBroker联邦ESB解决方案
针对该客户需求，我们给出的DataPower和MessageBroker联邦ESB解决方案架构如下图2所示：
图2.联邦ESB解决方案
在这个解决方案中，我们使用的IBM产品主要包括DataPowerXI50和WebSphereMessageBrokerV6.0.2，DB2V9以及WebSphereApplicationServerV6.1。
其中，WebSphereDataPowerXI50是一个实现ESB的硬件解决方案，它的主要功能包括：
∙XML高速转换引擎；
∙基于消息内容的路由；
∙协议桥接:
HTTP,MQ,JMS,FTP等；
∙XML/SOAP防火墙：
过滤任何内容、元数据和网络数据；
∙数据验证：
对进出的XML和SOAP进行数据验证；
∙保护数据域级别安全：
对不同的数据域可以进行WS-Security,加密和签名；
∙访问控制：
验证、授权和审计（AAA），支持SAML,LDAP,RADIUS等；
∙WebServices管理：
中心服务级别管理、服务虚拟化和策略管理等。
该客户的联邦ESB解决方案由下列组件构成：
GatewayDataPower：
在DataPower和MessageBroker组合ESB（以下简称DP/MB组合ESB）方案中，常见的产品分工定位方法是：
由DataPower作为企业对外的ESB入口，即担任B2B网关的角色，侧重提供其它企业的接入服务以及安全控制方面的工作；
而采用MessageBroker作为企业内部的ESB总线，实现企业内部各种应用系统，包括传统应用系统之间的集成平台。
在我们给出的这个实际案例中，采用了两台DataPower，其中GatewayDataPower主要负责外围的接入，接入的通信协议包括MQ，HTTP（S），JMS，FTP四种。
GatewayDataPower位于网络架构中的DMZ区，它负责XMLthreatprotection，信息属性传递（例如IP地址的传递）和SSL传输层安全控制。
ESBDataPower：
这台设备位于网络架构中的受信区，对输入的消息进行更进一步的处理，其中包括：
1.校验Inbound/OutboundXML类型消息的Schema；
2.实现非MQ通信协议和MQ通信协议之间的转换，在我们的设计中，我们在ESBDataPower和ESBWMB之间采用MQ的通讯协议，因此在ESBDataPower上我们要将所有的协议转换为MQ；
3.信息头的处理：
在此我们将创建我们为应用设定的消息头并且插入到接收到的数据包头或SOAP头中。
4.认证/授权：
通过LDAP进行发送者的认证和授权；
5.日志：
为了审计目的，通过日志服务（LoggingService）组件对输入信息进行日志处理。
ESBMessageBroker：
由于我们的后台核心系统是位于IBM大型主机上的应用系统，需要的数据格式是COBOLCopybook的格式，因此在MessageBroker上我们将实现XML到Copybook的转换。
在MessageBroker上，我们设计了3种典型的MessageFlow，
1.OnBoardFlow:
通过查询数据库设置消息的环境树（EnvironmentTree），把输入消息转换为标准的XML格式；
2.MainApplicationFlow：
用于应用逻辑处理；
3.OffBoardFlow:
依据消息的EnvironmentTree，将消息路由到特定的ServiceEndpoint（服务端点），并且将数据转换为后台系统需要的格式。
ApplicationServer组件：
该组件接收和响应WebServices请求，并且Logging组件也运行在该组件上。
后台主机系统：
负责后台的业务逻辑处理。
LDAP组件：
存储认证/授权相关的信息。
RoutingDatabase（路由表）：
路由表中存储了服务路由信息、服务版本信息等，其中包含了特定于应用程序的配置信息，通过JavaAPI对其进行访问来决定服务的路由和绑定。
EventDatabase/EventLogger（事件数据库/事件日志处理器）：
EventDatabase（事件数据库）中存储了各种日志和错误信息，EventLogger（事件日志处理器）是一个Java应用，用于将各种日志和错误信息存储到事件数据库中。
DataPower/MessageBroker联邦ESB的关键服务组件设计
下面我们来介绍在这个DP/MB联邦ESB方案中的关键服务组件设计。
如下图3是ESB服务组件图：
图3.联邦ESB服务组件图
从服务的角度，联邦ESB主要由以下服务组件构成：
1.GatewayServices（网关服务）
2.SchemaValidationServices（模式校验服务）
3.SecurityServices（安全服务）
4.RoutingServices（路由服务）
5.TransformationServices（转换服务）
6.Logging,ErrorHandlingandNotificationServices（日志服务）
下面我们分别介绍这些服务的设计和实现方式。
GatewayServices（网关服务）
这个组件的所有功能都是通过对DataPower的配置实现的。
它是Internet和Intranet之间的一个网关，从ESB的角度，它就像第一道防火墙，起到对企业外部服务调用的安全控制和协议转换的作用。
同时，它根据来源数据的格式，例如SOAP，XML，文本或CopyBook等，进行粗粒度的路由。
SchemaValidationServices（模式校验服务）
这个组件的所有功能也都是通过对DataPower的配置实现的，开发者可以在部署时，在DataPower设备上配置有关的Schema，对XMLSchema的高速校验是DataPower的一个非常重要的功能。
需要注意的是，在我们的案例中，我们的联邦ESB除了XML格式之外，还必须支持Copybook的主机格式，这是DataPower不擅长的，对这种格式的解析，我们将交给后面的MessageBroker来实现，这正是体现了在这个联邦ESB解决方案中DataPower与MessageBroker的各自定位以及无缝配合。
图4描述了模式校验服务的序列图：
图4.模式校验服务序列图
模式验证服务主要由ESBDataPower实现，它负责对SOAP/XML消息模式的校验，如果失败，则调用日志服务进行错误处理。
1.服务请求者通过HTTPS经由GatewayDataPower向ESBDataPower发送SOAP/XML消息；
2.ESBDataPower对该消息进行校验；
3.如果校验失败，LoggingService（日志服务）组件将向数据库写入日志信息，向服务请求者返回“SchemaValidationError”；
4.如果校验成功，将继续安全校验等其它操作。
SecurityServices（安全服务）
安全服务将负责认证、授权和审
升级会员 