Velocity是微软推出的分布式缓存解决方案，为开发可扩展性，可用的，高性能的应用程提供支持，可以缓存各种类型的数据，如CLR对象、XML、二进制数据等，并且支持集群模式的缓存服务器。Velocity也将集成在.NET Framework 4.0中，本文将介绍Velocity中的配置模型、缓存复杂数据和创建分区、使用标签以及ASP.NET SessionState提供者。

配置模型

在本文开始之前，先简单介绍一下Velocity中的配置模型，主要包括三方面的配置，缓存集群的配置，缓存宿主服务器配置以及应用程序的配置，如下图所示：

缓存集群的配置，可以基于XML、SQL Server CE或者SQL Server数据库来进行存储，包括各个服务器以及所有的命名缓存、是否过期等配置，当我们使用Windows PowerShell管理工具进行配置时，将会修改该配置文件，如下代码所示：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="dcache" type="System.Data.Caching.DCacheSection, 
             CacheBaseLibrary, Version=1.0.0.0, Culture=neutral,
             PublicKeyToken=89845dcd8080cc91" />
  </configSections>
  <dcache cluster="localhost" size="Small">
    <caches>
      <cache type="partitioned" consistency="strong" name="default">
        <policy>
          <eviction type="lru" />
          <expiration defaultTTL="10" isExpirable="true" />
        </policy>
      </cache>
      <cache type="partitioned" consistency="strong" name="other">
        <policy>
          <eviction type="lru" />
          <expiration defaultTTL="10" isExpirable="true" />
        </policy>
      </cache>
    </caches>
    <hosts>
      <host clusterPort="22234" hostId="1319514812" size="1024" quorumHost="true"
          name="TERRYLEE-PC" cacheHostName="DistributedCacheService"
          cachePort="22233" />
    </hosts>
    <advancedProperties>
      <partitionStoreConnectionSettings providerName="System.Data.SqlServerCe.3.5"
          connectionString="D:\CacheShare\ConfigStore.sdf" />
    </advancedProperties>
  </dcache>
</configuration>

在上一篇的示例中，并没有使用应用程序配置文件，事实上使用配置文件是更好的编程实践，首先需要添加一个配置区：

<section name="dcacheClient"
type="System.Data.Caching.DCacheSection, 
      CacheBaseLibrary, Version=1.0.0.0, 
      Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>

配置信息包括部署方式，是否启用本地缓存以及缓存宿主等，如下代码所示：

<dcacheClient>
  <localCache isEnabled="true" sync="TTLBased" ttlValue="300" />
  <hosts>
    <host name="localhost" cachePort="22233" 
          cacheHostName="DistributedCacheService"/>
  </hosts>
</dcacheClient>

现在Velocity CTP2对于应用程序使用配置的支持似乎有些问题。缓存宿主的配置放在DistributedCache.exe.config文件中，可以在Velocity安装目录下找到。

缓存复杂数据类型

在Velocity中，可以缓存任何类型的数据，如CLR对象、XML或者二进制数据等。现在看一个简单的示例，如何缓存复杂类型数据，定义一个如下的Customer类，注意要能够序列化：

[Serializable]
public class Customer
{
    public String ID { get; set; }

    public String FirstName { get; set; }

    public String LastName { get; set; }

    public int Age { get; set; }

    public String Email { get; set; }
}

对应用程序做配置，参考本文的配置模型部分，使用方法与简单数据类型的基本一致，如添加缓存项，使用Customer主键作为缓存键，其中GetCurrentCache()方法的实现请参考上一篇文章：

Cache cache = GetCurrentCache();
Customer customer = new Customer()
{
    ID = "C20081117002",
    FirstName = "Terry",
    LastName = "Lee",
    Age = 25,
    Email = "lhj_cauc[#AT#]163.com"
};

cache.Add(customer.ID, customer);

获取缓存项：

Cache cache = GetCurrentCache();
Customer customer = cache.Get("C20081117002") as Customer;

