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

在上一篇文章我们已经介绍到通过在配置文件中指定自定义的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中加入额外的属性，如下所示：

public class CustomMessageSink:IMessageSink
{
   public IMessage SyncProcessMessage( IMessage msg )
   {
      // Add some custom data into msg.
      ((IMethodMessage)msg).LogicalCallContext.SetData("MyName" , "idior" );
      return m_NextSink.SyncProcessMessage( msg );
   }
}

代码 1

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

public IClientChannelSink CreateSink(IChannelSender channel, string url,
                                     object remoteChannelData) {...}

代码 2

注意它的返回值是IClientChannelSink，而不是IMessageSink，这样我们就无法将仅实现了IMessageSink接口的CustomMessageSink插入。为此，我们让CustomMessageSink也实现IClientChannelSink接口，只不过在实现IClientChannelSink接口中的方法时，我们全部抛出异常，以表示这些方法不应该被调用到。这样我们就可以瞒天过海般地利用ChannelSinkProvider创建出一个MessageSink。现在问题来了，这个MessageSink虽然创建出来了，但是它被插入Pipeline了吗？其实，我们在上一篇文章中就漏过了一个问题——那些利用ChannelSinkProvider创建出来的ChannelSink是如何被插入到Pipeline中的，明白了它的原理，就自然解决了上面的问题。

Pipeline

Pipeline是何物？我们并没有解释清楚这个概念，是否存在一个对象它就叫Pipeline或者类似的名字？遗憾地告诉你，没有！可以说这里的Pipeline是一个抽象的概念，它表示了当我们调用一个远程对象时从RealProxy到StackBuildSink之间所经过的一系列Sink的集合，但是并不存在一个单独的链表把这些Sink全部链接起来。也就是说并不存在一个大的Sink链表，当你触发远程方法后，我们就依次从这个链表中取出一个个的Sink，大家挨个处理一下消息。不过在远程对象的代理中倒是维护了一个由ChannelSink组成的链表。不过需要注意它并不代表整个Pipeline，而只能算是其中一部分，在后面我们会看到Pipeline中还包括了很多其他类型的Sink。这个链表保存在RealProxy的_identity对象中,链表是通过IClientChannelSink的Next属性链接起来的，在_identity对象中保存链表的第一个元素，其他元素可以通过Next属性获得，如下图所示：

下面我们来看看这个链表是如何得到的。每当我们通过TransparentProxy调用远程方法时，如下图所示，最终会调用到RemotingProxy中的InternalInvoke方法，它将负责把各个ChannelSink创建出来并链接在一起。

   1:  internal virtual IMessage InternalInvoke(IMethodCallMessage reqMcmMsg,  

   2:                                           bool useDispatchMessage, int callType)

   3: {

   4:      //...

   5:      if (identity.ChannelSink == null)

   6:        {

   7:              IMessageSink envoySink = null;

   8:              IMessageSink channelSink = null;

   9:              if (!identity.ObjectRef.IsObjRefLite())

  10:              {

  11:                    RemotingServices.CreateEnvoyAndChannelSinks(null,identity.ObjectRef,

  12:                                                        out envoySink , out channelSink );

  13:              }

  14:              else

  15:              {

  16:                    RemotingServices.CreateEnvoyAndChannelSinks(identity.ObjURI, null,    

  17:                                                        out envoySink , out channelSink );

  18:              }

  19:              RemotingServices.SetEnvoyAndChannelSinks(identity, envoySink,channelSink );

  20:              if (identity.ChannelSink == null)

  21:              {

  22:                    throw new RemotingException("..."));

  23:              }

  24:        }

  25:        //...

  26:  }

代码 3

第一个判断语句（Line 5）说明创建并链接ChannelSink的工作只发生在第一次调用，以后的每次调用将重复使用第一次的结果。第二个判断语句（Line 9）暂且不管，我只需知道在下一步将创建出两个Sink链，一个是EnvoySinl链，而另一个是ChannelSink链，前者我们也先不去管它（将在下部中介绍）而后者将通过out关键字传给局部变量channelSink。其中CreateEnvoyAndChannelSinks方法最终会把ChannelSink链的创建任务交给Channel对象，至于Channel对象是如何配合ChannelSinkProvider工作的，我们在上一篇文章中已经介绍过了。

