当前位置：文档库 › 航空公司ESB案例解析

航空公司ESB案例解析

航空公司ESB 案例解析

通过企业服务总线、接口适配器、服务注册管理等整合技术，实现将企业内部现有的各应用系统之间的信息共享，提高企业内部应用系统的数据共享和交换效率，提升企业在市场上的综合竞争力和客户服务质量，是所有企业的一个典型需求。本文将以航空公司的案例为基础，说明采用IBM ESB 相关产品整合航空公司电子商务、常旅客、航班动态、呼叫中心等系统的解决方案。

与其他行业一样，在民航业，国际和国内的主要航空公司内部也分布着众多已建和在建的用以支撑业务运行的IT 系统，这些系统之间缺乏对信息共享性、系统兼容性和接口标准规范的统一考虑，造成系统之间的连接比较困难，应用和数据无法得到全面共享，系统间“蜘蛛网状”的连接普遍存在。随着新系统的不断建设，在业务与流程方面的整合将会因系统和业务领域间的信息沟通障碍而面临越来越多的困难，对航空公司的整体发展战略带来制约。下面我们就来列举几个民航业的现状，以此说明对企业进行业务整合的必要性。

现状一：业务系统间数据共享需求强烈

总体来看，航空公司的IT 分为商务、航务、机务和管控四大体系，其中商务体系中包括定座系统、电子客票销售系统、离港系统、电子商务系统、常旅客系统、大客户系统、呼叫中心系统、运价收益管理系统、地面服务系统等。在这个庞大的体系结构中，存在着巨大的系统间数据集成和共享的需求。主要存在以下三类信息的共享：

航班数据共享：

航班数据包括航班计划、航班动态、飞机参数等数据，是保障航空公司正常运营的最基本信息，而航空公司内部通常都会有超过10 个的系统需要获取航班数据，其中包括：电子商务系统、呼叫中心系统、常旅客系统、地服系统、联盟成员系统等。目前，航班数据的源数据系统( 一般来自航空公司运控AOC 系统) 与其他业务系统之间的数据交换和共

享都是通过点对点单独开发接口的形式实现的，比如通过数据库视图的紧耦合的方式实现，这在增加各个系统接口复杂性的同时也增加了系统开发的周期和费用，而且各业务系统无法从统一的渠道获取航班数据，造成了各业务系统之间数据不一致，如下图所示：

图 1. 航空公司航班数据共享

客户主数据共享：

根据不同的直销、分销渠道以及不同的客户属性，航空公司的客户信息通常被分散地存储在多个不同的客户服务系统中，其中包括常旅客系统、大客户系统、电子商务系统等，这些现有系统或多或少地通过点到点的星型结构的接口方式进行了一些互连，在一定程度上实现了客户数据共享，但是仍普遍存在连接混乱、各系统间数据更新频率不一致、各系统内同一旅客基本信息不统一等问题，借鉴其他行业在客户主数据管理方面的发展趋势和最佳实践，因此航空公司需要对客户主数据进行统一存储和一致性管理，这就需要完成呼叫中心、电子商务、大客户、常旅客等系统与客户主数据系统之间的集成，希望通过ESB 技术实现上述系统间数据的实时同步，如下图所示：

图 2. 航空公司客户数据共享

客票销售和客户服务信息共享：

在航空公司的直销渠道中，电子商务与呼叫中心是非常重要的两大直销渠道，各自拥有独立的业务支持系统，以这两个系统为例，国内各个航空公司拥有的电子商务与呼叫中心这两个应用系统之间后台基本没有任何数据共享，在业务和应用上完全独立，如下图：

图 3. 呼叫中心和电子商务系统渠道分离

而实际上这两个系统之间存在着非常多的来自业务的数据共享需求。例如：当客户在互连网上完成了全部订座功能，希望能够在呼叫中心完成改期升舱、退票退款等操作；而如果

客户在呼叫中心渠道上完成了全部订座功能，或者在呼叫中心完成改期升舱、退票、退款操作后，也希望能够在互连网上进行状态查询，如下图所示：

图 4. 呼叫中心和电子商务系统间数据共享

