WCF是基于消息機制的，一些功能的實現如尋址，加密等在消息中都會體現的淋漓盡致，WCF中的通道就像車間的流水線，而消息就作為這個流水線上待加工的產品。每經過一個處理位置，相應的通道都會對消息對不同的操作處理。清晰的掌握消息的加工過程對WCF的工作原理，調試跟蹤，自定義擴展，性能安全都能非常好的現實意義。而要實現截獲消息的目的，通常可以有以下幾種辦法: 1 路由截獲法 2 自定義Binding法 3 實現IMessageInspector接口法 4 跟蹤診斷法 四種方法，實現的難度和得到的效果不盡相同。下面逐一闡述實現方式。

WCF是基于消息機制的，一些功能的實現如尋址，加密等在消息中都會體現的淋漓盡致，WCF中的通道就像車間的流水線，而消息就作為這個流水線上待加工的產品。每經過一個處理位置，相應的通道都會對消息對不同的操作處理。清晰的掌握消息的加工過程對WCF的工作原理，調試跟蹤，自定義擴展，性能安全都能非常好的現實意義。而要實現截獲消息的目的，通常可以有以下幾種辦法:

1  路由截獲法

2  自定義Binding法

3  實現IMessageInspector接口法

4  跟蹤診斷法

四種方法，實現的難度和得到的效果不盡相同。下面逐一闡述實現方式。

1 路由截獲法

此種方法，有可以分為兩種

a）采用現有tcp消息跟蹤工具。

b) 利用wcf中的路由功能做自定義的路由。

其中常見的現成tcp消息跟蹤工具，我所常用的是以下兩個：

a) tcpTrace

b) soap toolkit 3.0中所帶工具 soap trace utility

兩款工具工作原理一致，都如下圖所示：

通過這兩個工具截獲Message的方法，很多朋友們已經熟練使用。比如很早的時候Artech就在其blog文章中介紹過tcpTrace的使用，文章為：[原創]我的WCF之旅（9）：如何在WCF中使用tcpTrace來進行Soap Trace。所以具體使用方法，我就不再贅述。只總結一點，在使用tcpTrace或者soap trace utility 的時候，listen port指定的是路由的監聽地址，同時也應該是client端設置的via地址。而destination port要設置的服務的監聽地址。在上面的途中，listen port 應該為 8019, 而Destination port為8020

除了使用現成的工具來做路由，WCF本身也支持路由功能。實現原理和上圖一致。唯一不同的是中間的路由器可以由自己用WCF技術編寫。這樣一來就更靈活一些。做了一個非常簡單的demo,主要適用于request/reply的交互模式。

demo中有五個項目，他們分別為：

Jillzhang.Wcf.MessageInspectors.Contracts

Jillzhang.Wcf.MessageInspectors.Services

Jillzhang.Wcf.MessageInspectors.Host

Jillzhang.Wcf.MessageInspectors.Client

Jillzhang.Wcf.MessageInspectors.Rounter

前面四個是創建了一個非常簡單的WCF服務和客戶端，組成了一個分布式系統。最關鍵的是Jillzhang.Wcf.MessageInspectors.Rounter這個項目，通過將ServiceContract的Action和ReplyAction設置為* ，同時將其ServiceBehavior的AddressFilterMode設置為Any，就能接收到所有的消息，而不對消息的action或者消息體等進行任何篩選。具體代碼我不貼了，如果感興趣可以下載demo示例代碼。

好了，路由截獲法的兩種方法都以闡述完畢，那么此種方法有它的優點和缺點，它們分別是：

優點：

1）路由分析法不用過多修改原客戶端和服務端的代碼，和原來架構的耦合度也比較低。

2）路由分析法能夠體現WCF中強大的路由功能。

缺點：

路由分析法缺點也非常顯著：

1）它只能截獲到已經發送的請求消息卻不能截獲相應的響應。

2）路由法是在通訊過程中增加了節點，這樣一來就無法使用高效的傳輸安全保證信息的安全性了。

 

2  自定義Binding法

