Browse DevX
Sign up for e-mail newsletters from DevX


Using Remote Object Models in .NET : Page 3

.NET supports two types of remote objects (by value and by reference) and three activation models for the later (client-activated, single call, and singleton). Each model and object type has its place. This article explains and contrasts the different models and when to apply them.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

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. Client-Activated Object
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 cross—process 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.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date