Contexts

Before you look at using .NET Remoting to build servers and clients that communicate across a network, this section turns to the cases where a channel is needed inside an application domain: calling objects across contexts.

If you’ve previously written COM+ components, you already know about COM+ contexts. Contexts in .NET are very similar. A context is a boundary containing a collection of objects. Likewise, with a COM+ context, the objects in such a collection require the same usage rules that are defined by the context attributes.

As you already know, a single process can have multiple application domains. An application domain is something like a subprocess with security boundaries. Application domains are discussed in Chapter 16, “Assemblies.”

An application domain can have different contexts. A context is used to group objects with similar execution requirements. Contexts are composed from a set of properties and are used for interception: when a context-bound object is accessed by a different context, an interceptor can do some work before the call reaches the object. This can be used are for thread synchronization, transactions, and security management, for example.

A class derived from MarshalByRefObject is bound to the application domain. Outside the application domain a proxy is needed to access the object. A class derived from ContextBoundObject, which itself derives from MarshalByRefObject is bound to a context. Outside the context, a proxy is needed to access the object.

Context-bound objects can have context attributes. A context-bound object without context attributes is created in the context of the creator. A context-bound object with context attributes is created in a new context or in the creator’s context if the attributes are compatible.

To further understand contexts, you must be familiar with these terms:

• Creating an application domain creates the default context in this application domain. If a new object is instantiated that needs different context properties, a new context is created.

• Context attributes can be assigned to classes derived from ContextBoundObject. You can create a custom attribute class by implementing the interface IContextAttribute. The .NET Framework has one context attribute class in the namespace System.Runtime.Remoting .Contexts: SynchronizationAttribute.

• Context attributes define context properties that are needed for an object. A context property class implements the interface IContextProperty. Active properties contribute message sinks to the call chain. The class ContextAttribute implements both IContextProperty and IContextAttribute, and can be used as a base class for custom attributes.

• A message sink is an interceptor for a method call. With a message sink, method calls can be intercepted. Properties can contribute to message sinks.

Activation

A new context is created if an instance of a class that’s created needs a context different from the calling context. The attribute classes that are associated with the target class are asked if all the properties of the current context are acceptable. If any of these properties are unacceptable, the runtime asks for all property classes associated with the attribute class and creates a new context. The runtime then asks the property classes for the sinks they want to install. A property class can implement one of the IContributeXXXSink interfaces to contribute sink objects. Several of these interfaces are available to go with the variety of sinks.

Attributes and Properties

The properties of a context are defined with context attributes. A context attribute class primarily is an attribute - you can find out more about attributes in Chapter 12, “Reflection.” Context attribute classes must implement the interface IContextAttribute. A custom context attribute class can derive from the class ContextAttribute, because this class already has a default implementation of this interface.

.NET Framework 2.0 includes two context attribute classes: System.Runtime.Remoting.Contexts .SynchronizationAttribute and System.Runtime.Remoting.Activation.UrlAttribute. The Synchronization attribute defines synchronization requirements; it specifies the synchronization property that is needed by the object. With this attribute you can specify that multiple threads cannot access the object concurrently, but the thread accessing the object can change.

With the constructor of this attribute, you can set one of four values:

• NOT_SUPPORTED defines that the class should not be instantiated in a context where the synchronization is set.

• REQUIRED specifies that a synchronization context is required.

• REQUIRES_NEW always creates a new context.

• SUPPORTED means that it doesn’t matter what context you get; the object can live in it.

Communication between Contexts

How does the communication between contexts happen? The client uses a proxy instead of the real object. The proxy creates a message that is transferred to a channel, and sinks can do interception. Does this sound familiar? It ought to. The same mechanism is used for communication across different application domains or different systems. A TCP or HTTP channel is not required for the communication across contexts, but a channel is used here too. CrossContextChannel can use the same virtual memory in both the client and server sides of the channel, and formatters are not required for crossing contexts.