Remoting基本原理及扩展机制（中）

Remoting基本原理及扩展机制（中）2007-10-04idior在上一篇文章我们已经介绍到通过在配置文件中指定自定义的ChannelSinkProvider，我们可以在Pipeline中加入自己的ChannelSink，此时我们就可以加入自己的信息处理模块，但是这里我们所能操作的对象是已经经过格式化的消息（即数据流），我们看不到原始的消息对象，这也势必影响了我们所能实现的扩展功能。而在上文的图1中，我们看到除了ChannelSink可以扩展之外，我们还可以加入自定义的MessageSink，而它是位于格式器之前的，也就是说在MessageSink中我们可以直接操作尚未格式化的消息对象。此时，我们就获得一个功能更强大的扩展点。直接操作消息对象，这意味着什么呢？简单来说，我们可以在这里实现方法拦截，我们可以修改方法的参数、返回值，在调用方法前后加入自己的处理逻辑。是不是觉得听上去很耳熟？没错，这就也正是AOP所要实现的一个目标。下面，在了解了整个Remoting的大背景以及ChannelSink的扩展机制后，我们将对MessageSink的扩展机制做进一步介绍。

在介绍前，我先提醒各位读者注意以下几点：

1. 确定你确实想深入了解Remoting的内部机制；

2. 确定你能很好的理解上一篇文章；

3. 如果说上一篇文章总结归纳的内容较多的话，在本文中出现的内容大多是笔者个人的探索，我想其他资料（包括英文资料）中都不曾介绍过这些内容，所以我不保证所有观点的正确性，如果你觉得哪里有误，也欢迎你在评论中提出你的意见。

下面就让我们开始品尝大餐吧。

利用ChannelSinkProvider扩展MessageSink

MessageSink的扩展有两种实现方法，让我先从简单的开始。在上一篇文章我们已经介绍到通过在配置文件中指定自定义的ChannelSinkProvider，我们可以在Pipeline中加入自己的ChannelSink。那么有没有一个类似于IClientChannelSinkProvider的IMessageSinkProvider呢？可惜答案是否定的。那么我们能否通过IClientChannelSinkProvider插入一个MessageSink呢？插入之后它又能否发挥其功效呢？

首先我们先实现一个自定义的MessageSink。此时只需新建一个类，并实现IMessageSink接口中的SyncProcessMessage方法（为简单起见我们只考虑同步调用模式），在方法中我们可以直接操作Message对象，比如我们可以向Message中加入额外的属性，如下所示：

1: public class CustomMessageSink:IMessageSink
2: {
3: public IMessage SyncProcessMessage（ IMessage msg ）
4: {
5: // Add some custom data into msg.
6: （（IMethodMessage）msg）.LogicalCallContext.SetData（"MyName" , "idior" ）;
7: return m_NextSink.SyncProcessMessage（ msg ）;
8: }
9: }
代码 1

在上一篇文章的图２中我们可以看到IClientChannelSinkProvider是通过下面这个方法创建ChannelSink。

1: public IClientChannelSink CreateSink（IChannelSender channel, string url,
2: object remoteChannelData） {...}
代码 2