什么是ESB，它有什么用？

在上一份工作中，有很多关于“企业服务总线”（ESB）的讨论。我阅读了一本有关它的概念书，但从未真正理解过如何具体实现/集成它。我熟悉SOA /排队/目录服务/等。但我不明白ESB到底是什么。

您只是以不同的方式将所有应用程序连接到它，这是具体的事情（服务/服务器/代理/等等），还是仅是概念性的系统设计方式？

任何解释或与优秀示例的链接将不胜感激。谢谢。

这是一个相当高级的抽象概念。ESB的中心思想是提供中间件和接口，使企业无需编写代码即可连接其应用程序。

这可能包括调解以协调不兼容的协议，数据和交互。

一切都通过的中央总线的想法为附加的抽象层提供了机会。使用行业标准将其他应用程序，客户端等“插入”到此总线中，可以轻松连接具有不同需求的新服务，数据源和客户端。

实际实施

就实际实现而言，这是大型企业支持业务的领域。尽管这很笼统，但我们的目标是一个理想的目标，可以通过与互联网的比较从某种程度上了解它：

与互联网相似

一条大型通信总线，用途和数据千差万别，但都运行标准化协议。

实际上，可以编写一个HTTP至FTP连接器，该连接器使浏览器无需调用FTP客户端即可访问FTP站点（通常现在内置于浏览器中）。

混搭

混搭演示了一个有趣的实现-从旧金山当局获得一些公交路线数据，从Google获得地图，从Yahoo获得带有评分的寿司吧位置，并运行一个简单的查询，为您提供最接近的寿司吧，对其进行加权以使您成为愿意走得更远以获得更好的酒吧。

所有完全不同的服务，本身都不兼容，但是可以使用标准连接器（例如yahoo管道）将它们组合在一起，形成一个凝聚而有用的整体。

-亚当

免责声明：我为IBM工作，并就WebSphere ESB进行咨询，WebSphere ESB是一种旨在用来构建ESB的IBM产品。以下是我的观点，不一定反映IBM的立场。

不幸的是，ESB对不同的人来说是不同的事情。

对我而言，ESB是可以插入SOA（面向服务的体系结构）的任何技术，使您可以将不同的系统连接在一起。它通常执行协议转换，消息修改，路由，日志记录，充当安全网关等功能。例如，您可能使用ESB将以前只能作为Web服务使用的服务公开为基于JMS的服务。

在这方面，ESB实现（或更准确地说，是用于销售ESB的软件，例如我所咨询的产品）在技术上通常与过去称为消息传递或排队代理的技术相似，尽管目的有所不同，因为（正如首字母缩写所暗示的那样）它是围绕服务而不是将消息从一个地方移动到另一个地方的。技术上区分的重要性有待商of。

我在商业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}）

如果您在面向服务的体系结构中做同样的事情，则需要

1. 安装附加软件
2. 学习很多新概念
3. 在ESB的管理gui中定义新的Java组件
4. 实施一些由ESB控制的接口
5. sendJms（getDestination（），{MapMessage trader =“ pete” price = 101.4 vol = 100}）-请注意，目标是从ESB注入的

第一次可能有点痛苦，但我想您可以习惯它，就像您可以习惯EJB的;-)

您可以说MOM系统是“无类型的”（动态结构），而ESB是“类型的”（静态结构）。原始消息传递与ESB的权衡类似于其他未键入/键入的选择：

• REST与SOAP
• 未验证的XML与使用XSD验证的XML
• Groovy与Java
• 解释语言与编译语言

对于较小的项目，最好快速地散列功能（例如Groovy代码），但是对于较大的项目，最好有一个调试器（例如Java），当事情发生问题时可以提前得到警告，并在人们投入使用之前为人们制定标准项目。

因此，如果您的项目有太多人通过签入未经验证的更改来破坏系统，请采用更多的结构（ESB代替MOM）。如果您的项目因无法及时完成工作而苦恼-选择更简单，无类型的解决方案。如果两者兼而有之，请找顾问（开个玩笑；-）

好吧，这取决于您问的是谁...许多人会说这是一块“中间件”，它将各种“业务逻辑”片段连接在一起，以使这些模块之间的消息传递中的编码不再存在。我认为这已经足够笼统了，但是我相信您已经通过Wikipedia和其他方式到达那里了。

那些拥有出色ESB拯救世界的人会看到它，因为它是最常见的东西，它是一切工作的枢纽。大多数ESB实施都致力于封装我们在业务软件中看到的所有重复性任务。这意味着大多数ESB负责数据传输，安全性，日志记录，协议转换，事件系统，通过Web服务进行的api公开等。

我认为我已经很清楚了……希望能有所帮助。

看一下我的演讲“为选择而宠爱-如何选择正确的ESB ”。

我将说明何时使用ESB，Integration Suite或仅使用Integration Framework（例如Apache Camel）。我还将讨论开源ESB与专有ESB之间的区别。

除了可以从Wikipedia获得的标准定义之外。我发现它是连接跨多种平台和技术的一堆旧系统的绝佳工具。它也是构建分布式工作流和状态管理系统（例如总帐）的好工具。

但是，维护和扩展非常昂贵，复杂且不方便，因此，作为扩展应用程序的通用工具，它是一项糟糕的技术选择。