概述 Velocity是微软推出的分布式缓存解决方案，为开发可扩展性，可用的，高性能的应用程提供支持，可以缓存各种类型的数据，如CLR对象、XML、二进制数据等，并且支持集群模式的缓存服务器。Velocity也将集成在.NET Framework 4.0中，本文将介绍Velocity的一些预备知识、安装配置以及开发一个简单的示例。 简介 既然是分布式的缓存平台，客户端应用程序能够与缓存服务器集群中的任何一台服务器通信，并且执行缓存操作，如新增缓存项，移除缓存项等。在Velocity中，提供了一套统一的API，开发者可以使用任何一种.NET语言来访问这些API，如图1所示： 图 1 物理模型 在整个Velocity分布式缓存解决方案中，从物理模型上来看，主要涉及到如下几个元素：缓存宿主，缓存集群，Velocity提供的基于Windows PowerShell的管理工具，对于服务器集群配置的存储。缓存宿主是指一个或者多个以Windows服务形式运行的服务器，每台服务器都可以运行缓存宿主服务；缓存集群是一个或者多个缓存宿主实例的集合；当缓存集群启动时，它将从集群配置存储位置处来获取配置信息，Velocity提供了多种方式的集群配置信息存储，可以基于XML文件、SQL Server数据库或者SQL Server CE等；基于PowerShell的管理工具后面会详细讲到。 如图2所示： 图 2 逻辑模型 从逻辑模型上来看，在Velocity中主要有命名缓存，在命名缓存中我们还可以继续分区，命名缓存，可以理解为内存中的一个独立的存储结构单元，它们之间完全互相隔离，互不干扰，当有多个应用程序共享同一个缓存集群时，可以为每个应用程序分别建立命名缓存；在同一个命名缓存中，还可以对命名缓存进行分区，这样即可以解决数据冲突的问题，再配合Velocity中的“标签”功能，可以极大的提高检索效率。如图3所示： 图 3 安装 Velocity当前最新的版本是CTP 2，大家可以到微软官方站点下载，由于Velocity中提供了一套基于Windows PowerShell的管理工具，所以在安装之前需要首先安装Windows PowerShell。在安装过程中，其中有一步需要进行服务器集群的配置，如图4所示： 图 4 需要设置服务及集群端口号，集群配置的存储位置，集群配置存储的Provider，可以基于XML存储或者基于SQL Server CE存储等。另外可以访问如下站点获得一些资源： 团队博客：http://blogs.msdn.com/velocity/ 示例代码：http://code.msdn.microsoft.com/velocity 安装完成后，请在Windows Service中启动Microsoft project code named "Velocity"服务。 管理工具 Velocity提供了基于Windows PowerShell的管理工具，对于Windows PowerShell不熟悉的可以参考《回归Dos操作的快感，进入PowerShell世界》这篇文章。使用Windows PowerShell可以非常方便的对Velocity缓存集群、缓存宿主等进行管理。使用如下命令金额图对启动、停止、重启服务器集群： Start-CacheCluster Stop-CacheCluster Restart-CacheCluster 使用如下命令可以启动、停止缓存宿主、获取命名缓存、获取缓存分区等： Get-CacheHost Get-CacheConfig Set-CacheConfig Start-CacheHost Stop-CacheHost Get-CacheStatistics Get-Cache Get-CacheRegion 如使用Get-CacheHost命令获取缓存宿主的信息，如图5所示，可以看到宿主对应的服务名以及服务状态等： 图 5 使用Get-Cache命名查看所有的命名缓存，如图6所示： 图 6 使用该管理工具还可以创建、移除命名缓存等，这里不再叙述。 简单示例 经过前面一大堆的理论介绍，现在来看一个最简单的示例。首先要把CacheBaseLibrary和ClientLibrary这两个程序集添加到应用程中，在Velocity安装目录下可以找到，并且引入命名空间： using System.Data.Caching; 在使用Velocity缓存数据时，首先需要创建一个命名缓存，它可以通过CacheFactory来创建，如下代码所示： private Cache GetCurrentCache() { Cache dCache; ServerEndPoint[] ...

