Marshal by Reference Activation Modes
.NET supports two kinds of marshal by reference objects: client-activated and server-activated. The two kinds of reference objects map to three activation modes: client-activated object, server-activated single call, and server-activated singleton. The different activation modes control object state management, object sharing, object life cycle, and the way in which the client binds to an object. The client decides whether to use client-activated or server activated objects.
|The different activation modes control object state management, object sharing, object life cycle, and the way in which the client binds to an object.|
If the client chooses a client-activated object, then the client has just one activation model available. If the client chooses server-activated object, it is up to the hosting app domain to decide whether the client will get a server-activated single call object or a server-activated singleton object. It is called server activated because it is up to the host to activate an object on behalf of the client, and bind it to the client.
The hosting app domain indicates to .NET, using server registration, which activation modes it supports. The host can support both client and server activated objects, or either one. It is completely at the discretion of the host. If the host decides to support the server-activated model, it needs to register it either as single-call or as singleton, but not both.
The Client-activated object model is the classic client-server activation model: when a client creates a new object, the client gets a new object. That object is dedicated to the client and it is independent of all other instances of the same class. Different clients in different app domains get different objects when they create new objects on the host (see Figure 2).
|Figure 2: Client-activated objects. Each client gets an independent object for its use. Like the classic client-server model, clients can still share objects.|
There are no limitations on constructing client-activated objects, and you can use either parameterized constructors or the default constructor. The constructor is called exactly once, when the client creates the new remote object, and .NET will marshal the construction parameters to the new object if parameterized constructors are used. Clients can choose to share their objects with other clients, either in their app domains or in other app domains. Like local objects, client-activated objects can maintain state in memory.
To make sure the remote object is not disconnected from the remoting infrastructure and collected by its local garbage collector when making crossprocess calls, client-activated objects require leasing to keep them alive as long as the clients use them. Leasing provides a timestamp extending the life of the object. Leasing and sponsorship merit a dedicated article. The Client-activated object model is similar to the default DCOM activation model with one important difference: The host app domain must register itself as a host willing to accept client-activated calls, before remote calls are issued. This means the process containing the host app domain must be running before such calls are made.