[转载]Context and Interception : The .NET Context

转载自:Context and Interception : The .NET Context

Every new app domain starts with a single context, called the default context. The default context provides no component services at all. The main reason why it exists is to help maintain a consistent programming model. The first object created in the new app domain is placed in the default context, even if it isn't a context-bound object. This maintains the design principle that all objects execute in a context, even if they don't care about component services. An app domain can contain multiple contexts, and .NET creates new contexts as needed. There is no limit to the number of contexts an app domain can contain. A given context belongs to exactly one app domain and can host multiple context-bound objects. Every context has a unique ID (an integer) called the context ID. The context ID is guaranteed to be unique in the scope of an app domain. Every .NET context has a context object associated with it. The context object is an instance of the class Context, defined in the System.Runtime.Remoting.Contexts namespace. You typically don't need to interact with the context object. However, for diagnostics and tracing purposes, it's sometimes useful to retrieve the context ID, using the ContextID read-only property of the context object:

    public class Context
    {
       public virtual int ContextID{get;}
       //Other members
    }

Every
object can access the context object of the context it's executing by
using the CurrentContext static read-only property of the Thread class:

    public sealed class Thread
    {
       public static Context CurrentContext{ get; }
       /* Other members  */
    }

For example, here is how an object can trace its context ID:

    int contextID = Thread.CurrentContext.ContextID;
    Trace.WriteLine("Context ID is " + contextID);

Note that threads can enter and exit contexts, and in general, they have no affinity to any particular context.

1. Assigning Objects to Contexts

There
are two kinds of .NET types: context-agile and context-bound. Both
always execute in a context, and the main difference is in their
affinity to that context. The context-agile behavior is the .NET
default. Any class that doesn't derive from ContextBoundObject
is context-agile. Context-agile objects have no interest in component
services; they can execute in the contexts of their calling clients
because .NET doesn't need to intercept incoming calls to them. When a
client creates a context-agile object, the object executes in the
context of its creating client. The client gets a direct reference to
the object, and no proxies are involved. The client can pass the object
reference to a different client in the same context or in a different
context. When the other client uses the object, the object executes in
the context of that client. The context-agile model is shown in Figure 1.
Note that it's incorrect to state that a context-agile object has no
context. It does have one—the context of the client making the call. If
the context-agile object retrieves its context object and queries the
value of the context ID, it gets the same context ID as its calling
client.

Figure 1. A context-agile object

COM+ also had the notion of context-agile objects, in the form of objects that aggregated the free-threaded marshaler (FTM).
The FTM introduced some nasty side effects in cases in which the object
had other COM+ objects as members, though, and was therefore a
technique to avoid.

The picture is drastically different when it comes to context-bound objects.
A context-bound object is bound to a particular context for life. The
decision regarding which context the object resides in takes place when
the object is created and is based on the services the object requires
and the context of its creating client. If the creating client's context
is "good enough" for the object's needs—i.e., the context has adequate
properties, and the client and the object use a compatible set of
component services—the object is placed in its creating client's
context. If, on the other hand, the object requires some other service
that the creating client's context doesn't support, .NET creates a new
context and places the new object in it. Note that .NET doesn't try to
find out if there is already another appropriate context for the object
in that app domain. The algorithm is simple: the object either shares
its creator's context or gets a new context. This algorithm
intentionally trades memory and context-management overhead for speed in
allocating the new object to a context. The other alternative would be
to examine each of a potentially long list of existing contexts, but
that search might take a long time to complete and impede performance.
If the object is placed in a different context from that of its creating
client, the client gets back from .NET a reference to a proxy instead
of a direct reference (see Figure 2).
The proxy intercepts the calls the client makes on the object and
performs some pre- and post-call processing to provide the object with
the services it requires.

Figure 2. Clients of a context-bound object access it via a proxy

The .NET policy for allocating context-bound objects to contexts is very similar to the COM+ context activation policy.

2. The Call Interception Architecture

The
cross-context interception architecture is similar to the one used
across app domain boundaries. In .NET, the proxy has two parts: a
transparent proxy and a real proxy.
The transparent proxy exposes the same public entry points as the
object. When the client calls the transparent proxy, it converts the
stack frame to a message and passes the message to the real proxy. The
message is an object implementing the IMessage interface:

    public interface IMessage
    {   
       IDictionary Properties{ get; }
    }

