在以前的工作中,有很多关于“企业服务总线”(ESB)的讨论。我阅读了有关它的概念性书籍的部分内容,但从未真正理解您将如何具体实现/集成它。我熟悉 SOA/队列/目录服务/等。但我不明白 ESB 到底是什么。
它是一个具体的东西(服务/服务器/代理/等),你只是以不同的方式将你的所有应用程序连接到它,还是只是一种设计系统的概念性方式?
任何解释或链接到好的例子将不胜感激。谢谢。
在以前的工作中,有很多关于“企业服务总线”(ESB)的讨论。我阅读了有关它的概念性书籍的部分内容,但从未真正理解您将如何具体实现/集成它。我熟悉 SOA/队列/目录服务/等。但我不明白 ESB 到底是什么。
它是一个具体的东西(服务/服务器/代理/等),你只是以不同的方式将你的所有应用程序连接到它,还是只是一种设计系统的概念性方式?
任何解释或链接到好的例子将不胜感激。谢谢。
这是一个相当高级的抽象概念。中心概念是 ESB 提供允许企业在不编写代码的情况下连接其应用程序的中间件和接口。
这可能包括调解不兼容的协议、数据和交互。
一切都通过中央总线的想法为额外的抽象层提供了机会。使用行业标准将其他应用程序、客户端等“插入”到该总线中,这样就可以相对容易地连接具有不同需求的新服务、数据源和客户端。
就实际实施而言,这是非常大的企业支持业务的领域。虽然它非常流行,但目标是通过与互联网的比较在某种程度上可以理解的理想:
一种具有广泛不同用途和数据的大型通信总线,但都运行标准化协议。
事实上,可以编写一个 HTTP 到 FTP 连接器,它允许浏览器访问 FTP 站点而无需调用 FTP 客户端(现在通常内置在浏览器中)。
混搭展示了一个有趣的实现——从旧金山当局获取一些公交路线数据,从谷歌获取地图,从雅虎获取寿司店的位置以及评级,然后运行一个简单的查询,为您提供最近的寿司店,对其进行加权,以便您成为为了更好的酒吧愿意走得更远一点。
所有完全不同的服务,它们本身不兼容,但使用标准连接器(例如 yahoo 管道)可以将它们拉到一个有凝聚力和有用的整体中。
-亚当
免责声明:我为 IBM 工作并就 WebSphere ESB 进行咨询,这是一种旨在用于构建 ESB 的 IBM 产品。以下是我的观点,并不一定反映 IBM 的立场。
不幸的是,ESB 对不同的人来说是不同的东西。
对我来说,ESB 是一种可以插入到 SOA(面向服务的架构)中的任何技术,允许您将不同的系统连接在一起。它经常执行协议转换、消息修改、路由、日志记录、充当安全网关等功能。例如,您可以使用 ESB 将以前只能作为 Web 服务提供的服务公开为基于 JMS 的服务。
在这方面,ESB 实现(或者更准确地说,出售用于构建 ESB 的软件——例如我所咨询的)通常在技术上类似于过去被称为消息传递或队列代理的技术,尽管目的有些不同,因为(正如首字母缩略词所暗示的那样)它以服务为导向,而不是将消息从一个地方移动到另一个地方。这种区别在技术上的重要性是一个见仁见智的问题。
我对商业 ESB 的体验是,它是一种夸大其词且成本高昂的技术,它所解决的问题与它所解决的问题一样多。ESB 将连接新系统和遗留系统,消息将通过总线传输,并且一切都将能够与其他一切无缝通信。加入一些弹性、编排,你就拥有了一个非常强大的企业应用软件。
当您尝试真正使用它们时,问题就来了,为总线编写、创建消息结构等的开销可能会超过好处。作为一个高成本的项目,ESB 被视为解决所有技术问题的灵丹妙药,它不是,太多时间花在总线上,而不是花在连接的应用程序/数据上。通常情况下,多个竞争标准会在同一个组织中争夺至高无上的地位,从而导致这些系统实际上应该修复的经典技术主导的孤岛。
恕我直言,最好使用创建少量特定接口,通常仅在需要它的系统之间使用 Web 服务。
它基本上是一种设计系统的概念性方法——软件公司试图通过在其上贴上“ESB”标签来向您推销更多产品,而经理们喜欢因为 ESB 从“更高级别”看起来不错。
ESB 基本上是一个带有附加数据模型和结构定义管理的 MOM(面向消息的中间件)。您对该总线上的所有应用程序和适配器都有一个通用数据定义(可以是具有共享 XSD 的 XML)。任何连接的东西都必须发送符合此数据定义的信息。ESB 支持这个公共数据定义的加载、共享和版本控制。将新组件连接到 ESB 时,与将其连接到 MOM 时相比,您可以期待更多的开箱即用“兼容性”。该总线上的每个组件在概念上都被视为“资源”——因此引入了一个额外的抽象来将发送者与接收者分离。
示例:假设您想在标准的面向消息的中间件中连接应用程序 A 和应用程序 B,让我们以 JMS 为例。您与在应用程序 B 上工作的同事交谈,就主题、消息类型和字段达成一致并发送它(伪代码): sendJms("TRADE.MSFT", {MapMessage trader="pete" price=101.4 vol=100})
如果你在面向服务的架构中做同样的事情,你需要
第一次可能有点痛苦,但我想你可以习惯它,就像你可以习惯 EJB 一样;-)
您可以说 MOM 系统是“无类型”(动态结构),而 ESB 是“类型”(静态结构)。原始消息传递与 ESB 的权衡类似于其他无类型/有类型的选择:
对于较小的项目,最好快速散列功能(例如 Groovy 代码),但对于较大的项目,最好有一个调试器(例如 Java),在出现问题时提前得到警告,并在人们提交之前有一个标准项目。
因此,如果您的项目有太多人通过签入未经验证的更改来破坏系统 - 转向更多的结构(ESB 而不是 MOM)。如果您的项目无法及时完成足够的事情,请选择更简单、无类型的解决方案。如果两者兼而有之 - 找一个顾问(开个玩笑;-)
嗯,这取决于你问谁......很多人会说它是一个“中间件”,它将各种“业务逻辑”连接在一起,从而将编码从这些模块之间的消息传递中解脱出来。我认为这是一个足够笼统的定义,但我敢肯定你已经通过维基百科和诸如此类的东西到达那里。
那些希望拥有伟大的 ESB 来拯救世界的人认为它是最常见的,是做所有事情的中心。大多数 ESB 实现都努力封装我们在业务软件中看到的所有重复性任务。这意味着大多数 ESB 负责数据传输、安全性、日志记录、协议转换、事件系统、通过 Web 服务公开 API 等。
我认为这已经很清楚了……希望对您有所帮助。
看看我的演讲“ Spoiled for Choice - How to select the right ESB ”。
我解释了何时使用 ESB、集成套件或仅使用集成框架(例如 Apache Camel)。我还讨论了开源 ESB 和专有 ESB 之间的区别。
除了您可以从Wikipedia获得的标准定义之外。我发现它是一个很好的工具,可以跨多个平台和技术连接一堆遗留系统。它也是构建分布式工作流和状态管理系统(如总账)的好工具。
但是,它的维护和扩展相当昂贵、复杂且不方便,这使得它作为扩展应用程序的通用工具是一个糟糕的技术选择。