記得在上篇文章說說WCF中的可信賴會話中，曾經談到過Binding的組織結構。上面的描述中，我們一致強調WCF是基于消息的通訊方式，最重要概念的就是通道，再打一個比方，看下面一張食物消化過程圖：

我們可以把消息看做成上面這幅圖總的食物，而比如口腔，食道，胃，大腸，小腸，肛門等可以看做是對食物的進行加工的通道，他們各司其職，順序對食物進行處理。在WCF的通道(Channel)中，Channel也能對Message做各種各樣的處理，比如加密，解密，編碼，解碼，刷選，刪除，增加，修改等。我再畫一張圖來顯示消息在通道中的處理過程：

 

消息會順序通道Binding中的每一個BindingElement中的通道，這樣我們可以實現一個自定義的Channel專門用于記錄Message.這便是在實現自定義Binding截獲消息的理論依據和實現思路。也通過實際編碼實現了這種想法:

首先，先來了解一下Channel的實現方法。在WCF中，Channel被組織到了System.ServiceModel.Channels的命名空間下。所有的Channel均要實現System.ServiceModel.Channels.IChannel接口。IChannel接口事實上只定義了Open,Close,Abort三種種類型的操作，這些操作都是基于Socket，因此每種操作都會同步和異步的區分。系統中還給出了下面幾個常用的Channel接口定義:

1) IRequestChannel

在WCF中，只有實現了IRequestChannel的通道，才能成為請求/回復(Request/Reply)通訊的請求端。而且IRequestChannel定義了Request,這個操作負責將請求消息Message發送出去，能在這個操作中查看消息內容。另外增加了RemoteAddress和Via，分別用于表示消息發送的遠程地址和消息發送請求的傳輸地址。

2）IReplyChannel

IReplyChannel和IRequestChannel相對應，只有實現了IReplyChannel的通道才能作為Request/Reply的響應端，并且增加了ReceiveRequest的操作，這個操作負責接收請求，能購在這個操作中查看消息內容。

3）IDuplexSessionChannel

這個通道定義了雙工通道與會話關聯，提供了Send,Receive的操作，在這兩個操作中，都能查看消息內容。并且可以通過Session進行將IDuplexChannel與ISessionChannel進行關聯。

其他的還有很多常見Channel，比如IInputChannel，IOutputChannel,IDuplexChannel等，詳細信息可以查閱msdn，不再贅述。但上面三個十分重要。上面兩個IRequestChannel和IReplyChannel可以用在使用了HttpTransportBindingElement的Binding上面，而IDuplexSessionChannel可以用在使用了TcpTransportBindingElement的Binding上面。

通過Channel的能夠查看消息的指定位置上log消息內容，然后實現自定義Binding，便可以實現截獲消息的目的。

在實現的demo中，主要包含以下文件：

LogRequestChannel.cs：實現了IRequestChannel,用于請求端

LogReplyChannel.cs 實現了IReplyChannel，用于響應方

LogDuplexSessionChannel.cs 實現了IDuplexSessionChannel

LogChannelListerner.cs  實現了IChanelListener，是服務端對通道的監聽者

LogChannelFactory.cs 實現了IChanelFactory，是客戶端通道的管理者

LogHttpBinding.cs  用于http方式的自定義的能夠log消息的綁定

LogTcpBinding.cs  用于tcp方式的自定義的能夠log消息的綁定

查看一下最后的效果，采用LogHttpBinding的時候的效果圖：

服務端：

客戶端：

而采用LogTcpBinding時候的效果圖：

服務端：

客戶端：

從上面幾幅圖中，我們看出擴展Binding也可以截獲到消息內容

那么這種方法有什么優缺點呢？

優點是：

1） 能截獲到請求和響應兩方面的消息

2） 能結果到通道中得到消息

3） 截取位置非常靈活

缺點是實現起來比較復雜

 

四種辦法，先說這兩種，下面兩種留作下一篇吧，篇幅有些長，寫著真累。

示例項目： https://files.cnblogs.com/jillzhang/Jillzhang.Wcf.MessageInspector.rar