本文共 8873 字，大约阅读时间需要 29 分钟。

WCF采用基于消息交换的通信方式，而绑定则实现了所有的通信细节。绑定通过创建信道栈实现了消息的编码与传输，以及对WS-*协议的实现。在这一节中，我们就来着重介绍WCF中的信道和信道栈。在正式开始对信道和信息栈的介绍之前，我们先来介绍两个重要的类型：CommunicationObject和DefaultCommunicationTimeouts。

一、与DefaultCommunicationTimeouts

WCF绑定模型涉及多种类型的组件，比如信道、信道监听器、信道工厂等等。从功能上讲，这些对象都是为通信服务的，我们可以把它们称为通信对象（Communication Object）。对于这些通信对象来说，在通信不同的阶段，它们往往具有不同的状态；从整个通信的生命周期来看，在不同阶段过渡的过程中，它们具有一些相似的状态转换方式。

WCF定义了一个特殊的接口，System.ServiceModel.ICommunicationObject，来管理通信对象的状态和状态的转换。下面是ICommunicationObject的定义：

1: public interface ICommunicationObject

2: {

3:     // Events

4:     event EventHandler Closed;

5:     event EventHandler Closing;

6:     event EventHandler Faulted;

7:     event EventHandler Opened;

8:     event EventHandler Opening;

9:

10:     // Methods

11:     void Open();

12:     void Open(TimeSpan timeout);

13:     IAsyncResult BeginOpen(AsyncCallback callback, object state);

14:     IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state);

15:     void EndOpen(IAsyncResult result);

16:

17:     void Close();

18:     void Close(TimeSpan timeout);

19:     IAsyncResult BeginClose(AsyncCallback callback, object state);

20:     IAsyncResult BeginClose(TimeSpan timeout, AsyncCallback callback, object state);

21:     void EndClose(IAsyncResult result);

22:

23:     void Abort();

24:

25:     // Properties

26:     CommunicationState State { get; }

27: }

ICommunicationObject的State属性，表示通信对象当前所处的状态。该属性通过一个名为System.ServiceModel.CommunicationState的枚举类型表示，通信对象典型的六种状态都定义在CommunicationState中：被创建（Created）、正被开启（Opening）、已经被开启（Opened）、正被关闭（Closing）、已经被关闭（Closed）已经出错（Faulted）。

1: public enum CommunicationState

2: {

3:     Created,

4:     Opening,

5:     Opened,

6:     Closing,

7:     Closed,

8:     Faulted

9: }

• 事件：当正在进行状态转化，或者是状态转换成功，会触发相应的事件。通过注册相应的事件，可以在某个状态转换环节中注入你需要的处理操作。
• 方法：定义了三种类型的操作：开启（open）、关闭（close）、中止（abort）。关于“关闭”和“中止”在功能上具有相似之出，都是断开连接、回收对象。不过它们具有不同之处，很多英文文章或书籍将“关闭（close）”成为“graceful shutdown（优雅地关闭）”，而将“中止（abort）”描述为“immediate shutdown（立即关闭）”。那我们关闭电脑来说，前面一种是通过操作系统进行关闭，后一种则是直接切断电源。对于前一种方式，在关闭过程中，会进行一些IO操作。
• 属性：在上面已经提到，属性State代表通信对象当前所处的状态。

由于WCF处理的是跨应用程序域（Application Domain）、跨机器甚至是跨网络的通信。所以WCF服务调用的大部分时间都在进行象网络传输这样的IO操作，对于这种IO绑定（IO bound）的操作，对于多线程、异步的考虑肯定是可以不免的，所以ICommunicationObject中的开启和关闭操作，既定义了一个的同步方法，也按照异步编程模型（APM：Asynchronous Programming Mode）定义了异步方法。

除了简单定义ICommunicationObject接口之外，WCF还定义了一个实现了该接口的基类：System.ServiceModel.Channels.CommunicationObject。

1: public abstract class CommunicationObject : ICommunicationObject

2: {

3:         //... ...

4: }

在WCF体系中，很多的基于通信的基类都继承自CommunicationObject，比如信道的基类System.ServiceModel.Channels.ChannelBase；信道工厂和信道监听器的基类System.ServiceModel.Channels.ChannelManagerBase；ServiceHost的基类System.ServiceModel.ServiceHostBase；信道分发器的基类System.ServiceModel.Dispatcher.ChannelDispatcherBase；等等。大体的继承结构如图1所示 的类图所示。

图1 CommunicationObject继承关系