因此这两个系统希望共享客票销售数据、客票服务数据 ( 对于升舱、改期、退票、退款、订单追踪、邮寄行程单等客票服务流程的相关数据 ) 以及销售业绩管理等进行共享，从而实现航空公司的两大直销渠道之间在销售与服务流程上的统一和客户体验的统一，增加客户满意度和客户服务水平。

现状二：缺乏技术先进的、统一的、标准的 IT 集成架构

在以往各个系统的建设当中，都是采用传统的点对点的联接方式，导致了一个复杂的网状结构，其弊端在于系统接口众多，系统间造成密切的耦合性，某一个系统接口的修改导致其他所有系统的修改；系统没有扩展性，每新增一个系统就需要开发该系统和其他相关所有系统的接口；系统的后期维护成本过高。没有建立起统一的数据交换平台和数据交换标准。各系统之间根据自己的需要获取数据，存在着格式上、内容上、或者统计口径上的差异。以航空公司电子商务系统为例，电子商务系统与周边业务系统的集成需求如下：

表 1. 航空公司电子商务与外围系统集成举例

需要集成的系统待交换的数据通讯协议

数据格式定座 / 离港 (GDS/DCS) ? Booking ? Fare Query ? Available Query TTL: TCP/IP

Others:

TCP/IP**

TTL: MATIP Others: XML** 运价管理系统

? Fare Query JMS N/A 常旅客系统 ? SSO ? User information

? Award Redemption

HTTP SOAP (Web

Services) 电子支付系统 ? Authorization HTTP

XML

?Payment

?Cancel

Fare Management* ?Fare Rule N/A N/A

呼叫中心系统?Booking

?Searching

HTTP/MQ XML/SOAP

国际联盟系统?Dynamic Flight

Information HTTP SOAP (Web

Services)

客户主数据系统?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 以及其他应用系统的集成。

基于接口的通讯协议的不同，与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 将呼叫中心、电子商务、常旅客、大客户、航班动态发布平台等应用系统进行高效整合，达到航班信息、旅客信息、客票销售信息等主要业务数据的共享，从而提升航空公司的客户服务水平。

第4部分ESB在医疗行业中的应用健康服务总线

区域医疗 SOA 解决方案第 4 部分: ESB 在医疗行业中的应用 - 健康服务总线健康服务总线是企业服务总线在医疗行业的实现，它使用 SOA 架构和医疗行业标准为基础，将医疗卫生机构的业务流程、应用系统和相关数据整合起来，提供统一的访问总线。本文给出了 IBM WebSphere Message Broker 为实现平台的参考架构，并详细介绍了与 IBM 其他产品进行集成以提供健康服务总线的相关功能。背景介绍区域医疗信息网络内多系统的整合在区域医疗卫生信息网络（Regional Healthcare Information Network，RHIN）内医疗卫生机构之间共享临床与医疗健康信息的能力是当今医疗行业内面临的主要挑战之一，现有的医疗机构应用系统由于采用了不同标准、数据模型或者实现平台，在需要数据共享时候，常常根据某些特定需求实现了特定方式的连接，由于系统的异构性以及集成需求的变化和增加，这种点对点的信息交换模式越来越复杂而且难以维护，逐渐不能满足日益复杂的数据共享和交换要求，现有的系统整合和集成需要一种统一的应用架构来解决上述挑战，从而形成一个互联互通的医疗卫生业务协作网络，实现市民在各医疗机构间（例如医院与医院之间，医院与社区中心之间，社区中心与社区中心之间）的诊疗资料的共享和交换。健康服务总线概念在面向服务的体系架构（SOA）中，企业服务总线（Enterprise Service Bus, ESB）是一个实现系统间集成和互联互通的重要技术架构，它提供一个基于企业总线的先进应用整合理念，最大限度地减少应用系统互联所面临的复杂性，降低集成和维护成本。在区域医疗卫生信息整合环境下，构建统一的企业服务总线是实现区域医疗信息网络内多系统整合的重要实现手段，在这里，我们把企业服务总线在医疗卫生行业内特定的实现称之为健康服务总线（Health Service Bus，HSB）。健康服务总线在实现企业服务总线基本特点的同时，例如消息转换、路由、协议接入等，还需要满足医疗卫生行业内的特定需求，例如病人隐私保护、医疗卫生行业标准支持等。

ESB企业服务总线解决方案剖析

