1. 信道層與服務(wù)模型層(Channel Layer and Service Mode Layer)

對(duì)于一個(gè)分布式應(yīng)用的開發(fā)與設(shè)計(jì)來說，通信問題是不得不考慮，同時(shí)也是最為復(fù)雜、最難實(shí)現(xiàn)的問題。在過去的若干年中, 微軟先后推出了一系列廣受歡迎的通信技術(shù), 比如DCOM、Enterprise Service、.NET Remoting、XML Web Service、MSMQ等等。這些技術(shù)提供了各自的編程模型，是開發(fā)人員從繁瑣的完全基于通信的編程中解脫出來，使之僅僅需要關(guān)注具體的業(yè)務(wù)邏輯。WCF是所有的這些通信技術(shù)集大成者，它充分地整合了所有這些使用于不同領(lǐng)域、不同場(chǎng)景的通信技術(shù)，提供了一個(gè)統(tǒng)一的編程模型。

無論從功能上講，還是從WCF的整個(gè)基礎(chǔ)構(gòu)架的層次結(jié)構(gòu)上講，WCF可以分成兩個(gè)不部分：編程模型和通信實(shí)現(xiàn)。編程模型通過WCF服務(wù)模型層（service mode layer）提供，而信道層 (channel layer) 則提供了具體的通信的實(shí)現(xiàn)。服務(wù)模型層建立在信道層之上，對(duì)于一般的WCF開發(fā)人員來講，他們僅僅會(huì)接觸到服務(wù)模型層，而信道層則是被屏蔽掉的。

2. 信道與信道棧（Channel and Channel Stack）

WCF的通信是基于消息的，如果從消息交換（message exchange）的角度講，信道層則可以看成是進(jìn)行消息交換參與者之間的中介。信道層通過一個(gè)個(gè)信道組成一個(gè)連續(xù)的信道棧，該信道棧構(gòu)成了一個(gè)消息流通的管道。消息的發(fā)送者通過該管道流到消息的接收者，消息的接收者對(duì)消息進(jìn)行相應(yīng)的處理，生成新的消息通過該管道回復(fù)給消息的發(fā)送者。

但是，不要將這個(gè)通過一系列信道組成的管道的功能僅僅局限于消息的傳輸，實(shí)際上該管道承載著許多額外的功能。

我們可以打個(gè)比方，比如一個(gè)自來水廠，水源可能取自天然的湖水，在水廠生產(chǎn)的水最終通過自來水管流到居民的家中被飲用之前，需要對(duì)水進(jìn)行必要的處理。中間的流程可能是這樣的：湖水被汲取到一個(gè)池子中先進(jìn)行雜質(zhì)的過濾（我們稱這個(gè)池為過濾池）；被過濾后的水流到第二個(gè)池子中進(jìn)行消毒處理（我們稱這個(gè)池為消毒池）；被消毒處理的后水流到第三個(gè)池子中進(jìn)行水質(zhì)軟化處理（我們稱這個(gè)池為軟化池）；最終水通過自來水管道流到居民的家中。

實(shí)際上，我們將的信道棧就相當(dāng)于一個(gè)自來水廠，而構(gòu)成信道棧的一個(gè)個(gè)信道就相當(dāng)過濾池、消毒池、軟化池以及自來水管道。唯一不同的是，自來水廠處理的是水，而信道棧處理的是消息（message）。這樣設(shè)計(jì)的最大的好處就是具有很強(qiáng)的可擴(kuò)展性，因?yàn)槲覀儾豢赡堋⒁矝]有必要設(shè)計(jì)出一種信道能夠進(jìn)行所有的消息處理任務(wù)，我們需要做的僅僅讓一個(gè)信道專注于某一種功能的實(shí)現(xiàn)，通過對(duì)信道的合理組合從而實(shí)現(xiàn)我們實(shí)際的消息處理的功能。

對(duì)于一個(gè)自來水廠來說，最終的目的上自己生產(chǎn)的水讓消費(fèi)者能夠飲用，所以自來水管道是必須的，至于中間的環(huán)節(jié)，過濾、消毒、軟化、……，可能在水質(zhì)良好的情況下就不是必要的了。與此類似，對(duì)于一個(gè)信道棧來說，有兩種信道是必須的：傳輸信道（transport channel）和消息編碼信道（message encoding channel）。原因很簡單，信道棧的目的就是實(shí)現(xiàn)消息的傳輸，傳輸信道肯定是必須的，而進(jìn)行傳輸?shù)那疤幔枰獙?duì)消息進(jìn)行合理編碼，比如基于文本編碼和二進(jìn)制編碼。如下圖所示：

由于WCF采用完全基于消息的通信方式，所有功能的實(shí)現(xiàn)，無論是業(yè)務(wù)有關(guān)的，還是業(yè)務(wù)無關(guān)的，都是通過消息交換來實(shí)現(xiàn)的。對(duì)于信道棧來說，除了必要的消息處理功能（消息編碼與傳輸），為了一些額外的功能的實(shí)現(xiàn)需要添加新的信道。比如，對(duì)于無狀態(tài)的http協(xié)議需要提供對(duì)會(huì)話的支持，需要添加相應(yīng)的會(huì)話支持的信道；為了通過對(duì)事物的支持，將多個(gè)服務(wù)調(diào)用納入同一個(gè)事物中，需要專門的事物支持的信道；為了減少網(wǎng)絡(luò)流量，在傳輸之前需要對(duì)消息進(jìn)行壓縮，需要專門的消息壓縮信道，等等。