概述 通过前面两篇的介绍，对Web服务寻址规范以及在WCF开发中终结点地址有了深入的认识。本文我们继续深入WCF寻址第三部分内容，当消息传入时，如何来确定匹配的终结点，就是我们本文要讲到的消息筛选引擎。在WCF中，消息筛选器引擎包括两个重要的组成部分：筛选器和筛选器表。 认识消息筛选器 在WCF中当有消息传入时，它使用消息筛选器来确定匹配的终结点，每个终结点实际上关联着两个筛选器：一个地址筛选器和一个契约筛选器。地址筛选器确定传入消息是否匹配终结点的“To”地址和任何必需的地址报头，而契约筛选器则确定它是否匹配终结点的契约，两个筛选器都被调度程序用来确定目标终结点。 在WCF中，所有的消息筛选器都继承于MessageFilter抽象基类，系统内置了几种的消息筛选器，如图1所示： 图1 EndpointAddressMessageFilter：作为默认的地址筛选器，它会将SOAP消息中的“To”地址与终结点地址进行比较，预期它们完全匹配，也会传入消息中获得的寻址报头和终结点要求的一组寻址报头进行比较，要使最终匹配的结果返回true，必须满足以下两个条件： 1. 筛选器的地址统一资源标识符 (URI) 必须与消息 To 标头中的统一资源标识符相同。 2. 筛选器地址中的每个终结点参数都必须在消息中找到一个与之匹配的标头。 ActionMessageFilter：作为默认的契约筛选器，它根据传入的SAOP消息中“Action”值和契约上的操作进行比较，确定是否匹配匹配。该筛选器在初始化时将包含一个操作字符串列表，如果筛选器的列表中的任一操作与消息或消息缓冲区中的 Action 标头匹配，则 Match 方法返回 true。 如果该列表为空，则将该筛选器视为全匹配型筛选器，任何消息或消息缓冲区都与该筛选器匹配，并且 Match 返回 true。 如果筛选器列表中没有任何操作与消息或消息缓冲区中的 Action 标头匹配，则 Match 返回 false。 如果消息中不存在任何操作且筛选器的列表非空，则 Match 返回 false。 PrefixEndpointAddressMessageFilter：此筛选器与 EndpointAddressMessageFilter 执行相同的查询，不同的是测试消息是否与终结点地址相匹配是由“最长前缀匹配”完成的。这表示筛选器中指定的 URI 不需要与消息的 URI 完全匹配，不过必须作为前缀包含在该 URI 中。例如，如果筛选器指定地址“http://www.foo.com”，并且消息是发送给“http://www.foo.com/customerA”，则将满足筛选器查询条件的 URI 部分，但是筛选器查询的报头部分仍需要完成。 MatchAllMessageFilter：该筛选器将导致所有消息都匹配给定终结点，看一下它的Match方法实现，除非消息为空，否则就返回True： [DataContract] public class MatchAllMessageFilter : MessageFilter { public override bool Match(Message message) { if (message == null) { throw DiagnosticUtility.ExceptionUtility.ThrowHelperArgumentNull("message"); } return true; } } MatchNoneMessageFilter：该筛选器将导致所有消息都不匹配，看一下它的Match方法实现，除非消息为空，否则就返回False： [DataContract] public ...

应用程序架构指导包由微软模式与实践团队负责编写，为基于.NET平台的应用程序设计提供了一些指导，现在v2.0 Beta版本已经发布，包括的内容有应用程序架构基础、设计、分层、设计模式等等，设计的应用程序类型有Mobile Application，Office Business Application (OBA)，Rich Client Application ，Rich Internet Application (RIA)，Web Application等 ，之前园子里的蜡笔小巢也有过介绍。完整的目录如下所示： Parts Part I, Fundamentals of Application Architecture Part II, Design Part III, Layers Part IV, Quality Attributes Part V, Archetypes - Design and Patterns Chapters Introduction Architecture Best Practices At a Glance Fast Track - A Guide for Getting Started and Applying the Guidance Part I, Fundamentals of Application Architecture Chapter 1 - Fundamentals of Application Architecture Chapter 2 - .NET ...

