Windows Azure平台AppFabric Service Bus和Access Control常见问题解答

 

公告：本博客为微软云计算中文博客的镜像博客。部分文章因为博客兼容性问题，会影响阅读体验。如遇此情况，请访问原博客。

 

 

什么是 Windows Azure 平台的AppFabric?

通过AppFabric，微软使得开发者能够更简便的构建和管理复合型应用程序，无论是在服务器还是在云环境中。

 Windows Azure 平台的AppFabric, 之前被称为 “.NET Services”, 提供基于云的服务，帮助开发者通过Windows Azure、Windows Server 、和众多其他平台，连接至应用程序与服务。如今，它包括了 Service Bus 和Access Control功能。Windows Server AppFabric 包括了对运行在非云端的应用程序的缓存功能，工作流和服务的管理功能。

Windows Azure 平台 AppFabric 构建于 Windows Azure之上, 为需要将云服务与非云端的系统集成的客服，提供安全的连通性与访问控制，完成B2B的集成，或连接至远程设备。

 Service Bus 在服务与应用程序之间允许安全的连通性 （通过防火墙或网络界限），可以使用大量通信模式。

Access Control Service 为REST 网络服务提供了联合的、基于声明的访问控制。开发者可以使用这些服务构建分布式或混合式的应用程序与服务。

 

开发者如何使用Service Bus 以及 Access Control?

自从去年我们发布了Windows Azure的第一个CTP，顾客已经意识到将连通性作为服务，是他们现代化计算架构的关键要求,它包括云应用程序与非云端系统的混合。针对这一反馈，现在Windows Azure平台的AppFabric通过Service Bus和Access Control提供了原生的连通性 ，同样的，它也将计算与存储作为一个云服务提供。

 

对于简单的综合方案，远程服务和复杂的协议数据封装，Service Bus 提供了开发者连接应用程序，以及选择如何通信的弹性。这有利于帮助他们构建分布式与复合式的应用程序，同时也能应对防火墙、NAT、动态IP、独立域名、验证系统阻挡带来的挑战。 Access Control 使得开发者将授权决策客观化，成为联合的，基于申明的方法。 这有助于他们开发用于REST 网络服务和Service Bus通信，更简单的和易于管理访问控制逻辑。这都将意味着当他们要拓展已有软件至云端时，开发者会更高效、与商业伙伴合作时更迅捷、拓展新用户时更集中。因为构建于Windows Azure, Service Bus 和 Access Control 能够与您的云端应用程序与数据协同工作。此外， Service Bus 和Access Control 自然的带来了 Windows Azure 平台的好处，例如动态拓展,自动化服务管理，按需收费以及SLA支持的可靠性。所有这一切都托管于微软数据中心，所以您可以更关注开发业务逻辑，减少构建管理基础设施的时间。

在最新的November CTP中 Service Bus and Access Control引入了哪些新特性?

November CTP 关注于对 Service Bus (SB) 和Access Control (ACS)做一些设计性的关键变化。在November CTP中, Service Bus 和  Access Control服务现在包括的特性将在明年早期商用时可用。注意， Service Bus 和 Access Control现在运行在Windows Azure之上。 November CTP更新于变化为 :

·      Access Control: November CTP中, 我们关注于围绕对于REST网络服务的访问控制的未满足的需求。为REST网络服务授权与支持提供健壮的基础设施 。

·      Service Bus: Service Bus 现在提供信息缓冲区来支持持久化与异步信息。它也为每个解决方案提供更多‘客户端’、‘服务’以及连接数。

 

 November CTP 更新与变化对于开发者为Service Bus 以及 Access Control构建应用程序意味什么？这些变化的意义？

事实上，REST网络服务在WEB开发者间越发流行起来。我们从社区接收到的反馈来看，缺乏对于REST网络服务的访问控制是服务开发者如今要面对的一个主要难点。

 协同工作能力仍然是我们的目标，这意味着我们会简化ACS的访问方式 ，以便访问控制方案与REST能很好的集成。 这被设计来吸引那些想要一个简单方法使用Service Bus 和 Access Control 或者在非微软平台上使用这些服务的开发者。同时，在未来我们仍然以实现SSO 以及网站授权、对WS-*的支持，联合大量的web与企业验证提供商为目标。

 

November CTP 的Service Bus 和Access Control如何使用户或开发者收益?

