ESB技术调研报告

关于是否在新产品中应用ESB技术的调研报告  

ESB的概念

ESB全称为Enterprise Service Bus，即企业服务总线。它是传统中间件技术与XML、Web服务等技术结合的产物。ESB提供了网络中最基本的连接中枢，是构筑企业神经系统的必要元素。

ESB的出现改变了传统的软件架构，可以提供比传统中间件产品更为廉价的解决方案，同时它还可以消除不同应用之间的技术差异，让不同的应用服务器协调运作，实现了不同服务之间的通信与整合。从功能上看，ESB提供了事件驱动和文档导向的处理模式，以及分布式的运行管理机制，它支持基于内容的路由和过滤，具备了复杂数据的传输能力，并可以提供一系列的标准接口。

 

以面向服务的方式，实现异构、分布式应用系统之间松散耦合的集成共享、互联互通的基础软件平台

较早系统架构：

ESB处理后：

 

 

ESB的优势

 扩展的、基于标准的互连技术
      ESB包含了一个基于标准的消息系统，使企业内部以及外部整个价值链上的系统之间，可以很容易地通过异步或同步交换信息。ESB通过Web服务、J2EE、.NET和其他标准提供更强的系统互连功能。

 

灵活的、基于服务的应用组合
      基于面向服务的架构(SOA)，ESB应用模型允许复杂的分布式应用，包括跨越多个应用程序、系统和防火墙的集成解决方案，由事先开发和测试好的服务灵活组合而成，这为系统提供了易扩展性。

 

有效管理服务资源

当IT资源逐渐积累到一定数量级，企业必须借助更先进的技术对这些资源进行有效管理。ESB通过一个分布模型和多个容器型适配器推进了服务资源的有效管理。这个分布模型对于服务消费者来说，是完全透明的，从任何位置打开与ESB的会话，都可以访问到存在于所有的ESB上的任何一个服务提供者。这为服务资源的有效管理提供了良好的基础。只要在一个位置部署监控子系统，就能够监视所有的服务。有些ESB提供商，还通过专门的Registry服务和Repository服务，提供所有服务的元信息视图和运行状态视图。反过来，每个服务都可以以通知的形式向这个分布模型内的监控者发送自己的运行状态信息，而它们之间并不需要知道彼此的实际位置。

 

通过提高重用来降低总体拥有成本
      SOA方式直接提高了重用程度，降低了维护难度，因而降低了系统的总体拥有成本。

 

减少面市时间和提高生产率
      ESB通过重用组件和服务，以及SOA提供的简便的应用组织方式、基于标准的通信、转换和互连来提高生产率和减少面市时间。所有这些优势都来源于ESB架构中的每个组件对于通信、互连、转换、移植性和安全性标准的强有力支持。

ESB的风险

性能低

SOA由服务集成发展到软件服务化，又进一步发展到基于服务的高级开发，使软件系统增加了很多环节，软件内部形成了很多消耗，而随着SOA应用规模的扩大，这些消耗将带来潜在的市场风险。如何将这些消耗降低到最小，成为了令开发商十分头痛的问题。

 

事务处理难

事务问题已经在.net和j2ee得到了很好的解决。这些容器型事务为单点应用提供了很好的开发模型。但是SOA是一种多点应用模型，服务提供者之间关系更加松散，并且其技术实现几乎被忽略，所以容器型事务根本派不上用场，这就给大规模SOA应用设置了巨大的障碍。事务问题的解决可能会体现在两个方面：一是通过更加智能化的开发辅助工具减轻开发者的负担；另一方面可能是在局部提供针对数据库的多阶段提交型的事务支持，但这将限制服务提供者所采用的实现技术。

 

兼容性差

随着软件系统规模的日趋扩张，平台、技术的兼容性问题，已经成为构筑平等的商业环境的必要条件。而ESB在这个问题上所面临的困境则十分尴尬，几乎每个厂商所提供的ESB都使用自己的标准，移植问题并不在它们的考虑范围之内。Sun曾经推出过JBI，但是并没有得到主流厂商的推崇，后来不了了之。

主流软件平台提供商（IBM、BEA、JBoss、Oracle、IONA、Microsoft等）都提出了自己的ESB方案，但是他们都是扩展其现有平台（如WebSphere）使其具有ESB的一些关键特征。

ESB的产品