关于SOA 关于SOA的概念，你可以找到很多的文章从不同的角度来描述它，不同的软件提供商也有不同的定义方式。BEA有流体计算，微软有Indigo和SOA-building，SAP有ESA。每个人都可以从不同的视角来理解SOA，从程序员的角度，SOA是一种全新的开发技术，新的组件模型，比如说Web Service；从架构设计师的角度，SOA就是一种新的设计模式，方法学；从业务分析人员的角度，SOA就是基于标准的业务应用服务。从概念的角度，IBM 对SOA的定义是最为全面的，既SOA是一种构造分布式系统的方法，它将业务应用功能以服务的形式提供给最终用户应用或其他服务。SOA包括如下要素: 一个体系架构，用开放的标准将软件资产(Asset)化为服务提供标准的方法来表示软件资产及其交互单独的软件资产作为构造单元，被重复使用来开发其他应用将关注点从细节实现转移到应用(application)组装整合企业外部的应用（B2B）的方式开发（现在）和整合（未来）的统一本文针对的读者是软件开发人员，站在开发人员的角度，往往希望软件开发能够满足对于开发效率、可靠性、易维护性、易管理等多方面的更高要求。让我们通过回顾软件开发的演化过程来看一看SOA出现的必然性：面向机器语言(Monolithic)的开发模式：需要根据不同平台的机器语言来开发代码。面向过程(Procedure)的开发模式：独立于机器的程序语言(C,Pascal等)使开发过程变得简单了，用过程来代表一个抽象的代码集合，包装重用现成的代码。面向对象(Object)的开发模式：用更接近现实的对象来表述一个相对完整的事物。面向对象的语言(Smalltalk，Java等)，提供了更抽象的封装和重用模式。面向对象的开发强调从现实世界问题域到软件程序的直接映射，更接近人类的自然思维方式。

XXXXXX股份有限公司_ESB企业服务总线系统厂商价格调查版

XXXXXX股份有限公司 ESB企业服务总线建设项目厂商价格调查版第二部分项目基本需求一、公司介绍二、信息系统概述略

三、项目总体目标和项目实施范围项目总体目标：通过构建ESB企业服务总线来统一各个信息系统的服务接口协议，对全司内所有服务接口统一标准、统一管理，并且进行全局监控，从而打造信息系统之间信息交互的高速公路，以此来支持XXXX的信息化建设。项目实施范围：根据XXXX业务发展情况和信息系统建设情况，结合目前已知的需求范围，ESB企业服务总线将进行分阶段实施： 1、项目一期建设内容首先按照项目总体目标构建功能齐全的ESB企业服务总线，在此基础上制定信息技术部ESB管理规范和ESB技术标准。根据信息技术部计划，将下列软件系统的服务接口迁移到ESB企业服务总线：

项目一期建设周期，需求分析、设计开发、系统集成及联合调试的整体周期为5个月。四、ESB企业服务总线技术需求描述 1.技术体系及基础架构 1)描述系统的体系架构，说明系统的层次结构（包括物理和逻辑）。 2)描述系统的硬件、系统软件、网络需求的估算和选型建议。系统应使用当前主流的开源Mule ESB产品和ActiveMQ产品，系统应具有多机集群功能，并容易实现未来扩展。系统使用的硬件应为当前主流的硬件产品，该机型应具备升级扩充能力，以满足用户未来一定范围内的需求变化。 3)描述系统的开发方式、开发技术、开发环境等； 4)描述系统的备份和恢复方案。 2.系统性能要求部署在物理环境（CPU：1Core 2.2GHZ；RAM：4GB）上的ESB企业服务总线单个实例，需要满足如下性能要求： 1)并发用户数为100，PayLoad<10KB的条件下，透传业务在ESB中的平均处理时间需要在100ms以下，CPU、RAM等系统资源使用率低于70%。 2)并发用户数为100，PayLoad<10KB的条件下，对于需要进行协议数据转换业务在ESB中的平均处理时间需要在1s以下，CPU、RAM等系统资源使用率需要低于70%。

ESB企业服务总线接口规范

