第一個判斷語句（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: }代碼 4
