现在可用：2011年9月版Service Bus

  • Article

如这个星期BUILD上所宣布的 ，2011年9月版的Service Bus现在可用了。这是自2010年1月服务建立以来生产环境最大的功能更新。

Service Bus提供了安全的连通性和消息传送能力，使得能够构建云里分布式的和松散耦合的应用程序，以及穿过非云端和云端的混合应用程序。它可用于各种通信和消息传递协议和模式，并让开发人员免于担心交付保险、可靠的消息传送和规模。在这里你能够学习更多有关Service Bus的信息。的全

此版本引入了Service Bus的增强功能，通过支持Queues、 Topics 和 Subscriptions、Rules等特征来改善pub/sub消息传送。此版本还在Windows Azure平台上一些新的情形中起作用，例如：

  • 异步云事件——向偶尔连接的客户端分送事件通知（例如，电话、远程worker、终端等等）。
  • 事件驱动面向服务体系结构(SOA)——构建松散耦合系统，可以随着时间演变。
  • 先进的内部应用程序消息传递——加载资源调配和为构建高扩张性且有弹性的应用程序的均衡负载。

Queues 和 Topics里具体化的新的消息传递功能作为服务预览在May 2011 CTP里首次可用 ，现在在Service Bus生产环境里也可用了。新的消息传递功能的一些详细功能，像唯独支持session连同跟踪session处理状态的功能，这些都直接被客户项目需求所告知的，这些项目是那些我们已经跟进的早期体验项目和在Service Bus上花了很大功夫的其他的一些微软开发成果。

改变了什么

在看到文档和开发实例后开发人员立即注意到的是新的消息传递功能的API与2011年5月份发布的CTP相比有所改变——响应客户的反馈。API变化的主要目标之一是合理化API和减少使用Service Bus新功能的代码量；下面我将给出几个例子。

另一个目标是使得API的运行时组件更加健壮——例如：开发人员不得不根据CTP中明确的残缺网络连接来处理异常并采取明确的步骤来替换“故障”的接收器或发送对象；在此版本中发布的消息传递客户端API将自动尝试重新连接，就像Service Bus的中级侦听器和客户端对象不能进入“故障”状态，要求由应用程序显示地恢复。

没有改变什么

开发人员不会看服务中断或产品中Service Bus行为发生巨大改变。即使这样，我们笼统地抽出桌布并换上一个新的——伴随一个很大扩展的功能集——而不移动桌上的水晶、瓷器或银器。现有的应用程序使用Service Bus仍然运行并且先前版本SDK的Microsoft.ServiceBus.dll assembly 1.0.x.x“能运行”——不需要对现有程序做额外的工作来适应新版本。

怎样使用新特性

然而，从.NET利用Service Bus的所有新功能确实需要使用包含新的消息传递功能API的Microsoft.ServiceBus.dll 1.5.x.x版本的新SDK。我们建议甚至是那些只使用Relay功能被重新编译和针对这个新程序集的测试以及1.0.x.x程序集的客户部署均作为定期的升级和部署循环的一部分开始被淘汰。

请记住新的1.5.x.x程序集只在完全.NET 4.0 framework中可用——从Silverlight、新的Windows 8 client profile、.NET 4.0 client profile或从需要.NET 3.5的应用程序中访问新的消息传递功能，开发人员可以利用客户端示例为Silverlight提供的通过Service Bus REST API来访问绝大多数功能。这些Silverlight示例和从Java、PHP和其他平台访问Service Bus的代码，在即将到来几个星期的course里将会可用——它们当中的每个都将使用适当的当地的运行时API，但是从术语和模式上重复.NET API。

使用REST API也是一个不错的选择，对于此版本，如果应用程序取决于Service Bus Queues 和 Topics，那么需要从紧凑的管理网络环境来访问，在那里向外HTTPS访问是可能的，但是对于出栈通信TCP 9354是不可用的。

直接使用新的.NET API的最大好处是新的Microsoft.ServiceBus.dll client bits使用的 TCP协议比HTTP有效得多。现在，对一些高级的功能像session和transaction support 来说TCP协议也是先决条件。

现有应用程序的新机遇

