integration - 有人可以用非嗡嗡声向我解释企业服务总线吗？

Question

我们的一些合作伙伴告诉我们，我们的软件需要与企业服务总线进行交互。经过研究后，我的直觉是说这只是在谈论我们需要一种平台无关的方式来回传递消息。我只是想了解我们的合作伙伴告诉我们的内容。我拒绝合作伙伴的要求是正确的，只是试图使我们的软件更符合流行语，还是他们在告诉我们我们应该听的内容(即使是使用buzzspeak编码)？

Answer 1

尽管ESB基于消息传递，但它不只是“消息传递”，而不仅仅是流行语。

因此，如果您从普通的老式异步消息开始，早期的网络往往是非常点对点的。您必须连接(即通过某个管理界面进行配置)每个连接和每对目的地，并且如果您敢于随意移动任何东西，则总会发生故障。因为连接点是手工布线的，所以这些网络从未达到高连接密度。增量成本太高，无法扩展。拓 flutter 中还嵌入了许多访问控制和策略。尽管缺乏连接密度，但实际上会阻碍这种方法的安全性，尽管它会抑制灵活性。

ESB尝试通过...解决这些问题。

目标/服务/资源的运行时解析

位置透明度

任意对任意连接和最大连接密度

专为冗余，水平可伸缩性，故障转移而设计

策略，访问控制，从拓 flutter

外部化的规则

在物理消息传递网络层

之上实现的逻辑消息传递网络层

公用 namespace

因此，当您的客户要求ESB兼容性时，他们想要像上面这样的东西。从应用程序的 Angular 来看，这还意味着...

避免消息亲和力，例如严格处理顺序或仅将请求寻址到特定节点而不是通用网络目标

的要求

能够在运行时动态解析目的地(即添加队列的另一个实例，它会自动开始获取流量，删除一个流量以及到其余节点的流量路由)

请求者和提供者应用程序彼此不知道彼此“住”的地方。请求者建立一个连接，无论调用

可能需要多少服务

通过策略而不是拓 flutter 进行授权

能够识别和处理重复项的服务提供商应用程序(根据JMS规范，由于 session 处理，请参阅“功能重复”)

能够运行服务提供商应用程序

的多个 Activity 实例

检测服务提供商应用程序，以便您可以查询网络状态或执行测试，而无需发送实际交易

另一方面，如果您的客户无法阐明这些内容，那么他​​们可能只希望能够选中“与ESB一起使用”框。