Windows Server AppFabric：更好，更快，更便宜
微软全球副总裁Soma，负责微软公司Developer Division的工作，在博客上发布了文章 Windows Server AppFabric：更好，更快，更便宜 。微软服务器和Internet信息服务(IIS)没有提供用于部署、管理和监控特定类别Web应用程序的全方位的服务，Windows服务器AppFabric的推出是为了响应大量组织和开发商的要求，多年来他们一直希望微软提供“应用程序服务器”。微软服务器AppFabirc基本填补了这个空白，它作为微软服务器自由扩展以及预计Windows服务器将发行的本地组件的可用性。
Windows Server AppFabric作为Windows Server的扩展，应用程序可以部分或全部的免费应用。它提供了一系列功能来提高性能，并加强Web和混合应用的管理。Windows Server AppFabric使用我们所熟悉的.NET技术，提供了分布式缓存技术，以及分布式管理和监控的基础结构。
改进用户操作体验以及系统可扩展性的一种方法是加速他们对信息的访问。如果多个服务器上多个应用程序访问同一个数据库时，对数据的访问则成为瓶颈。如果asp.net页面等待访问数据库，增加更多的前端服务器是于事无补的。现在需要一种扩展的办法：如何将频繁访问的数据分布到多台服务器上直接让其访问，从而解决访问一台数据库服务器的瓶颈。一个行之有效的方法就是建立一个发布缓存服务（distributed cache），这个服务向多台客户端机器分发。相对于从一个单独的数据库获取数据，现在asp.net页面可以从多个不同的机器上获取数据了，负载均衡，应用程序会有更好的表现。这就是AppFabric Caching Services要做的。
AppFabric Caching Services的一个主要组件是缓存客户端（cache client），如asp.net页面，它访问缓存群集，缓存群集由多台运行缓存服务的服务器组成，每台服务器都运行一个AppFabric Caching Services的实例，且每个缓存服务都包含一些数据缓存。缓存客户端可以包含自己的本地缓存，通过软件方式作为AppFabric Caching Services的一部分对外提供服务。
当缓存客户端第一次使用数据，这些数据可以是asp.net应用程序的使用者提供的信息，也可以是数据库读取的值，可以通过AppFabric Caching Services客户端库明确的向缓存群集使用唯一的名字来存储这些数据。（后面也会说明，asp.net应用程序也可以同session对象透明的来做这一切，因此使用缓存服务并不需要对代码做任何改动）对于客户端来说，缓存群集中的所有缓存服务器显示为一个逻辑的缓存服务，客户端无需知道也不需要关心具体是哪一个服务器为其提供数据，如果选择了本地缓存，客户端也可以在其本地缓存中存储数据项。
当客户端需要再次访问相同的数据项时，需要使用数据项的名字。查询首先从本地缓存中查找（如果设置了本地缓存）。如果数据项能够找到，则直接返回缓存数据，如果数据没有在本地缓存，查询将被送到缓存群集，如果数据能够在缓存群集中找到，则从缓存群集返回数据。数据向客户端传送的过程，就是客户端提出数据请求，AppFabric Caching Services为其准备并返回结果。如果数据没有在本地和缓存群集找到，客户端需要从其他地方查询信息，如数据库。
AppFabric Caching Services被设计由.net应用程序使用，因此，缓存数据项可以是任何可以序列化的.net对象。一旦对象进入缓存，应用程序可以更新缓存的版本或者显示的删除它；缓存数据也可以被缓存服务自行删除，删除条件可以是设定的过期时间或者被更频繁访问的数据替代，缓存到本地的数据项同样如此，同时，本地缓存可以设置为与缓存群集的改变自动同步。
多个缓存客户端可以共享相同的缓存群集，这是有意义的，因为一个可伸缩扩展的应用程序可以横跨多个服务器复制它的业务逻辑（如asp.net页面），并访问缓存。同时，安全也是一个需要提出的问题，为了使共享的风险降到较低，缓存客户端或缓存服务器之间传递的数据需要数字签名和加密，管理员能够限制账户对每个缓存的访问权限。尽管如此，组织还需要保证使用同一个缓存的多个客户端是可信任的，因为他们默认可以相互访问相互之间的数据。
缓存是对各种各样的数据时非常有用的。例如，对于类似于在线销售的产品目录信息等变化较慢或基本没有变化的数据，缓存有很好的体验，它可以在同时满足多个客户端的请求；缓存的另一个应用是存储变化的数据，但同时只能有一个客户端访问，如asp.net的session对象。再次强调一下，不要发生对缓存的并发访问控制问题。
但是，对于需要变化又需要同时被多个客户端访问的数据应该怎么办呢？缓存服务仍然可以使用，但情形会复杂一下，并发控制是必须的。为了解决这个问题，AppFabric Caching Services提供了两种并发控制方式：一种是乐观的并发控制方式，即为每个缓存对象提供版本号；另一种是悲观的并发控制方式，即使用显式锁。
应用程序一般是通过服务的方式暴露功能，对于Windows应用程序来说，这些服务很多情况下是通过WCF实现的，同时，一些服务的逻辑通过工作流来实现会更好，因此，在工作流基础上创建WCF服务也会有很大的可能。我们怎么样让这些服务运行起来呢？windows提供了很多通用的host宿主方式，开发者可以按其所需创建host程序。但创建一个高效的、可管理的host宿主却不是容易的事情了。使用wcf与wf，通过Windows server自身提供的功能方便的实现对host的支持及管理，这就是AppFabric Hosting Services所要做的工作。
WCF提供常用暴露及使用服务的途径，WF提供创建工作流逻辑的支持。AppFabric既管理WCF服务，也管理工作流服务（工作流服务也是一种WCF服务）。其区别在于服务中包含的内容。WCF服务的内容就是你的代码。而对于工作流服务，你通常需要使用Visual Studio工作流设计器绘制你的工作流以及一组可重用的工作流活动。工作流活动中需包含一些活动，使你的工作流成为一个服务，并能调用其它的服务。
我们也可以将工作流活动理解为一个组件。你可以从已有的组件中创建新的活动，即集成活动。用不同的组件合成应用程序，这是一个非常强大的模型，不论对云端应用还是当今的普通应用程序都也非常有用。
Visual Studio WCF工作流服务应用模板帮助你在短时间内启动运行你的工作流服务，并能在AppFabric中查看结果。欲启动服务，你可以使用模板创建一个新的项目，并设置项目中的Web属性，使其使用本地的IIS服务器。构建你的项目并运行，内建的WCF测试客户端就会运行。你可以通过该测试客户端向你的工作流发送数据并查看结果。以代码为基础的WCF服务也有类似的模板，因此你可以立即将你的关注点放在用代码编写的业务逻辑上，而不用编写WCF基础结构或任何相关的宿主逻辑和管理功能——AppFabric替您完成了这些工作。
AppFabric操作板可以让你在IIS管理器中查看所有和你的代码及工作流服务相关的统计数据。工作流实例历史数据部分展现了已经激活和完成的工作流。操作板还可以帮助你监视和控制工作流的持久性。所有的服务调用都会被跟踪。创建你自己的监控事件并将其显示在操作板中也非常简单。
AppFabric从一个接一个的活动中跟踪工作流的执行，并将信息在操作板中表现出来。这对于故障分析以及理解某个工作流实例的流运行情况来说很有用。你甚至可以从你的工作流中向AppFabric暴露你的数据，并通过查询其数据找到它所包含的工作流实例。
更详细信息参见 http://www.microsoft.com/windowsserver2008/en/us/default.aspx