《WCF後續之旅》博文係列總結[共17篇]

Windows Communication Foundation，顧名思義，就是一個在Windows平台下進行如何進行Communication的基礎構造（Infrastructure）。由於WCF的核心還是Communication，這個新的係列就先來討論WCF如何進行Communication的。通過本篇文章，你將對WCF的通信機製有一個總體的認識，了解到一些和通信相關的概念， 比如：Communication、Channel、Channel Listener、Channel Factory、BindingElement，Channel  Shape等等。

我們已經很清楚了，WCF的通信是通過Endpoint來完成的：Service Provider將WCF service通過Endpoint暴露出來供Service consumer調用，而Service consumer通過與之相匹配的Endpoint來調用service。"Endpoint=ABC”，大家一定也牢記於心。就Endpoint包含的這3個元素而言，Address解決了尋址的問題，代表如何定位和標識對應的Endpoint，而Contract在對Service提供的功能、操作（Service Contract）以及數據（Data contract、Message contract和Fault contract）的抽象表示。而真正實現了通信功能的則是Binding。

中，我們通過一個直接借助BasicHttpBinding對象實現Client和Server端進行通信的例子，對WCF channel layer進行了一個大致上的介紹。由此引出了一些列通信相關的概念和對象，比如Channel，Output channel， Input channel，Request channel, Reply Channel，Duplex channel， Channel Shape，Channel manager，Channel factory, Channel listener, Binding element 等。通過這些元素，我們很容易地實現對WCF channel layer進行擴展。

對channel layer進行擴展一般適用於當你的需求通過現有的Binding，或者channel不能實現，而需要自定義一些channel來實現你所需的功能。不如現在的WCF係統定義的Channel中沒有實現對Message body的壓縮功能。你可以就需要將此功能定義到一個custom channel中，然後將其注入到channel stack中。一般來說，僅僅創建custom channel是不夠的，因為在runtime， channel是通過Channel manager進行創建的，所以你需要創建對應的Channel factory（如何對發送方進行擴展）或者Channel listener（如果對接受方進行擴展）。而Channel factory和channel listener最終又是通過Binding element進行創建的，所以你還需要創建相應的Binding element。（Binding element=〉Channel factory&Channel listener=>Channel）

• 如何根據不同的listening URI創建ChannelListener並進行監聽；
• 當request抵達，如何創建適合的Channel接收request message；
• 如何將Message分發到對應的Endpoint進行處理；
• 如何進一步將Message分發到對應的service instance；
• 以及如何進一步地分發的具體的service instance的匹配的method call。

由於“分發（Dispatch）”是其根本的功能和任務，所以Dispatcher是整個Service端ServiceMode的核心。正如標題所述，Dispatcher是整個WCF service mode layer的中樞，本篇文章講著重圍繞著Dispatcher來展開介紹。

[第7篇]通過WCF Extension實現和Enterprise Library Unity Container的集成

[第8篇] 通過WCF Extension 實現與MS Enterprise Library Policy Injection Application Block 的集成

[第9篇]通過WCF的雙向通信實現Session管理

[第10篇]通過WCF Extension實現以對象池的方式創建Service Instance

[第11篇]關於並發、回調的線程關聯性（Thread Affinity）

[第12篇] 線程關聯性（Thread Affinity）對WCF並發訪問的影響

WCF是.NET平台下實現SOA的一種手段，SOA的一個重要的特征就基於Message的通信方式。從 Messaging的角度講，WCF可以看成是對Message進行發送、傳遞、接收、基礎的工具。對於一個消息交換的過程，很多人隻會關注 message的最初的發送端和最終的接收端。實際上在很多情況下，在兩者之間還存在很多的中間結點（Intermediary），這些中間結點在可能在 實際的應用中發揮中重要的作用。比如，我們可以創建路由器（Router）進行消息的轉發，甚至是Load Balance；可以創建一個消息攔截器（Interceptor）獲取request或者response message，並進行Audit、Logging和Instrumentation。今天我們就我們的目光轉向這些充當著中間人角色的 Intermediary上麵來。

在本篇文章中，我們將會創建一個message的攔截和轉發工具（message interceptor）。它將被置於WCF調用的client和service之間，攔截並轉發從client到service的request message，以及service到client的response message，並將request message和response message顯示到一個可視化的界麵上。我們將討論這個message interceptor若幹種不同的實現方式。

在基於TCP/IP協議簇的對等網絡通信下，相互通信的應用程序運行各自的進程中，出於應用層的進程將數據局封裝成數據報，並通過傳輸層的TCP或者UDP進行網絡通信。而TCP和UPD則通過一個16bit的端口來識別不同的應用程序。

對 於一些常用網絡服務，他們都有一個知名的端口好與之匹配。比如，FTP服務是用的TCP端口為21；Telnet服務的TCP端口為23等等。而對於客戶 端通常對所使用的端口並不關心，隻需要保證端口在本機是唯一的就可以了，這樣的端口又成為臨時端口，臨時端口一般在1024到5000之間。

一般來講，在某一個時刻，一個端口隻能供一個應用程序使用。對於WCF來說，當我們通過一個托管的應用程序對某個服務進行寄宿的時候，一個端口被該應用程序獨占使用。如何多個寄宿進行使用相同的端口。

在WCF中，每個終結點都包含兩個不同的地址——邏輯地址和物理地址。邏輯地址就是終結點Address屬性表示的地址。至於物理地址，對於消息發送放來講，就是消息被真正發送的目的地址；而對於消息的接收放來講，就是監聽器真正監聽的地址。

在介紹終結點的ListenUriMode時，我們提到了兩個特殊的對象ChannelDispatcher和ChannelListener。這兩個對象在整個WCF的消息分發係統中具有重要的地位，在這節裏，我們對WCF的整個消息分發過程作一個簡單的介紹。

對於希望對WCF的消息交換有一個深層次了解的讀者來說，tcpTracer絕對是一個不可多得好工具。我們將tcpTracer置於服務和服務代理之間，tcpTracer會幫助我們接獲、顯示和轉發流經他的消息。

從 本質上講，tcpTracer是一個路由器。當啟動的時候，我們需要設置兩個端口:原端口（source port）和目的端口（destination port），然後tcpTracer就會在原端口進行網絡監聽。一旦請求抵達，他會截獲整個請求的消息，並將整個消息顯示到消息麵板上。隨後， tcpTracer會將該消息原封不動地轉發給目的端口。在另一方麵，從目的端口發送給原端口的消息，也同樣被tcpTracer截獲、顯示和轉發。

 

 

作者：蔣金楠
微信公眾賬號：大內老A
微博：www.weibo.com/artech
如果你想及時得到個人撰寫文章以及著作的消息推送，或者想看看個人推薦的技術資料，可以掃描左邊二維碼（或者長按識別二維碼）關注個人公眾號（原來公眾帳號蔣金楠的自媒體將會停用）。
本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁麵明顯位置給出原文連接，否則保留追究法律責任的權利。

原文鏈接