Enterprise Service Bus Overview

轻量级ESB解决方案

引言

企业应用的发展概述

在介绍企业服务总线之前，有必要花一些笔墨来介绍企业应用架构的发展和变迁。企业级应用架构的发展经历了以下几个阶段：

·         独立应用系统

·         EAI 阶段

·         SOA 阶段

独立应用阶段

20 世纪 60 到 70 年代，企业应用处于独立应用系统阶段，当时的企业应用是一种用来替代重复性劳动的简单设计，其目的是用计算机代替孤立的，体力性质的工作环节，将相关联的企业信息或数据管理起来。这些系统大部分是独立的系统——有独立的数据库、应用服务器、用户界面。因此有时候这类应用也叫“竖井型”的应用。

但是，随着业务和信息的不断扩展，独立应用系统渐渐不能满足企业对 IT 的需求，表现在大量的信息冗余，因为在建立一个新的应用的时候需要重新建立一套数据库；功能的重新设计，相似的功能存在于多个系统中；例如，客户信息在一个公司中可能有多个拷贝分别存在于多个数据库中，不同时期建立的应用系统所使用的技术也会不同。对于获取客户资料这样的功能，必然存在于多个系统中，而且在不同的系统中其实现方式可能是 Java/J2EE、Delphi、C/C++。

EAI 阶段

20 世纪 80 到 90 年代，一些公司或集成商意识到应用集成的价值和必要性。EAI 是一种将多个不同平台、用不同方案建立的异构的应用集成的一种技术和方法。它的目标包括以下几个方面：各个分离的系统间的相互通讯，消除信息孤岛，实现信息的共享。从功能的角度来看，EAI 包括信息接收、转换、翻译、路由、传播和业务流程管理。从架构上看有两种方式：Hub/Spoke 方式和 Bus 方式。

图 1 所示的 Hub/Spoke 结构使用一个中心代理（Hub）和多个适配器（Spoke）将 Hub 和应用连接起来。适配器负责将应用的数据格式转换成 Hub 可以理解的格式，Hub 将数据再转换成目标系统可以理解的格式，并执行消息的路由。Hub/Spoke 方式的弊端在于只有一个代理中心，当连接的应用种类增加或者消息量增大时，代理中心的性能将成为整个系统的瓶颈，在可扩展性方面也存在着一定的问题。

 

Figure 1 Hub/Spoke 结构的EAI集成

 

图 2 所示的 Bus 结构使用一个中心总线，应用程序通过 Adapter 将消息发送给总线，总线负责消息的路由，接受方的应用程序也有自己的 Adapter 来转换接受到的消息。Bus 结构和 Hub/Spoke 结构的最大区别在于在 Bus 结构中，Adapter 位于应用程序中，而 Hub/Spoke 结构中，Adapter 由 Hub 来统一管理。这样在 Bus 结构中，加入一个新的应用变得很简单，可扩展性得到了很大的提高，但是应用程序方的负担加重了。

Figure 2 Bus结构的EAI集成

SOA 阶段

SOA 将应用资源看成一个个独立的，自包含并良好定义的服务，通过这些服务的组装，编排可以产生新的应用。每一个服务可以完成一个独立业务功能，并且不依赖于业务上下文或者其他服务的状态。服务的定义是标准的且被广泛支持的，比如 Web Service。在 SOA 的架构中，人们都用标准的方式来封装自己的服务，使得任何一个客户端程序都可以容易的和后台系统实施连接。而 ESB 是 SOA 架构中的一个核心基石，在几乎所有的 SOA 架构中，都将 ESB 放在核心的位置。

什么是ESB

ESB是对传统EAI的一个扩展。ESB (Enterprise Service Bus)目前并没有一致的定义。对于其中一些厂商（IBM、微软）来说，ESB是将一系列能力（service）联结在一起的一种模式，而其他厂商认为ESB是一种产品.。总之，ESB通常是指一类由中间件来实现的软件架构技术。ESB应该遵守开放标准，构建在事件驱动，标准消息引擎和SOA基础之上，是以整合各种基础服务为目的的复杂架构1。这种软件架构模式允许我们优化在跨地域的不同系统间的信息分发 。ESB的核心特性包括2：

·         消息路由：将传入消息发送到目的地，该目的地通过硬编码方式连接的逻辑确定或基于内容的动态方式确定。路由是启用服务虚拟化的关键功能。在调用方和服务之间建立中间层可以在调用方不知道更改的情况下移动服务的位置。

