本周，微软发布了Service Bus for Windows的bata版，其功能是基于云的Windows Azure Service Bus消息引擎的子集。这是微软向使用自管理产品交付快速且成熟的云整合解决方案迈出的第一步。

　　Windows Azure Service Bus包含一组用于跨云整合应用系统的产品。Relay service是Windows Azure Service Bus的第一大组件，开发者可用它在企业本地的Windows Communication Foundation（WCF） 服务与Windows Azure云之间建立双向交互通道。然后，服务消费者就可向公开的服务地址发送请求消息，Windows Azure Service Bus则会将消息安全地转发给本地服务。用户通过访问控制服务（Access Control Service）进行认证，该服务支持与Google、Facebook、Yahoo和微软的身份联盟。去年，微软给Windows Azure Service Bus增加了更多功能，例如，通过Service Bus EAI组件（参考InfoQ以前的报道）与本地业务线系统进行集成；通过主题和队列提供的持久的消息传输支持。

　　Service Bus for Windows使得用户可在任何Windows 2008 R2及更高版本服务器上提供和操作服务总线主题（Service Bus Topics ）和服务总线队列（Service Bus Queues ）。整套解决方案可在单台Windows机器上运行，也可支持高可用的多节点部署模型。该软件除了需要Windows操作系统之外，还需要SQL Server 2008 R2（及更高版本）作为持久层，以及Windows PowerShell 提供的服务管理。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……）与此网关交互。

　　此前，Microsoft曾经试图通过在本地和云端产品间“AppFabric”建立完全对称的关系。但是，唯一在两个环境中通用的产品是内存缓存（in-memory cache）引擎，Windows Azure团队最近丢弃了AppFabric这一产品名称。Microsoft似乎选定了“Service Bus”这一名称，而且Windows Azure Service Bus里缺失的功能有可能会在本地软件中找到。目前，除了Microsoft Active Directory之外，该产品还缺乏任何访问控制服务组件和认证模块。同样地，处于beta版的Windows Azure Service Bus EAI组件，在本地版中尚无明确的时间表。Vanhoutte提到了在本地和云端保持软件功能的同步所面临的挑战。

　　当前最大的疑问是Microsoft如何保持服务器版本的对称。服务器产品的发布步调与基于云的服务差别迥异。许多服务都在不断增加新特性，一直以来这些更新都搬到了服务器安装版本之上。我非常好奇这些更新采用的是怎样的发布周期。