移除缓存项：

Cache cache = GetCurrentCache();
cache.Remove("C20081117002");

更新缓存中数据，可以有两种方法，一是直接使用缓存索引，如果确保缓存键存在：

Cache cache = GetCurrentCache();
Customer customer = new Customer()
{
    ID = "C20081117002",
    FirstName = "Huijui",
    LastName = "Li",
    Age = 26,
    Email = "lhj_cauc[#AT#]163.com"
};
cache["C20081117002"] = customer;

另外一种是使用Put方法，如果缓存键不存在，它将会新增到缓存中，否则会进行覆盖，如下代码所示：

Cache cache = GetCurrentCache();
Customer customer = new Customer()
{
    ID = "C20081117002",
    FirstName = "Huijui",
    LastName = "Li",
    Age = 26,
    Email = "lhj_cauc[#AT#]163.com"
};
cache.Put(customer.ID, customer);

使用分区

在实际部署中，经常会出现多个应用程序共享同一个缓存集群，这不可避免的会出现缓存键冲突，如上面的示例中使用CustomerID作为缓存键，此时可以使用Velocity中的分区功能，它会在逻辑上把各个命名缓存再进行分区，这样可以完全保持数据隔离，如下图所示：

图中共有三个命名缓存，其中在缓存Catalog中又分区为Sports和Arts。在Velocity中对于分区的操作提供了如下三个方法，可以用于创建分区，删除分区以及清空分区中所有的对象：

public void ClearRegion(string region);
public bool CreateRegion(string region, bool evictable);
public bool RemoveRegion(string region);

如下代码所示，创建了一个名为“Customers”的分区，在调用Add方法时可以指定数据将会缓存到哪个分区：

Cache cache = GetCurrentCache();
string regionName = "Customers";
cache.CreateRegion(regionName, false);

Customer customer = new Customer()
{
    ID = "C20081117003",
    FirstName = "Terry",
    LastName = "Lee",
    Age = 25,
    Email = "lhj_cauc[#AT#]163.com"
};

cache.Add(regionName, customer.ID, customer);

可以使用Get-CacheRegion命令在Windows PowerShell中来查看一下当前缓存集群中所有的分区信息，如下图所示：

同样在检索缓存数据时，仍然可以使用分区名进行检索。

使用标签

在Velocity还允许对加入到缓存中的缓存项设置Tag，可以是一个或者多个，使用了Tag，就可以从多个方面对缓存项进行描述，这样在检索数据时，就可以根据Tag来一次检索多个缓存项。为缓存项设置Tag，如下代码所示：

Cache cache = GetCurrentCache();
string regionName = "Customers";

Customer customer1 = new Customer()
{
    ID = "C20081117004",
    FirstName = "Terry",
    LastName = "Lee",
    Age = 25,
    Email = "lhj_cauc[#AT#]163.com"
};
Customer customer2 = new Customer()
{
    ID = "C20081117005",
    FirstName = "Terry",
    LastName = "Lee",
    Age = 25,
    Email = "lhj_cauc[#AT#]163.com"
};

Tag tag1 = new Tag("Beijing");
Tag tag2 = new Tag("Tianjin");
cache.Add(regionName, customer1.ID, customer1, new Tag[] { tag1, tag2 });
cache.Add(regionName, customer2.ID, customer2, new Tag[] { tag2 });

这样就可以对设置了Tag的缓存项进行检索，根据实际需求选择使用如下三个方法之一：

GetAllMatchingTags(string region, Tag[] tags)
GetAnyMatchingTag(string region, Tag[] tags)
GetByTag(string region, Tag tag)

第一个检索匹配所有Tag的数据，第二个检索匹配所有Tag中的任意一个即可，最后只使用一个Tag，如下代码所示：

string regionName = "Customers";
Tag[] tags = new Tag[] { new Tag("Beijing"), 
           new Tag("Tianjin")};

List<KeyValuePair<string, object>> result
    = cache.GetAllMatchingTags(regionName, tags);

