通道功能
通道能夠執行不同的任務。實際上，通道裡可以定義任何消息功能，然後嵌 入到WCF運行時裡。我們可以大概地劃分一下WCF通道執行任務的類型。概念上， 通道可以方便使用特定的傳輸、協議或通道形狀。
傳輸通道
傳輸通道是與網絡、文件系統、內存或其他的程序（如Microsoft SQL Server 2005、SAP或Oracle）交互的通道。WCF至少有一個對應的通道來支持每 一個傳輸。例如，WCF支持TCP/IP通信，而且WCF程序與sockets交互的工具就是 TCP/IP通道。
在TCP/IP、HTTP、Named Pipes和MSMQ成為主流傳輸方式的今天，應用系統或 許還需要其他的傳輸方式。比如，文件系統、簡單郵件傳輸協議（SMTP）、郵局 協議3（POP3）和文件傳輸協議（FTP）。這些都可以成為候選者。如果一個支持 ，那麼其它的成為WCF支持的傳輸也很有可能。考慮一下SQL Server 2005 Service Broker。雖然它不是一個標准的傳輸，但是通過創建WCF 傳輸通道就可 以使得程序能夠通過WCF的編程模型使用SQL Server 2005 Service Broker的功 能。借助Service Broker自定義通道，程序就可以像調用WS-*一樣，來調用 Service Broker。作用上，自定義傳輸通道允許開發人員更多的關注與業務功能 而不是Service Broker接口或API。這些自定義通道的概念也同樣適用於其它的 計算系統，如SAP和Oracle
在通道堆棧裡，傳輸通道通常都位於最底層。從發送者的角度，在數據發送 以前，傳輸通道是堆棧裡最後一個通道。從接收者的角度，在數據接收以後，傳 輸通道是第一個通道。作用上，堆棧裡的其它通道不需要知道程序使用的傳輸協 議。沒有傳輸通道的通道堆棧沒有任何價值（極端情況除外）所有的通道至少包 含一個傳輸通道。你會在本章的 “組合通道”部分看到有些通道可以包含多個 傳輸通道。
協議通道
協議通道是WCF 實現消息協議的主要方式，像WS-ReliableMessaging、 WS- AtomicTransaction和WS-SecureConversation。實際上，WCF是通過協議通道來 支持WS-*規范的。因為 WS-*規范裡規定程序級別的消息交換可以在傳輸層產生 多個消息。在通道堆棧裡，WS-*協議通道經常產生消息，上層的通道不會理解這 些消息。例如，考慮圖6-3裡的通道堆棧。
圖6-3:支持WS-ReliableMessaging協議的通道
當發送程序發送一個Message 到通道堆棧，堆棧最終會對消息進行編碼並通 過網絡發送出去。因為堆棧裡包含WS-RM 通道，所以會有多個Message實例被編 碼和發送。WS-RM應答消息會停留在堆棧裡直到它們都到達WS-RM通道。對於WS- RM應答消息，WS- RM通道會執行WS-RM規范定義的操作，並且不需要發送消息給 上一層的通道。如果發送消息使用一個雙向契約，WS-RM通道將會發送應答消息 給上一層的通道。通常，堆棧裡可以存在多個協議通道。在圖6-3裡，給出了4個 協議通道。實際上堆棧裡協議通道的工作方式和上圖裡WS-RM通道非常類似。
組合通道
組合通道允許通道在堆棧裡修改通道形狀。 這樣，組合通道就創建了一種使 用已有功能模塊的新的方式。例如，MSMQ是發送單向消息的一種方式，而且WCF 支持使用MSMQ。一個自定義的組合通道允許WCF程序使用MSMQ來進行雙工通信。 因為雙工通信本質上就是可以同時發送和接收消息，一個MSMQ雙工組合通道需要 同時包裝一個MSMQ接收通道和發送通道，如圖6-4所示：
圖6-4：一個組合通道
如圖6-4所示，組合通道為了支持IDuplexChannel而包裝了IInputChannel 和 IOutputChannel。實際上，組合通道值得花費太多的時間去介紹，是因為它們擁 有比較有趣的線程和同步機制。例如，考慮一下為了組合通道，通道狀態機的轉 換問題。因為組合通道包裝了其它通道，所有包裝的通道必須使用組合通道來轉 換通道狀態機。因為上一層通道可以調用組合通道之上的 BeginOpen和 BeginClose方法，所以組合通道必須返回一個表示子通道裡BeginOpen和 BeginClose方法返回結果的IAsyncResult對象。關於這個問題的詳細信息，我推 薦在http://wintellect.com/下載，然後閱讀一下PowerThreading庫部分，同樣 也可以看一下Jeffrey Richter的《CLR via C#》一書關於線程部分的描述。
