.NET Remoting and Delphi - Object Activation
(Page 6 of 11 )
Before you can acquire a reference to a remote object running in a different application domain, the object needs to be created on the remote machine.
There are two ways to create an instance of a remotable object: using server activation and using client activation.
Server Activation
Server-activated objects are referred to as well-known because they are registered in the .NET remoting system and published at a specific and well-known endpoint or URI.
Well-known objects can be activated in two ways: singleton and single-call.
Singleton Activation
Singleton activated means only one instance of an object will be created and be accessible at any given time. If two clients request a reference to a singleton-mode–configured object, they will both receive the same reference and their calls will be serialized.
The following code shows how to register a singleton-mode–configured object:
RemotingConfiguration.RegisterWellKnownServiceType(
typeOf(TBankManager),
'BankManager.soap',
WellKnownObjectMode.Singleton);
Single-call Activation
Single-call instantiation is the most scalable activation mode because it best fits stateless systems. When you register an object as single-call, an instance will be created upon each client's request and, once the call is completed, it will be released for garbage collection.
The following code shows how to enable single-call instantiation:
RemotingConfiguration.RegisterWellKnownServiceType(
typeOf(TBankManager),
'BankManager.soap',
WellKnownObjectMode.SingleCall);
Client Activation
Client-activated objects are activated on a per-client basis. Each client will have his own unique reference that can also remain active between method calls (stateful).
Although client-activation offers some advantages and is simpler to use than server-side instantiation, it is less scalable. It uses more resources on the server, ties clients to one server, and, because of this, doesn't work in Web farms.
To enable for this kind of activation, your server will have to include a call similar to the following:
RemotingConfiguration.RegisterActivatedServiceType(typeof(TBankManager));
And corresponding code on the client would look like this:
RemotingConfiguration.RegisterActivatedClientType(typeof(TBankManager),
'http://someurl');
You will see more in detail how to create client-activated objects in the section "Client Activation" in Chapter 30.
Leases and Sponsors
A remote object's lifetime is managed by lease-based garbage collection. Each application domain contains its own lease manager and tracks access to objects. If an object is not accessed for a certain amount of time, it's then handed to the garbage collector that destroys it.
Object lifetime management in .NET is radically different from how DCOM handles object lifetimes. In DCOM, a combination of reference counting and network pinging was used to determine when objects could be destroyed. This led to network congestion and other side effects that were less-than-optimal in large installations. .NET remoting was designed to resolve those problems.
Leases are used for server-activated singleton objects and client-activated objects. After the .NET Framework creates an instance of those, it calls the virtual method InitializeLifeTimeServices (inherited from MarshalByRefObject and possibly overridden), which returns an object that implements the interface ILease. This object will then be queried to determine if the lease on the object has expired and it can be destroyed.
Leases can be renewed by sponsors. You can define a class that acts as a sponsor by implementing the ISponsor interface. You then need to associate the sponsor to a lease by calling the method ILease.Register.
The .NET Framework defines the ClientSponsor class, which provides a default implementation for a lifetime sponsor class.
Proxies
Clients communicate with remote objects by using proxies. A proxy is an object that resides in the address space of the client and acts as a surrogate for the remote object.
In .NET, we have two types of proxies: transparent and real.
The transparent proxy is the object we directly acquire when writing code such as
fBankManager := Activator.GetObject(
typeof(IBankManager),
'http://localhost:8099/BankManager.soap');
After a method call is issued, the transparent proxy packages the name and parameters into a message object and hands this to the real proxy.
The real proxy then dispatches the message object to the .NET Framework, which will then use a remoting channel to deliver it.
Channels
Remoting channels transport messages across application domains. The .NET SDK provides two types of channels you can use: TCP/IP and HTTP.
You would use a TCP/IP channel mostly in local area networks or where communication has to be as fast as possible.
You would instead use the HTTP channel for Internet or, in general, firewall-friendly type of communication.
Both channels can be used independently of the messaging format. This means that you can decide to use SOAP or Binary formatting over either TCP/IP or HTTP.
 This chapter is from Delphi for .NET Developer's Guide, by Xavier Pacheco (Sams, 2004, ISBN: 0-672-32443-1). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Your First .NET Remoting Application >>
More .NET Articles
More By Xavier Pacheco