·         消息转换：将传入消息从一种格式转换为另一种格式。例如，可以将逗号分隔的消息转换为 SOAP，这样可以将数据传递到 Web 服务。

·         协议中介：传入消息使用不同的协议从发出位置发送。例如，传入消息可以使用 HTTP，而传出消息可以使用 WebSphere MQ。

·         事件处理：事件的传入消息一般通过发布和订阅模型分发给许多端点。

这些特性使得 ESB可以方便的将企业内的服务联系起来，协同完成某项业务活动。它支持开放标准，以及可供选择的众多的通信模式。即便信息的发送方和接收端使用不同的通信模型和数据格式，信息也能通过ESB传输，比如从JSM系统到Web service, web service 到Message Queue系统, 发布/订阅系统到点对点系统的系统等等。

与传统的EAI不同，ESB支持物理上的分布式部署和逻辑上的集中管理，所以ESB具有更好的可扩展性和健壮性。

ESB和SOA的关系

ESB是随着SOA的发展而出现的一种新的软件架构模式。ESB通过实现消息的订阅/发布将数据路由给合适的目的服务，从而实现服务之间的解耦，提高了系统的敏捷度。只有在SOA的环境中，ESB才能实现应有的价值。可是说SOA是ESB的基础而ESB是SOA应用蓬勃发展的自然产物，在SOA实现中总是占有重要的地位。

ESB的相关产品

商业软件

IBM

IBM 有三款 ESB 产品：WebSphere ESB (WESB)，WebSphere Message Broker(WMB)，DataPower。这三款 ESB 产品都提供了 ESB 所必备的特征，但是它们各有侧重，WESB 主要构建与 WebSphere Application Server 之上，侧重于对标准协议和消息的支持，更适合于 J2EE，Web-Service 为主要特征的集成环境；WMB 提供了一个高级的 ESB，它构建于 WebSphere Message Queue 之上，提供了百种以上协议的连接和数据格式的转换机制。Datapower 是一款比较新的 ESB 产品，除了提供必备的 ESB 的特性之外，Datapower 更侧重于安全。

WESB 适用于 J2EE 环境下，对性能要求不是很高的，标遵循标准协议的 SOA 集成；WMB 应用更复杂的集成环境，表现为数据格式多种，传输协议多样，性能要求很高；而在安全和性能要求都很高的应用场景下，选择 Datapower是最好的选择。

ESB 功能特点	WESB 的支持	MB 的支持	Datapower
消息转换	XML	XML、非 XML	XML、非 XML
支持的协议	HTTP,JMS, WMQ 等	多达上百种	介于前二者之间
消息路由	强大，灵活	功能强大，灵活	灵活度比前二者稍弱
Web Service	强大的支持	支持 WS 扩展	强大的支持
事件处理	CEI，可以和外部事件消费系统监控	Trace Service	用于调试 Probe
遗留系统的集成	Adapter	丰富的 SupportPac	特定的遗留系统
安全	依赖 WAS 的安全	部署和运行时两个级别的安全	超强的安全支持
性能	几十到几百每秒	几千到几万每秒	达到线速
开发和部署	WID 集成开发环境	WMB Toolkit	WebGUI

 

微软

微软推出的BizTalk Server是.NET 平台上非常强大的ESB产品，BizTalk Server的最新版本是2006 R2。不仅包含了ESB理论的核心功能也支持业务编排，规则引擎。通过支持集群部署可以有效的提高整个ESB的可用性和可扩展性。同时BizTalk Server提供了了业务活动监视和管理工具，可以是用户更加方便的监控整个个ESB系统的运行状态。可以说BizTalk 2006 R2 不仅仅是一个ESB产品，实际上提供了对BPEL，BPM和BAM的支持。

开源软件

Mule

它是一个轻量级的消息框架和整合平台，基于EIP（Enterprise Integration Patterns,由Hohpe和Woolf编写的一本书）而实现的。从2005年发表1.0版本以来，Mule吸引了越来越多的关注者，成为开源ESB中的一支独秀。目前许多公司都使用了Mule，比如Walmart,HP,Sony,Deutsche Bank 以及 CitiBank等公司。

Apache ServiceMix

