从本质上说，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能够有更深的认识。

总结

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

在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> ?
  <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> ?
<wsa:Action>xs:anyURI</wsa:Action>
<wsa:MessageID>xs:anyURI</wsa:MessageID> ?
<wsa:RelatesTo RelationshipType="xs:anyURI"?>xs:anyURI</wsa:RelatesTo> *
<wsa:ReferenceParameters>xs:any*</wsa:ReferenceParameters> ?

下面我们对其做一些解释：

To：表示目标 Web 服务的 URL，当使用端点引用（EPR）时，To 头应该与 <wsa:Address> 元素具有相同的值。

From：表示消息发送方的终结点引用，如果消息接收方需要向发送消息的终结点发送回消息，那么它应该使用这个终结点引用。

ReplyTo：表示来自于Web服务的任何响应都应该被发送给ReplyTo终结点引用，即消息的发送方并不一定是要接收响应消息的终结点，这和From是有区别的。

FaultTo：如果消息的响应是SOAP错误，那么这个错误应该在 FaultTo头中发送给终结点引用。

MessageID：用来唯一的识别消息。

Action：对于Action可以这么理解，当消息发送的服务时，指定如何处理该消息，更简单一点，就是希望服务调用哪个方法来处理消息。如下代码所示，希望消息到达服务时，调用Add方法来处理。

<wsa:Action>http://tempuri.org/ICalculator/Add</wsa:Action>

RelatesTo：RelatesTo常用在响应消息中，用来指示它与先前知道的消息相关并且定义这种关系的URI。这在请求响应模式中非常关键，尤其是异步消息传递中，响应消息的接收方必须能够将它与原始请求消息相关联。

我们把消息信息报头Message Information Headers与SOAP用图3来清晰的表示：

图3

有关WS-Addressing规范的详细信息大家可以参考http://www.w3.org/Submission/ws-addressing/。

分析WCF消息

上面我介绍了Web服务寻址规范，现在我们截获一下WCF的消息，来看看它是如何符合WS-Addressing的。现在编写一个简单的WCF服务：

/// <summary>
/// Author: TerryLee
/// Url:http://www.cnblogs.com/terrylee
/// </summary>
[ServiceContract]
public interface ICalculator
{
    [OperationContract]
    int Add(int x, int y);
}

public class CalculatorService : ICalculator
{
    public int Add(int x, int y)
    {
        return x + y;
    }
}

我们可以用跟踪诊断的方式来截获到SOAP消息，如下所示，可以看到这个调用服务过程中，消息报头中的To地址以及Action，这里的Action就是我们在服务中定义的Add方法，以及消息的Body：

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
  <s:Header>
    <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>

结束语

Web服务寻址规范带来了Web服务世界的寻址标准，它通过定义终结点引用（Endpoint Reference）和消息信息报头（Message Information Headers）来提供了一种统一的机制。在下一篇中，我将继续深入分析WCF中的寻址，WCF寻址相关文章：

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

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

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

WCF专题系列（2）：深入WCF寻址Part 2—自定义寻址报头