4.5 MsgService接口说明 8 4.5.1 登陆到ESB(Login) 8 4.5.1.1 服务.NET原型 8 4.5.1.2 传入参数 9 4.5.1.3 返回参数 9 4.5.1.4 服务说明 9 4.5.2 发送消息到ESB(SendMessage) 9 4.5.2.1 服务.NET原型 9 4.5.2.2 传入参数 10 4.5.2.3 返回参数 10 4.5.2.4 服务说明 10 4.5.3 从ESB接收消息(ReceiveMessage) 10 4.5.3.1 服务.NET原型 10 4.5.3.2 传入参数 11 4.5.3.3 返回参数 11 4.5.3.4 服务说明 11 4.5.4 发送确认消息到ESB(AcknowledgeMessage) 11

4.5.4.1 服务.NET原型 11 4.5.4.2 传入参数 11 4.5.4.3 返回参数 12 4.5.4.4 服务说明 12 5.附录A 返回代码对照表 12 1.前言随着信息技术的不断发展，企业、政府部门等在信息化建设上投入了大量的资金、人力，逐步形成了适合自身某些部门或某些业务需要的管理信息系统，如办公自动化、客户关系管理CRM、企业资源计划ERP、生产制造系统等，这些管理信息系统，在企业和政府某些部门或业务的管理上，发挥了信息电子化、流程自动化、管理科学化的重要作用。但是，企业和政府现有的管理信息系统，由于投入的时间、使用的部门、生产的厂家及实现技术等各不相同，造成企业和政府现有的应用信息系统各自独立运行，数据不能共享，各自业务流程不能自动衔接，造成企业和政府内部许多自成体系的信息化孤岛，各个应用系统不能相互协作，形成统一高效的有机整体。企业应用集成，英文名称为Enterprise Application Integration，简称EAI，是为了解决企业和政府现有多种应用系统不能互连互通、数据共享、业务流程协调统一的问题，将异构的两个或更多的硬件、平台及应用系统进行无缝集成，使它们形成一个统一的整体。

企业服务总线ESB项目供应商征集要求

企业服务总线ESB项目供应商征集要求一、项目名称企业服务总线ESB项目二、项目背景随着我行经营战略的实施，经营管理改革不断深化，业务规模不断壮大，产品种类不断增多，对应的支撑信息系统也在不断增加，目前已达到了一百多个，且系统与系统之间的交互也越来越多，如何高效的实现这一百多个系统之间的互联互通互用，从而形成一个有机的整体，就成了我行当前面临的一个新问题，这个问题需要在科技层面引入一种先进的架构来解决。面向服务的SOA架构思想是当前IT架构发展的主流，SOA 是一种面向服务的分布式应用体系架构，它将各应用程序的业务功能定义为服务，并按松耦合方式组合服务形成业务功能或业务流程。通过SOA架构建设，可极大的提升整体系统对业务发展变化响应的敏捷性和灵活性。企业服务总线（简称ESB：Enterprise Service Bus）是企业SOA架构落地的最佳实践，是实施SOA的切入点。通过ESB项目建设，可建立起多层次、条线化、松耦合的IT应用架构，简化了接口和交易环节，架构更加清晰，从而能更有效支撑我行未来的业务发展战略。

三、项目要求本系统的建设目标为建立起一个灵活的、高效的、稳定的全行总线系统，实现我行异构系统的互联互通互用，实现我行统一服务视图和统一服务监控。建设该系统，具体需达到以下要求： 1.建立起松耦合的、灵活、稳定的面向服务的SOA 系统架构,高效解决我行异构系统间互联互通互用问题。 2.制定起我行统一的银行服务规范和技术规范，搭建一套服务治理平台，梳理我行服务，实现服务全生命周期管理，形成我行的统一服务视图，以支持快速地构建新业务和新产品。 3.提升我行系统整体效率，通过引入流量控制和故障隔离机制，增强系统整体健壮性。 4.通过对各系统的服务运行情况监测及分析，实现对全行系统的有效监控。

企业服务总线ESB方案书