不知你有没有注意到局部变量channelSink（Line 8）此时的类型是IMessageSink 而不是IClientChannelSink。到关键地方了，大家提起精神啊！明明我们创建的是ChannelSink链却把头元素的类型设为IMessageSink 。这是为什么？大家知道在采用HttpChannel时，ChannelSink链的一个元素是什么吗？——SoapClientFormatterSink。你认为它应该是一个Message Sink还是Channel Sink？它是负责将消息对象格式为数据流的，操作对象是原始消息，自然应该是一个MessageSink。呵呵，原来搞了半天Remoting本身就有一个利用IClientChannelSinkProvider扩展MessageSink的例子（你可以在类库中找到SoapClientFormatterSinkProvider）。如之前所述，SoapClientFormatterSink虽然是一个MessageSink，但是为了利用IClientChannelSinkProvider将其插入到Pipeline中，它也不得不实现IClientChannelSink接口，而且你可以看到它在实现IClientChannelSink接口中的方法时，全部抛出异常。如下所示：

public class SoapClientFormatterSink :IMessageSink, IClientChannelSink//...
{
   //...

   //Implement method in IMessageSink
   public IMessage SyncProcessMessage(IMessage msg)
   {
      IMethodCallMessage message1 = (IMethodCallMessage) msg;
      try
      {
            ITransportHeaders headers1;
            Stream stream1;
            Stream stream2;
            ITransportHeaders headers2;
            this.SerializeMessage(message1, out headers1, out stream1);
            this._nextSink.ProcessMessage(msg, headers1, stream1,
                                          out headers2, out stream2);
            if (headers2 == null)
            {
                  throw new ArgumentNullException("returnHeaders");
            }
            return this.DeserializeMessage(message1, headers2, stream2);
      }
      catch (Exception exception1)
      {
            return new ReturnMessage(exception1, message1);
      }
      catch
      {
            return new ReturnMessage(new Exception("...")), message1);
      }
   }

   //Implement method in IClientChannelSink
   public void ProcessMessage(...)
   {
      throw new NotSupportedException();
   }

   //...
}

代码 4

然后在InternalInvoke方法中（代码3），我们又通过SetEnvoyAndChannelSinks方法（Line19）把之前赋值的局部变量channelSink赋给RemotingProxy对象中identity对象的_channelSink变量，这样一个个ChannelSink被链接在一起并能被代理对象所访问。

现在我们可以确定通过IClientChannelSinkProvider完全可以向Pipeline中插入新的MessageSink。由于SoapClientFormatterSink的存在，我们也完全可以相信这个被插入到ChannelSink链中的MessageSink能正常的工作（即执行IMessageSink中的方法，而不是IClientChannelSink中的方法），不过为了让大家更清楚Remoting的底层实现，我们还是想探究一下它是如何调用ChannelSink链中的一个个Sink来处理消息的。下图就是调用一次远程方法所产生的序列图：

查看原图

在上图中，我们可以看到在InternalInvoke方法中将调用CallProcessMessage方法，它会把消息对象交给ChannelSink链中的第一个Sink处理。如下所示：

RemotingProxy.CallProcessMessage(identity.ChannelSink,reqMsg,...);

代码 5

而我们在上图中可以发现CallProcessMessage方法的第一个形参是IMessageSink类型的。也就是说通过IClientChannelSinkProvider方式插入到Pipeline中的第一个Sink，反倒是IMessageSink类型的，而不是IClientChannelSink。这也为插入到ChannelSink链中的MessageSink能正常工作扫清了障碍。正是因为这个原因SoapClientFormatterSink才能发挥其作用。

另外在利用IClientChannelSinkProvider插入MessageSink的时候，必须将它插入到FormatterSink的前面。因为只有在消息被Formmat之前，我们才能通过MessageSink对它进行处理，Format之后在Sink对消息的修改就无效了。这点在配置文件中体现为自定义的SinkProvider必须放在Formatter前面。不过这是针对客户端而言，服务器端则恰恰与此相反。

<channel ref="http">
   <clientProviders>
      <provider type="CustomSinks.CustomSinkProvider,CustomSinks" />
      <formatter ref="soap" />
   </clientProviders>
</channel>

而在客户端插入ChannelSink时，自定义的SinkProvider都是放在Formatter后面的。你可以在上一篇文章的图2中发现这点。


总结
在本节中主要介绍了如何利用IClientChannelSinkProvider向Pipeline中加入MessageSink，从而在远程方法调用中修改消息对象，实现功能更强大的扩展。并由此介绍了Remoting在实现此功能时，它的内部实现机制，有助于大家更深入地了解Remoting框架。

下一节将介绍当Client和Server对象处在同一个Appdomain时，如何拦截并修改消息，其中将涉及到更多类型的Sink。

系列文章

一点废话：
文章的格式在FireFox下非常漂亮，为什么到IE下就被撑的很宽。郁闷，谁知道怎么修正，麻烦告知一二。