Contexts

 

Chapter 21 - Distributed Applications with .NET Remoting
bySimon Robinsonet al.
Wrox Press 2002

  

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

If you've 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 sub-process with security boundaries. We discussed application domains in Chapter 8.

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 from a different context, an interceptor can do some work before the call reaches the object. Examples where this can be used are for thread synchronization, transactions, and security management.

A class that is 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 that 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 we have to know some 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 . We 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 we can intercept method calls. 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. There are several of these interfaces to go with the variety of sinks.

Attributes and Properties

With context attributes we define the properties of a context. A context attribute class primarily is an attribute. You can read more about attributes in from the class ContextAttribute , because this class already has a default implementation of this interface.

With the .NET Framework we have one context attribute class: System.Runtime.Remoting.Contexts.SynchronizationAttribute. The Synchronization attribute defines synchronization requirements it specifies the synchronization property that is needed by the object. We can specify that multiple threads cannot access the object concurrently, but the thread accessing the object can change.

With the constructor of this attribute we can set four values:

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

• REQUIRED specifies that we need a context with synchronization

• With REQUIRES_NEW we always get a new context

• SUPPORTED means that it doesn't matter what context we get, the object can live in it

Communication between Contexts

So, 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.