1需求综述 (4) 1.1主数据平台接口 (4) 1.2业务数据接口 (4) 1.3OA系统接口： (5) 1.4国家法定信息发布媒体： (5) 2系统解决方案 (5) 2.1系统技术架构 (5) 2.1.1运行平台 (6) 2.1.2开发平台 (6) 2.1.3监控平台 (7) 2.1.4公共服务 (7) 2.1.5适配器 (7) 2.2部署方案 (9) 2.2.1管理监控部分部署方案 (9) 2.2.2硬件选型建议 (10) 2.2.3逻辑分区部署方案 (11) 2.2.4硬件配置建议 (11) 2.2.5服务接口规范 (12) 2.2.6高性能、高可用性及扩展能力设计 (12) 2.2.7完善的安全机制 (13) 2.3整体解决方案 (15) 2.3.1接入控制 (16) 2.3.2通信接入模块 (17) 2.3.3请求系统适配 (18) 2.4集成服务功能 (19) 2.4.1服务治理 (19) 2.4.2提供对出错服务的及时检测和隔离功能 (20) 2.4.3协议转换 (20) 2.4.4消息格式转换 (21) 2.4.5服务路由 (22) 2.4.6监控和运维 (22) 2.4.7服务等级 (23) 2.5系统非功能需求 (24) 2.5.1可用性 (24) 2.5.2可扩展性 (24) 2.5.3可维护性 (25)

2.5.4安全性 (25) 2.5.5性能需求 (25) 2.6公用服务 (26) 2.6.1流量控制 (26) 2.6.2故障隔离 (26) 2.6.3统一流水号 (27) 2.6.4日志记录 (27) 2.7管理监控 (27) 2.7.1系统平台级监控 (27) 2.7.2应用级监控 (27) 2.7.3统计分析 (27) 2.7.4异常报警 (28) 2.7.5统一的运维管理 (28) 3技术支持与服务方案 (28) 3.1技术支持与售后服务体系 (29) 3.2服务管理模式 (29) 3.3服务响应 (30) 3.3.1问题优先级（或问题严重程度）级定义 (30) 3.3.2服务响应时间 (31) 3.3.3问题解决时间 (33) 3.3.4服务文档 (34) 3.4维护支持服务流程 (35) 3.4.1服务消息创建流程 (35) 3.4.2问题处理流程 (35) 3.4.3服务确认流程 (36) 3.4.4投诉及问题升级流程 (37)

ESB企业服务总线接口规范

目录 1.前言 (4) 2 .ESB简介 (4) 3. ESB主要功能和特点 (6) 3.1.ESB主要功能： (6) 3.1.ESB主要特点： (7) 4.ESB接口设计 (8) 4.1 总体设计框图 (8) 4.2 技术规范 (8) 4.3 消息传输流程 (8) 4.4 文件传输流程 (8) 4.5 MsgService接口说明 (8) 4.5.1 登陆到ESB(Login) (8) 4.5.1.1 服务.NET原型 (8) 4.5.1.2 传入参数 (9) 4.5.1.3 返回参数 (9) 4.5.1.4 服务说明 (9) 4.5.2 发送消息到ESB(SendMessage) (10) 4.5.2.1 服务.NET原型 (10) 4.5.2.2 传入参数 (10) 4.5.2.3 返回参数 (10) 4.5.2.4 服务说明 (10) 4.5.3 从ESB接收消息(ReceiveMessage) (11) 4.5.3.1 服务.NET原型 (11) 4.5.3.2 传入参数 (11) 4.5.3.3 返回参数 (11) 4.5.3.4 服务说明 (11) 4.5.4 发送确认消息到ESB(AcknowledgeMessage) (12) 4.5.4.1 服务.NET原型 (12)

4.5.4.2 传入参数 (12) 4.5.4.3 返回参数 (12) 4.5.4.4 服务说明 (12) 5.附录A 返回代码对照表 (13)

1.前言随着信息技术的不断发展，企业、政府部门等在信息化建设上投入了大量的资金、人力，逐步形成了适合自身某些部门或某些业务需要的管理信息系统，如办公自动化、客户关系管理CRM、企业资源计划ERP、生产制造系统等，这些管理信息系统，在企业和政府某些部门或业务的管理上，发挥了信息电子化、流程自动化、管理科学化的重要作用。但是，企业和政府现有的管理信息系统，由于投入的时间、使用的部门、生产的厂家及实现技术等各不相同，造成企业和政府现有的应用信息系统各自独立运行，数据不能共享，各自业务流程不能自动衔接，造成企业和政府内部许多自成体系的信息化孤岛，各个应用系统不能相互协作，形成统一高效的有机整体。企业应用集成，英文名称为Enterprise Application Integration，简称EAI，是为了解决企业和政府现有多种应用系统不能互连互通、数据共享、业务流程协调统一的问题，将异构的两个或更多的硬件、平台及应用系统进行无缝集成，使它们形成一个统一的整体。企业服务总线（Enterprise Service Bus，缩写ESB），是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。采用SOA架构，基于ESB总线进行企业应用集成，应用系统之间的交互通过总线进行，这样可以降低应用系统、各个组件及相关技术的耦合度，消除应用系统点对点集成瓶颈，降低集成开发难度，提高复用，增进系统开发和运行效率，便于业务系统灵活重构，快速适应业务及流程变化需要。 2 .ESB简介 ESB作为博立特科技公司的企业应用集成产品，主要功能是在两个或更多的异构系统（如不同的数据库、消息中间件、ERP或CRM等）之间进行资源整合，实现互连互通、数据共享、业务流程协调统一等功能，构建灵活可扩展的分布式企业应用。

