Server Activation

This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).

Server-activated objects are objects whose lifetimes are directly controlled by the server. The server application domain creates these objects only when the client makes a method call on the object, rather than when the client calls new (New() in Visual Basic) or Activator.GetObject; this saves a network round trip solely for the purpose of instance creation. Only a proxy is created in the client application domain when a client requests an instance of a server-activated type. This means that only default constructors are allowed for server-activated types. To publish a type whose instances will be created with specific constructors that take arguments, you can use Client Activation or you can dynamically publish your particular instance.

Server Activation Modes

There are two activation modes (or WellKnownObjectMode values) for server-activated objects: Singleton and SingleCall.

Singleton types never have more than one instance at any one time. If an instance exists, all client requests are serviced by that instance. If an instance does not exist, the server creates an instance and all subsequent client requests will be serviced by that instance. Because Singleton types have an associated default lifetime, clients will not always receive a reference to the same instance of the remotable class, even though there is never more than one instance available at any one time.

SingleCall types always have one instance per client request. The next method invocation will be serviced by a different server instance, even if the previous instance has not yet been recycled by the system. SingleCall types do not participate in the lifetime lease system.

To create an instance of a server-activated type, clients either configure their application programmatically or using a configuration file. When configuring an application programmatically you use the Activator.GetObject method to instantiate a server activated object on the client. When configuring an application with a configuration file you can either call Activator.GetObject or use the new operator to instantiate a server activated object on the client.

Note

You might not have to register the channel on the client side. If the client does not register a channel, the remoting system automatically creates a channel using one of the default channels specified in the Machine.config file to make outgoing requests. This automatic channel selection on the client does not register the channel to listen for any callback functions from the server, and, unless that custom channel is added to the machine.config file, it does not register any custom channel implementation. In these cases, you must register the type of channel you want to use in the client application domain.

The following code example shows a call to Activator.GetObject, assuming a TcpChannel has been registered to communicate on port 8080. If your client knows only that the server object implements a particular interface, you must use a call to Activator.GetObject, because you can only use new (New in Visual Basic) to create an instance of a class.

Dim MyRemoteClass As RemoteObjectClass = _
   CType( _
      Activator.GetObject(GetType(RemoteObjectClass), _
         "tcp://computername:8080/RemoteObjectUri" ), _
      RemoteObjectClass
   ) 

RemoteObjectClass MyRemoteClass = (RemoteObjectClass)Activator.GetObject(
   typeof(RemoteObjectClass),
   "tcp://computername:8080/RemoteObjectUri "
);

Keep in mind that at this point no actual communication with the server has occurred, so the remote object itself has not been instantiated. What has been instantiated is the proxy object on the client side. The client can now use MyRemoteClass as though it is a direct reference to the remote object. The RemoteObjectClass instance that the client actually uses to communicate with from method call to method call depends on whether the server object is declared as a Singleton or SingleCall type. Regardless of whether the publisher of the server object exposes this information, the client treats the object reference that it has exactly the same.

Singletons

In COM, "singleton" meant that as long as clients had references to your object, the object would not be deleted from memory. In .NET Remoting, however, a Singleton object is subject to the lifetime lease that was specified for it, so it can be recycled even if clients currently hold references to it. You can create the former type of Singleton object by overriding the InitializeLifetimeService method of MarshalByRefObject to return a null reference (Nothing in Visual Basic). This effectively keeps the object in memory as long as the host application domain is running. For details, see Lifetime Leases. You can create the latter type of Singleton object by configuring the initial lease time in the remoting configuration file.

See Also

Reference

WellKnownObjectMode Enumeration

Concepts

Activation of Remote Objects
Client Activation
Lifetime Leases