通过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网络服务提供了联合的、基于声明的访问控制。开发者可以使用这些服务构建分布式或混合式的应用程序与服务。
自从去年我们发布了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 (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现在提供信息缓冲区来支持持久化与异步信息。它也为每个解决方案提供更多‘客户端’、‘服务’以及连接数。
事实上,REST网络服务在WEB开发者间越发流行起来。我们从社区接收到的反馈来看,缺乏对于REST网络服务的访问控制是服务开发者如今要面对的一个主要难点。
协同工作能力仍然是我们的目标,这意味着我们会简化ACS的访问方式,以便访问控制方案与REST能很好的集成。这被设计来吸引那些想要一个简单方法使用Service Bus和Access Control或者在非微软平台上使用这些服务的开发者。同时,在未来我们仍然以实现SSO以及网站授权、对WS-*的支持,联合大量的web与企业验证提供商为目标。
为了充分运用云计算带来的机会,用户需要具有弹性的在多种硬件与软件平台上运行他们的应用程序以及服务,并有无数的部署方案。Service Bus和Access Control简化了如何让非云端与云端应用程序松耦合,并在业务之间集成。
November 2009 CTP中包含一些对于July 2009 CTP版本功能的删减。这些删减主要关注在Routers和Queues上, Service Bus团队会在接下来的版本中改善拓展这些功能。
在November 2009 CTP伊始,我们已决定暂时移除“Routers”.虽然我们知道会对一些客户造成负面影响,我们已决定当前的Router的实现需要重构,让其有一个健壮的基础,以便能进行计划中的对于特性集得拓展。暂时移除Routers能让我们加速重构,恢复Router健壮的功能性。
我们坚信Routers对于Service Bus来说是一个重要的特性,能支持多种信息传递架构。
对于构建了依赖Router功能的应用程序的用户,我们提供了一个案例,展示了如何利用现有的Service Bus特性实现类Router功能的方法,包括多播,任播以及推送类型的信息操作。此样例是Service Bus和Access Control的November 2009 SDK的一部分。
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 2009 CTP中,我们关注于REST网络服务的访问控制的未满足的需求。这意味着前一个CTP版本中的WS-Trust特性将会暂时不可用。我们关注于为REST网络服务授权与支持提供健壮的基础设施。在未来版本中,一旦这些基础设施就位,ACS特性,例如单点登录、跨越REST/SOAP的丰富的企业WS*支持将可用。
随着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产品。