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

最新推荐文章于 2017-01-11 16:13:00 发布

cbbbc

最新推荐文章于 2017-01-11 16:13:00 发布

阅读量442

点赞数

分类专栏： c#学习日志

c#学习日志专栏收录该内容

55 篇文章 0 订阅

订阅专栏

在上一篇文章我们已经介绍到通过在配置文件中指定自定义的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 );
        }
     }

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

    public IClientChannelSink CreateSink(IChannelSender channel, string url, 

                                        object remoteChannelData) {...}

注意它的返回值是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创建出来并链接在一起。

   internal virtual IMessage InternalInvoke(IMethodCallMessage reqMcmMsg,  

                                           bool useDispatchMessage, int callType)

    {

       //...

       if (identity.ChannelSink == null)

         {

               IMessageSink envoySink = null;

               IMessageSink channelSink = null;

               if (!identity.ObjectRef.IsObjRefLite())

              {

                     RemotingServices.CreateEnvoyAndChannelSinks(null,identity.ObjectRef,

                                                         out envoySink , out channelSink );

               }

                else

            {

                    RemotingServices.CreateEnvoyAndChannelSinks(identity.ObjURI, null,    

                                                        out envoySink , out channelSink );

                }

               RemotingServices.SetEnvoyAndChannelSinks(identity, envoySink,channelSink );

              if (identity.ChannelSink == null)

               {

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

              }

        }

         //...

  }

第一个判断语句（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接口中的方法时，全部抛出异常。如下所示：

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

   2:  {

   3:     //...

   4:   

   5:     //Implement method in IMessageSink

   6:     public IMessage SyncProcessMessage(IMessage msg)

   7:     {

   8:        IMethodCallMessage message1 = (IMethodCallMessage) msg;

   9:        try

  10:        {

  11:              ITransportHeaders headers1;

  12:              Stream stream1;

  13:              Stream stream2;

  14:              ITransportHeaders headers2;

  15:              this.SerializeMessage(message1, out headers1, out stream1);

  16:              this._nextSink.ProcessMessage(msg, headers1, stream1, 

  17:                                            out headers2, out stream2);

  18:              if (headers2 == null)

  19:              {

  20:                    throw new ArgumentNullException("returnHeaders");

  21:              }

  22:              return this.DeserializeMessage(message1, headers2, stream2);

  23:        }

  24:        catch (Exception exception1)

  25:        {

  26:              return new ReturnMessage(exception1, message1);

  27:        }

  28:        catch

  29:        {

  30:              return new ReturnMessage(new Exception("...")), message1);

  31:        }

  32:     }

  33:   

  34:     //Implement method in IClientChannelSink

  35:     public void ProcessMessage(...)

  36:     {

  37:        throw new NotSupportedException();

  38:     }

  39:    

  40:     //...

  41:  }

然后在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,...);

而我们在上图中可以发现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。

原文地址：http://www.cnblogs.com/idior/archive/2007/01/09/614995.html