ESB、EAI、MCI、BPM联系与区别

首先，ESB、EAI、MCI、BPM这4种技术都和SOA沾边。

对ESB的一种说法是是SOA的核心；

EAI企业系统整合、MCI多渠道整合，这2个分别整合企业内、外部系统，分布式系统整合，当然跟SOA也靠的上。

BPM和SOA比较有意思，BPM说SOA不是必须的；SOA说BPM是其服务编排（ServiceOrchestration）的手段，事实上却是2者的结合更紧密了。

 ESB从大的方面说包含了EAI、MCI、BPM。即可以整合企业内部系统，当然也可以对外面访问的各种渠道做整合，BPM作为SOA服务的编排的工具。结合在一起体现了ESB的2大核心功能：服务的抽取和编排。

 

 

 

转载:http://blog.sina.com.cn/s/blog_62bcc50c0100yvgq.html

 esb就是eai+设计和使用的best practice的应用。且看看以下官方的比较论述：

1. 集成的本质

EAI的集成方式从本质而言是基于消息的集成，因此EAI的各组成部件，如适配器与hub，都带有消息转换与消息路由的功能，在EAI的运作过程中，单个应用系统只关心其与EAI连接部分消息的输入与输出，不关心具体的业务处理，业务处理都是在应用系统内部完成的。

SOA的集成方式，其本质是对业务功能服务化后根据业务流程进行编排，是真正意义上的基于功能服务的集成。当然在基于SOA的集成中同样包含了基于消息集成的功能。

因此基于SOA的集成方式比EAI的集成方式适用范围更广。

个人观点：无非是在设计接口时，是面向服务和面向消息的区别。关键在于使用者的设计方式。EAI本身又不是不能设计成支持服务的。

2. 集成对象的颗粒度

SOA和EAI从不同的视角切入去看待企业已有的信息资源，并基于此对企业已有的资源进行梳理、分类和集成。

        EAI从应用系统的层面去看待企业已有信息资源，企业的每一个应用系统被看作一个集成单元，EAI工作的目标就是，通过为这些已有的应用系统提供一种中间沟通方式，让这些应用软件之间可以进行数据的共享与交换，从而盘活这一个个独立的“信息孤岛”。

         SOA从提供服务、使用服务的角度去看待企业已有的信息资源。在这种方式下，同样的一种资源既可能是服务提供者，也同样可以是服务使用者； 在这种方式下，一个应用模块可能只提供一种服务，因此被封装成一个服务，也可能由于提供了多种服务，而需要进一步划分。

显然，SOA方式集成处理的颗粒度比EAI要小，因此SOA方式比EAI方式更具有灵活性。

个人观点：这丫的更不靠谱了。粒度的设计摆明主要是由使用者决定的嘛

3. 标准化

SOA在实现企业信息化集成的同时，也将实现企业级服务的高度可重用作为目标，因此，在SOA架构中任何一种接口、通讯、协议都是遵循相应的国际标准，如：标准描述语言（WSDL）、发现协议（UDDI)和消息协议(SOAP)等。

EAI则大多使用基于具体实施EAI企业中制定的私有标准。基于私有标准的优点是可以在一定程度上减轻EAI中间层对应用系统消息翻译转换的压力，在应用系统较少的情况下可以提高EAI的整体性能，但私有标准同时也对企业整合的灵活可扩展性上带来损失，当企业引入新的应用系统，或当某个应用系统需要做比较大的改动时，整个EAI总线的适应性将变得十分脆弱。

在系统较少的情况下或是系统集成的早期阶段，采用私有标准的EAI会体现出性能高，实现难度低等优点，但在企业规模不断增长的过程中，新引入系统的整合难度将因为标准的不统一而呈指数级上升。

个人观点：标准化。。。又是扣帽子的东西。这个eai也可以设计成支持这些协议吧。

4. 灵活可扩展性

