揭示EAI和ESB之间的区别

日期:2011-10-26作者:Todd Bisk

EAI   ESB   BPM技术   遗留EAI工具   

【TechTarget中国原创】

ESB和EAI技术之间的区别是什么?

  在我最新一篇关于成功使用ESB文章发表之后,收到了很多反馈,基于这些反馈以及LinkedIn上SOA兴趣组关于 “进行ESB还是不进行是个问题” 的论点,我认为探讨一下ESB和EAI技术是很有用的。

  EAI或者企业应用集成在ESB被发明出来之前就存在很久了,这些技术旨在为管理点对点集成蔓延提供一种手段,这种集成蔓延经常以连接不同的系统之间出现,变得越来越重要。EAI技术允许这些集成集中管理,甚至是促成一个企业部门,像集成能力中心(ICC)或者集成卓越中心。不幸的是,很多EAI技术由于集中化兼并了所有集成逻辑而遭遇了性能问题,因为这样做十分复杂。

  ESB技术是随着SOA到来的。尽管一些ESB产品是全新的,也有相当一部分是EAI产品重新包装变成ESB。这就对于客户造成了一些困扰,正如一些案例中,企业不但有遗留集成产品,也有ESB、XML设备和Web服务管理产品,他们提供的功能都是重叠的。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

作者>更多

Todd Bisk
Todd Bisk

暂无

技术手册>更多

  • 智能BPM与业务流程工具

    Gartner认为iBPM要比运营型智能平台更优秀,表现在以下几个方面:iBPM套件提供更好的工作流,适配性案例管理以及结构化流程协调能力。

  • 云BPM新常态解析

    云端业务流程管理已经不再是什么新鲜事,更不再是什么可怕的方法来管理重要的业务流程。现在,它已经普遍被认为是一种新常态。组织已经从这一技术中获益,使它来更有效地访问和管理企业信息。

  • 企业IT集成指南

    随着云技术的不断采用,现代企业都面临着重大的集成问题。现在已经不再是把企业内部的数据和应用简单地缝合在一起,企业IT现在面临着整合着外部与内部信息的难题。

  • API开发与管理大作战

    2014将会是API管理方法新旧PK的一年,据Delyn Simons说,她领导了Mashery开发者的外展团队。应用编程接口(API)的主流化和私有化在新的一年也将掀起波澜,她在波士顿“Future Insights Ultimate Developer Event 2013”大会上预测说。

【TechTarget中国原创】

ESB和EAI技术之间的区别是什么?

  在我最新一篇关于成功使用ESB文章发表之后,收到了很多反馈,基于这些反馈以及LinkedIn上SOA兴趣组关于 “进行ESB还是不进行是个问题” 的论点,我认为探讨一下ESB和EAI技术是很有用的。

  EAI或者企业应用集成在ESB被发明出来之前就存在很久了,这些技术旨在为管理点对点集成蔓延提供一种手段,这种集成蔓延经常以连接不同的系统之间出现,变得越来越重要。EAI技术允许这些集成集中管理,甚至是促成一个企业部门,像集成能力中心(ICC)或者集成卓越中心。不幸的是,很多EAI技术由于集中化兼并了所有集成逻辑而遭遇了性能问题,因为这样做十分复杂。

  ESB技术是随着SOA到来的。尽管一些ESB产品是全新的,也有相当一部分是EAI产品重新包装变成ESB。这就对于客户造成了一些困扰,正如一些案例中,企业不但有遗留集成产品,也有ESB、XML设备和Web服务管理产品,他们提供的功能都是重叠的。当BPM技术开始得到关注时,就变得更为复杂了,正如很多EAI工具以同样的方式利用图形化建模环境进行集成自动化,BPM工具为流程编制提供了图形化建模环境。那么我们如何理清这些呢?

  首先,集成仍是必须的,而且一直都需要。尽管最佳路径仍旧是构建一个包含集成的系统,都使用统一的接口,有时这是不可能的。例如,你可能有两个第三方的系统,每一个都有自己的引入和输出集成技术。如果这两个不能立即兼容,他们可能不会兼容,你唯一的选择就是在二者之间放点东西进行集成。即使一端有固定的集成接口,在中间,你仍旧需要一些东西,因为你并不希望所有的系统都使用私有接口。

  其次,记住必须开发集成逻辑。即使“语言”是图形化环境,也不应该被认为是配置实践,就像配置防火墙或者是负载均衡器那样配置。这也正是我上一篇文章一再强调的内容。技术迈向开发人员可能也会促进运营策略管理和加强。技术如果面向运营人员可能就是很好的策略管理和加强,但是紧密配合开发集成逻辑。

  第三,理解技术的重叠领域,所以仍旧可能是购买了单一的技术。厂商构建了这种重叠,因为不是每一个公司都想在集成任何东西到任何EAI上花费数百万。然而,他们可能对于某个具体的单一ERP系统仍有集成需求。尽管ESB可能不具备遗留EAI工具的所有集成功能,但是可能对于很多场景十分有效。

  你需要避免什么呢?尽管这是一个单一的ESB部署,试图解决所有的服务交互以及集成逻辑的运营策略。在策略非故意修改、错误配置时或者是由于糟糕的责任分离,注定要面对性能瓶颈和运营风险。

  我有两个建议:

  第一,如我上一篇文章所述,尝试维护业务和集成逻辑以及配置运营策略之间的独立性,尽管使用同样的技术也要分离。这可能意味着要有分离的技术实例。

  第二,部署技术是为某处的运行时策略加强和集成逻辑负责,他们可能只处理受这些策略或者逻辑支持的流量。如果消息进入和离开你的ERP系统需要集成逻辑,在ERP系统之前放置ESB或者EAI,但是不能允许ESB为其他不包含在ERP系统进行简单WEB服务交互的应用处理流量。如果对于所有防火墙之外的web服务需求有一个流量控制的策略加强,对这些策略使用单一ESB或者是服务网关,但是不要和只适用于这些消息自己的集成逻辑混合。把这个逻辑放在其他实例中,或者甚至是其他更适合这项任务的技术中。