Microsoft 通过 Service Bus for Windows 把云整合服务搬到本地

本周，微软发布了 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 如何保持服务器版本的对称。服务器产品的发布步调与基于云的服务差别迥异。许多服务都在不断增加新特性，一直以来这些更新都搬到了服务器安装版本之上。我非常好奇这些更新采用的是怎样的发布周期。

查看英文原文： Microsoft Brings Cloud Integration Services Onsite with Service Bus for Windows