WCF采用基于消息交換的通信方式，而綁定則實現(xiàn)了所有的通信細節(jié)。綁定通過創(chuàng)建信道棧實現(xiàn)了消息的編碼與傳輸，以及對WS-*協(xié)議的實現(xiàn)。在這一節(jié)中，我們就來著重介紹WCF中的信道和信道棧。在正式開始對信道和信息棧的介紹之前，我們先來介紹兩個重要的類型：CommunicationObject和DefaultCommunicationTimeouts。

CommunicationObject與DefaultCommunicationTimeouts

WCF綁定模型涉及多種類型的組件，比如信道、信道監(jiān)聽器、信道工廠等等。從功能上講，這些對象都是為通信服務(wù)的，我們可以把它們稱為通信對象（Communication Object）。對于這些通信對象來說，在通信不同的階段，它們往往具有不同的狀態(tài)；從整個通信的生命周期來看，在不同階段過渡的過程中，它們具有一些相似的狀態(tài)轉(zhuǎn)換方式。

WCF定義了一個特殊的接口，System.ServiceModel.ICommunicationObject，來管理通信對象的狀態(tài)和狀態(tài)的轉(zhuǎn)換。下面是ICommunicationObject的定義：

public interface ICommunicationObject{    // Events    event EventHandler Closed;    event EventHandler Closing;    event EventHandler Faulted;    event EventHandler Opened;    event EventHandler Opening;    // Methods    void Open();    void Open(TimeSpan timeout);    IAsyncResult BeginOpen(AsyncCallback callback, object state);    IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state);    void EndOpen(IAsyncResult result);    void Close();    void Close(TimeSpan timeout);    IAsyncResult BeginClose(AsyncCallback callback, object state);    IAsyncResult BeginClose(TimeSpan timeout, AsyncCallback callback, object state);    void EndClose(IAsyncResult result);    void Abort();    // Properties    CommunicationState State { get; }}

ICommunicationObject的State屬性，表示通信對象當前所處的狀態(tài)。該屬性通過一個名為System.ServiceModel.CommunicationState的枚舉類型表示，通信對象典型的六種狀態(tài)都定義在CommunicationState中：被創(chuàng)建（Created）、正被開啟（Opening）、已經(jīng)被開啟（Opened）、正被關(guān)閉（Closing）、已經(jīng)被關(guān)閉（Closed）已經(jīng)出錯（Faulted）。

public enum CommunicationState{    Created,    Opening,    Opened,    Closing,    Closed,    Faulted}

ICommunicationObject定義了以下三種類型的成員：

• 事件：當正在進行狀態(tài)轉(zhuǎn)化，或者是狀態(tài)轉(zhuǎn)換成功，會觸發(fā)相應(yīng)的事件。通過注冊相應(yīng)的事件，可以在某個狀態(tài)轉(zhuǎn)換環(huán)節(jié)中注入你需要的處理操作。
• 方法：定義了三種類型的操作：開啟（open）、關(guān)閉（close）、中止（abort）。關(guān)于“關(guān)閉”和“中止”在功能上具有相似之出，都是斷開連接、回收對象。不過它們具有不同之處，很多英文文章或書籍將“關(guān)閉（close）”成為“graceful shutdown（優(yōu)雅地關(guān)閉）”，而將“中止（abort）”描述為“immediate shutdown（立即關(guān)閉）”。那我們關(guān)閉電腦來說，前面一種是通過操作系統(tǒng)進行關(guān)閉，后一種則是直接切斷電源。對于前一種方式，在關(guān)閉過程中，會進行一些IO操作。
• 屬性：在上面已經(jīng)提到，屬性State代表通信對象當前所處的狀態(tài)。

由于WCF處理的是跨應(yīng)用程序域（Application Domain）、跨機器甚至是跨網(wǎng)絡(luò)的通信。所以WCF服務(wù)調(diào)用的大部分時間都在進行象網(wǎng)絡(luò)傳輸這樣的IO操作，對于這種IO綁定（IO bound）的操作，對于多線程、異步的考慮肯定是可以不免的，所以ICommunicationObject中的開啟和關(guān)閉操作，既定義了一個的同步方法，也按照異步編程模型（APM：Asynchronous Programming Mode）定義了異步方法。

除了簡單定義ICommunicationObject接口之外，WCF還定義了一個實現(xiàn)了該接口的基類：System.ServiceModel.Channels.CommunicationObject。

public abstract class CommunicationObject : ICommunicationObject { ... } 

在WCF體系中，很多的基于通信的基類都繼承自CommunicationObject，比如信道的基類System.ServiceModel.Channels.ChannelBase；信道工廠和信道監(jiān)聽器的基類System.ServiceModel.Channels.ChannelManagerBase；ServiceHost的基類System.ServiceModel.ServiceHostBase；信道分發(fā)器的基類System.ServiceModel.Dispatcher.ChannelDispatcherBase；等等。大體的繼承結(jié)構(gòu)如圖3-8所示 的類圖所示。

圖3-8 CommunicationObject繼承關(guān)系

由于WCF往往需要跨域網(wǎng)絡(luò)進行服務(wù)的訪問，較之一般的方法調(diào)用，服務(wù)訪問的所花的時間往往較長，所以對超時的處理顯得異常重要。比如對于消息的發(fā)送，可能由于網(wǎng)絡(luò)的故障，該消息在一端時間內(nèi)根本無法成功發(fā)送，客戶端程序不可能無限制地等待下去。一般的情況下，我們會設(shè)定一個操作執(zhí)行的所允許的最大時限，一旦超時則取消操作，并進行相應(yīng)的超時處理。

我們回顧一下ICommunicationObject的Open和BeginOpen方法，我們會發(fā)現(xiàn)它們各有兩個重載，其中一個具有的TimeSpan類型的timeout參數(shù)，另一個則沒有。在這里的timeout參數(shù)實際上代表Open方法執(zhí)行的超時時間，如果Open操作執(zhí)行的時間過長，一旦超過了該事件，操作將被立即中止。

public interface ICommunicationObject { void Open(); void Open(TimeSpan timeout); IAsyncResult BeginOpen(AsyncCallback callback, object state); IAsyncResult BeginOpen(TimeSpan timeout, AsyncCallback callback, object state); ... ... } 

可能讀者會問，對于沒有timeout參數(shù)的操作，比如無參的Open方法，是否意味著沒有這樣的超時限制，操作將會一直執(zhí)行下去直到操作正常結(jié)束呢？答案是否定的，實際上，對于沒有顯式指定超時時限的操作，采用的是默認的超時時限。WCF為所有需要默認超時時限的通信對象定義了一個接口：System.ServiceModel.IDefaultCommunicationTimeouts。在IDefaultCommunicationTimeouts中定一個了四個Timeout屬性，分別定義了開啟、關(guān)閉、發(fā)送、接收四大操作的超時時限。

public interface IDefaultCommunicationTimeouts{    // Properties     TimeSpan CloseTimeout { get; }    TimeSpan OpenTimeout { get; }    TimeSpan ReceiveTimeout { get; }    TimeSpan SendTimeout { get; }}

很多的基于通信的基類都實現(xiàn)了IDefaultCommunicationTimeouts接口，比如信道的基類System.ServiceModel.Channels.ChannelBase信道工廠和信道監(jiān)聽器的基類System.ServiceModel.Channels.ChannelManagerBase；以及所有綁定對象的基類System.ServiceModel.Channels.Binding等等。

2. IChannel和ChannelBase

WCF中信道層中的每種類型的信道直接或者間接實現(xiàn)了接口System.ServiceModel.Channels.IChannel，IChannel的定義異常簡單，僅僅具有一個唯一范型方法成員：GetProperty()。

public interface IChannel : ICommunicationObject{    // Methods     T GetProperty() where T : class;}

通過調(diào)用信道對象GetProperty方法，獲得具有范型類型的屬性。這個方法比較重要，因為它是探測信道是否具有某種能力的一種有效的方法。比如我們可以通過該方法，指定相應(yīng)的范型類型，確定信道是否支持某種Channel Shape（關(guān)于channel shape將在接下來的部分中進行介紹），消息版本和安全模式等等。

除了IChannel接口之外，WCF還定義了一個實現(xiàn)了IChannel接口的基類：System.ServiceModel.Channels.ChannelBase。。除了實現(xiàn)了IChannel接口，ChannelBase還實現(xiàn)了另外兩個接口：ICommnucationObject和IDefaultCommunicationTimeouts，并直接繼承自CommnucationObject。

public abstract class ChannelBase : CommunicationObject, IChannel, ICommunicationObject, IDefaultCommunicationTimeouts {     public virtual T GetProperty() where T : class;     //... ...     TimeSpan IDefaultCommunicationTimeouts.CloseTimeout { get; }     TimeSpan IDefaultCommunicationTimeouts.OpenTimeout { get; }     TimeSpan IDefaultCommunicationTimeouts.ReceiveTimeout { get; }     TimeSpan IDefaultCommunicationTimeouts.SendTimeout { get; } } 

3. 消息交換模式與Channel Shape

WCF完全采用基于消息的通信方式，對服務(wù)的消費最終通過一些列的消息交換實現(xiàn)。WCF應(yīng)用在不同的場景中按照不同的模式進行消息交換。

3.1. 消息交換模式（MEP）

消息交換模式（Message Exchange Pattern：MEP）在SOA中是一個重要的概念。在W3C的文獻中對MEP的官方定義是這樣的：MEP定義了參與者進行消息交換的模板（原文是：a template that describes the message exchange between messaging participants.），這是一個很抽象的定義。實際上我們可以這樣來理解MEP：消息交換模式（MEP）代表一系列的模板，它們定義了消息的發(fā)送者和接收者相互進行消息傳輸?shù)拇涡颉１容^典型的消息交換模式包含以下三種：數(shù)據(jù)報模式（Datagram）、請求/回復(fù)模式（Request/Reply）以及雙工模式（Duplex）。

數(shù)據(jù)報模式（Datagram）

數(shù)據(jù)報模式是最簡單的消息交換模式，又稱為發(fā)送/遺忘（Send/Forget）或者是單向模式（One-way）。數(shù)據(jù)報模式基于從一個源到一個或者多個目的地的單向消息傳輸。如圖3-9所示，在數(shù)據(jù)報模式下，消息的發(fā)送方將消息發(fā)送到接收方，并不希望收到對象的回復(fù)。

圖3-9 數(shù)據(jù)報消息交換模式

數(shù)據(jù)報模式具有一些變形，比較典型的包括以下一些消息交換的方式：

• 單目的地模式：一個消息的發(fā)送方將消息發(fā)送給單一的接收方
• 多投模式：一個消息發(fā)送方將消息發(fā)送給一系列預(yù)定義的接收方
• 廣播模式：和多投模式相似，只是接收方的范圍更加寬泛

數(shù)據(jù)報模式一般采用異步的消息發(fā)送方式，并不希望接收到對方的回復(fù)消息，在個別情況下甚至不關(guān)心消息能否正常地被接收。

請求/回復(fù)模式（Request/Reply）

在這三種典型的消息交換模式中，請求/回復(fù)模式是使用得最多的一種模式。在這種模式下，消息發(fā)送方來將消息發(fā)送給接收方后會等待對方的回復(fù)。請求/回復(fù)模式的消息交換情況如下圖所示。請求/回復(fù)模式一般采用同步的通信模式（盡管該模式也可以用于異步通信）。

圖3-10 請求-回復(fù)消息交換模式

雙工模式（Duplex）

如果采用雙工的消息交換模式，在進行消息交換過程中，任何一方都可以向?qū)Ψ桨l(fā)送消息，如圖3-11所示。

圖3-11 雙工消息交換模式

雙工通信使服務(wù)端回調(diào)客戶端成為可能：客戶端在調(diào)用服務(wù)的時候，指定一個回調(diào)對象，服務(wù)端操作執(zhí)行過程中可以通過回調(diào)對象回調(diào)客戶端的操作。比較典型雙工通信是我們熟悉的訂閱/發(fā)布模式。訂閱/發(fā)布模式下的消息交換雙方的角色發(fā)生了變化，傳統(tǒng)的發(fā)送方和接收方變成了訂閱方和發(fā)布方。訂閱方向發(fā)布方發(fā)送訂閱消息定于某一主題進行訂閱，發(fā)布方接收到訂閱消息后將訂閱方添加到訂閱列表之中。主題發(fā)布的時候，發(fā)布方提取當前主題的所有訂閱方，對它們進行消息廣播。

由于消息的交換依賴于網(wǎng)絡(luò)傳遞，所以消息交換模式與網(wǎng)絡(luò)協(xié)議的支持是一個不得不考慮的。對于雙工通信模式來說，它對于基于TCP協(xié)議的通信來說是完全沒有問題，因為TCP協(xié)議本身就是全雙工的網(wǎng)絡(luò)通信協(xié)議。但是對于HTTP來說，它本身就是簡單的基于請求/回復(fù)的網(wǎng)絡(luò)協(xié)議，是不支持雙工通信的。WCF通過WsDualHttpBinding實現(xiàn)了基于HTTP協(xié)議的雙工通信，實際上是采用了兩個HTTP通道實現(xiàn)的。

3.2. Channel Shape

在上面我們討論了三種典型的消息交換模式（MEP），現(xiàn)在我們結(jié)合MEP再來討論我們本節(jié)的主題：信道與信道棧。信道棧是消息交換的管道，在不同的消息交換模式下，這個管道在消息的發(fā)送端和接收端扮演著不同的角色。在數(shù)據(jù)報模式下，發(fā)送端的信道棧的作用是輸出（Output）數(shù)據(jù)報，接收端則是輸入（Input）數(shù)據(jù)報；對于請求恢復(fù)模式來說，發(fā)送端的作用是發(fā)送消息請求（Request），而接收端則是恢復(fù)（Reply）請求；而在雙工通信模式下，消息交換的雙方的地位完全是等價的，它們都具有 輸出和輸入的功能。

WCF通過一個特殊的術(shù)語來表述不同的消息交換模式對消息交換雙方信道的不同要求：Channel Shape。Channel Shape按照適用的消息交換模式的不同，將信道進行了分類。WCF為這些信道定義了一些列的接口來描述其賦予的能力。這些接口包括：IOutputChannel、IInputChannel、IRequestChannel、IReplyChannel、 IDuplexChannel，它們均定義在System.ServiceModel.Channels命名空間下。

下面的表格簡單列出了在不同的消息交換模式下，消息的發(fā)送方和接收方所使用的信道：

圖3-12所示的類圖簡單地描述了這些接口之間的層次結(jié)構(gòu)：所有的接口均繼承自IChannel接口，IDuplexChannel則繼承了IOutputChannel和IInput、Channel兩個接口。

圖3-12 Channel Shape

IOutChannel 與IInputChannel

接下來我們對這五種信道進行逐個介紹，先從IOutputChannel和IInputChannel開始。這兩種類型的信道適用于基于數(shù)據(jù)報模式的消息交換中，發(fā)送端通過IOutputChannel發(fā)送消息，而接收端則通過IInputChannel接收消息。反應(yīng)在接口的定義上，IOutputChannel主要定義的Send方法進行消息的發(fā)送，而IInputChannel則定義Receive方法進行消息的接收。先來看看IOutputChannel的定義：

public interface IOutputChannel : IChannel, ICommunicationObject{    // Methods    void Send(Message message);    void Send(Message message, TimeSpan timeout);    IAsyncResult BeginSend(Message message, AsyncCallback callback, object state);    IAsyncResult BeginSend(Message message, TimeSpan timeout, AsyncCallback callback, object state);    void EndSend(IAsyncResult result);    // Properties    EndpointAddress RemoteAddress { get; }    Uri Via { get; }}

IOutputChannel的定義顯得異常簡單，兩個重載的Send方法以同步的方式進行消息的發(fā)送，而兩個BeginSend/EndSend則用于消息的異步發(fā)送。重載方法通過一個timeout參數(shù)區(qū)分。對于一個具體的信道類型來說，它一般會繼承自ChannelBase類型。在上面我們已經(jīng)介紹了ChannelBase實現(xiàn)了接口System.ServiceModel.IDefaultCommunicationTimeouts接口，所以它具有默認的發(fā)送超時時限（SendTimout）。因此，在調(diào)用沒有timeout參數(shù)的Send或者BeginSend方法時，實際上采用的是自己默認的消息發(fā)送超時時限。

除了用于消息發(fā)送的方法成員之外，IOutputChannel還具有兩個額外的屬性成員：RemoteAddress和Via。RemoteAddress代表它試圖訪問的服務(wù)終結(jié)點的地址，而Via則代表是消息會真正發(fā)送的目的地址。RemoteAddress和Via所代表的地址 也就是在第二章介紹的邏輯地址和物理地址。在一般的情況下，這兩個地址是相同的，在需要進行手工尋址的情況下，它們可以是完全不同的兩個地址，關(guān)于WCF的尋址，請參閱第二章。

了解了IOutputChannel的定義，我想讀者應(yīng)該可以大體上猜得到與之相對的IInputChannel的定義了。IInputChannel用于消息的接收，所以定義了一系列Receive和BeginReceive/EndReceive方法用于同步或者異步的方式接收消息。不過IInputChannel較之IOutputChannel稍微復(fù)雜一些，它還定義了兩組額外的方法成員：TryReceive和BeginTryReceive/EndTryReceive，以及WaitForMessage和BeginWaitForMessage/EndWaitForMessage。

public interface IInputChannel : IChannel, ICommunicationObject{    // Methods    Message Receive();    Message Receive(TimeSpan timeout);    IAsyncResult BeginReceive(AsyncCallback callback, object state);    IAsyncResult BeginReceive(TimeSpan timeout, AsyncCallback callback, object state);    Message EndReceive(IAsyncResult result);    bool TryReceive(TimeSpan timeout, out Message message);    IAsyncResult BeginTryReceive(TimeSpan timeout, AsyncCallback callback, object state);    bool EndTryReceive(IAsyncResult result, out Message message);    bool WaitForMessage(TimeSpan timeout);    IAsyncResult BeginWaitForMessage(TimeSpan timeout, AsyncCallback callback, object state);    bool EndWaitForMessage(IAsyncResult result);    // Properties    EndpointAddress LocalAddress { get; }}

調(diào)用TryReceive和BeginTryReceive/EndTryReceive方法，在一個給定的時間范圍內(nèi)嘗試去接收請求消息，而WaitForMessage和BeginWaitForMessage/EndWaitForMessage則用于檢測是否有請求消息抵達。此外IOutputChannel的LocalAddress屬性代表信道所屬終結(jié)點的地址。

IRequestChannel和IReplyChannel

IRequestChannel和IReplyChannel定義了在請求-回復(fù)模式下消息發(fā)送方和接收方對信道的基本要求。對于消息的發(fā)送方的信道來說，它的主要功能就是向接收方發(fā)送消息請求并接收接收方發(fā)回的回復(fù)消息；與之相對，消息接收方負責對消息請求的接收，以及對回復(fù)消息的發(fā)送。

所以IRequestChannel的主要方法成員就是一組Request和BeginRequest/EndRequest方法用于同步和異步下請求的發(fā)送。整個IRequestChannel的定義如下所示 ：

public interface IRequestChannel : IChannel, ICommunicationObject{    // Methods    Message Request(Message message);    Message Request(Message message, TimeSpan timeout);    IAsyncResult BeginRequest(Message message, AsyncCallback callback, object state);    IAsyncResult BeginRequest(Message message, TimeSpan timeout, AsyncCallback callback, object state);    Message EndRequest(IAsyncResult result);    // Properties    EndpointAddress RemoteAddress { get; }    Uri Via { get; }}

和IOutputChannel接口一樣，Request和BeginRequest方法各有兩個重載，它們通過一個timeout參數(shù)進行區(qū)分。Timeout參數(shù)代表請求發(fā)送（同步或者異步）的超時時限，如果沒有此參數(shù)，則采用默認的超時時限。兩個屬性RemoteAddress和Via則分別表示目的終結(jié)點的地址，以及消息真正發(fā)送的目的地址。換句話說，RemoteAddress和Via所代表的是在第二章介紹的邏輯地址和物理地址。

IReplyChannel和IInputChannel的成員結(jié)構(gòu)很相似，不過IInputChannel的主要功能就就是單純的接收消息，所以定義了一系列Receive相關(guān)的方法；而IReplyChannel負責接受請求，所以IReplyChannel圍繞著ReceiveRequest展開。包括3種類型的ReceiveRequest方法：ReceiveRequest和BeginReceiveRequest/EndReceiveRequest，TryReceiveRequest和BeginTryReceiveRequest/EndTryReceiveRequest和WaitForRequest和BeginWaitForRequest和EndWaitForRequest。

public interface IReplyChannel : IChannel, ICommunicationObject{    // Methods     RequestContext ReceiveRequest();    RequestContext ReceiveRequest(TimeSpan timeout);    IAsyncResult BeginReceiveRequest(AsyncCallback callback, object state);    IAsyncResult BeginReceiveRequest(TimeSpan timeout, AsyncCallback callback, object state);    RequestContext EndReceiveRequest(IAsyncResult result);    bool TryReceiveRequest(TimeSpan timeout, out RequestContext context);    IAsyncResult BeginTryReceiveRequest(TimeSpan timeout, AsyncCallback callback, object state);    bool EndTryReceiveRequest(IAsyncResult result, out RequestContext context);    bool WaitForRequest(TimeSpan timeout);    IAsyncResult BeginWaitForRequest(TimeSpan timeout, AsyncCallback callback, object state);    bool EndWaitForRequest(IAsyncResult result);    // Properties    EndpointAddress LocalAddress { get; }}

對于IReplyChannel來說，有一點需要特別說明。和我們一般想象的不一樣，不論是ReceiveRequest的返回類型，還是EndTryReceiveRequest的輸出參數(shù)類型，并不是一個Message類型，而是一個RequestContext類型。RequestContext可以看成是請求和回復(fù)之間的一道橋梁，通過RequestContext既可以獲取請求消息（通過RequestContext的RequestMessage屬性獲取以Message類型返回德請求消息），也可以向請求端發(fā)送回復(fù)消息（在RequestContext定義了一系列Reply和BeginReply/EndReply方法將作為參數(shù)的Message對象發(fā)回請求端）。

IDuplexChannel

由于在雙工模式下的消息交換中，消息的發(fā)送端和接收端具有相同的行為和功能：消息的發(fā)送和接收，所以基于雙工模式的信道， IDuplexChannel兼具IOutputChannel和IInputChannel的特性。反映在接口的定義上就是IDuplexChannel同時繼承了IOutputChannel和IInputChannel：

public interface IDuplexChannel : IInputChannel, IOutputChannel, IChannel, ICommunicationObject{}

WCF中的綁定模型：
[WCF中的Binding模型]之一: Binding模型簡介
[WCF中的Binding模型]之二: 信道與信道棧（Channel and Channel Stack）
[WCF中的Binding模型]之三：信道監(jiān)聽器（Channel Listener）
[WCF中的Binding模型]之四：信道工廠（Channel Factory）
[WCF中的Binding模型]之五：綁定元素（Binding Element）
[WCF中的Binding模型]之六：從綁定元素認識系統(tǒng)預(yù)定義綁定

NET技術(shù)：[WCF中的Binding模型]之二: 信道與信道棧（Channel and Channel Stack），轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。