ESB解决实施方案

ESB解决实施方案

———————————————————————————————— 作者：

———————————————————————————————— 日期：

一、 引言 

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

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

　由于缺少统筹规划，企业内部遗留的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协议接口（例如IBM的WebSphere 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一览

七、 开源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 ESB的Transport接入，Mule通过Transformer进行数据的格式转换，然后经过Inbound Router进行消息过滤（内部通过配置filter实现）后交给Mule的Component进行业务逻辑处理，处理后的结果通过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，不过需要实现Mule的LifeCycle接口。Mule 3.0版本开始提供@PostConstruct和@PreDestroy的注解，对应生命周期的initialise和dispose阶段，不需要实现Mule的LifeCycle接口了。

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在不断升级

本文来源：https://www.2haoxitong.net/k/doc/6d7424a5178884868762caaedd3383c4ba4cb418.html