ESB解决专项方案.docx

一、 引言 
信息化发展在给企业带来难得机遇同时，也给企业带来了新挑战。巨大投资为企业建立了众多信息系统，以帮助企业进行内外部业务处理和管理工作。不过这些信息系统可能由不一样品牌导入实施，只关注于各自领域内数据和业务处理，因为缺乏对应接口标准和规范，它们各自为政，相互之间无法进行信息共享和业务集成，从而形成“信息孤岛”。 

　伴随企业规模不停扩大，应用系统不停增加， 对信息共享、系统互操作性和软件重用方面要求越来越高，这些相对独立、标准各异“烟囱”式系统已经不能满足业务需要，暴露出弊端越来越多，对企业提出了很多挑战。

　因为缺乏统筹计划，企业内部遗留IT基础架构庞大且管理起来极其复杂，这些基础架构含有严格操作要求，分阶段改造很困难，这么肯定会影响企业对用户需求响应能力和新增加和改善后服务布署。

一个个“信息孤岛”常常分属于不一样管理职能部门。因为这些系统没有进行互联，造成难于信息共享，即不一样软件提供商应用程序之间无法互操作。 

在多个系统共存情况下，同一个用户信息或企业信息，通常在多个系统中同时存在，不过各个系统统计出数据常常不一致，为企业领导层进行正确决议增加了难度。 

面对这么挑战，系统整合成为企业迫在眉睫问题。企业迫切需要一个集成方法，将多种旧应用系统和新应用系统集成起来，这使得企业应用集成（Enterprise Application Integration，EAI）技术产生和发展起来。传统EAI往往使用如CORBA和COM等组件化技术进行分布式、跨平台程序交互，系统整体拓扑结构较复杂，组件连接协议是私有、非标准。其存在着诸如系统灵活性差、投入成本巨大、新系统无法快速布署等问题，不能很好满足企业集成需求。 

在这种背景下，业内多年来提出了SOA（面向服务架构）模型，将应用系统抽象成一个个粗粒度服务，标准化服务接口，松耦合服务架构。使用面向服务ESB平台集成遗留IT系统，将系统服务化，经过服务组合方法复用企业IT资产，对于新开发信息系统，采取插接方法进行快速布署，缩短了投资回报周期，提升了系统适应性、灵活性和扩展性。采取这种面向服务ESB平台进行系统整合，成为目前企业处理“信息孤岛”最好方案。 

二、 面向服务架构SOA 

　 SOA本身就是一个面向企业级服务系统架构，简单来说，SOA就是一个进行系统开发新体系架构，在基于SOA架构系统中，具体应用程序功效是由部分松耦合而且含有统一接口定义方法组件（也就是service）组合构建起来。它是一个以服务为基础架构，服务边界清楚，服务自治，低耦合。它将应用分解为模块和可重用函数和服务，组合服务和模块以符合业务需求，并重用现有服务和模块以满足改变业务需求。

三、 ESB概述 
　ESB是传统中间件技术和XML、WEB服务等技术结合产物。ESB提供了网络中最基础连接中枢，是构筑企业神经系统必需元素。ESB提供了一个开放、基于标准消息机制，经过简单标准适配器和接口，来完成粗粒度应用和其它组件之间互操作，能够满足大型异构企业环境集成需求。它能够在不改变现有基础结构情况下让几代技术实现互操作。
ESB就是一个能够提供可靠、有确保消息技术最新方法。ESB中间件产品利用是web服务标准和公认可靠消息MOM协议接口（比如IBMWebSphere MQ）。企业服务总线概念是从面向服务体系架构SOA发展而来。SOA描述了一个IT基础设施应用集成模型，其中软构件集是以一个定义清楚层次化结构相互耦合，其中，每一个ESB是一耳光预先组装SOA实现，它包含了实现SOA分层目标所必需基础功效部件。
ESB不是一个应用程序框架，也不是一个企业应用处理方案，它只是一个基于消息调用企业服务通信模块。能够把它嵌入到应用程序框架中，比如嵌入到spring容器里面，或嵌入到工作流系统中，它作用是对企业里面SOA服务调用提供一个框架和简便方法。