即使我们致力于向后兼容性，开发人员对于现有的Service Bus应用程序在未来的几个月内可能还要考虑几个方面。我们在接下来的帖子中将提供更具体的指导，但现在，这里有几个高级别的例子：

  • 对于绝大多数的用例，与消息缓冲区相比新的Queue功能是更好的选择。对于一些特殊的用例，消息缓冲区可能是首选，例如应用程序短暂依赖于消息缓冲区（它自动过期和消失）或应用程序依赖于消息缓冲区流策略来对发送者施加反压力——在大多数其他情况下，移动到Queue是一个非常好的办法。
  • NetEventRelayBinding提供中继多播单向消息——虽然是在最多只允许25个并发侦听器的情况下。许多情况下，用Topic更换这些路径是一个值得一试的方法，其中每个目标都有自己的使用新的NetMessagingBinding 的Subscription。这提供了更大的规模（多达2000个并发subscription）并且还可以删选subscription。NetEventRelayBinding仍然存在的不同是，如果监听者的接收速度在理论上低于发送者的发送速度它将向客户端施加反压力，这也是所有直接的TCP连接机制存在的不同。

相比于5月的CTP， API的变化

鉴于客户的反馈和我们用API构建应用程序的经验（我们在5月已经介绍了），我们对API做了相当多的改进，其中一些还使Service Bus Relay的功能受益——同时与现有的代码兼容。

其中最明显的变化是围绕安全性我们引入了‘token providers’这一概念，而不是直接供给证书进入API。使用证书类和在TransportClientEndpointBehavior上设置证书对Relay仍有可能，但是现在标记已经过时。Service Bus使用联合保证和由Windows Azure AppFabric Access Control service (ACS) 发行的通行令牌。API代理现在反映联邦性质，与令牌供应商成为独立的实体获得并免除进入Service Bus客户端基础设施所需要的令牌。好处是这个新的代理业务使得客户能够向API插入新的令牌供应商，需要证书和以特殊的方式与访问控制服务交互，托管web-browser控件可能会弹出一个对话框请求Facebook登录，将Facebook登录结果令牌传到ACS，然后将Service Bus访问令牌返回给应用程序。

管理API表面上也有一点转变。ServiceBusNamespaceClient现在被称为NamespaceManager ，当然，现在有方法允许检查特定的Queue、Topic或 Subscription是否存在。Namespace管理器现在也允许对Subscription规则的直接管理。使用删选器和各自的重组类来创建Subscription规则，例如SqlFilterExpression 现在只是 SqlFilter 。

最显著的变化和我们所希望的改进在核心Messaging API，‘under the hood’我们改变了很多东西，让我们能够摆脱面临API表面相当多的复杂性。

浏览新示例时，你将会发现MessagingFactory 和所有由它分发的对象拥有一个更为简单的状态管理模型。你不再需要“打开”对象来使用，也不再需要进入故障状态。那些改变差不多像是细节上的改变，它们是潜在的二进制协议中改进的直接结果，现在允许跨多个发件人和接受者、消息预取及也许是最重要的一点——如前面提到的，当连接丢失时自动重新连接session。换句话说，拥有程序现在可以有挂起的“接收”请求，断开连接或甚至操作系统休眠，一旦网络可用重新连接并自动重试获取消息。

NetMessagingBinding 是Queues 和 Topics绑定的新名字，提供与WCF的完全集成，在功能上类似于它的姊妹NetMsmqBinding。在服务器端，NetMessagingBinding提供自动消息泵，将消息从Queue
或 Subscription上拉下来，并且它是和WCF的 ReceiveContext机制集成在一起的。

在哪里？怎样？

如上所述——新版本现在已经可用了，你可以立即使用这些功能。必须的客户端程序集和示例在这里能下载到。也可以通过NuGet 或Web Platform Installer将这些运行时组件作为Windows Azure SDK的一部分来安装，并开始构建应用程序。

请注意2011年9月发布的版本只在Service Bus通常的开发环境中可用，不能在你以前可能用过的CTP环境(“appfabriclabs.com”)中使用。

这里是学习这个新版本的资源列表：

若要在BUILD上阅读Windows Azure相关的所有公告的相关信息，请阅读这个博客帖子： "JUST ANNOUNCED @ BUILD: New Windows Azure Toolkit for Windows 8, Windows Azure SDK 1.5, Geo-Replication for Windows Azure Storage, and More"。想知道有关BUILD的更多信息或相关演讲，请访问BUILD Virtual Press Room。并通过密切注意@WindowsAzure 和 @STBNewsBytes 来获取最新消息和BUILD在线访谈。

Clemens Vasters是Service Bus主要技术领导者。 Follow Clemens吧！ @clemensv

本文翻译自：https://blogs.msdn.com/b/windowsazure/archive/2011/09/16/the-service-bus-september-2011-release.aspx