集团公司服务总线ESB方案计划书

企业服务总线ESB方案书 1需求综述 (3) 1.1主数据平台接口 (3) 1.2业务数据接口 (3) 1.3OA系统接口： (4) 1.4国家法定信息发布媒体： (4) 2系统解决方案 (5) 2.1系统技术架构 (5) 2.1.1运行平台 (5) 2.1.2开发平台 (6) 2.1.3监控平台 (6)

2.1.5适配器 (6) 2.2部署方案 (7) 2.2.1管理监控部分部署方案 (7) 2.2.2硬件选型建议 (8) 2.2.3逻辑分区部署方案 (9) 2.2.4硬件配置建议 (9) 2.2.5服务接口规范 (10) 2.2.6高性能、高可用性及扩展能力设计 (10) 2.2.7完善的安全机制 (11) 2.3整体解决方案 (12) 2.3.1接入控制 (12) 2.3.2通信接入模块 (13) 2.3.3请求系统适配 (14) 2.4集成服务功能 (15) 2.4.1服务治理 (15) 2.4.2提供对出错服务的及时检测和隔离功能 (15) 2.4.3协议转换 (15) 2.4.4消息格式转换 (16) 2.4.5服务路由 (16) 2.4.6监控和运维 (16) 2.4.7服务等级 (17) 2.5系统非功能需求 (17) 2.5.1可用性 (17) 2.5.2可扩展性 (17) 2.5.3可维护性 (18) 2.5.4安全性 (18) 2.5.5性能需求 (18) 2.6公用服务 (18) 2.6.1流量控制 (18) 2.6.2故障隔离 (19) 2.6.3统一流水号 (19) 2.6.4日志记录 (19) 2.7管理监控 (19) 2.7.1系统平台级监控 (19) 2.7.2应用级监控 (19) 2.7.3统计分析 (19) 2.7.4异常报警 (20)

谈及企业服务总线

