Message Broker和ESB之间的区别

我已经经历了Message Brokers和ESB上的不同问题/文章（甚至在stackoverflow上）。仍然不知道Message Broker和ESB之间的CLEAR分界是什么？现在我在这里试图比较产品，Websphere Broker和Mule ESB！

首先，（任何版本）Webshere Broker是一个ESB？我们的IBM产品家伙声称它是一个ESB！（我对此并不感到惊讶）。

我的有限信息告诉我，Message Broker在HUB-SPOKE模型上工作。然而，ESB在公共汽车架构上工作。那么这到底是什么意思呢？我读过比如果HUB失败（我猜不可用），那么经纪人完全失败。这不是一个ESB的情况（所以这些人说）。我不明白的是“如果公交车怎么办？

现在通常关于ESB和Brokers的东西是，它们提供了路由，转换，编排等等。所以如果两者都提供这个，那么为什么我会select一个呢。

冲突的另一个领域是关于变革。与Message Brokers相比，ESB是否以不同的方式来实现它？我真的很喜欢这方面的一些见解。

现在谈论水平缩放。谁胜过谁？或者，在复杂性（或任何其他因素）方面，它们都是同等可扩展的。当然成本明智，Webshpere经纪人是要收取你的每个盒子（更不用说每个CPU）。我相信，即使是商业MULE ESB也没有这样做。撇开成本部分，ESB扩展和Message Broker扩展的含义是什么？我碰巧知道你可以扩展到ESB的服务级别。在Message Broker中这可能吗？

您可以使用没有服务总线的转换代理，反之亦然。就具体的产品而言，我认为任何一个产品都不是纯粹的产品，而是因为每个产品都相互补充。一些产品在一个地区更强，另一个更强。也许需要根据哪个function最能涵盖个人问题来作出select。

一家券商可能比ESB产品有更好的内置“乐高积木”来构build转型链。作为ESB服务的经纪人可能会受到压力，不能很好地扩展，或者可能缺乏强大的日志和工具来处理期刊。

一些ESB允许数据库更新回滚，并且一旦发现并修复了逻辑中的令人震惊的错误，就可以将队列重播到更正后的应用程序中。我不认为大多数经纪人都会整合这种交易支持。为了在所有“交易”中工作，几乎必须是商业事件（销售，更新，所有权变更等），而不是像RPCish“数据库更新”那样的事情。

免责声明：我是一名IBM顾问，擅长WebSphere ESB。这个评论不是以任何官方身份留下的。

与产品相比，ESB更像是一种架构模式或概念 – 广泛而言，是基于服务的工程松耦合方式。它的定义已经过去了，并没有完全凝固。一般来说，一个ESB被设置为与技术意义上无关的服务 – 它们暴露接口，并从其他服务中消耗它们。一般来说，没有涉及到的中心辐射架构，尽pipe可以。

IBM当然会将WebSphere Message Broker和WebSphere ESB作为产品轻松构buildESB（以及DataPower硬件设备）。它们有不同的技术根源，但有一些重叠的目的。另外，这并不是说你不能用许多其他没有被标记为“ESB产品”的东西来构buildESB。

这并不能回答你所有的问题，但希望能够解决IBM的一部分问题。

我刚才读了Udi Dahan的这篇文章，这可能会让你更清楚地看到我的感受是一个根本的区别。

http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences

引用：

一个给定的事件types只能有一个发布者的规则是将公共汽车与经纪人区分开来的事情之一，尽pipe这两者显然允许你有多个订阅者

…

不幸的是，在企业服务总线的旗帜下，有许多经纪人式的技术正在市场上销售。虽然有些产品能够以集中式和分布式方式（有时称为“联合”或“embedded式”模式）进行部署，但许多产品并不强制执行“每个事件types的单个发布端点”规则。

没有这个约束，犯错就太容易了。

希望能帮助到你。

Message Broker和ESB之间的区别主要是“总线”这个词。

对我来说，Message Broker是一个（通常很大的）过程，它将数据从一个结构转换到另一个结构或修改内容。

ESB是面向消息的中间件（MOM）和附加服务，其中一个可以是 Message Broker。所以一个ESB可以包含一个Message Broker作为它的一个组件。一辆公共汽车由多个程序组成，否则我不会称之为“公共汽车”。公共汽车的性质是有多个组件服务于不同的任务，每个组件都通过MOM进行通信，并遵循某种“通用数据格式”。总线将包括：向MOM发送数据的应用程序，数据库适配器，Message Brokers，MOM网桥等。

分离是有点渐进的，但Message Broker体系结构和总线之间的最大区别在于粒度。如果您的任务是集成应用程序A，B，…，Z和一些数据库，则可以使用一个连接每个人和每个人的大型Message Broker来完成此任务。或者在一个ESB中，多个小组件接pipe一些小任务。例如，一个适配器连接到A，另一个适配器连接到B（但他们不做转换），然后每个适配器将它们的东西发送到一个（或多个）Message Broker，每个Message Broker都应尽可能简单 – 例如不能必须知道“A”或“B”的数据模型。一个好的ESB应该在公共汽车上有一个共同的数据定义，从个别应用程序的“不同性”中抽象出来。

转换：ESB对转换没有帮助，除非它带有Message Broker。但是每个好的ESB都应该包含一个Message Broker。 Message Broker应该是您公交专家的转型专家，但没有别的。

水平缩放：如果你只有3件事情要连接（现在和永远），那么获得一个完整的ESB可能是不值得的。 Message Broker具有只是一个大stream程的优势。您可以configuration所有内容，并为您的所有数据映射，过滤和路由设置一个中心位置。

但是如果你有30个应用程序连接，一个Message Broker可能会停下来。当然，你可以购买更多的实例，运行冗余等，但是你应该改变你的策略来“本地化”工作。每个应用程序的适配器（每个应用程序都可以是一个Message Broker实例）应该能够生成和/或接收一个抽象的通用数据模型（例如带有共享XSD的XML）。也可能有一个用于转换任务的中央Message Broker，但该实例应该不知道数据模型A或B.因此，ESB应将处理移至专家组件，而不是将所有内容都放在一个中心位置。

企业服务总线为业务提供了三个关键值：

交易的基于上下文或内容的路由;
从一个消息域或传输转换到另一个消息域或传输;
多对多的服务连接。

ESB提供了服务的松散耦合，允许将服务重构成完全不同的应用程序环境，而不是服务最初设想或开发时的环境，并促进应用程序的重用，而无需重新编码应用程序。 WebSphere Message Broker（或现在称为IBM Integration Bus）是企业服务总线的主要示例。作为一个简单的代码，可以在几行中引入强大的function，您可以在这里查看我的post： http : //soabus.org/viewtopic.php?f=3&t=13 。 IIB运行时内部的基本结构称为逻辑消息树 （LMT）。开发者想要做的一切都是在LMT上进行的一些操作。 ESQL是开发人员可以用来在LMT上执行这些操作的最有效的语言，但支持许多其他语言（例如，Java，PHP，Python等）。没有其他产品接近开发ESB的效率和易用性应用程序而不是IBM Integration Bus，因为这些应用程序的编码的90％是通过将节点拖放到托盘上来完成的。只留下10％的编码由消息stream程开发者完成。顺便说一句，WebSphere ESB已经被IBM停止了，许多与IBM Integration Bus相竞争的产品在几年前都没有看到有任何新的发展。在soabus.org上可以看到各种ESB产品列表。