使用Tag功能对于检索缓存项提供了极大的灵活性，对于任何一个数据，都可以使用多个Tag从很多方面去描述它。

ASP.NET SessionState提供者

Velocity还提供了对于ASP.NET SessionState提供者的支持，可以通过配置把Session信息缓存到缓存集群中，添加Velocity配置区：

<section name="dcacheClient"
         type="System.Data.Caching.DCacheSection, 
         CacheBaseLibrary, Version=1.0.0.0, 
         Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>

配置缓存客户端信息：

<dcacheClient>
  <localCache isEnabled="true" sync="TTLBased" ttlValue="300" />
  <hosts>
    <host name="localhost" cachePort="22233" 
          cacheHostName="DistributedCacheService"/>
  </hosts>
</dcacheClient>

配置SessionState信息：

<sessionState mode="Custom" customProvider="Velocity">
  <providers>
    <add name="Velocity" 
         type="System.Data.Caching.SessionStoreProvider,ClientLibrary"
         cacheName="default"/>
  </providers>
</sessionState>

需要指定使用哪个命名缓存，但是该功能似乎到目前还存在问题，无法测试通过L

总结

本文简单介绍了Velocity的配置模型，以及如何缓存复杂数据类型，对命名缓存分区，为缓存项设置Tag，以及对于ASP.NET SessionState的支持，希望对大家有用。

相关文章：

1. 使用微软分布式缓存服务Velocity Part 1

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[] servers = new ServerEndPoint[1];
    servers[0] = new ServerEndPoint("localhost", 22233, "DistributedCacheService");
    bool routingClient = true;
    bool localCache = false;
    var factory = new CacheFactory(servers, routingClient, localCache);
    dCache = factory.GetCache("default");

    return dCache;
}

此处首先指定了所有的服务器信息，当然这些都可以放在应用程序配置文件中，将会在下篇中介绍，有了Cache对象，其它的使用就非常方便了，如我们可以使用Add、Put、Remove、Get等方法来对缓存项进行操作，

添加缓存项：

Cache dCache = GetCurrentCache();

String key = keyTextbox.Text;
String val = valueTxtBox.Text;

if (key == "" || val == "") return;

dCache.Add(key, val);
statusLabel.Text =
    String.Format("Successfully added key {0} to cache.", key);

获取缓存项：

Cache dCache = GetCurrentCache();
String key = keyTextbox.Text;

if (key == "") return;

String val = dCache.Get(key).ToString();
valueTxtBox.Text = val;
statusLabel.Text =
    String.Format("Successfully did Get of key {0} from cache", key);

运行程序可以测试，数据被正确的缓存，如图7所示：

图 7

总结

本文简单介绍了微软的分布式缓存解决方案Velocity的一些概念以及开发了一个简单的示例，希望对大家有用。在下篇文章中，我们将会更深入学习缓存复杂数据类型以及Velocity的编程模型和配置模型。

相关文章：

1. 使用微软分布式缓存服务Velocity Part 2

原文请参考：Update on Silverlight 2 - and a glimpse of Silverlight 3

从本质上说，WCF是一个通信服务框架，它允许我们使用不同的传输协议，使用不同的消息编码形式，跟不同的WS-*系列规范交互，而所有这些细节都是由通道堆栈来处理的。在《WCF专题系列（8）：深度通道编程模型Part 1—设计篇》中，对于WCF中的通道模型有了深入的认识，本文中，我将通过实例来说明在通道模型中，服务端是如何接收消息，客户端是如何发送消息的。

服务端通道

本文将不使用WCF的编程模型，而直接利用通道模型来进行通信，这样有助于我们更进一步加深对服务端处理消息的认识，在服务端侦听并接收消息的第一步需要创建绑定，我们既可以使用WCF中内置的绑定或者使用自定义的绑定，如下代码所示，创建一个CustomBinding：

