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

现在我们可以确定通过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。 

查看本文来源