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

CommunicationObject與DefaultCommunicationTimeouts

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

WCF定義了一個(gè)特殊的接口，System.ServiceModel.ICommunicationObject，來管理通信對(duì)象的狀態(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屬性，表示通信對(duì)象當(dāng)前所處的狀態(tài)。該屬性通過一個(gè)名為System.ServiceModel.CommunicationState的枚舉類型表示，通信對(duì)象典型的六種狀態(tài)都定義在CommunicationState中：被創(chuàng)建（Created）、正被開啟（Opening）、已經(jīng)被開啟（Opened）、正被關(guān)閉（Closing）、已經(jīng)被關(guān)閉（Closed）已經(jīng)出錯(cuò)（Faulted）。

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

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

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

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

除了簡(jiǎn)單定義ICommunicationObject接口之外，WCF還定義了一個(gè)實(shí)現(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ò)進(jìn)行服務(wù)的訪問，較之一般的方法調(diào)用，服務(wù)訪問的所花的時(shí)間往往較長(zhǎng)，所以對(duì)超時(shí)的處理顯得異常重要。比如對(duì)于消息的發(fā)送，可能由于網(wǎng)絡(luò)的故障，該消息在一端時(shí)間內(nèi)根本無法成功發(fā)送，客戶端程序不可能無限制地等待下去。一般的情況下，我們會(huì)設(shè)定一個(gè)操作執(zhí)行的所允許的最大時(shí)限，一旦超時(shí)則取消操作，并進(jìn)行相應(yīng)的超時(shí)處理。

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

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

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

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

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

2. IChannel和ChannelBase

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

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

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

除了IChannel接口之外，WCF還定義了一個(gè)實(shí)現(xiàn)了IChannel接口的基類：System.ServiceModel.Channels.ChannelBase。。除了實(shí)現(xiàn)了IChannel接口，ChannelBase還實(shí)現(xiàn)了另外兩個(gè)接口：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完全采用基于消息的通信方式，對(duì)服務(wù)的消費(fèi)最終通過一些列的消息交換實(shí)現(xiàn)。WCF應(yīng)用在不同的場(chǎng)景中按照不同的模式進(jìn)行消息交換。

3.1. 消息交換模式（MEP）

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

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

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

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

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

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

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

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

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

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

雙工模式（Duplex）

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

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

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

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

3.2. Channel Shape

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

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

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

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

圖3-12 Channel Shape

IOutChannel 與IInputChannel

接下來我們對(duì)這五種信道進(jìn)行逐個(gè)介紹，先從IOutputChannel和IInputChannel開始。這兩種類型的信道適用于基于數(shù)據(jù)報(bào)模式的消息交換中，發(fā)送端通過IOutputChannel發(fā)送消息，而接收端則通過IInputChannel接收消息。反應(yīng)在接口的定義上，IOutputChannel主要定義的Send方法進(jìn)行消息的發(fā)送，而IInputChannel則定義Receive方法進(jìn)行消息的接收。先來看看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的定義顯得異常簡(jiǎn)單，兩個(gè)重載的Send方法以同步的方式進(jìn)行消息的發(fā)送，而兩個(gè)BeginSend/EndSend則用于消息的異步發(fā)送。重載方法通過一個(gè)timeout參數(shù)區(qū)分。對(duì)于一個(gè)具體的信道類型來說，它一般會(huì)繼承自ChannelBase類型。在上面我們已經(jīng)介紹了ChannelBase實(shí)現(xiàn)了接口System.ServiceModel.IDefaultCommunicationTimeouts接口，所以它具有默認(rèn)的發(fā)送超時(shí)時(shí)限（SendTimout）。因此，在調(diào)用沒有timeout參數(shù)的Send或者BeginSend方法時(shí)，實(shí)際上采用的是自己默認(rèn)的消息發(fā)送超時(shí)時(shí)限。

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

了解了IOutputChannel的定義，我想讀者應(yīng)該可以大體上猜得到與之相對(duì)的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方法，在一個(gè)給定的時(shí)間范圍內(nèi)嘗試去接收請(qǐng)求消息，而WaitForMessage和BeginWaitForMessage/EndWaitForMessage則用于檢測(cè)是否有請(qǐng)求消息抵達(dá)。此外IOutputChannel的LocalAddress屬性代表信道所屬終結(jié)點(diǎn)的地址。

IRequestChannel和IReplyChannel

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

所以IRequestChannel的主要方法成員就是一組Request和BeginRequest/EndRequest方法用于同步和異步下請(qǐng)求的發(fā)送。整個(gè)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方法各有兩個(gè)重載，它們通過一個(gè)timeout參數(shù)進(jìn)行區(qū)分。Timeout參數(shù)代表請(qǐng)求發(fā)送（同步或者異步）的超時(shí)時(shí)限，如果沒有此參數(shù)，則采用默認(rèn)的超時(shí)時(shí)限。兩個(gè)屬性RemoteAddress和Via則分別表示目的終結(jié)點(diǎn)的地址，以及消息真正發(fā)送的目的地址。換句話說，RemoteAddress和Via所代表的是在第二章介紹的邏輯地址和物理地址。

IReplyChannel和IInputChannel的成員結(jié)構(gòu)很相似，不過IInputChannel的主要功能就就是單純的接收消息，所以定義了一系列Receive相關(guān)的方法；而IReplyChannel負(fù)責(zé)接受請(qǐng)求，所以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; }}

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

IDuplexChannel

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

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

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

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

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