// 创建自定义绑定
BindingElement[] bindingElements = new BindingElement[2];
bindingElements[0] = new TextMessageEncodingBindingElement();
bindingElements[1] = new HttpTransportBindingElement();

CustomBinding binding = new CustomBinding(bindingElements);

此处添加了HttpTransportBindingElement，所以生成的通道堆栈具有HTTP传输通道，另外采用了文本消息编码器。接下来调用刚才创建的CustomBinding的BuildChannelListener方法来构造通道侦听器，需要指定侦听基地址以及绑定参数，另外调用Open()方法打开通道监听器，相信大家一定还记得Open()方法是在接口ICommunicationObject中定义的，如下代码所示：

// 使用自定义绑定创建通道侦听器         
IChannelListener<IReplyChannel> listener =
      binding.BuildChannelListener<IReplyChannel>(
         new Uri("http://localhost:8887/StringService"),
         new BindingParameterCollection());

// 监听消息
listener.Open();
Console.WriteLine("Listening for incoming channel connections");

现在侦听传入的消息，由于我们使用请求了响应消息交换模式，此处侦听器返回一个实现了IReplyChannel的通道，为了在此通道上接收消息，我们首先对其调用Open()方法（该方法仍然是在ICommunicationObject中定义），以便将其置于一个准备进行通信的状态。 然后，我们调用ReceiveRequest()方法，它会处于阻止状态，直到消息达到，如下代码所示：

// 创建Reply通道
IReplyChannel channel = listener.AcceptChannel();
Console.WriteLine("Channel accepted. Listening for messages");
channel.Open();

RequestContext request = channel.ReceiveRequest();

当ReceiveRequest()方法返回一个RequestContext时，再使用其RequestMessage属性获取接收到的消息。输出消息的操作（Action）和内容。为了发送答复，在此例中创建一个新的答复消息，它会将我们在请求中接收到的字符串数据，添加一段字符后再传递回去。然后，调用Reply()方法以发送答复消息，如下代码所示：

// 读取请求的消息
Message message = request.RequestMessage;
Console.WriteLine("Message Received");
Console.WriteLine("Message Action: {0}", message.Headers.Action);
string body = message.GetBody<string>();
Console.WriteLine("Message Content: {0}", body);

// 发送响应消息
Message replymessage = Message.CreateMessage(
    binding.MessageVersion,
    "http://www.cnblogs.com/TerryLee/Encode",
     "Hello : " + body);

request.Reply(replymessage);

最后别忘了做资源释放工作，关闭通道侦听器、通道、请求消息、请求上下文等，如下代码所示：

// 释放对象
message.Close();
request.Close();
channel.Close();
listener.Close();

完整的代码如下所示：

/// <summary>
/// Author:TerryLee
/// Url:http://www.cnblogs.com/terrylee
/// </summary>
static void Main()
{
    // 创建自定义绑定
    BindingElement[] bindingElements = new BindingElement[2];
    bindingElements[0] = new TextMessageEncodingBindingElement();
    bindingElements[1] = new HttpTransportBindingElement();

    CustomBinding binding = new CustomBinding(bindingElements);

    // 使用自定义绑定创建通道侦听器         
    IChannelListener<IReplyChannel> listener =
          binding.BuildChannelListener<IReplyChannel>(
             new Uri("http://localhost:8887/StringService"),
             new BindingParameterCollection());

    // 监听消息
    listener.Open();
    Console.WriteLine("Listening for incoming channel connections");

    // 创建Reply通道
    IReplyChannel channel = listener.AcceptChannel();
    Console.WriteLine("Channel accepted. Listening for messages");
    channel.Open();

    RequestContext request = channel.ReceiveRequest();

    // 读取请求的消息
    Message message = request.RequestMessage;
    Console.WriteLine("Message Received");
    Console.WriteLine("Message Action: {0}", message.Headers.Action);
    string body = message.GetBody<string>();
    Console.WriteLine("Message Content: {0}", body);

    // 发送响应消息
    Message replymessage = Message.CreateMessage(
        binding.MessageVersion,
        "http://www.cnblogs.com/TerryLee/Encode",
         "Hello : " + body);

    request.Reply(replymessage);

    // 释放对象
    message.Close();
    request.Close();
    channel.Close();
    listener.Close();

    Console.WriteLine("Press Enter to exit");
    Console.ReadLine();
}

