1.信道層與服務模型層(Channel Layer and Service Mode Layer)
對於一個分布式應用的開發與設計來說，通信問題是不得不考慮，同時也是最為復雜、最難實現的問題。在過去的若干年中, 微軟先後推出了一系列廣受歡迎的通信技術, 比如DCOM、Enterprise Service、.NET Remoting、XML Web Service、MSMQ等等。這些技術提供了各自的編程模型，是開發人員從繁瑣的完全基於通信的編程中解脫出來，使之僅僅需要關注具體的業務邏輯。WCF是所有的這些通信技術集大成者，它充分地整合了所有這些使用於不同領域、不同場景的通信技術，提供了一個統一的編程模型。
無論從功能上講，還是從WCF的整個基礎構架的層次結構上講，WCF可以分成兩個不部分：編程模型和通信實現。編程模型通過WCF服務模型層（service mode layer）提供，而信道層 (channel layer) 則提供了具體的通信的實現。服務模型層建立在信道層之上，對於一般的WCF開發人員來講，他們僅僅會接觸到服務模型層，而信道層則是被屏蔽掉的。
2.信道與信道棧（Channel and Channel Stack）
WCF的通信是基於消息的，如果從消息交換（message exchange）的角度講，信道層則可以看成是進行消息交換參與者之間的中介。信道層通過一個個信道組成一個連續的信道棧，該信道棧構成了一個消息流通的管道。消息的發送者通過該管道流到消息的接收者，消息的接收者對消息進行相應的處理，生成新的消息通過該管道回復給消息的發送者。
但是，不要將這個通過一系列信道組成的管道的功能僅僅局限於消息的傳輸，實際上該管道承載著許多額外的功能。
我們可以打個比方，比如一個自來水廠，水源可能取自天然的湖水，在水廠生產的水最終通過自來水管流到居民的家中被飲用之前，需要對水進行必要的處理。中間的流程可能是這樣的：湖水被汲取到一個池子中先進行雜質的過濾（我們稱這個池為過濾池）；被過濾後的水流到第二個池子中進行消毒處理（我們稱這個池為消毒池）；被消毒處理的後水流到第三個池子中進行水質軟化處理（我們稱這個池為軟化池）；最終水通過自來水管道流到居民的家中。
實際上，我們將的信道棧就相當於一個自來水廠，而構成信道棧的一個個信道就相當過濾池、消毒池、軟化池以及自來水管道。唯一不同的是，自來水廠處理的是水，而信道棧處理的是消息（message）。這樣設計的最大的好處就是具有很強的可擴展性，因為我們不可能、也沒有必要設計出一種信道能夠進行所有的消息處理任務，我們需要做的僅僅讓一個信道專注於某一種功能的實現，通過對信道的合理組合從而實現我們實際的消息處理的功能。
對於一個自來水廠來說，最終的目的上自己生產的水讓消費者能夠飲用，所以自來水管道是必須的，至於中間的環節，過濾、消毒、軟化、……，可能在水質良好的情況下就不是必要的了。與此類似，對於一個信道棧來說，有兩種信道是必須的：傳輸信道（transport channel）和消息編碼信道（message encoding channel）。原因很簡單，信道棧的目的就是實現消息的傳輸，傳輸信道肯定是必須的，而進行傳輸的前提，需要對消息進行合理編碼，比如基於文本編碼和二進制編碼。如下圖所示：
由於WCF采用完全基於消息的通信方式，所有功能的實現，無論是業務有關的，還是業務無關的，都是通過消息交換來實現的。對於信道棧來說，除了必要的消息處理功能（消息編碼與傳輸），為了一些額外的功能的實現需要添加新的信道。比如，對於無狀態的http協議需要提供對會話的支持，需要添加相應的會話支持的信道；為了通過對事物的支持，將多個服務調用納入同一個事物中，需要專門的事物支持的信道；為了減少網絡流量，在傳輸之前需要對消息進行壓縮，需要專門的消息壓縮信道，等等。
從另一個方面講，WCF是基於WS-*的，WS-*通過一系列的協議制定了一套業界的Web Service標准，使不同廠商之間的互操作成為可能。WCF對最新的WS-*提供了支持，而且毫無疑問，隨著WS-*的逐步完善，WCF將會與之保持同步。對於絕大部分WS-*協議的支持，都是通過在信道棧中添加相應的信道實現的, 所以我們把這樣的信道稱為協議信道（protocol channel）。如下圖所示,在傳輸信道和消息編碼信道之上, WS-Security實現了消息層的安全;WS-RM（WS-Reliable Messaging）實現了可靠消息通信；WS-AT（WS-Atomic Transaction）實現了分布式的事務支持。
3.WCF的綁定模型（WCF Binding Mode）
綁定模型如下圖所示，其中最左邊的部分就是信道棧，而右邊就則是綁定對象本身。WCF通信的本質在於通過綁定對象提供的API構建信道棧，從而實現基於消息的通信。在信道棧和綁定之間，還存在著一些中間對象。它們是信道管理器（Channel Manager）、綁定元素（Binding Element）和綁定上下文（Binding Context）。
在整個綁定模型中，信道和信道棧位於最底層。信道棧是消息進行通信的通道，組成信道棧的各個信道處於各自的目的對消息進行相應的處理。按照功能劃分，可以將信道分成三類：傳輸信道、消息編碼信道和協議信道。傳輸信道實現了基於某種協議（HTTP、HTTPS、TCP等等）的消息傳輸；消息編碼實現了對消息的編碼，常見的消息編碼方式有：Text/XML、Binary和MTOM；而協議信道則實現了WCF對若然WS-*協議的支持，比如WS-Security、WS-RM、WS-AT等等。
在WCF中，信道棧的創建和生命周期的管理通過信道管理器（channel manager）來進行管理。對於信道管理器，大家可能有點了陌生，不過如果回顧一下我們前面演示的通過綁定進行直接通信的例子，大家一定還記得這麼兩個對象：信道監聽器（channel listener）和信道工廠（channel factory）。實際上，信道監聽器和信道工廠是信道管理器兩個別名。在服務端，通過信道監聽器對服務請求進行監聽，當請求消息被成功檢測，則通過信道監聽器創建信道棧對請求消息進行接收和處理；在客戶端，信道棧被信道工廠創建，並用於請求消息的處理和發送。
一般來講，信道管理器，無論是信道監聽器還是信道工廠，都對應著一個綁定元素（binding element）對象。綁定元素負責對相應信道管理器的創建。從創建對象的角度來看，信道管理器負責對信道的創建 ，而綁定元素則負責對信道管理器的創建。綁定元素，顧名思義，就是組成綁定的元素。從本質上講，每一個綁定對象，就是一個綁定元素對象的有序集合；綁定元素的構成和次序決定綁定對象的特性。
而我們所說的信道棧，指的是若干相關的信道按照一定的排列次序組成的一個消息流通的管道。信道棧中的信道的先後次序是如何來維護的呢？由於信道的創建者是信道管理器，所以信道管理者的次序決定信道的次序。從某種意義上講，所有的信道管理器組成一個信道管理器棧。以此類推，信道管理器棧中每個信道管理器的先後次序由構成綁定對象的所有綁定元素的次序決定。但是綁定元素的次序先後次序又是如何決定的呢？那就需要使用到另一個有用的對象：綁定上下文（binding context）對象，一般來說，一個綁定上下文維護著基於該綁定對象當前綁定元素的有序列表，可以很容易地定位到下一個綁定元素。