由于对标准的良好支持，使得SOA具有可灵活扩展的特性，而EAI要达到同样的扩展效果，其代价将远远高于SOA。例如，现在有甲、乙两个系统需要集成。假设它们通过SOA完成集成形成A方案，使用EAI完成集成形成B方案。当集成需求发生变化后，甲乙两个系统需要以另外一种业务逻辑进行集成。对于A方案而言，所需要做的工作比较简单，只需将之前的业务逻辑打开，重新组合一下业务逻辑就可以实现。而对于B方案而言，过程就会麻烦的多，需要根据新的业务逻辑，重新设计开发满足新业务逻辑需要的适配器和中间层的消息处理逻辑。

个人观点：这个怎么看也是设计层面比如消息（服务）粒度等问题了。

5. 重用性

企业信息化建设的投资可以分为两个部分：现有应用系统的维护与新系统的开发费用。在SOA架构下，各个服务是以完全独立的方式通过服务目录暴露在SOA集成平台上的，当新集成进来的应用系统需要使用现有的某个服务时，可以直接使用，无需再次开发，即服务是可重用的，只需用开发目前还没有的业务功能服务，这样可以充分利用现有的资源，降低成本。

通过EAI方式实现企业应用集成，其开发的适配器、中间层消息转换规则和消息路由都是紧耦合的，当新系统要在EAI中进行集成，便需要对现有的部分适配器、中间层消息转换规则与消息路由进行改造，无法重用。

因此，使用SOA比使用EAI更经济，尤其在多个应用系统相互集成的复杂场景下，SOA的优点将更加突出。

个人观点：也是由使用者的设计层面决定的吧。。。

6. SOA企业服务总线与EAI总线的比较

ESB(Enterprise Service Bus企业服务总线）是一种用于推动SOA的基础设施，从技术上而言，企业服务总线是一种消息传递的主干线，它用于提供协议转换，消息格式的转换，地址路由，接收并分发从各个连接到ESB的服务请求与系统传递来的消息。

在EAI的总线架构中，EAI为消息传播提供了一个中央消息主干线—Bus。应用程序使用适配器将消息发布到总线，消息通过总线流动到预订的应用程序中。总线是消息流动的通道，捆绑在应用软件端的适配器负责将消息在应用程序端的格式与符合总线标准的格式之间转换。因此，对于每一个应用程序，都需要单独为其开发符合应用程序自身要求的适配器，而由于没有遵循统一的标准，这些适配器是无法通用的。当某个应用系统进行比较大的改动时，则有可能存在对适配器的改造已经不能满足系统变更需求的情况，此时甚至有可能会牵涉到对BUS总线的修改，给企业信息架构带来很大的风险。

从ESB和EAI的总线工作过程上的区别可以看出ESB承担了更多的责任，做了更多的事情，为集成后的系统提供了完善、坚固的底层支持。而EAI的总线，只是一个消息的分发器。功能上的差别导致了系统集成到总线上的代价的巨大差异。

个人观点：EAI和ESB架构上有些区别的可能也在这里了。EAI有HUB和总线两种类型，总线类型的把消息处理适配器部署于应用系统，而hub类型的把消息处理适配器部署于hub系统。对于hub型的，加个消息适配器统一管理调用层应该就达到ESB的类似功效吧？至于总线类型的，也只需要轻量级的改造就可以支持类似功能。

题外话：总线类型的EAI我觉得有点像SOA里的SCA的概念，SCA的编程模型也是基于点对点的（应用系统之间直连)，消息转换功能也是放在应用系统的。这又引出一个话题，SCA和ESB有什么关系，很多文章关于这点又是一笔糊涂账，下篇文章我们也来试着分析一下。

至于说EAI本质是点对点的，这个我觉得有些牵强，EAI本身要支持集中式的改造起来也很容易的吧，还有就是使用者设计层面的事情了。

总结：ESB应该是在EAI的架构基础上进一步完善、标准化，并且辅以提供更多的best practice给使用者。这样说估计大家更清楚一些，但很多文章非得把两个说成不一样的东西，好像非得把ESB抬高一个层次，说成不一样的东西，这样反倒让人犯糊涂了。