现在运行服务端如图1所示，由于没有消息到达，所以ReceiveRequest()方法会阻塞：

图 1

客户端通道

前面完成了服务端的工作，接下来我们看看如何在客户端直接使用通道模型进行通信。与服务端一致，请求消息的第一步是创建绑定，因为双方需要通过绑定就通信的细节达成一致。创建自定义绑定与服务端一致，如下代码所示：

// 创建绑定
BindingElement[] bindingElements = new BindingElement[2];
bindingElements[0] = new TextMessageEncodingBindingElement();
bindingElements[1] = new HttpTransportBindingElement();

CustomBinding binding = new CustomBinding(bindingElements);

接下来需要使用刚才创建的绑定来构造通道工厂，在上一篇中我们提到，消息的接收方使用通道侦听器，而消息的请求方使用通道工厂，这次使用BuildChannelFactory()方法构造通道工厂并打开，如下代码所示：

// 使用绑定创建通道工厂
IChannelFactory<IRequestChannel> factory =
binding.BuildChannelFactory<IRequestChannel>(
                 new BindingParameterCollection());
// 打开通道工厂
factory.Open();
Console.WriteLine("Channel factory opened");

现在使用通道工厂的CreateChannel()方法来创建IRequestChannel，得到通道后，调用它的Open()方法以使其处于通信就绪状态，如下代码所示：

// 创建Request通道
IRequestChannel channel = factory.CreateChannel(
   new EndpointAddress("http://localhost:8887/StringService"));
channel.Open();
Console.WriteLine("Request channel opened");

打开通道之后，就可以创建消息并使用通道的 Request()方法发送请求并等待响应，这里我们发送的消息内容是“TerryLee”，当此方法返回时，我们将能够得到回复消息，可以读取该消息以发现终结点回复的内容，如下代码所示：

// 创建请求消息
Message requestmessage = Message.CreateMessage(
    binding.MessageVersion,
    "http://www.cnblogs.com/TerryLee/Encode",
     "TerryLee");

// 发送请求消息并接收响应消息
Message replymessage = channel.Request(requestmessage);
Console.WriteLine("Reply message received");
Console.WriteLine("Reply action: {0}",
                      replymessage.Headers.Action);
string data = replymessage.GetBody<string>();
Console.WriteLine("Reply content: {0}", data);

最后仍然是资源释放工作，关闭通道工厂、通道以及请求消息，如下代码所示：

replymessage.Close();
channel.Close();
factory.Close();

完整的客户端代码为：

/// <summary>
/// Author:TerryLee
/// Url:http://www.cnblogs.com/terrylee
/// </summary>
public static void Main()
{
    // 创建绑定
    BindingElement[] bindingElements = new BindingElement[2];
    bindingElements[0] = new TextMessageEncodingBindingElement();
    bindingElements[1] = new HttpTransportBindingElement();

    CustomBinding binding = new CustomBinding(bindingElements);

    // 使用绑定创建通道工厂
    IChannelFactory<IRequestChannel> factory =
    binding.BuildChannelFactory<IRequestChannel>(
                     new BindingParameterCollection());
    // 打开通道工厂
    factory.Open();
    Console.WriteLine("Channel factory opened");

    // 创建Request通道
    IRequestChannel channel = factory.CreateChannel(
       new EndpointAddress("http://localhost:8887/StringService"));
    channel.Open();
    Console.WriteLine("Request channel opened");

    // 创建请求消息
    Message requestmessage = Message.CreateMessage(
        binding.MessageVersion,
        "http://www.cnblogs.com/TerryLee/Encode",
         "TerryLee");

    // 发送请求消息并接收响应消息
    Message replymessage = channel.Request(requestmessage);
    Console.WriteLine("Reply message received");
    Console.WriteLine("Reply action: {0}",
                          replymessage.Headers.Action);
    string data = replymessage.GetBody<string>();
    Console.WriteLine("Reply content: {0}", data);

    replymessage.Close();
    channel.Close();
    factory.Close();

    Console.WriteLine("Press Enter to exit");
    Console.ReadLine();
}