四、 ESB和JBI

JBI：Java Business Integration
一个ESB规范（Java领域）
定义了组件框架、组件描述、布署模型 定义了归一化消息模型
定义了用户端API接口 定义了管理模型（JMX）

ESB是产品，JBI是一个Java领域ESB规范

五、 ESB定义
它是面向服务框架实现
它通常是操作系统和编程语无关，它应能在Java和.Net应用程序之间工作
它使用XML作为标准通信语言
它支持Web服务标准
它支持消息传输（同时、异步、点对点、公布-订阅）
它包含基于标准适配器，用于集成传统系统
它包含对服务编制（orchestration）和编排（choreography）支持
它包含智能、基于内容路由服务
它包含标准安全模型，用于ESB认证、授权和审计
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值转换
它包含基于模式（schema）验证，用于发送和接收消息
它能够统一应用业务规则，充实其它起源消息，分拆和组合多个消息，和处理异常
它能够条件路由，或基于非集中策略消息转换，即不需要集中规则引擎
它能够监视不一样SLA（服务等级合约）消息响应门限，和在SLA中定义其它特征
它常常简化“服务类别”，向更高或更低优先级用户做出合适响应
它支持队列，在应用临时不可用时用来保留消息
它由分布式环境中选择性布署应用适配器组成

六、 主流商业和开源ESB一览
类型
产品
企业

商业
Oracle Service Bus (OSB)

Oracle
Oracle Enterprise Service Bus (ESB)
WebSphere Enterprise Service Bus

IBM
WebSphere Message Broker
WebSphere DataPower
Sonic ESB
Progress
ActiveMatrix Service Bus
TIBCO

开源
Mule
MuleSoft
ServiceMix/FUSE ESB
Progress
Synapse/WSO2 ESB
WSO2

七、 开源ESB框架Mule介绍

1. Mule概述
Mule是一个开源消息ESB框架，一个消息代理，一个分级事件驱动框架（SEDA）。 SEDA（Staged Event-Driven Architecture）关键思想是把一个请求处理过程分成多个Stage，不一样资源消耗Stage使用不一样数量线程来处理，Stage间使用事件驱动异步通信模式。

Mule ESB模式驱动系统中全部服务，这个系统有着一个分离消息通讯中枢。服务注册在总线上，不过不知道其它任何被注册消息，所以，每个服务只关心处理它收到事件。Mule也把容器，传输，转换细节从服务中分离出来，许可任何对象作为服务注册到总线。
Mule ESB是一个基于Java轻量级企业服务总线和集成平台，许可开发人员快速便利地连接多个应用，并支持应用间数据交换。Mule ESB支持集成现有系统而不管其底层采取何种技术，如JMS、Web Services、JDBC、HTTP和其它技术。

2. Mule整体结构

从上图可见，Mule经过Transports/Connectors和外围异构系统连接，提供Routing（路由）、Transaction Management（事务管理）、Transformation（转换）、Message Broker（消息代理）、Transportation Management（传输管理）、Security（安全）等关键模块。Mule能够单独使用，也能够架设在常见应用服务器上。

外围系统服务请求经过Mule ESBTransport接入，Mule经过Transformer进行数据格式转换，然后经过Inbound Router进行消息过滤（内部经过配置filter实现）后交给MuleComponent进行业务逻辑处理，处理后结果经过Outbound Router确定传输给哪个接收方，然后经过Transformer进行数据格式转换，经过Transport连接至接收方，传输信息。
此图描述是Mule中一个经典场景处理过程，涵盖了Mule中各个关键组件。其中一些处理步骤不是必需，如Inbound Router、Transformer。后续能够看到部分其它场景处理。
3. Mule ESB中部分基础概念
1）Model
Model表示托管各个服务运行时环境。

图 Model
2）Service
Service是用来处理服务请求基础单位，它调用各个组件进行服务请求处理。

图 Service
3）Transport
Transport管理消息接收和发送，数据转换过程也是在Transport中经过调用Transformer完成。

