Summary

Application domains provide isolation between different applications running on the same system.

A context provides a runtime environment for compatible objects to live in. It contains one or more context properties and context sinks. Context properties provide passive services. Context sinks provide active interception-based services.

When an object is activated, the runtime houses the object in the caller's context if the context attributes on the object are compatible with the caller's context. If not, the runtime creates a compatible context and houses the object in the new context.

An application domain holds one or more contexts. When an application domain is created, the runtime creates a default context within the AppDomain. Subsequently, more contexts may be created within the domain as more objects are created.

When a remote object is created or an object is passed to another domain as a method parameter, the runtime transforms the object into a block of memory suitable for transmitting to the other context. This process is referred to as marshaling. Subsequently, the importing domain can unmarshal the block of data and create a new object that has similar characteristics to the original object.

Under .NET, objects are classified as MBV objects, MBR objects, and nonremotable objects. When an MBV object is moved to a different domain, an exact copy of the object is made in the target domain. When an MBR object is moved to a target domain, the runtime creates a proxy object in the target domain and returns it to client. Any call on the proxy object is intercepted by the runtime and is forwarded to the original object in the remote domain. These objects cannot leave their domain.

MBR objects are further classified as context-bound objects or context-agile objects. Context-bound objects are bound to a context and require proxy marshaling if moved to a different context, even if the context is in the same AppDomain. A context-agile object does not require any marshaling within the AppDomain but needs to be marshaled when moved to a different AppDomain.

A remote object can be created as a server-activated object or a client-activated object. Server-activated objects are those objects with a lifetime that is directly controlled by the server. The lifetime of a client-activated object is controlled by the client. Server-activated objects are usually identified by a name, so they are also called well-known objects.

Server-activated objects can be published in two modes, single-call or singleton. A single-call object mode implies that the remote object be created on each method call and torn down after the call returns. A singleton object mode implies that the remote object be created just once on the first method call and be reused on subsequent method calls.

.NET uses a lease-based technique to manage the lifetime of MBR objects. An MBR object, either client-activated or singleton, can be associated with a lifetime lease. When the lease expires, the object is destroyed (garbage collected). However, .NET provides various ways to extend the lease.

It is possible to store the object activation information in external configuration files. This provides flexibility to the administrator in configuring an application. The configuration files can be created on the server side and the client side.

.NET remoting applications can also be hosted under ASP.NET. However, this requires a client to be on the .NET platform. True platform independence can be achieved by creating Web services. ASP.NET makes it easy to develop and test Web services. The .NET platform also makes it convenient for clients to consume the Web services.

The .NET remoting framework provides full managed code type–system fidelity over the network. The mechanism is open to use TCP, HTTP, or any other proprietary channel. The message can be formatted in binary, SOAP, or using a custom formatter. In addition, different types of sinks can be added at various stages in the remoting pipeline.