最后运行时服务端如图2所示：

图 2

客户端如图3所示：

图 3

温故知新

现在我们再回顾一下上一篇中所讲的知识，通道对象模型是实现通道、通道侦听器和通道工厂所必需的一组核心接口。还提供一些基类以辅助自定义实现。可以看到通道模型中最重要的有三组接口：通道、通道侦听器和通道工厂。每个通道均实现一个或多个接口，称为通道形状接口或通道形状；通道侦听器负责侦听传入消息，即在消息的接收端，然后通过由通道侦听器创建的通道将这些消息传送到上面的层；通道工厂负责创建通道用于发送消息，即在消息的发送方，并在通道工厂关闭时，关闭通道工厂创建的所有通道。如图4所示：

图 4

对照本文的示例代码，相信大家对于图4能够有更深的认识。

总结

本文我们通过一个简单的示例介绍了在通道模型中服务端是如何接收消息以及客户端是如何发送消息的，希望对大家有所帮助。

Deep Zoom在线版

下载PDF版本

在WCF专题系列（1）：深入WCF寻址Part1一文中，我们对Web服务寻址规范做了一些认识，了解了终结点引用和消息信息报头两种结构，该规范在Web服务中的地位举足轻重，后续我们会经常提到该规范。在本文中，我们将继续深入WCF寻址的内容，包括元数据中的终结点地址，自定义寻址标头等相关信息。

终结点地址定义

了解了Web服务寻址规范，再回到WCF，在WCF中，终结点地址是由EndpointAddress类来表示的，它其中很重要的几个部分是：一个表示服务地址的统一资源定位符 (URI)，一个表示服务的安全标识的 Identity 和一个可选的 Headers 集合，其中Headers用于标识终结点或与终结点交互的更多详细寻址信息。如图1所示：

图1

记的我在WCF专题系列（1）：深入WCF寻址Part1一文提到过，每个终结点引用都可以包含一些添加额外标识信息的引用参数，即寻址标头，在 WCF 中，将这些引用参数建模为 AddressHeader 类的实例，这里的Headers属性就是这些实例的集合，可以通过AddressHeader类提供的静态方法CreateAddressHeader来创建一个AddressHeader实例，如下代码所示：

AddressHeader header = AddressHeader.CreateAddressHeader("basic",
                        "http://www.cnblogs.com/terrylee", "Terrylee");

指定终结点地址

在WCF中提供了基址技术，这使的我们在指定终结点地址时可以酌情选用相对地址或者绝对地址，指定绝对地址的方法是在终结点定义中提供完全限定的地址，如下代码所示：

<service name="TerryLee.WCFAddressing.Service.CalculatorService"
         behaviorConfiguration="calculatorBehavior">

  <endpoint address="http://localhost:8887/CalculatorService"
            binding ="basicHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
</service>

使用绝对地址固然简单，但是如果我们的服务需要公开多个终结点，而这些终结点地址又具有相同的基地址时，也许相对地址是更好的选择。在创建服务宿主对象时，提供一个基地址，如下代码所示：

using (ServiceHost calculatorServiceHost =
        new ServiceHost(typeof(CalculatorService),
        new Uri("http://localhost:8887/CalculatorService")))
{
    calculatorServiceHost.Opened += delegate
    {
        Console.WriteLine("Service begin to listen via the Address:{0}",
            calculatorServiceHost.BaseAddresses[0].ToString());
    };

    calculatorServiceHost.Open();
    Console.Read();
}

又或者同时在配置文件中指定基地址，这样就无须在每个终结点中指定绝对地址了，如下代码所示：