由于WCF往往需要跨域网络进行服务的访问，较之一般的方法调用，服务访问的所花的时间往往较长，所以对超时的处理显得异常重要。比如对于消息的发送，可能由于网络的故障，该消息在一端时间内根本无法成功发送，客户端程序不可能无限制地等待下去。一般的情况下，我们会设定一个操作执行的所允许的最大时限，一旦超时则取消操作，并进行相应的超时处理。

我们回顾一下ICommunicationObject的Open和BeginOpen方法，我们会发现它们各有两个重载，其中一个具有的TimeSpan类型的timeout参数，另一个则没有。在这里的timeout参数实际上代表Open方法执行的超时时间，如果Open操作执行的时间过长，一旦超过了该事件，操作将被立即中止。

1: public interface ICommunicationObject

2: {

3:     void Open();

4:     void Open(TimeSpan timeout);

5:     IAsyncResult BeginOpen(AsyncCallback callback, object state);

6:     IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state);

7:     //... ...

8: }

可能读者会问，对于没有timeout参数的操作，比如无参的Open方法，是否意味着没有这样的超时限制，操作将会一直执行下去直到操作正常结束呢？答案是否定的，实际上，对于没有显式指定超时时限的操作，采用的是默认的超时时限。WCF为所有需要默认超时时限的通信对象定义了一个接口：System.ServiceModel.IDefaultCommunicationTimeouts。在IDefaultCommunicationTimeouts中定一个了四个Timeout属性，分别定义了开启、关闭、发送、接收四大操作的超时时限。

1: public interface IDefaultCommunicationTimeouts

2: {

3:     // Properties

4:     TimeSpan CloseTimeout { get; }

5:     TimeSpan OpenTimeout { get; }

6:     TimeSpan ReceiveTimeout { get; }

7:     TimeSpan SendTimeout { get; }

8: }

很多的基于通信的基类都实现了IDefaultCommunicationTimeouts接口，比如信道的基类System.ServiceModel.Channels.ChannelBase信道工厂和信道监听器的基类System.ServiceModel.Channels.ChannelManagerBase；以及所有绑定对象的基类System.ServiceModel.Channels.Binding等等。

二、和ChannelBase

WCF中信道层中的每种类型的信道直接或者间接实现了接口System.ServiceModel.Channels.IChannel，IChannel的定义异常简单，仅仅具有一个唯一范型方法成员：GetProperty<T>()：

1: public interface IChannel : ICommunicationObject

2: {

3:     // Methods

4:     T GetProperty
     
      () where T : class;
     

5: }

6:

通过调用信道对象GetProperty<T>方法，获得具有范型类型的属性。这个方法比较重要，因为它是探测信道是否具有某种能力的一种有效的方法。比如我们可以通过该方法，指定相应的范型类型，确定信道是否支持某种Channel Shape（关于channel shape将在接下来的部分中进行介绍），消息版本和安全模式等等。

除了IChannel接口之外，WCF还定义了一个实现了IChannel接口的基类：System.ServiceModel.Channels.ChannelBase。。除了实现了IChannel接口，ChannelBase还实现了另外两个接口：ICommnucationObject和IDefaultCommunicationTimeouts，并直接继承自CommnucationObject。

1: public abstract class ChannelBase : CommunicationObject, IChannel, ICommunicationObject, IDefaultCommunicationTimeouts

2: {

3:     public virtual T GetProperty
     
      () where T : class;
     

4:     //... ...

5:     TimeSpan IDefaultCommunicationTimeouts.CloseTimeout { get; }

6:     TimeSpan IDefaultCommunicationTimeouts.OpenTimeout { get; }

7:     TimeSpan IDefaultCommunicationTimeouts.ReceiveTimeout { get; }

8:     TimeSpan IDefaultCommunicationTimeouts.SendTimeout { get; }

9: }

三、 消息交换模式与Channel Shape

WCF完全采用基于消息的通信方式，对服务的消费最终通过一些列的消息交换实现。WCF应用在不同的场景中按照不同的模式进行消息交换。

3.1. 消息交换模式（MEP）

消息交换模式（Message Exchange Pattern：MEP）在SOA中是一个重要的概念。在W3C的文献中对MEP的官方定义是这样的：MEP定义了参与者进行消息交换的模板（原文是：a template that describes the message exchange between messaging participants.），这是一个很抽象的定义。实际上我们可以这样来理解MEP：消息交换模式（MEP）代表一系列的模板，它们定义了消息的发送者和接收者相互进行消息传输的次序。比较典型的消息交换模式包含以下三种：数据报模式（Datagram）、请求/回复模式（Request/Reply）以及双工模式（Duplex）。

数据报模式（Datagram）