它是JBI规范的一种实现。它包涵了许多JBI组件，这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。自从JBI被JCP接收后，2005年末Apache ServiceMix才被Apache作为其卵化项目，到2007年9月，它已经成为Apache的顶级项目。ApacheServiceMix 也整合了其他的开源项目，比如Apache ActiveMQ,Apache CXF,Apahe Camel,Apache ODE以及Apache Geronimo。 

Open ESB

前两个开源ESB都由开源社区提供支持，Mule由Codehaus社区提供支持，ServiceMix由Apache社区提供支持。Open ESB是由SUN发起，现在作为Java.net的子项目。所有Open ESB的开发人员都来自SUN。

如同Apache ServiceMix一样，Open ESB也实现了JBI规范。Open ESB可运行在由SUN支持的Glassfish应用服务中。同时SUN的Netbeans IDE为Open ESB提供了拖拉式的开发工具，这是其他开源ESB不可匹敌的，尽管Mule也提供了基于Eclipse的插件工具，但目前仍然不够强大。

Apache Synapse

虽然Apache Synapse具备一些ESB所必备的功能，但是从本质上而言Synapse更是一个web服务仲裁框架，它是构建在Apache Axis2之上的。Synapse的关注点是路由，转换，消息验证以及基于web服务和xml标准的注册。它支持HTTP, SOAP, SMTP, JMS,FTP ,MTOM/XOPPOP3/IMAP/SMTP 等传输协议，还支持多种web服务规范(WS-*)，比如WS-Addressing,WS-Security,WS-Policy以及WS- Reliable Messaging。在它的最新版本1.2中加入了对FIX(Financial Information eXchange,金融信息交换协议 ) 和 Hessian 的支持。同时它还支持多种流行语言，比如Java, JavaScript, Ruby, Groovy等。

JBoss ESB

JBoss ESB基于JBoss公司的ESB产品Rosetta。Jboss ESB将JbossMQ作为其消息层，将JBoss rules为其提供路由功能， 将jBPM为其提供服务编排功能。

ESB面临的问题

可用性Availability

可用性一般是指系统能

ESB功能可以是一个由多个物理实例（甚至多个产品）组合成的逻辑结构。某些情况下用户也可以选择将将多个ESB实例部署在同一个物理节点，或者将ESB分布部署在企业或组织内部。因此，可以想象，一个比较简单的只有一套有限的功能的ESB可能只包括一个通讯样式的Web服务，比如点对点或发布/订阅。然而。随着对ESB的不断增强和连接到Bus的service的不断增多， ESB迅速成为整个企业内的关键应用。ESB的故障将会影响到他上下游链接的系统，从而造成整个企业应用的瘫痪。所以可用性是ESB架构设计中必须要考虑和满足的关键问题。

可扩展性Scalability

ESB作为SOA应用的基石和服务主干，随着企业业务的增长和连接系统的增多。ESB承载了大量的数据流。在ESB系统性能达到瓶颈时如何扩展ESB以满足更高的性能和容量要求也是ESB构架设计中需要考虑的主要问题。

成本和复杂性Cost and Complexity

企业ESB往往意味着需要高性能的硬件来支撑整个总线系统，同时也带来维护，扩展等等问题。需要掌握ESB理论和实际经验的专门人才来设计和维护。实施ESB通常意味着要选择若干技术平台和产品，这也增加了ESB的设计和实现难度。

总结

随着软件技术的蓬勃发展，SOA已经成为企业应用软件设计和开发的主流方法，如何应用ESB整合和集成企业内部的众多服务以有效的利用IT资源是企业应用软件面临的又一重大课题。对于中小企业来说，市场上的ESB产品过于沉重和昂贵，如何在众多的开源软件中选择ESB软件或者开发构造适合自身的ESB，同时控制系统的复杂度以保证较好的可用性和可扩展性至关重要。这方面的研究成果较少，所以适合中小企业的轻量级ESB架构设计研究是具有十分重大的实际意义的。

[1] Wiki, Enterprise service bus

[2]IBM, Clustering and high availability in an enterprise service bus

[3]马 国耀,吴 宇, IBM ESB 产品之间的比较及应用场景: 第 1 部分，IBM ESB 产品之间的比较

[4]IBM, Clustering and high availability in an enterprise service bus

 

转载于:https://www.cnblogs.com/jonasli/archive/2009/04/08/1431960.html