为了充分运用云计算带来的机会，用户需要具有弹性的在多种硬件与软件平台上运行他们的应用程序以及服务，并有无数的部署方案。 Service Bus和Access Control 简化了如何让非云端与云端应用程序松耦合，并在业务之间集成。

Service Bus有何更改?

 November 2009 CTP中包含一些对于July 2009 CTP 版本功能的删减。这些删减主要关注在Routers 和 Queues上, Service Bus团队会在接下来的版本中改善拓展这些功能。

Service Bus的“Routers”有何变化?

在 November 2009 CTP伊始，我们已决定暂时移除“Routers”. 虽然我们知道会对一些客户造成负面影响，我们已决定当前的Router的实现需要重构，让其有一个健壮的基础，以便能进行计划中的对于特性集得拓展。暂时移除Routers能让我们加速重构，恢复Router健壮的功能性。
          我们坚信 Routers对于Service Bus来说是一个重要的特性，能支持多种信息传递架构。

对于构建了依赖Router功能的应用程序的用户，我们提供了一个案例，展示了如何利用现有的Service Bus特性实现类Router功能的方法，包括多播，任播以及推送类型的信息操作。此样例是Service Bus 和 Access Control的November 2009 SDK 的一部分。

 

Service Bus的“Queue”何变化?

          November 2009 CTP中, Queues 被一个更简单的Message Buffers临时所取代。 此改变的动机为我们需要为缓冲区的持久性、信息投递保证性以及其他增强的信息投递语义奠定基础。.

现有Queue 实现的改变如下：

·      最大能持有 1MB 的数据。

·      每次请求出列（Dequeue）操作只返回一条信息。

·      Overflow Policy 会限制于 Reject 。

·      Message Buffers 会支持一个简化配置元素集合，包括:授权，发现性，传送防护，过期失效，最大信息数。

·      Message Buffers 只可被 REST 访问 (之前我们也支持WS-Transfer)

其他所有方面，Message Buffers 与July 2009 CTP 中 Queues的实现一致。

 November CTP 更新中Access Control具体有哪些变化？

November 2009 CTP 中, 我们关注于REST网络服务的访问控制的未满足的需求。这意味着前一个CTP版本中的WS-Trust特性将会暂时不可用。我们关注于为REST网络服务授权与支持提供健壮的基础设施 。在未来版本中，一旦这些基础设施就位，ACS特性，例如单点登录、跨越REST/SOAP的丰富的企业WS*支持将可用。

 

为何对Access Control做这些变化?

随着REST网络服务在web与企业开发者间的流行，市场上出现了一个验证与访问控制技术的缺口。如今，REST网络服务的开发者缺少一个简单可用的方法来保证他们服务的安全。他们面临着对于管理验证与访问控制缺乏一致性与公共模式。而某种程度上，与REST得注重简洁是一致的。当REST开发者转向企业，他们对于健壮的安全性有着与日俱增的需求。他们需要给与更多的企业用户的系统安全，以及更复杂的验证管理方案。他们需要一个简单并与REST能够良好的集成的方法 。

          将此问题作为区分Access Control的机会，并为更大范围的开发者服务，我们已进行了几个月的实验了（Access Control打包并传递安全令牌）。 虽然此简化设计满足了REST网络服务开发者的需求，但我们希望它能吸引所有的需要一个简便的方法来使用我们服务的，或需要在非微软平台使用Service Bus和Access Control的客户。 

          在 MIX09上，我们提出了一些评估客户对此方法是否感兴趣的想法。 另外，我们的目标是简化与加强协同合作性，我们通过多种不同的用户身份，展示了对SaaS网站访问控制的能力 。与我们的宗旨一致，我们展示了这个方法可以从根本上简化REST开发。从 MIX09的反应来看，我们的展示得到热烈反响，并证明我们是正确的。 

          从反馈来看，我们已能得出结论，缺乏对于REST网络服务的访问控制工具，是如今网络服务开发者面临的主要问题。我们坚信Access Control具有良好的定位，满足此需求，在某种程度上在安全与验证管理方面，实现了其他MSFT产品。简化的结合于对关键企业集成方案的支持，会确保Access Control能吸引企业用户,同时满足了更广泛的开发者群。未来,我们会加强对  WS-* 协议的完整支持,网站单点登录，丰富跨越REEST/SOAP的 Access Control产品。

 

原文链接： http://blog.csdn.net/azurechina/article/details/5597271