数据报模式是最简单的消息交换模式，又称为发送/遗忘（Send/Forget）或者是单向模式（One-way）。数据报模式基于从一个源到一个或者多个目的地的单向消息传输。如图2所示，在数据报模式下，消息的发送方将消息发送到接收方，并不希望收到对象的回复。

图2数据报消息交换模式

数据报模式具有一些变形，比较典型的包括以下一些消息交换的方式：

• 单目的地模式：一个消息的发送方将消息发送给单一的接收方
• 多投模式：一个消息发送方将消息发送给一系列预定义的接收方
• 广播模式：和多投模式相似，只是接收方的范围更加宽泛

数据报模式一般采用异步的消息发送方式，并不希望接收到对方的回复消息，在个别情况下甚至不关心消息能否正常地被接收。

请求/回复模式（Request/Reply）

在这三种典型的消息交换模式中，请求/回复模式是使用得最多的一种模式。在这种模式下，消息发送方来将消息发送给接收方后会等待对方的回复。请求/回复模式的消息交换情况如下图所示。请求/回复模式一般采用同步的通信模式（尽管该模式也可以用于异步通信）。

图3 请求-回复消息交换模式

双工模式（Duplex）

如果采用双工的消息交换模式，在进行消息交换过程中，任何一方都可以向对方发送消息，如图4所示。

图4双工消息交换模式

双工通信使服务端回调客户端成为可能：客户端在调用服务的时候，指定一个回调对象，服务端操作执行过程中可以通过回调对象回调客户端的操作。比较典型双工通信是我们熟悉的订阅/发布模式。订阅/发布模式下的消息交换双方的角色发生了变化，传统的发送方和接收方变成了订阅方和发布方。订阅方向发布方发送订阅消息定于某一主题进行订阅，发布方接收到订阅消息后将订阅方添加到订阅列表之中。主题发布的时候，发布方提取当前主题的所有订阅方，对它们进行消息广播。

由于消息的交换依赖于网络传递，所以消息交换模式与网络协议的支持是一个不得不考虑的。对于双工通信模式来说，它对于基于TCP协议的通信来说是完全没有问题，因为TCP协议本身就是全双工的网络通信协议。但是对于HTTP来说，它本身就是简单的基于请求/回复的网络协议，是不支持双工通信的。WCF通过WsDualHttpBinding实现了基于HTTP协议的双工通信，实际上是采用了两个HTTP通道实现的。

3.2. Channel Shape

在上面我们讨论了三种典型的消息交换模式（MEP），现在我们结合MEP再来讨论我们本节的主题：信道与信道栈。信道栈是消息交换的管道，在不同的消息交换模式下，这个管道在消息的发送端和接收端扮演着不同的角色。在数据报模式下，发送端的信道栈的作用是输出（Output）数据报，接收端则是输入（Input）数据报；对于请求恢复模式来说，发送端的作用是发送消息请求（Request），而接收端则是恢复（Reply）请求；而在双工通信模式下，消息交换的双方的地位完全是等价的，它们都具有 输出和输入的功能。

WCF通过一个特殊的术语来表述不同的消息交换模式对消息交换双方信道的不同要求：Channel Shape。Channel Shape按照适用的消息交换模式的不同，将信道进行了分类。WCF为这些信道定义了一些列的接口来描述其赋予的能力。这些接口包括：IOutputChannel、IInputChannel、IRequestChannel、IReplyChannel、 IDuplexChannel，它们均定义在System.ServiceModel.Channels命名空间下。

下面的表格简单列出了在不同的消息交换模式下，消息的发送方和接收方所使用的信道：

图5所示的类图简单地描述了这些接口之间的层次结构：所有的接口均继承自IChannel接口，IDuplexChannel则继承了IOutputChannel和IInput、Channel两个接口。

图5 Channel Shape

IOutChannel 与IInputChannel

接下来我们对这五种信道进行逐个介绍，先从IOutputChannel和IInputChannel开始。这两种类型的信道适用于基于数据报模式的消息交换中，发送端通过IOutputChannel发送消息，而接收端则通过IInputChannel接收消息。反应在接口的定义上，IOutputChannel主要定义的Send方法进行消息的发送，而IInputChannel则定义Receive方法进行消息的接收。先来看看IOutputChannel的定义：

1: public interface IOutputChannel : IChannel, ICommunicationObject

2: {

3:     // Methods

4:     void Send(Message message);

5:     void Send(Message message, TimeSpan timeout);

6:

7:     IAsyncResult BeginSend(Message message, AsyncCallback callback, object state);

8:     IAsyncResult BeginSend(Message message, TimeSpan timeout, AsyncCallback callback, object state);

转载地址：https://blog.csdn.net/iteye_11848/article/details/81646858 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！