從另一個(gè)方面講，WCF是基于WS-*的，WS-*通過一系列的協(xié)議制定了一套業(yè)界的Web Service標(biāo)準(zhǔn)，使不同廠商之間的互操作成為可能。WCF對(duì)最新的WS-*提供了支持，而且毫無疑問，隨著WS-*的逐步完善，WCF將會(huì)與之保持同步。對(duì)于絕大部分WS-*協(xié)議的支持，都是通過在信道棧中添加相應(yīng)的信道實(shí)現(xiàn)的, 所以我們把這樣的信道稱為協(xié)議信道（protocol channel）。如下圖所示,在傳輸信道和消息編碼信道之上, WS-Security實(shí)現(xiàn)了消息層的安全;WS-RM（WS-Reliable Messaging）實(shí)現(xiàn)了可靠消息通信；WS-AT（WS-Atomic Transaction）實(shí)現(xiàn)了分布式的事務(wù)支持。

3. WCF的綁定模型（WCF Binding Mode）

綁定模型如下圖所示，其中最左邊的部分就是信道棧，而右邊就則是綁定對(duì)象本身。WCF通信的本質(zhì)在于通過綁定對(duì)象提供的API構(gòu)建信道棧，從而實(shí)現(xiàn)基于消息的通信。在信道棧和綁定之間，還存在著一些中間對(duì)象。它們是信道管理器（Channel Manager）、綁定元素（Binding Element）和綁定上下文（Binding Context）。

在整個(gè)綁定模型中，信道和信道棧位于最底層。信道棧是消息進(jìn)行通信的通道，組成信道棧的各個(gè)信道處于各自的目的對(duì)消息進(jìn)行相應(yīng)的處理。按照功能劃分，可以將信道分成三類：傳輸信道、消息編碼信道和協(xié)議信道。傳輸信道實(shí)現(xiàn)了基于某種協(xié)議（HTTP、HTTPS、TCP等等）的消息傳輸；消息編碼實(shí)現(xiàn)了對(duì)消息的編碼，常見的消息編碼方式有：Text/XML、Binary和MTOM；而協(xié)議信道則實(shí)現(xiàn)了WCF對(duì)若然WS-*協(xié)議的支持，比如WS-Security、WS-RM、WS-AT等等。

在WCF中，信道棧的創(chuàng)建和生命周期的管理通過信道管理器（channel manager）來進(jìn)行管理。對(duì)于信道管理器，大家可能有點(diǎn)了陌生，不過如果回顧一下我們前面演示的通過綁定進(jìn)行直接通信的例子，大家一定還記得這么兩個(gè)對(duì)象：信道監(jiān)聽器（channel listener）和信道工廠（channel factory）。實(shí)際上，信道監(jiān)聽器和信道工廠是信道管理器兩個(gè)別名。在服務(wù)端，通過信道監(jiān)聽器對(duì)服務(wù)請(qǐng)求進(jìn)行監(jiān)聽，當(dāng)請(qǐng)求消息被成功檢測(cè)，則通過信道監(jiān)聽器創(chuàng)建信道棧對(duì)請(qǐng)求消息進(jìn)行接收和處理；在客戶端，信道棧被信道工廠創(chuàng)建，并用于請(qǐng)求消息的處理和發(fā)送。

一般來講，信道管理器，無論是信道監(jiān)聽器還是信道工廠，都對(duì)應(yīng)著一個(gè)綁定元素（binding element）對(duì)象。綁定元素負(fù)責(zé)對(duì)相應(yīng)信道管理器的創(chuàng)建。從創(chuàng)建對(duì)象的角度來看，信道管理器負(fù)責(zé)對(duì)信道的創(chuàng)建 ，而綁定元素則負(fù)責(zé)對(duì)信道管理器的創(chuàng)建。綁定元素，顧名思義，就是組成綁定的元素。從本質(zhì)上講，每一個(gè)綁定對(duì)象，就是一個(gè)綁定元素對(duì)象的有序集合；綁定元素的構(gòu)成和次序決定綁定對(duì)象的特性。

而我們所說的信道棧，指的是若干相關(guān)的信道按照一定的排列次序組成的一個(gè)消息流通的管道。信道棧中的信道的先后次序是如何來維護(hù)的呢？由于信道的創(chuàng)建者是信道管理器，所以信道管理者的次序決定信道的次序。從某種意義上講，所有的信道管理器組成一個(gè)信道管理器棧。以此類推，信道管理器棧中每個(gè)信道管理器的先后次序由構(gòu)成綁定對(duì)象的所有綁定元素的次序決定。但是綁定元素的次序先后次序又是如何決定的呢？那就需要使用到另一個(gè)有用的對(duì)象：綁定上下文（binding context）對(duì)象，一般來說，一個(gè)綁定上下文維護(hù)著基于該綁定對(duì)象當(dāng)前綁定元素的有序列表，可以很容易地定位到下一個(gè)綁定元素。

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模型]之六：從綁定元素認(rèn)識(shí)系統(tǒng)預(yù)定義綁定

NET技術(shù)：[WCF中的Binding模型]之一: Binding模型簡介，轉(zhuǎn)載需保留來源！

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