企业服务总线（ESB），.NET服务总线（Windows Azure AppFabric服务总线），NServiceBus，RhinoServiceBus，MassTransit等。
我试图了解这些技术的共同点或共同点。
我今天早些时候参加了JuvalLöwy关于.NET Service Bus的演讲，他说.NET Service Bus可以用作ESB的穷人版本，所以我认为这意味着.NET Service Bus不是ESB，其他任何一个都是真正的ESB吗？
如果其他任何一个都是真正的ESB，那么什么会使它们成为真正的ESB而不是.NET Service Bus？
答案 0 :(得分：37)
我同意另一张海报：ESB有点像SOA，这是一个通用的定义，主要用作营销卖点，而不是你必须满足的严格标准。
来自维基百科：
评论员对是否存在不同意见 定义企业服务总线 （ESB）作为建筑风格，a 软件产品，或一组 软件产品。使用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://plus.google.com/112678702228711889851/posts/eVeouesvaVX
答案 1 :(得分：36)
我认为您需要了解ESB更像是一个营销术语而不是技术术语。许多供应商都在这个旗帜下展示技术。
要看的是Bus Architectural Style，其中事件源和接收器协作。 NServiceBus，RhinoServiceBus和MassTransit具有发布和订阅内置事件的概念 - .NET Service Bus不会。
上述三者之间的差异在于形式而非功能 - 稳定性，文档，社区等。
希望有所帮助。