| Object Activation |
|
Object activation refers to the various ways in which a remote object can be instantiated. We begin with a detailed examination of the possible types of object activation and their ramifications. Marshal By Value objects have a simple activation scheme, they are crerated when the client first requests them. Marshal By Reference objects have two activation schemes:
|
Server Activated Objects (SAO) |
Client Activated Objects (CAO) |
|
Server Activated Objects. (Well-Known) Before a remote method can be invoked on a remote object, the remote object must exist or be created. Server Activated Objects are created only when the client makes the first call to the remote method. In other words, when the client asked for the creation of the remote object only the local proxy is created onthe client, the actual remote object on the server is instantiated on the first method call.So, how do we generate one? Here is an example:
|
… // On the Server RemotingConfiguration.RegisterWellKnownServiceType(typeof(RemoteServerObject), "Test", WellKnownObjectMode.SingleCall); … // On the Client IRemoteCom obj = (IRemoteCom)Activator.GetObject(typeof(IRemoteCom), "tcp://localhost:1002/Test"); … |
|
SAO have two registration types, Singleton and SingleCall.
|
|
Singleton objects, as the name implies, are instantiated one time only, and services all client requests in a multi-threaded fashion. SingleCall object are at the other extreme, everytime a remote method is invoked on these types of SAO a new remote object is created. The new instance services the request and is then left for the garbage collector to dispose. These can be acomplished on the server as follows::
|
RemotingConfiguration.RegisterWellKnownServiceType( typeof(RemoteServerObject), "Test", WellKnownObjectMode.SingleCall); … RemotingConfiguration.RegisterWellKnownServiceType( typeof(RemoteServerObject), "Test", WellKnownObjectMode.Singleton); |
|
For SAOs the proxy object (on the client) and the actual object (on the server) are created at different times, for this reason only default constructors can be used for SAOs. If an SAO object requires a non-default constructor you can use the factory pattern for provide one. Note that if a Singleton object has been removed by the garbage collector, a new one will be created on a subsequent client call.
|
|
Client Activated Objects. (Activated) These are created on the server immediately upon the client's request. An instance of a CAO is cretated every time the client instiantiates one, either by the use of new or Activator.CreateInstance(…)
|
… // On the Server RemotingConfiguration.ApplicationName = "TestCAO"; RemotingConfiguration.RegisterActivatedServiceType(typeof(RemoteObjectCAO)); … // On the Client RemotingConfiguration.RegisterActivatedClientType(typeof(RemoteObjectCAO), "tcp://localhost:1002/TestCAO"); obj = new RemoteObjectCAO(); …
|
|
In all these examples "localhost" can be replaced with an actual remote machine's IP address. The following shows a small example of a few of these ideas.
|
  |
|
On startup the server registers all of its remote object types and waits. The client consistes of three examples, a Singleton SAO, a SingleCall SAO and a CAO. The SAO examples demostrates the key fact about SAOs, object creation is done at the time of the first method's invocation, also the Singleton object is instiantiated once while the SingleCall objects are instiantiated each time a call is made. The CAO object is created right away. When an object is passed to a remote method as ref it behaves exactly as expected any changes to the reference parameter is marshaled back to the caller (client). A word of caution, in order to keep the examples as simple and as clear as possible the CAO button on the client constructs a class that calls RemotingConfiguration.RegisterActivatedClientType(…) this should only be done once, not each time a class is instiantiated. For this reason I have disabled the button after the first click.
|
| Object Lifetime And Configurtion |
|
We have seen three main categories of MBR server-side objects, two SAO types and the CAO type. An SAO that has been registered as SingelCall has a very simple and limited lifetime. It lives for a single call only, thereafter it is marked for removal by the Garbage Collector. The other two types Singleton and CAO have their lifetimes managed by a service introduced by the .Net Framework, the Leased Based Manager, on the server the application domain's lease manager determines when a server-side object should be marked for deletion. Each application domain has its own lease manager object. A sponsor is any object that the lease manager can call to determine wether or not a remote object's lifetime lease should be extended. Notice that under this scheme the remote object's (server-side object) lifetime is independent of the client object's lifetime. The decoupling of the server and client lifetimes is a very flexable design. Consider the following, a remote object that is costly to instiantiate can be given a long lifetime lease or can be kept alive by a sponsor. In addition a remote object that holds scarce or important resources can be given short lifetimes and be reclaimed by the Garbage Collector quickly. More importantly, this decoupling gurantees that the remoteobject will have a finite lifetime regardless of network conditions or the existance of any clients. The default settings for the lease mamager are five minutes for initial time-to-live, poll every ten seconds, and add an additional two minutes for every remote call by a client. All these values are configurable, we can override MarshalByRefObject InitializeLifetimeService() to define our own values.
|
|
<
span sty |
<configuration> <system.runtime.remoting> <application> <channels> <channel ref="tcp" port=1002 /> </channels> <service> <wellknown mode="Singleton" type="TestSAOSingleton" /> <activated mode="SingleCall" type="TestSAOSingleCall" /> </service> <lifetime leaseTime="10M" sponsorshipTimeOut="2M" renewOnCallTime = "2M" LeaseManagePollTime="10s"/> </application> </system.runtime.remoting> </configuration> |
↧
.Net Remoting – Part2 Object Activation, Lifetime And Configuration
↧