总结WCF中截获消息的几种方式

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的时候的效果图：

服务端：