揭示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

暂无

ESB>更多

相关推荐

  • 总线技术究竟该不该用?

    曾几何时企业服务总线(ESB)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。

  • 企业应用集成的关键产品之工作流

    企业在努力实现业务敏捷、推动朝着对工人的个性化支持以及集成业务流程的组合发展。应用集成项目必须权衡这些要素。

  • 从ESB到微服务:如何演变?

    从web开发人员的角度看,大量的微服务部署到轻量级的Karaf 容器中,这就符合了ESB的定义。

  • 普元ESB6.3GA版发布 新增热点功能提高企业管控力

    2013年6月,国内最大的软件平台厂商普元发布了企业服务总线Primeton ESB 6.3正式版。该版本是在原有广受好评ESB产品基础上,融入了SOA服务治理以及文件传输等热点功能。

技术手册>更多

  • 特别关注:大型机应用现代化分析手册

    大型机应用现代化对于保持原有系统至关重要,而且大型机在大型企业高性能企业计算仍旧处于核心地位。这也是SOA成功案例中,目前正在进行的革新中最为显著的内容。以前,遗留大型机应用抵制重建,开发团队通过为意大利面式的代码排序,试图改写系统并非易事。那么现在这个问题该如何解决?有哪些好的案例可供参考?请看特别关注:大型机应用现代化。

  • 企业架构师工具包

    企业架构师如何创建一个有用的工具集呢?目前实践者正在将UML和TOGAF以及其他工具连同使用,从而能够构建出软件模型解决业务构想变成工作系统最重要的一步。但是需要高度熟练的架构师,来创造业务架构参考模型。成功的软件架构师会发现和企业匹配的工作参考模型会成为他们自定制添加“工具”的框架。下面专家的一些建议可以为我们提供一些引导。

  • 云服务设计入门指南

    正如我们所看到的,云计算还处在发展的早期阶段,通过观察大量的小型和新兴的提供云开发工具的公司就能够看到这一点。但是持续向前发展并颠覆传统开发方式的趋势已经越来越明朗。在这本技术手册中,我们将着重从云服务设计的基本内容入手,同时兼顾云端集成和云数据服务的相关内容。同时要提醒准备购买云服务的企业,在选择相关服务之前要避免落入厂商锁定的陷阱中。

  • SOA和虚拟化

    虚拟化和SOA之间是一种间接的、相辅相成的关系。也许在IT及业务转型中,两者的结合使用会发挥最大的优势。虚拟化有助于更快地显示部署基础设施的投资回报率(ROI)。

TechTarget

最新资源
  • 安全
  • 存储
  • CIO
  • 数据库
  • 服务器
  • 云计算
【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或者是服务网关,但是不要和只适用于这些消息自己的集成逻辑混合。把这个逻辑放在其他实例中,或者甚至是其他更适合这项任务的技术中。