.net - Enterprise Service Bus、.NET Service Bus、NServiceBus 和总线上的轮子

Question

企业服务总线(ESB)、.NET 服务总线(Windows Azure AppFabric 服务总线)、NServiceBus、RhinoServiceBus、MassTransit 等。

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

我今天早些时候参加了 Juval Löwy 关于 .NET 服务总线的演讲，他说 .NET 服务总线可以用作 ESB 的穷人版本，所以我认为这意味着 .NET 服务总线不是ESB，其他任何一个都是真正的 ESB 吗？

如果其他任何一个是真正的 ESB，与 .NET 服务总线相比，什么会使它们成为真正的 ESB？

Answer 1

我同意另一张海报:ESB 有点像 SOA，这是一个一般定义，主要用作营销卖点，而不是您必须满足的严格标准。
来自维基百科:

Commentators disagree over whetherto define an Enterprise Service Bus(ESB) as an architectural style, asoftware product, or a group ofsoftware products. While use of an ESBcertainly implies adherence to aparticular architecture, the term“enterprise service bus” almost alwaysdenotes the software infrastructurethat enables such an architecture, andin essence, the ESB is considered aplatform to realize a service-orientedarchitecture.

An ESB brings flow-related conceptssuch as transformation and routing toa Service-Oriented Architecture. AnESB can also provide an abstractionfor endpoints.

作为一个术语，ESB 似乎是由 Dave Chappel 创造的，他是(曾经是？) Sonic Software 的技术布道者(以及作者“企业服务总线” - O'Reilly:2004 年 6 月，ISBN 0-596-00675-6)。我读过这本书并参加了 Chappell 的几次研讨会，恐怕这本书本身并不能帮助您确定产品 X 是否是“真正的”ESB。
一般来说，您应该寻找基于消息的东西(显然，这是最初的意图，即使其他一些公司，如 webMethods，使用该术语来表示他们的产品，这更面向 Web 服务)。
这个想法是让您的 IT 基础架构中的所有“服务”能够相互接收和发送消息。 ESB 提供路由，并具有接口(interface)端点，因此如果您的原始应用程序工作 - 例如 - 通过通过 HTTP post 调用 JSP 页面，您有一个可以接收消息的小程序，使用其有效负载通过 HTTP 发布消息，解释结果并使用这些构建消息响应。
基本上，想象一下，不是对所有事情都使用 Web 服务，而是使用消息队列、构建路由站以及消息队列和其他系统之间的接口(interface)。这是一个 ESB。

这很长，但很有启发性: https://gist.github.com/chitchcock/1281611
(Steve Yegge 的一篇关于亚马逊如何转向“API for Everything”政策的文章)。