Understanding the System.Runtime. Remoting.Contexts Namespace

This book doesn’t discuss all of the intricacies of remoting—you could probably fill several chapters of a general programming book with the required information. However, this section does discuss the security benefits of a context, which is an essential coding consideration for remoting. A context describes the environment in which one or more objects execute. It includes properties that define this environment. The environment includes a number of factors including security. Of course, it also defines synchronization, transactions, and Just-In-Time (JIT) activation. All of these elements combine to define the application environment.

Tip

You can find a complete description of the System.Runtime.Remoting.Contexts namespace at http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemruntimeremotingcontexts.asp. The description includes as list of the classes directly associated with this namespace.

Contexts Namespace Overview

The most important aspect of context for this book is the security that an application domain (AppDomain) can provide by isolating an object. The isolation places the object within a different security context than other objects executing with the same process. For example, ASP.NET places each Web page in a separate application domain, but all of the Web pages execute within the same process.

Tip

Sometimes you need an alternative view of the .NET Framework. The .NET Framework Class Browser (http://docs.aspng.com/quickstart/aspplus/samples/classbrowser/vb/classbrowser.aspx) provides this view. It actually lists all of the classes that Microsoft keeps hidden in the help files. The site doesn’t contain any documentation of the sort that you find in the help files, but it does make the interactions between the various .NET Framework elements clearer than the help file does in some situations. For example, look at the class for this section and you’ll find a number of related interfaces and classes that aren’t associated with the System.Runtime.Remoting.Contexts namespace in the help file.

One of the main security benefits of the System.Runtime.Remoting.Contexts namespace is the isolation it provides between objects. Whenever your application creates a context-bound object (one based on a context-bound class), the CLR finds a compatible context or places the object in a new context. The object remains in this context for life. Whenever another object wants to access the current object, it does so through a proxy. CLR oversees the entire process, making the environment inherently more secure.

SynchronizationAttribute Attribute Example

The only accessible class in the System.Runtime.Remoting.Contexts namespace is SynchronizationAttribute. The main purpose of this class is to enforce the synchronization domain for the current object and all objects that share the same instance. Think of a domain as a method for isolating a set of related objects. Listing 2.1 shows three examples of classes that rely on the SynchronizationAttribute attribute. (You can find this code in the \Chapter 02\C#\Crypto or \Chapter 02\VB\Crypto folder of the source code located on the Sybex Web site.)

Listing 2.1 Three examples of the SynchronizationAttribute attribute

[Synchronization(SynchronizationAttribute.REQUIRES_NEW, false)] public class Sync1 {    public String GetName()    {       return (AppDomain.CurrentDomain.FriendlyName);    } } [Synchronization(SynchronizationAttribute.SUPPORTED, false)] public class Sync2 : MarshalByRefObject {    public String GetName()    {       return (AppDomain.CurrentDomain.FriendlyName);    } } [Synchronization(SynchronizationAttribute.REQUIRED, false)] public class Sync3 : ContextBoundObject {    public String GetName()    {       return (AppDomain.CurrentDomain.FriendlyName);    } }

The first class uses the SynchronizationAttribute.REQUIRES_NEW argument, which means that the class must appear in a context with a new copy of the synchronization property each time. What this really means is that the resulting object must reside in its own context because the new copy of the synchronization property requires a different context each time.

Notice that this object doesn’t derive from anything. The result is a standard system object of the Sync1 type. Figure 2.1 shows the debug view of this object (and the others in this example). When a client attempts to access this object, CLR creates a copy of the object and places the in the client context. The copy contains all of the data and other features of the original. Therefore, if you have a property set to a certain value, the client will see that value. Consequently, a client accesses this class by value. Any changes the client makes to the object won’t appear in the original version of the object.

click to expand
Figure 2.1: The method used to design an object determines the client access type.

The Sync2 class uses the SynchronizationAttribute.SUPPORTED argument. Using this argument means that CLR can place the object in a context that either does or doesn’t have the synchronization property. An alternative to this value is the SynchronizationAttribute.NOT_SUPPORTED argument. This value means that CLR can’t place the object within a context that has the synchronization property set. If no context exists, then CLR creates a new one.

This class also demonstrates another access strategy because it derives from the MarshalByRefObject class. This addition means that the client will work with the actual object on the server, not a copy. Any changes the client makes will appear to all clients that access the object. When a client exists in a different application domain than the object, CLR creates a proxy for the client. The proxy receives the client requests and passes them to the object. In many respects, this access strategy works the same as COM+. Notice from the debug view in Figure 2.1 that this also adds to the memory footprint of the object by adding an embedded entity.

The Sync3 class uses the SynchronizationAttribute.REQUIRED argument. In this case, CLR can create the object in the same context as other objects, so long as the context has the synchronization property set. Of course, the resource and other requirements of the context must also match.

This class uses the context bound access technique because it derives from the ContextBoundObject class. Using this method means that every client sees the object as if it exists in the same context as the client. However, CLR sends every call through one or more proxies (see the debug view in Figure 2.1) to ensure both the client and the object receive the environment and resources they expect and can access.

The context bound object shown in the debug view in Figure 2.1 provides the isolation and security required for most distributed applications today. Because the proxies are invisible and each party receives what it expects, the program behaves as if it were all on one machine. This is the type of class setup required to ensure maximum benefits from .NET security.