揭示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)被视为企业IT的核心。今天,不仅ESB受到了比被废弃还要糟糕的攻击,若干开发趋势似乎对更简单的消息总线也发起了质疑。

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

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

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

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

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

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

技术手册>更多

  • 企业Mashup应用指南

    Mashup是一个非常cool的新的应用程序种类。如果你想真正的了解它们,我们需要回过头来看看你现在的计算机,其实它就是一个非常好的帮助你理解mashup的模型。现在开源的操作系统无疑是非常好的apis的集合或应用程序编程接口,帮助开发者去构建其应用程序。计算机本身也是一个很好的为用户提供接口的例子,键盘和鼠标可以被理解为你通过计算机的接口而使用的不同的应用程序。本技术手册为读者提供了一些相关信息,如果需要深入了解mashup,读者可以借助其他参考资源。

  • 松散耦合的七个级别

    在软件领域,“耦合”一般指软件组件之间的依赖程度。那么,什么是依赖?各种依赖对耦合度和松散度有多大影响?软件耦合可以发生在许多级别。必须区分生成时(编译时)依赖和运行时依赖。在分布环境中,为了确定系统的耦合程度,必须分析各个级别。下面我们就来具体看一下。

  • 架构框架TOGAF学习指南

    TOAGF是一个架构框架,简而言之,TOGAF是一种协助发展,验收,运行,使用,和维护架构的工具。它是基于一个迭代(Iterative)的过程模型,支持最佳实践和一套可重用的现有架构资产。

  • SOA与IT治理

    治理意味着授权。它提供一个策略和最佳实践的框架,可以用这个框架定义谁有权做出何种类型的IT决策。它还能指定应对这些决策负责的人员。很多分析人员已经清晰地划定了治理和管理之间的区别,而重申这一区别是十分重要的。治理与具体的IT决策无关;它会决定有能力做出这些决策的人员所充当的角色。管理则通过治理指导原则获得授权,并做出具体的IT决策。

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