<service name="TerryLee.WCFAddressing.Service.CalculatorService"
         behaviorConfiguration="calculatorBehavior">
  <host>
    <baseAddresses>
      <add baseAddress="http://localhost:8887/Calculator"/>
    </baseAddresses>
  </host>
  <endpoint address="myservice1"
            binding ="basicHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
  <endpoint address="myservice2"
            binding ="wsHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
</service>

但请注意，基址技术是为我们在配置终结点时提供了方便，客户端对它是毫无所知的，客户端看到的仍然是绝对地址，在打开服务宿主时，它会匹配所有的相对地址，从而为每个终结点提供相应的绝对地址，如上面的示例，可以在WSDL中看到：

<wsdl:service name="CalculatorService">
  <wsdl:port name="BasicHttpBinding_ICalculator" binding="tns:BasicHttpBinding_ICalculator">
    <soap:address location="http://localhost:8887/Calculator/myservice1" />
  </wsdl:port>
  <wsdl:port name="WSHttpBinding_ICalculator" binding="tns:WSHttpBinding_ICalculator">
    <soap12:address location="http://localhost:8887/Calculator/myservice2" />
    <wsa10:EndpointReference>
      <wsa10:Address>http://localhost:8887/Calculator/myservice2</wsa10:Address>
      <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
        <Upn>TerryLee-PC\TerryLee</Upn>
      </Identity>
    </wsa10:EndpointReference>
  </wsdl:port>
</wsdl:service>

如果在指定了基地址的情况下，有以下几种情况：指定相对地址为空，终结点地址与基地址相同；指定相对地址不为空，追加相对地址到基地址上；指定一个绝对地址，基地址不起作用，终结点地址仍然为指定的绝对地址；指定一个绝对地址和一个与基地址不同的绑定，基地址不起作用。现在有这样一段配置信息：

<service name="TerryLee.WCFAddressing.Service.CalculatorService"
         behaviorConfiguration="calculatorBehavior">
  <host>
    <baseAddresses>
      <add baseAddress="http://localhost:8887/Calculator"/>
    </baseAddresses>
  </host>
  <endpoint address=""
            binding ="wsHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
  <endpoint address="myservice2"
            binding ="wsHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
  <endpoint address="http://localhost:8886/CalculatorService"
            binding ="wsHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
  <endpoint address="net.tcp://localhost:8885/Calculator"
            binding ="netTcpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
  </endpoint>
</service>

可以在ServiceHost启动后，输出所有的终结点地址和绑定信息，如下代码：

ServiceDescription desc = calculatorServiceHost.Description;
foreach (ServiceEndpoint endpoint in desc.Endpoints)
{
    Console.WriteLine("Endpoint - address:  {0}", endpoint.Address);
    Console.WriteLine("           binding:  {0}", endpoint.Binding.Name);
    Console.WriteLine("           contract: {0}", endpoint.Contract.Name);
}

输出结果如图2所示：

图2

元数据中终结点地址

终结点地址在WSDL中表示为对应终结点的 wsdl:port元素内的终结点引用（EndpointReference）元素。终结点引用包含终结点的地址以及所有的地址属性，如下示例代码所示：

<wsdl:service name="CalculatorService">
  <wsdl:port name="WSHttpBinding_ICalculator" binding="tns:WSHttpBinding_ICalculator">
    <soap12:address location="http://localhost:8887/Calculator" />
    <wsa10:EndpointReference>
      <wsa10:Address>http://localhost:8887/Calculator</wsa10:Address>
      <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
        <Upn>TerryLee-PC\TerryLee</Upn>
      </Identity>
    </wsa10:EndpointReference>
  </wsdl:port>
</wsdl:service>

自定义寻址报头

在本文的终结点定义一节，我们提到了寻址报头，在某些情况下，我们可能希望通过自定义寻址报头来解决一些复杂的问题，如根据根据传入的寻址报头中是否包含某些信息，将其转发到不同的终结点，通过自定义寻址报头，可以实现SOAP消息的无限扩展，放置任何希望的控制信息到SOAP消息。如下面的代码：