图 Transport
Connector用于管控特定协议使用，如HTTP Connector、JMS Connector等。
Endpoint用于表示一个协议特定使用方法，如listening/polling、从中读取、向指定地址写入等，定义了发送和接收消息通道。Endpoint控制是底层实体在Connector中怎样被使用。
Endpoint定义于Inbound和Outbound Router中。
4）Transformer
Transformer用于转换消息内容。

图 Transformer
5）Router
Router使用Filter基于消息中属性信息进行消息分发。

图 Router
Router在Service中位置决定了Router性质（inbound、outbound和response）和担任角色（pass-through、aggregator等）。
6）Component
Component是Service关键部件，是Service业务逻辑实现。

图 Component: implicit bridge component
Component能够是Java Class（POJO、Spring Bean）、Web Service、Script等。
Component可定义自己生命周期：initialise、start、stop、dispose，不过需要实现MuleLifeCycle接口。Mule 3.0版本开始提供@PostConstruct和@PreDestroy注解，对应生命周期initialise和dispose阶段，不需要实现MuleLifeCycle接口了。
7） Flow（@since 3.0）
Flow是Mule 3.0新引入，包含一个消息源（Message Source）和多个消息处理器组成处理器链。

图 Flow
4. 事件驱动框架概述
Mule是一个开源消息ESB框架，一个消息代理，一个分级事件驱动框架（SEDA）。所谓事件驱动框架，系统由事件消费者和事件产生着组成。事件消费者向事件管理器订阅事件，事件产生者向事件管理器公布事件。当事件管理器从事件产生者那接收到一个事件时，事件管理器把这个事件转送给对应事件消费者。假如这个事件消费者是不可用，事件管理者将保留这个事件，一段间隔后再次转送该事件消费者。这种事件传送方法在基于消息系统里就是：储存（store）和转送（forward）
事件驱动设计和开发优势：
1） 能够更轻易开发和维护大规模分布式应用程序和不可预知服务或异步服务
2） 能够很轻易，低成本集成、再集成、再配置新和已存在应用程序和服务
3） 促进远程组件和服务再使用，拥有一个更灵敏、没有bug开发环境
4） 短期利益：更轻易定制。因为设计对动态处理有愈加好响应。
5） 长久利益：系统和组织状态变得更正确，对实时改变响应靠近于同时。
事件分类：
1) 系统层事件：系统级动作，比如创建一个文件或关闭一个端口
2) 平台层事件：平台级动作，比如修改一个数据源或增加一个新服务
3) 组件层事件：组件级动作，比如视图对象转换活状态机改变
4) 业务层事件：业务级动作，比如创建用户或删除账号
5) 应用层事件：应用级动作，比如增加保险金或报价提交
5. SEDA处理请求步骤
1) 接收用户请求
2) 数据库查询
3) 依据数据库查询结果，准备webservice调用参数
4) 提议webservice调用
5) 将结果返回给用户
SEDA会使用一条线程处理1、3、5步骤，两条线程处理2步骤，而用五条线程处理耗时最多4步骤。
6. ESB分布式基础——传输层和远程通讯
四层协议：网络通讯一个模型
传输协议：四层模型中第三层-传输层，关键指TCP、UDP
应用协议：四层模型中第四层-应用层，基于TCP/UDP，而向应用开发高层协议，比如：HTTP、FTP等
ESB传输层：它是一个逻辑概念，相对于ESB体系结构来说，处理服务（或系统）交互一层。能够直接利用第四层协议，比如：SMTP协议，FTP协议等；或基于第三层、第四层协议定制处理服务交互协议，把一个系统数据和指令传输到另一个系统（能够获取回执，也能够不获取回执），比如：SOAP+HTTP协议，RMI协议，Hessian协议，REST（HTTP+XML方法）协议，XML+JMS协议；甚至和传输无关部分交互方法，比如：File协议，内存协议等
在通讯框架上，选择了MINA，关键原因有：A：文档齐全B：扩展性好C:协议层定制方便D:基于事件模型E:有HTTP扩展F:稳定性不错G:Apache在不停升级