我在Message Brokers和ESB上经历了不同的问题/文章(甚至在stackoverflow上).仍然不是一个线索,因为消息代理和ESB之间的CLEAR划分区别是什么？现在我在这里尝试比较产品,Websphere Broker和Mule ESB !!
首先,(任何版本)Webshere Broker是ESB吗？我们的IBM产品人员声称它是ESB!(我并不感到惊讶).
我的有限信息告诉我Message Broker在HUB-SPOKE模型上工作.然而,ESB适用于总线架构.那究竟是什么意思呢？我读过如果HUB失败(我猜不到)那么经纪人就完全失败了.这不是ESB的情况(所以那些人说).我在这里不明白的是"如果BUS怎么办"失败？
现在关于ESB和Brokers的常见内容是,它们提供路由,转换,编排等.所以如果它们都提供了这个,那么为什么我会选择一个而不是另一个.
另一个冲突领域是转型.与Message Brokers相比,ESB是否以不同的方式为其提供便利？我真的很喜欢这方面的一些见解.
现在谈论HORIZONTAL缩放.谁比谁更优秀？或者它们在复杂性(或任何其他因素)方面都具有相同的可扩展性.当然,Webshpere Broker会为每个盒子收费(更不用说每个cpu)了.我相信,即使是商业上的MULE ESB也不会这样做.暂且不说它的Cost部分,ESB扩展和Message Broker扩展的含义是什么.我碰巧知道您可以扩展到ESB中的服务级别.这是否可以在Message Broker中使用？
您可以在没有服务总线的情况下使用转换代理,反之亦然.就具体产品而言,我认为任何一个都不是纯粹的一个或另一个,因为每个产品都是对另一个产品的补充方式.有些产品在一个区域更强,另一个在另一个区域更强.也许需要根据哪个功能最好地涵盖个别问题来做出选择.
与ESB产品相比,经纪人可能拥有更好的内置"乐高积木"来构建转型链.作为ESB服务的经纪人可能会在负载下被压垮而且规模不大,或者可能缺乏强大的日记和处理期刊的工具.
一旦发现并修复了逻辑中的一个严重错误,一些ESB允许回滚数据库更新并将队列重放到已更正的应用程序中.我不认为大多数经纪人整合了这种级别的交易支持.为了在所有"交易"中工作,几乎必须是商业活动(销售,续订,所有权变更等),而不是像RPCish"数据库更新".
免责声明:我是IBM顾问,专门研究WebSphere ESB.此评论不以任何官方身份保留.
ESB更像是一种架构模式或概念而非产品 - 广泛地说,是一种基于服务的松散耦合工程方式.它的定义是争吵而不是完全一成不变的.通常,ESB是一组不相关的(在技术意义上)服务 - 它们公开接口,并且它们从其他服务中消费它们.通常情况下,没有涉及中心和辐射架构,尽管可以.
IBM确实将WebSphere Message Broker和WebSphere ESB都作为可以轻松构建ESB(以及DataPower硬件设备)的产品进行销售.它们有不同的技术根源,但在目的上有一些重叠.此外,这并不是说您无法构建具有许多其他未被标记为"ESB产品"的ESB.
这并不能回答您的所有问题,但希望能够解决IBM的问题.
Message Broker和ESB之间的区别主要是"总线"这个词.
对我来说,Message Broker是一个(通常很大的)进程,它将数据从一个结构转换为另一个结构或修改内容.
ESB是面向消息的中间件(MOM)以及其他服务,其中一个可以是 Message Broker.因此,ESB可以包含Message Broker作为其中一个组件.总线由多个进程组成,否则我不会将其称为"总线".总线的本质是有多个组件服务于不同的任务,每个组件通过MOM进行通信并遵守某种形式的"通用数据格式".总线包括:将数据发送到MOM的应用程序,数据库适配器,消息代理,MOM桥等.
分离有点渐进,但Message Broker体系结构和总线之间的最大区别在于粒度.如果您的任务是集成应用程序A,B,..,Z和几个数据库,则可以使用一个连接每个人的大型Message Broker来完成此任务.或者使用ESB,其中多个小组件只接管很少的任务.例如,一个适配器连接到A,另一个适配器连接到B(但它们不进行转换),然后每个适配器将它们的内容发送给一个(或多个)Message Broker,每个Message Broker都应尽可能简单 - 例如不必须知道'A'或'B'的数据模型.一个好的ESB应该在总线上有一个共同的数据定义,从各个应用程序的"不同"中抽象出来.
转换:ESB对转换没有帮助,除非它带有Message Broker.但无论如何,每个好的ESB都应该包含一个Message Broker.Message Broker应该是您的总线转换专家,但没有别的.
HORIZONTAL缩放:如果你只有三件事要连接(现在和永远),那么获得一个成熟的ESB可能是不值得的.Message Broker的优势在于它只是一个大流程.您可以在其中配置所有内容,并为所有数据映射,过滤和路由提供中心位置.
但是如果你有30个连接应用程序,一个Message Broker可能会停止运行.当然,您可以购买更多实例,运行冗余等等,但您应该将策略更改为"本地化"作业.每个应用程序的适配器(可能是一个小的Message Broker实例)应该能够生成和/或接收抽象的公共数据模型(例如,具有共享XSD的XML).可能还有一个用于转换任务的中央Message Broker,但该实例应该不知道数据模型A或B.因此,ESB应该将处理移动到专家组件,而不是将所有内容保存在中心位置.
我刚才读到了Udi Dahan的这篇文章,这可能会让你更清楚地看到我认为的一个根本区别.
http://www.udidahan.com/2011/03/24/bus-and-broker-pubsub-differences
引用:
对于给定的事件类型只能有一个发布者的规则是区分公交车与经纪人的事情之一,尽管两者显然允许您拥有多个订户
...
不幸的是,有许多代理商风格的技术正在企业服务总线的旗帜下销售.虽然某些产品能够以集中式和分布式方式(有时称为"联合"或"嵌入"模式)进行部署,但许多产品并未强制执行"每个事件类型的单一发布端点"规则.
没有这种限制,犯错就太容易了.
希望能帮助到你.
企业服务总线为业务提供三个关键值:
基于上下文或内容的交易路由;
从一个消息域或传输到另一个消息域或传输的转换;
多对多服务连接.
ESB提供松散的服务耦合,允许将服务重新组合成完全不同的应用程序上下文,而不是首次设想或开发服务时,并且无需重新编码应用程序即可促进应用程序的重用.WebSphere Message Broker(或现在称为IBM Integration Bus)是企业服务总线的主要示例.有关简单代码的例子,可以在几行中获得强大的功能,您可以在这里查看我的帖子:http: //soabus.org/viewtopic.php？f = 3&t = 13.IIB运行时内部的基本构造称为逻辑消息树(LMT).开发人员想要做的一切都是LMT上的某种操作.ESQL是开发人员可以用来在LMT上执行这些操作的最有效的语言,尽管支持许多其他语言(例如,Java,PHP,Python等).没有其他产品能够很好地开发ESB的效率和易用性应用程序而不是IBM Integration Bus,因为这些应用程序的90%编码是通过将节点拖放到托盘上完成的.只留下10%的编码由Message Flow开发人员完成.顺便说一句,IBM已经停止使用WebSphere ESB,并且许多与IBM Integration Bus竞争的产品已经好几年没有看到它们的任何新开发.可以在soabus.org上看到各种ESB产品列表.
京公网安备 11010802040832号 | 京ICP备19059560号-6 