企业服务总线（ESB）、.NET 服务总线（Windows Azure AppFabric 服务总线）、NServiceBus、RhinoServiceBus、MassTransit 等。
我试图了解这些技术的共同点或不共同点。
我今天早些时候参加了 Juval Löwy 关于 .NET 服务总线的演讲，他说 .NET 服务总线可以用作 ESB 的穷人版本，所以我认为这意味着 .NET 服务总线不是ESB，其他任何一个都是真正的 ESB 吗？
如果其他任何一个是真正的 ESB，与 .NET 服务总线相比，什么会使它们成为真正的 ESB？
我同意另一张海报：ESB 有点像 SOA，这是一个一般定义，主要用作营销卖点，而不是您必须满足的严格标准。
来自维基百科：
对于是否将企业服务总线 (ESB) 定义为一种架构风格、一个软件产品或一组软件产品，评论者意见不一。虽然使用 ESB 肯定意味着遵循特定的架构，但术语“企业服务总线”几乎总是指支持这种架构的软件基础架构，本质上，ESB 被认为是实现面向服务架构的平台。
ESB 将转换和路由等与流相关的概念引入了面向服务的体系结构。ESB 还可以为端点提供抽象。
作为一个术语，ESB 似乎是由 Dave Chappel 创造的，他是（曾经是？） Sonic Software 的技术布道者（以及作者“企业服务总线” - O'Reilly：2004 年 6 月，ISBN 0-596-00675-6）。我读过这本书并参加了 Chappell 的几次研讨会，恐怕这本书本身并不能帮助您确定产品 X 是否是“真正的”ESB。
一般来说，您应该寻找基于消息的东西（显然，这是最初的意图，即使其他一些公司，如 webMethods，使用该术语来表示他们的产品，这更面向 Web 服务）。
这个想法是让您的 IT 基础架构中的所有“服务”能够相互接收和发送消息。ESB 提供路由，并具有接口端点，因此如果您的原始应用程序工作 - 例如 - 通过 HTTP post 调用 JSP 页面，您有一个可以接收消息的小程序，使用其有效负载通过 HTTP 发布它，解释结果并使用这些构建消息响应。
基本上，想象一下，不是对所有事情都使用 Web 服务，而是使用消息队列、构建路由站以及消息队列和其他系统之间的接口。这是一个 ESB。
这很长，但很有启发性：https ://gist.github.com/chitchcock/1281611
（Steve Yegge 的一篇关于亚马逊如何转向“API for Everything”政策的文章）。
我认为您需要了解 ESB 与其说是技术术语，不如说是一个营销术语。许多供应商都在此旗帜下展示技术。
要看的是总线架构风格，其中事件源和接收器协作。NServiceBus、RhinoServiceBus 和 MassTransit 具有发布和订阅内置事件的概念 - .NET 服务总线没有。
上述三者的区别更多的是形式而非功能——稳定性、文档、社区等。
希望有帮助。