Server Activation

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. However, this also means that only default constructors are allowed for server-activated types when you use the default implementations. 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.

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 if 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) and call new, or they pass the remote object's configuration in a call to Activator.GetObject.

**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 chooses or 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
   ) [C#]
RemoteObjectClass MyRemoteClass = (RemoteObjectClass)Activator.GetObject(
   typeof(RemoteObjectClass),
   "tcp://computername:8080/RemoteObjectUri "
);

Remember, the preceding call does not create the remote object on the server. It returns to the client only a reference to the local proxy for the remote object. The client can now continue to treat MyRemoteClass as though it is a direct reference to the remote object. The instance that the client actually uses to communicate 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

Activation | Client Activation | WellKnownObjectMode Enumeration | Activation | Lifetime Leases