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

服务端：

客户端：

而采用LogTcpBinding时候的效果图：

服务端：

客户端：

从上面几幅图中，我们看出扩展Binding也可以截获到消息内容

那么这种方法有什么优缺点呢？

优点是：

1） 能截获到请求和响应两方面的消息

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

3） 截取位置非常灵活

缺点是实现起来比较复杂

 

四种办法，先说这两种，下面两种留作下一篇吧，篇幅有些长，写着真累。

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