基本原理及其扩展机制中呢

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

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

llProcessMessage(annelSink,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=\"stomSinkProvider,CustomSinks\" /＞

＜formatter ref=\"soap\" /＞

＜/clientProviders＞

＜/channel＞

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

总结

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

并删改了顾客的充值信息。假账做出来了 下一节将介绍当Client和Server对象处在同一个Appdomain时，如何拦截并修改消息，其中将涉及到更多类型的Sink。查看本文来源