Remoting基本原理及擴展機制（下）(2)

麼MessageSink與上下文有什麼關系呢? 我們知道在通常情況下，如果訪問同一個AppDomain中對象的方法時，會采用基於棧的方式(詳見本系列上部)。在這種情況下，我們是無法攔截其中的消息的，因為此時根本不存在消息對象。只有當我們通過Transparent Proxy訪問另一個對象的方法時，才會采用基於消息的方式。而現在我們只知道當一個對象調用處在另一個AppDomain中的遠程對象(該對象為MarshalByRefObject子類)時，Remoting才會為調用方創建那個遠程對象的Transparent Proxy。在了解了.Net上下文的概念後，你會發現，即使處在同一個AppDomain中的兩個對象，如果它們所處的上下文不同，在訪問對方的方法時，也會借由Transparent Proxy實現，即采用基於消息的方法調用方式。此時，我們就可以在上下文中插入MessageSink了。那麼在上下文中是否存在類似IClientChannelSinkProvider的接口呢?很幸運，在經過一番探索後，我們發現確實存在類似的接口，而且還不止一個：IContributeEnvoySink、IContributeServerContextSink、IContributeObjectSink、IContributeClientContextSink這四個接口中各自包含了一個GetXXXSink的方法，它們都會返回一個實現了IMessageSink接口的對象。我們知道IClientChannelSinkProvider接口是配合配置文件最終實現向Pipeline中加入ChannelSink的，而以上這四個接口並沒有配合配置文件使用，不過與IClIEntChannelSinkProvider的使用方式倒也有異曲同工之效。讀者可以將下面這幅圖與本系列上部中的圖2比較一番。

在上圖中又出現了很多新的概念，下面將對它們一一做出解釋：

·ContextBoundObject

上下文可以看作應用程序域中一個包含對象和消息接收器的區域。對上下文裡的對象的調用會轉換成可以被MessageSink(消息接收器)攔截和處理的消息。我們知道要把調用轉換成消息，必須通過透明代理這個中介。而且，僅當對象是MarshalByRefObject的子類的實例並被其所在的應用程序域以外的實體調用時，CLR才會為它創建透明代理。這裡，我們希望對所有調用使用消息接收器機制，即使那些調用是來自同一個應用程序域中的實體。這個時候我們就需要用到System.ContextBoundObject類了。繼承自ContextBoundObject的類的實例同樣僅能由透明代理訪問。此時，即使在這個類的方法中使用的this引用也是透明代理而不是對這個對象的直接引用。我們會發現ContextBoundObject類繼承自MarshalByRefObject，這非常合理，因為它很好地強調了該類的特性——它告訴CLR這個類將會通過透明代理使用。

ContextBoundObject的子類的實例被視為上下文綁定的(context-bound)。沒有繼承自ContextBoundObject的類的實例則被視為上下文靈活的(context-agile)。上下文綁定的對象永遠在其上下文中執行。只要不是遠程對象，上下文靈活的對象總是在執行這個調用的上下文中執行。如下圖所示：

·ContextAttribute

上下文attribute是應用在上下文綁定的類上的.Net attribute。上下文attribute類實現了System.Runtime.Remoting.Contexts.IContextAttribute接口。上下文綁定的類可以應用多個上下文attribute。在這個類的對象創建期間，這個類的每個上下文attribute判斷這個對象的創建者所在的上下文是否適用。該操作通過以下方法完成：