企业服务总线（ESB）、.NET 服务总线（Windows Azure AppFabric 服务总线）、NServiceBus、RhinoServiceBus、MassTransit等技术都与IT技术有关。
我正在尝试理解这些技术的共同点或不同点。
今天早些时候，我参加了Juval Löwy的.NET服务总线演示，他说.NET服务总线可以用作贫民版的ESB，因此我认为.NET服务总线不是ESB，那么其他任何一个真正的ESB呢？
如果有任何其他真正的ESB，那么它们与.NET服务总线相比具有什么特点？
我同意其他发帖者的观点：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撰写的文章，讲述了Amazon如何实施“一切皆API”的策略)。
我认为你需要了解的是，ESB更多的是一个营销术语而不是技术术语。许多供应商都在这个旗帜下提供技术。
需要关注的是总线架构风格，在这种风格中，事件源和汇聚协作。NServiceBus、RhinoServiceBus和MassTransit都内置了发布和订阅事件的概念——.NET Service Bus没有。
这三种方法之间的区别更多是形式上的而不是功能上的——稳定性、文档、社区等。
希望对你有所帮助。
