揭示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遇到Web 2.0

    Web 2.0是2003年之后互联网的热门概念之一,不过对什么是Web2.0并没有很严格的定义。一般来说Web 2.0是相对Web1.0的新的一类互联网应用的统称。

  • 移动中间件服务技术手册

    移动中间件是连接不同的移动应用,程序和系统的一种软件。移动中间件实际上隐藏了多种复杂性:在移动环境下工作的复杂性,允许设备对设备的流畅交互的复杂性,移动与计算机集成的复杂性和移动应用开发的复杂性。和其它的中间件一样,移动中间件也是通过提供信息服务来使不同的应用之间进行通话的一个典型。随着多样化的平台和设备进入到移动空间,移到中间件已经变得越越重要。随之而来的结果就是,众多移动中间件厂商纷纷提供开发服务,以解决快速增长的移动硬件与移动软件市场。本技术手册将介绍移动开发对于面向服务架构的影响,以及未来移动中间件可以实现哪些功能,在这个过程中我们有哪些经验和技巧可以参照。

  • SOA测试全面指导

    在SOA环境中,测试团队超越了传统的以应用程序为中心的功能和性能测试。SOA需要整合地测试界面和服务,这些界面和服务有助于组合利用不同的系统、平台以及相关安全标准。要测试这些应用程序时,就提出了独特挑战。那么如何应对这些挑战呢?下面我们来具体看一下。

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或者是服务网关,但是不要和只适用于这些消息自己的集成逻辑混合。把这个逻辑放在其他实例中,或者甚至是其他更适合这项任务的技术中。