揭示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服务治理以及文件传输等热点功能。

技术手册>更多

  • BPM资源指南

    业务流程管理BPM究竟是怎么回事?BPM资源指南涵盖了BPM工具的最新消息、举措和平台。了解业务流程建模符号、如何采用SOA影响的BPM建模工具,以及如何得到改善,以致业务分析师可以发挥重大作用的BPM举措。

  • SAML技术手册

    安全是所有Web项目在设计时都要考虑的一个重要因素。无论是选择最短口令,决定何时使用SSL加密HTTP会话,还是通过自动登录cookie来识别用户,都经常要付出重大的设计努力,以保护用户的身份信息和他们可能存放于Web站点的其他资料。糟糕的安全性可能带来公关灾难。下面我们就来具体看一下SAML在这里所起到的重要作用。

  • SOA之云开发技术手册

    十年前,面向服务架构突然出现在IT舞台上,而且许多公司已经在SOA应用上进行了大量的投资。现在云计算在IT舞台上更是独领风骚。SOA之于云,云之于SOA的意义又是怎样的。很明显,云计算的成功取决于它能够给现有的SOA实现增加价值的能力。而SOA的使用也促进了云开发。

  • SOA与MDM知识解析

    大多数企业领导人都同意这样的观点:数据是重要的战略资产。因此,有效的信息管理一直是令人难以捉摸的问题。通过正确地使用SOA架构,企业能够利用自己现有的系统,在保持这些系统基本不变的同时为各种单独的应用程序之间有效的信息共享创建一个新的集成解决方案。本技术手册对于SOA与MDM知识进行了简要解析。

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