企业服务总线,.NET服务总线,NServiceBus和总线上的轮子

企业服务总线(ESB),.NET服务总线(Windows Azure AppFabric Service Bus),NServiceBus,RhinoServiceBus,MassTransit等.

我试图了解这些技术的共同点或共同点.

我参加了朱瓦尔·洛的基于.NET服务总线介绍今天早些时候,他说,.NET服务总线可以作为一个穷人版的ESB的,所以我会认为这意味着在.NET服务总线是不是ESB,其他任何一个都是真正的ESB吗？

如果其他任何一个都是真正的ESB,那么它们将成为真正的ESB而不是.NET服务总线？

我同意另一张海报:ESB有点像SOA,这是一个通用的定义,主要用作营销卖点,而不是你必须满足的严格标准.

来自维基百科:

评论员不同意是否将企业服务总线(ESB)定义为架构风格,软件产品或一组软件产品.虽然使用ESB肯定意味着遵守特定体系结构,但术语"企业服务总线"几乎总是表示支持这种体系结构的软件基础结构,并且实质上,ESB被认为是实现面向服务的体系结构的平台.

ESB将与流相关的概念(如转换和路由)引入面向服务的体系结构.ESB还可以为端点提供抽象.

ESB作为一个术语似乎是由Dave Chappel创造的,他是Sonic Software的技术传播者(和作者"Enterprise Service Bus" - O'Reilly:2004年6月,ISBN 0-596-00675-6).我已经阅读了这本书并参加了Chappell的几个研讨会,我担心这本书本身对帮助你决定产品X是否是"真正的"ESB没有多大帮助.

一般来说,你应该寻找基于消息的东西(显然,这是最初的意图,即使像webMethods这样的其他公司也使用这个术语来表示他们的产品,这更像是面向Web服务的).

我们的想法是让您的IT基础架构中的所有"服务"能够相互接收和发送消息.ESB提供路由,并具有接口端点,以便如果您的原始应用程序工作 - 例如 - 通过HTTP post调用JSP页面,您有一个小程序可以接收消息,使用其有效负载通过HTTP发布,解释结果并使用这些构建消息响应.

基本上,假设您不使用Web服务来代替所有内容,而是使用消息队列,构建路由站以及消息队列和其他系统之间的接口.这是一个ESB.

这很冗长,但很有启发性:https://plus.google.com/112678702228711889851/posts/eVeouesvaVX

我认为您需要了解ESB更像是一个营销术语而不是技术术语.许多供应商正在该旗帜下展示技术.

要看的是Bus Architectural Style,其中事件源和接收器协作.NServiceBus,RhinoServiceBus和MassTransit具有发布和订阅内置事件的概念 - 而.NET Service Bus则没有.

上述三者之间的区别在于形式而非功能 - 稳定性,文档,社区等.

希望有所帮助.