The message is a
collection of properties, such as the method's name and its arguments.
The real proxy knows where the actual object resides. In the case of a
call across app domains, the real proxy needs to serialize the message
using a formatter and pass it to the channel. In the case of a
cross-context call, the real proxy needs to apply interception steps
before forwarding the call to the object. An elegant design solution
allows .NET to use the same real proxy in both cases. The real proxy
doesn't know about formatters, channels, or context interceptors; it
simply passes the message to a message sink. A message sink is an object
that implements the IMessageSink interface, defined in the System.Runtime.Remoting.Messaging namespace:

    public interface IMessageSink
    {
       IMessageSink NextSink{ get; }
       IMessageCtrl AsyncProcessMessage(IMessage msg,IMessageSink replySink);
       IMessage SyncProcessMessage(IMessage msg);
    }

					  

.NET strings together message sinks in a linked list. Each message sink knows about the next sink in the list (you can also get the next sink via the NextSink property). The real proxy calls the SyncProcessMessage( )
method of the first sink, allowing it to process the message. After
processing the message, the first sink calls SyncProcessMessage( )
on the next sink. In the case of cross-app domain calls, the first sink
on the client's side is the message formatter . After formatting the
message, the formatter sink passes it to the next sink—the transport
channel. When the SyncProcessMessage( ) method returns to the proxy, it returns the returned message from the object.

The IMessageSink interface also provides the AsyncProcessMessage( ) method, which intercepts asynchronous calls .

2.1. Cross-context sinks

In the case of a cross-context call, there is no need for a formatter; .NET uses an internal channel called CrossContextChannel,
which is also a message sink. However, there is a difference in
component services configuration between the client and the object, and
it's up to the sinks to compensate for these differences. .NET installs
as many message sinks as required between the client's context and the
object (see Figure 3).

Figure 3. A cross-context call to a context-bound object

The .NET context interception architecture is similar to the Decorator design pattern^[*] and is a private case of aspect-oriented programming .
A typical message sink does both pre- and post-call processing. The
canonical example is again thread synchronization. The sink needs to
acquire a lock before proceeding to call the object, and it must release
the lock after the method returns. The next sink down the call chain
may enforce security, and so on.

^[*] See Design Patterns: Elements of Reusable Object-Oriented Software, by E. Gamma, R. Helm, R. Johnson, and J. Vlissides (Addison-Wesley).

It's best to use an example to demystify the way sinks work. Example 1 shows a generic sink implementation. The sink constructor accepts the next sink in the chain. When the SyncProcessMessage( ) method is called, the sink performs some pre-call processing and then calls SyncProcessMessage( ) on the next sink. The call advances down the sink chain until it reaches a stack-builder sink,
the last sink. The stack builder converts the message to a stack frame
and calls the object. When the call returns to the stack builder, it
constructs a return message with the method results and returns that
message to the sink that called it. That sink then does its post-call
processing and returns control to the sink that called it, and so on.
Eventually, the call returns to the generic sink. The generic sink now
has a chance to examine the returned message and do some post-call
processing before returning control to the sink that called it. The
first sink in the chain returns control to the real proxy, providing it
with the returned message from the object. The real proxy returns the
message to the transparent proxy, which places it back on the calling
client's stack.

Example 1. Generic implementation of a message sink

public class GenericSink : IMessageSink
{
   IMessageSink m_NextSink;

   public GenericSink(IMessageSink nextSink)
   {
      m_NextSink = nextSink;
   }

   public IMessageSink NextSink
   {
      get
      {
         return m_NextSink;
      }
   }
   public IMessage SyncProcessMessage(IMessage msg)
   {
      PreCallProcessing(msg);

      //This calls the object:
      IMessage returnedMessage = m_NextSink.SyncProcessMessage(msg);

      PostCallProcessing(returnedMessage);

      return returnedMessage;
   }
   void PreCallProcessing(IMessage msg)
   {
      /* Do some pre-call processing */
   }
   void PostCallProcessing(IMessage msg)
   {
      /* Do some post-call processing */
   }
   public IMessageCtrl AsyncProcessMessage(IMessage msg,IMessageSink replySink)
   {
      /* Handle the asynchronous call, then: */
      return m_NextSink.AsyncProcessMessage(msg,replySink);
   }
}

					  

