Microsoft最近公开发布了Service Bus 1.0，该Service Bus可以免费地使用于具有适当license的Windows服务器上，这使得Windows服务器也具有了像Windows Azure消息服务这样的功能。
Service Bus for Windows使得用户可在任何Windows 2008 R2及更高版本服务器上提供和操作服务总线主题（Service Bus Topics ）和服务总线队列（Service Bus Queues ）。整套解决方案可在单台Windows机器上运行，也可支持高可用的多节点部署模型。该软件除了需要Windows操作系统之外，还需要SQL Server 2008 R2（及更高版本）作为持久层，以及Windows PowerShell 提供的服务管理。
目前，除了Microsoft Active Directory之外，该产品还缺乏任何访问控制服务组件和认证模块。此前，Microsoft曾经试图通过在本地和云端产品间“AppFabric”建立完全对称的关系。但是，唯一在两个环境中通用的产品是内存缓存（in-memory cache）引擎，Windows Azure团队最近丢弃了AppFabric这一产品名称。Microsoft似乎选定了“Service Bus”这一名称， 以下图为证。
如果想用Service Bus 1.0来进行开发，可以阅读该MSDN文档。另外，还可以参阅一下CloudFX library ，该库对Service Bus的一些复杂任务进行了抽象，比如实现消息重发等。
在.NET里除了Service Bus还有一些其他的消息服务软件，比如NServiceBus、 Rhino Service Bus 和 MassTransit.
IT服务公司Codit的首席架构师Sam Vanhoutte在一篇博文中阐述了一组场景，在这些场景中，使用自管理的环境比使用Microsoft的Windows Azure云更适合。
仅需持久消息传输的场景
如果仅仅需要在本地进行消息交换，你就可以使用Service Bus for Windows服务器很好地在应用及服务之间进行传输，并且保证消息传输的持久性和可靠性。
存储转发场景
通过Service Bus for Windows服务器，你可以在主题（Topic）上定义ForwardTo类型的订阅（subscription），只要消息匹配这些订阅规则，就会被自动转发到预先定义好的消息实体中。虽然ForwardTo不能将消息转发到远端的实体，但是有一个绕行方案可解决此问题，即定义一个订阅者，让它监听本地的ForwardTo实体，然后将其消息转发给公共实体。
分布式场景
多数企业是由多个不同的业务单元或子公司组成，这些单元和子公司需要互联互通。在许多企业里（往往在并购和收购之后），不同的子公司使用的技术不尽相同。所以，将Service Bus 用作消息交换网关是很好的选择，每个单元都可使用其自身标准（REST、SOAP、.NET、AMQP……）与此网关交互。
相关文章：