谈及企业服务总线（ESB），在有面向服务的架构（SOA）实施经验的开发者眼中一定不会陌生。这些年，人们一直在谈论它，以至有些人认为“实施SOA一定需要ESB”，或“只要将ESB架起来了，我们就SOA了”。这些说法有可取之处，也存在片面之嫌，由于业界对于ESB没有统一、标准的定义，所以一千个人眼中有一千个“ESB”也就成了情理中的事情了。然而，怎么才能将ESB 用好？我们需要清楚地认识ESB在SOA中所扮演的角色，理解哪些工作是ESB的职责之内，哪些却不是。只有正确地认识了ESB的职能，并委以恰当的任务，才能将它用在刀刃上、发挥其巨大的能量。事实上，ESB在SOA中扮演着重要的角色，在技术层解决了SOA的整合问题，耦合了应用与应用之间的集成逻辑，使得SOA更灵活，更易于扩展，更敏捷。有了ESB，新建的服务消费者应用程序不需要关心服务的提供者在哪里，使用何种通讯协议，与其交互的数据是怎样的……，它只需向ESB发出请求，使用开放的、标准的通讯协议。相反，若某个可重用的价值较大的服务位于某一个遗留系统中，而由于种种原因，该遗留系统不能在短期内重写，此时ESB可以架起该服务与其使用者之间沟通的桥梁。当然，ESB的作用远不止这些，业内也有很多讨论，本文不再赘述。读者可在Google上搜索ESB Patterns获得相关资料。然而，ESB并非“救世主”，它注定也不可能解决应用系统整合中出现的所有问题。道理很简单，计算机发展历史长从没有出现过一个产品/工具可以满足所有的应用需求，技术发展得很快，需求发展更快，所以技术永远跟不上需求。此外，ESB或ESB产品有其特定的适用范围，它是基础设施层的概念/产品，解决的是整合中的常见问题，比如服务连通、路由、消息丰富、服务的注册/查找/发布等服务的管理、服务监控和质量保证等。ESB不能解决的问题比其能解决的问题多很多。比如，让它去做人工流程的编排是不合适的，让它提供门户类产品那样的用户交互也是极其困难的……。笔者支持过许多客户项目。在这些项目中，有的客户将ESB用的好，有的则勉强用上，用的功能很简单，有的则用ESB做一些原本不属于它该做的工作。在这里，笔者仅从个人的立场，分享自己这些年来积累的ESB实施经验。下面列出笔者常看到但不推荐的实施和笔者在实施ESB 的过程中积累的一些较好的实践方式，供读者参考。同时欢迎批评指正。不推荐实施挟ESB以令外围应用 ?现象： ESB的架构师在ESB上设计一套标准的数据接口（通用的XML格式），规定使用统一的协议（如Web Service/HTTP）。所有的ESB服务消费者和接入ESB的服务必须符合该标准。其目的是为了简化ESB上的开发工作。这就是一种“挟天子以令诸侯”的做法，因为在实际情况中，可能领导规定了“所有的服务必须要经过ESB，即便是透传”。 ?分析：国内的ESB实施者大多数是一些SI/ISV，出于成本/人力或其他个方面的原因，总会有一些架构师希望达成这样一个目标：我能否设计/实现一个一劳永逸的ESB中间平台，将来不论哪种服务都可以方便地接入到ESB上？

几种ESB(企业服务总线)架构介绍

ESB（Enterprise Service Bus，即企业服务总线）是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。企业服务总线ESB就是一种可以提供可靠的、有保证的消息技术的最新方法。ESB中间件产品利用的是Web服务标准和与公认的可靠消息MOM协议接口(例如IBM的WebSphere MQ、Tibco的Rendezvous 和Sonic Software的SoniCMQ)。ESB产品的共有特性包括:连接异构的MOM、利用Web服务描述语言接口封装MOM协议，以及在MOM传输层上传送简单对象应用协议(SOAP)传输流的能力。大多数ESB产品支持在分布式应用之间通过中间层如集成代理实现直接对等沟通。企业服务总线（Enterprise Service Bus，ESB）的概念是从面向服务体系架构(Service -Oriented Architecture，SOA)发展而来的。SOA描述了一种IT基础设施的应用集成模型，其中的软构件集是以一种定义清晰的层次化结构相互耦合，其中，一个ESB是一个预先组装的SOA实现，它包含了实现SOA分层目标所必需的基础功能部件。一、ESB的出现改变了传统的软件架构 ESB 是传统中间件技术与XML、Web服务等技术相互结合的产物，ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。二、企业服务总线（ESB）的用处 ESB 不是万能的,他不是一个应用程序框架,也不是一个企业应用的解决方案.它只是一个基于消息的调用企业服务的通信模块!你可以把它嵌入到你的应用程序框架中,例如嵌入到spring容器里面,或者嵌入到工作流系统中.它的作用是对企业里面的SOA服务的调用提供一个框架和简便的方法. 三、企业服务总线（ESB）的应用特征大规模分布式的企业应用需要相对简单而实用的中间件技术来简化和统一越来越复杂、繁琐的企业级信息系统平台。面向服务体系架构（SOA）是能够将应用程序的不同功能单元通过服务之间定义良好的接口和契约联系起来。SOA使用户可以不受限制地重复使用软件、把各种资源互连起来，只要IT人员选用标准接口包装旧的应用程序、把新的应用程序构建成服务，那么其他应用系统就可以很方便的使用这些功能服务。支撑SOA的关键是其消息传递架构-企业服务总线（ESB）。ESB是传统中间件技术与XML、Web服务等技术相互结合的产物，用于实现企业应用不同消息和信息的准确、高效和安全传递。ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务协调运作，实现不同服务之间的通信与整合。ESB在不同领域具有非常广泛的用途: 电信领域：ESB能够在全方位支持电信行业OSS的应用整合概念。是理想的电信级应用软件承载平台。电力领域：ESB能够在全方位支持电力行业EMS的数据整合概念，是理想的SCADA系统数据交换平台。金融领域：ESB能够在全方位支持银企间业务处理平台的流程整合概念，是理想的B2B交易支撑平台。电子政务：ESB能够在全方位支持电子政务应用软件业务基础平台、信息共享交换平台、决策分析支撑平台和政务门户的平台化实现。四、几种ESB的结构和功能 ESB提供了一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用（服务）和其他组件之间的互操作，能够满足大型异构企业环境的集成需求。它可以在不改变现有基础结构的情况下让几代技术实现互操作。通过使用ESB，可以在几乎不更改代码的情况下，以一种无缝的非侵入方式使企业已有的系统具有全新的服务接口，并能够在部署环境中支持任何标准。更重要的是，充当“缓冲器”的ESB（负责在诸多服务之间转换业务逻辑和数据格式）与服务逻辑相分离，从而使得不同的应用程序可以同时使用同一服务，用不着在应用程序或者数据发生变化时，改动服务代码。 1. IBM WebSphere ESB IBM 提供了三种ESB 产品：IBM WebSphere ESB、IBM WebSphere Message Broker、IBM WebSphere DataPower Integration Appliance XI50。根据您的需求选择ESB 来增强您的SOA。WebSphere ESB 是一种基于平台的ESB，作为集成的SOA 平台，针对WebSphere 应用服务器进行了优化。WebSphere Message Broker 是跨平台的ESB，是为异构IT 环境中的统一连接和转换而构建的。WebSphere DataPower