2.2. Message sink types

Call interception can
take place in two places. First, sinks can intercept calls coming into
the context and do some pre- and post-call processing, such as locking
and unlocking a thread lock. Such sinks are called server-side sinks. Second, sinks can intercept calls going out of the context and do some pre- and post-call processing. Such sinks are called client-side sinks. For example, using a client-side sink, the Synchronization
attribute can optionally track calls outside the synchronization domain
and unlock locks to allow other threads access. This is done using a
client-side sink. You will see later how to install sinks.

Server-side sinks intercepting all calls into the context are called server context sinks. Server-side sinks intercepting calls to a particular object are called server object sinks. The server is responsible for installing server-side sinks. Client-side sinks installed by the client are called client context sinks, and they affect all calls going out of the context. Client-side sinks installed by the object are called envoy sinks.
An envoy sink intercepts calls only to the particular object with which
it's associated. The last sink on the client's side and the first sink
on the server's side are instances of the type CrossContextChannel. The resulting sink chain is comprised of segments, each of which is a different type of sink, as shown in Figure 4. Because there must be a stack builder at the end of the sink chain to convert messages, .NET installs a terminator at the end of each segment. A terminator
is a sink of the segment's type; it does the final processing for that
segment and forwards the message to the next segment. For example, the
last message sink in the server context sink segment is called the ServerContextTerminatorSink. The terminators behave like true dead ends: if you call IMessageSink.NextSink on a terminator, you get back a null
reference. The actual next sink (the first sink in the next segment) is
a private member of the terminator. As a result, there is no way to
iterate using IMessageSink.NextSink on the entire length of the interception chain.

There is another type of sink, called a dynamic sink,
that lets you add a sink programmatically at runtime, without using
attributes.

3. Same-Context Calls

A context-bound object must
always be accessed via a proxy across a context boundary, so that the
various sinks can be in place to intercept the calls. The question now
is, what happens if a client in the same context as the object passes a
reference to the

Figure 4. Client-side and server-side sink chains

object to a client in a
different context (for example, by setting the value of some static
variable)? If the same-context client has a direct reference to the
object, how can .NET detect that and introduce a proxy between the
object and the new client? .NET solves the problem by always having the
object accessed via a proxy, even by clients in the same context (see Figure 5).
Because the client and the object share the same context, there is no
need for message sinks to perform any pre- or post-call processing. The
interception layer consists of the transparent and real proxy, and a
single message sink—the stack builder. When the same-context client
passes its reference to the transparent proxy to clients in other
contexts, .NET detects that and sets up the correct interception chain
between the new clients and the object.

Figure 5. Even in the same context, clients access a context-bound object using a proxy

In the COM+ world,
same-context clients had direct references to the objects. As a result,
developers had to manually marshal those references—that is, they had to
manually set up the proxy, and the two clients had to coordinate on the
marshaling protocol. This was often done using the Global Interface
Table (GIT).

4. Context-Bound Objects and Remoting

Context-bound objects are a special case of .NET remoting (in particular, of client-activated objects).
In many respects .NET treats them just like remote objects, but it does
optimize some elements of its remoting architecture for context-bound
objects—for example, as mentioned previously, the channel used for
cross-context calls is an optimized channel called CrossContextChannel. For truly remote client-activated objects,
.NET creates a lease and manages the lifecycle of the object via the
lease and its sponsors. However, because the client of a context-bound
object shares with it the same app domain, .NET can still use garbage
collection to manage the object's lifecycle. In fact, when .NET creates a
context-bound object it still creates a lease for it, and the object
can even override MarshalByRefObject.InitializeLifetimeService( ) and provide its own lease. However, the lease doesn't control the lifetime of the object.

With truly remote
objects, when the TCP or HTTP channels marshal a reference across a
process boundary, these channels set up the lease. With cross-context or
cross-app domain objects, the CrossContextChannel and CrossAppDomainChannel channels ignore the lease and let the remote objects be managed via garbage collection.

Read more at
http://mscerts.programming4.us/programming/context%20and%20interception%20%20%20the%20_net%20context.aspx#vFt2rUtbPjB0Hw7M.99