厂商名称	ESB主要产品	关键特性
商业ESB产品
IBM	IBM WebSphere ESB	提供了基于SCA的开发模式和完备的开发工具，并且提供了预先定义的元中介(Mediation Bean)。这样用户通过工具WID (WebSphere Integration Developer)，可以采用拖拽/配置的方式简单地开发中介信息流，实现ESB不再是复杂的任务。
Microsoft	Microsoft ESB	微软通过其应用平台提供了全面的ESB服务，包括：Windows Server®, .NET Framework, BizTalk® Server. 应用平台提供了一个基础架构，基于此可以灵活和安全地重复使用架构和商业服务，并具有协调原有的服务整合到新的端到端的业务流程中的能力。
BEA	AquaLogic Service Bus2.0	支持多种消息格式和传输协议，消除了消息之间的差距，发送方和接收方在不替换现有基础架构的 情况下，实现服务之间的快速集成和部署。可配置监控能力提供服务交互标准、消息跟踪事件和消息记录，并根据可配置的SLA设置界限和警告（不需要购买和集 成其他管理产品），支持有效的日常SOA运行，有在线建模能力。
IONA	Artix4.0	广泛的操作系统平台支持和编程语言支持，多协议集成；基于ART的高性能内核Artix底层 采用C++实现，不依赖于Java虚拟机，因此更具性能优势。Artix内核内存占用率低，更能充分利用操作系统资源，特别适合于大用户量、大并发量的企 业级应用。而ART的插件式结构也是用户能充分优化运行时环境，选用不同的插件集适用于不同的集成需求。
开源ESB产品
JBoss	JBoss ESB	JBossESB是JBoss推出的ESB的实现，也是JBoss的SOA产品的基础，JBossESB能够把抽象的SOA设计映射成具体实现。它作为企业应用程序、业务服务、业务组件与中间件交互的一个媒介，对实现整合及业务流程自动化起重要作用。
Apache	ServiceMix	ServiceMix是JBI规范的一种实现。它包涵了许多JBI组件，这些组件支持多种协议，比如JMS,HTTP,FTP,FILE等。同时也实现了EIP，规则和调度。早在几年前，它就已经成为了Apache的顶级项目。ApacheServiceMix 也整合了其他的开源项目，比如Apache ActiveMQ,Apache CXF,Apahe Camel,Apache ODE以及Apache Geronimo。
Sun	Open ESB	Open ESB是在Sun公司支持下的一个开源项目，其核心是基于JBI(Java Business Integration)规范的实现。Open ESB可运行在Glassfish应用服务中，同时Netbeans IDE也为Open ESB提供了拖拽式的开发工具，这是其他开源ESB不可匹敌的。
MuleSoft	Mule	Mule 是一个基于ESB架构理念的消息平台。它是可升级的、高分布式的对象代理，可以通过异步传输消息技术来无缝的处理服务与应用之间的交互。   Mule 的核心是一个基于SEDA的服务容器，该容器管理被称为通用消息对象（Universal Message Objects /UMO）的服务对象，而这些对象都是POJO
WSO2	WSO2 ESB	WSO2 ESB是一个基于Apache Synapse的开源项目，可以使用简单的Java、JavaScript、Ruby或者其他脚本语言进行扩展。除此之外，还可以用Spring Framework来配置中介流（mediation flow）。

 

ESB的应用

国内的比较重要典型的业务领域，电信、金融和电子政务领域目前面临一些迫切需要解决异构系统整合的问题。

 

电信领域

电信领域里的业务，BOS业务，客服业务和经营分析业务存在各自开发，各自管理与维护，这时候体现出来的弊端是对客户的服务商，管理的精细化，领导的科学决策上都体现不能满足需求的特性，特别电信面临更大的挑战是如何把产品快速推向市场，如何面对很多的增值业务的提出，如何面对访问的多样性和很多第三方支持的服务，现在都很难解决的难题，目前期望着SOA的架构可以解决这样的问题

案例：北京移动、中国移动

 

金融行业

金融行业经过十多年的发展形成了众多的业务系统，包括个人业务，对公业务，信贷，信用卡，网上银行等。过去都是以产品和业务为中心，现在要转向以客户为中心，过去的系统最突出的弊端是系统封闭性很强。在各个系统里面，各个业务紧耦合，要增加一个新的业务或改变一个业务都很难，维护成本也很高。目前通过SOA在金融领域里重要解决主机集成，打通和数据转换的关键业务。

案例：平安银行（采用神州数码的ESB产品，实施效果不好）、交通银行（采用IBM ESB产品，效果一般，性能是主要问题）、浙商银行、北京银行（Oracle实施）、美国Wachovia银行等

 

电子政务
电子政务常常在轮回先建设后整合的循环，并且表现出来永远是部门割裂，条块分割。在电子政务建设的时候，一开始都是为了某个需求开发一个系统，在某种环境下用，不考虑全局信息的共享，业务流程的联系，造成后面整合的时候成本很高，也造成这样一类系统难以应付管理模式的变化。

案例：香港政府

总的来说，ESB在国外有不少成功案例，但是在国内实施效果并不好，主要原因有两个：其一，国内在这方面的技术积累相对缺乏，经验不够；其二，实施困难，国外厂商提供的产品实施费用太高，缺乏随时的技术支持，国内厂商的产品功能和质量方面相对薄弱，而开源的产品缺乏必要的技术支持且资料不足，这些都给ESB的推广带来了不小的困难。

ESB在Qone Online中应用的必要性

利：

1.         ESB的概念很符合Qone Online的远景目标，即做一个大的集成平台，其上的服务都是可组装可插拔的。

2.         Qone Online也涉及到与其它异构系统的集成，未来可能不仅要集成项目管理相关的系统，也可能集成企业ERP、CRM、财务系统等，ESB与异构系统的集成是其重要的优势之一。

 

弊：

1.         目前ESB国内成功的案例太少，实施的话会有不小的风险；

2.         ESB的产品中，国外厂商（像IBM、微软）推出的产品解决方案相对完善，且有一些成功的案例，但是价格过于昂贵；国内厂商（像神州数码、金蝶）推出的产品，客户少，且实施效果较差；Qone Online做的话只能是基于开源的一些ESB产品，这样花费的工作会比较多，因为目前这方面的资料并不是太全；

3.         标准的问题，ESB的各个产品并没有一个完全统一的标准，移植的话是个问题。设想一下，假设我们基于ESB开发的Qone Online，卖给客户后，客户内部系统是基于另一种ESB产品，两者标准不一样的话集成起来估计问题会比较大。

4.         目前ESB的应用目的和场景，大都是企业自有内部系统的集成，故应用领域主要是金融、电信，而对Qone Online来说，更多的是希望集成客户内部的系统，而不仅仅是我们内部开发的一些业务模块。

<!-- END entry -->