企业服务总线消息框架Mule简介

企业服务总线消息框架. Mule 1Mule简介 Mule是一个轻量级的基于Java的ESB消息框架，它允许用户快捷地连接多个应用并且在这些应用之间交换数据。Mule使用了SOA的体系结构思想，可以方便的集成已有的应用。它是可升级的、高分布式的对象代理，可以通过异步传输消息技术来无缝的处理服务与应用之间的交互。 Mule框架提供了一个可升级的环境，可以把自己的业务组件部署在里面。Mule管理所有组件之间的交互，不管它们是在同一个虚拟机中还是在internet上，也不管底层使用的传输方式。 Mule围绕着企业服务总线（ESB）架构进行设计，保证了不同的组件或者应用可以通过公共的消息总线进行交互，公共的消息总线一般是由JMS或者其他消息服务器来实现。在应用中会使用不同的技术，包括JMS,Web Services，JDBC，HTTP等等，Mule可以很好地处理他们之间的交互。 2Mule快速入门

2.1Mule特性 Mule是一个企业服务总线(ESB)消息框架.它的主要特性包括: 1.基于J2EE1.4的企业消息总线(ESB)和消息代理(broker). 2.可插入的连接性:比如Jms,jdbc,tcp,udp,multicast,http,servlet,smtp,pop3, file,xmpp等. 3.支持任何传输之上的异步，同步和请求响应事件处理机制. 4.支持Axis或者Glue的Web Service. 5.灵活的部署结构[Topologies]包括Client/Server, P2P, ESB 和Enterprise Service Network. 6.与Spring 框架集成:可用作ESB 容器，也可以很容易的嵌入到Spring应用中. 7.使用基于SEDA处理模型的高度可伸缩的企业服务器. 8.强大的基于EIP模式的事件路由机制等. 2.1.1产品简介 Mule ESB 是一个轻量级的基于java的企业服务总线和集成平台，使得开发人员可以快速，简单的连接多个应用，使得它们可以交换数据。 Mule ESB 容易集成现有异构系统，包括：JMS, Web Services, JDBC, HTTP, 等. ESB的关键特性是允许不同的应用通讯，其作为运输系统在企业内或Internet应用间搬运数据。 Mule ESB 包含如下强大的能力： ?服务创建和托管—暴露和托管可重用服务，使用Mule ESB作为一个轻量级服务容器； ?服务调解— shield services from message formats and protocols, separate ； business logic from messaging, and enable location-independent service calls ； ?消息路由—路由, 过滤, 聚合, 基于内容和规则对消息re-sequence； ?数据转换—通过一些格式和传输协议交换数据。