概述 众所周知，WCF服务的所有通信都是通过服务的终结点发生的，每个 服务终结点都包含一个地址Address、一个绑定Binding 和一个契约Contract。契约指定可用的操作，绑定指定如何与服务进行通信，而地址指定查找服务的位置，即非常经典的“ABC”。WCF用多种不同的通信协议为公开服务终结点和与其通信提供了灵活的模式，在WCF专题系列的第一部分，我将围绕终结点的寻址细节展开讨论，再此之前，我们先看一下WCF的编程模型，如图1所示： 图1 Web服务寻址规范 在 WCF 中，终结点地址是按照Web服务寻址 WS-Addressing 规范中的定义建立终结点引用（Endpoint Reference，EPR）的模型，我们有必要对Web服务寻址规范来做一个认识，这里先提出一个问题，为什么需要Web服务寻址？一方面SOAP如果要做到真正的与传输协议无关，就要以一种与传输协议无关的方式来定义消息的接收者与消息返回的地址；另一方面，定义寻址信息有助于在发生网络错误或丢失响应的情况下将消息返回给请求者；最后一套完善的寻址机制使的复杂的交互模式成为可能，如图2所示： 图2 在WS-Addressing中，其实就两个概念：终结点引用（Endpoint Reference）和SOAP结构的消息信息报头（Message Information Headers）。如下面的示例表示将一条SOAP 1.2的消息发送到http://fabrikam123.com/Purchasing。：<S:Envelope xmlns:S="http://www.w3.org/2002/12/soap-envelope" xmlns:wsa="http://schemas.xmlsoap.org/ws/2003/03/addressing"> <S:Header> <wsa:ReplyTo> <wsa:Address>http://business456.com/client1</wsa:Address> </wsa:ReplyTo> <wsa:To>http://fabrikam123.com/Purchasing</wsa:To> <wsa:Action>http://fabrikam123.com/SubmitPO</wsa:Action> </S:Header> <S:Body> ...... </S:Body> </S:Envelope> 终结点引用 Web 服务终结点是一个可以引用的实体、处理器或可以作为 Web 服务消息目标的资源，而终结点引用传达了标识或者引用一个 Web 服务终结点所需的信息，它的使用方式可以有多种：终结点引用适用于传达访问 Web 服务终结点所需的信息，也可以在 Web 服务间往返的各条消息提供地址。如下面的代码表示了终结点引用的信息集：<wsa:EndpointReference> <wsa:Address>xs:anyURI</wsa:Address> <wsa:ReferenceProperties>... </wsa:ReferenceProperties> ? <wsa:ReferenceParameters>... </wsa:ReferenceParameters> ? <wsa:PortType>xs:QName</wsa:PortType> ? <wsa:ServiceName PortName="xs:NCName"?>xs:QName</wsa:ServiceName> ? <wsa:Policies> ... </wsa:Policies>? <xs:any/>* </wsa:EndpointReference> 从最简单的意义上来说，终结点引用就是一些使用XML元素来包装的URL，如下面的代码：<wsa:myLocation> <wsa:Address>http://localhost:8887/CalculatorService</wsa:Address> </wsa:myLocation> 这里wsa:myLocation就是终结点引用，在它的内部是一个Web服务寻址规范定义的元素，用它来指定当访问CalculatorService服务时所用的地址。作为终结点引用模型的一部分，每个终结点引用都可以包含一些添加额外标识信息的引用参数。 消息信息报头 消息信息报头（Message Information Headers）是Web 服务寻址规范定义了一些附加的也是标准的SOAP头，它们用于帮助传送关于消息的信息，它与终结点引用不同，消息信息报头将作为SOAP Head的扩展包含在SOAP消息中，它的信息集如下所示：<wsa:To>xs:anyURI</wsa:To> ? <wsa:From>wsa:EndpointReferenceType</wsa:From> ? <wsa:ReplyTo>wsa:EndpointReferenceType</wsa:ReplyTo> ? <wsa:FaultTo>wsa:EndpointReferenceType</wsa:FaultTo> ...