using (ServiceHost calculatorServiceHost =
    new ServiceHost(typeof(CalculatorService),
    new Uri("http://localhost:8887/CalculatorService")))
{
    calculatorServiceHost.Opened += delegate
    {
        Console.WriteLine("Service begin to listen via the Address:{0}",
            calculatorServiceHost.BaseAddresses[0].ToString());
    };

    AddressHeader header =
        AddressHeader.CreateAddressHeader("basic",
        "http://www.cnblogs.com/terrylee", "Terrylee");

    EndpointAddress ea = new EndpointAddress(
        new Uri("http://localhost:8887/CalculatorService"), header);

    calculatorServiceHost.Description.Endpoints.Add(
        new ServiceEndpoint(
            ContractDescription.GetContract(typeof(ICalculator)),
            new WSHttpBinding(),
            ea));

    ServiceMetadataBehavior behavior = new ServiceMetadataBehavior();
    behavior.HttpGetEnabled = true;
    calculatorServiceHost.Description.Behaviors.Add(behavior);

    calculatorServiceHost.Open();
    Console.Read();
}

我们在WSDL中可以看到该自定义的报头，它作为终结点引用的引用参数：

<wsdl:service name="CalculatorService">
  <wsdl:port name="WSHttpBinding_ICalculator" binding="tns:WSHttpBinding_ICalculator">
    <soap12:address location="http://localhost:8887/CalculatorService" />
    <wsa10:EndpointReference>
      <wsa10:Address>http://localhost:8887/CalculatorService</wsa10:Address>
      <wsa10:ReferenceParameters>
        <basic xmlns="http://www.cnblogs.com/terrylee">Terrylee</basic>
      </wsa10:ReferenceParameters>
      <Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
        <Upn>TerryLee-PC\TerryLee</Upn>
      </Identity>
    </wsa10:EndpointReference>
  </wsdl:port>
</wsdl:service>

截获到SOAP消息可以看到，在消息报头中添加了basic这样的信息，如下代码所示：

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <basic xmlns="http://www.cnblogs.com/terrylee">Terrylee</basic>
    <To s:mustUnderstand="1">http://localhost:8887/CalculatorService</To>
    <Action s:mustUnderstand="1">http://tempuri.org/ICalculator/Add</Action>
  </s:Header>
  <s:Body>
    <Add xmlns="http://tempuri.org/">
      <x>1</x>
      <y>2</y>
    </Add>
  </s:Body>
</s:Envelope>

当然我们也可以通过配置的方式来自定义寻址报头，如下代码所示：

<service name="TerryLee.WCFAddressing.Service.CalculatorService"
         behaviorConfiguration="calculatorBehavior">
  <host>
    <baseAddresses>
      <add baseAddress="http://localhost:8887/Calculator"/>
    </baseAddresses>
  </host>
  <endpoint address=""
            binding ="wsHttpBinding"
            contract="TerryLee.WCFAddressing.Contract.ICalculator">
    <headers>
      <basic xmlns="http://www.cnblogs.com/terrylee">Terrylee</basic>
    </headers>
  </endpoint>
</service>

结束语

本文相对于WCF专题系列（1）：深入WCF寻址Part1来说，注重于实际的使用，介绍了指定终结点地址、元数据中的终结点地址、自定义消寻址报头等，在下一篇中，我们将继续深入WCF寻址，探讨消息筛选器等问题。WCF寻址相关文章：

WCF专题系列（5）：深入WCF寻址Part 5—逻辑地址和物理地址

WCF专题系列（4）：深入WCF寻址Part 4—自定义消息筛选器

WCF专题系列（3）：深入WCF寻址Part 3—消息过滤引擎

WCF专题系列（1）：深入WCF寻址Part 1—Web服务寻址规范

众所周知，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> ?
  <