Choosing Lifetime and Lifecycle Options Appropriately

The example in this chapter created a remoted class called Greeter . Greeter is a well-known object, meaning that client applications ask for it by name . The alternative to a well-known object is a client-activated object. Well-known objects are activated on the server when a method of the object is first called (constructing the proxy object on the client does not create an object on the server). If the object is a Singleton , as in this chapter's example, it is not destroyed when the call returns, but waits on the server. All subsequent method calls (from any and all clients that are connecting to this server) are handled by this server object. If calls stop coming in, the object does not wait forever; eventually it is cleaned up on the server. You can control the amount of time that a Singleton object will exist after the last call it handles with a <lifetime> element in the configuration file, within the <application> element. Here is an example <lifetime> element:

 <lifetime    leaseTime = "10M"    sponsorshipTimeOut = "2M"    renewOnCallTime = "2M"    LeaseManagePollTime = "10s" />

This element has four attributes:

leaseTime After this much time has elapsed since the creation of the object without a call for it, the cleanup process will begin. The default value is five minutes. Use zero ( "0M" ) to achieve an infinite lifetime for the object.
sponsorshipTimeOut The cleanup process begins with a call to every remote client that has been using the object, asking if they still want it. (All this code is behind the scenes; you don't need to write anything to handle it.) The amount of time specified in this attribute controls how long the server will wait for an answer before assuming the client is no longer running and therefore is finished with the object. The default value is two minutes.
renewOnCallTime After the object is in use, this is the amount of time that will elapse after each call before cleanup will begin. The default value is two minutes.
LeaseManagePollTime How often the lease manager checks to see whether lifetimes have elapsed. Default is 10 seconds.

In all these attributes, a number followed by M indicates a number of minutes, and a number followed by S indicates a number of seconds.

If the object is SingleCall , it is cleaned up after every call and does not persist between calls. You must decide whether Singleton or SingleCall is the right lifetime option for your application. In this example, the Greeter object holds a list of event handlers, so it must continue to exist between callsthat makes Singleton the right choice. In another application, calls might be infrequent and stateless, making SingleCall the right choice.

Client-activated objects provide an alternative to well-known objects and allow multiple remoted instances of a class to exist at the same time. With well-known objects, either one instance exists and is shared by all clients, or one instance is created and then destroyed for each method call, with no state persisting between calls. The client-activated approach allows you to create an object that lives between calls and can hold state, and to create a different instance for each client that is using the application. Use type=activated instead of type=wellknown in the configuration file. The lifetime is still governed in the same way; when the client that created a particular instance hasn't used it for a while, the lease may expire and the object may be cleaned up. Use the same <lifetime> element to control the lifetime of an activated object as shown for a well-known object.

SHOP TALK: REMOTING VERSUS WEB SERVICES

Web Services, covered in Chapter 10, "Writing and Consuming a Web Service," allow client code to execute code on a remote machine over the Internet. It's reasonable to wonder what the difference is between the two and under what circumstances you would choose one over the other.

Web Services are an excellent way for unrelated applications to communicate. For example, an application written by Company A can use a Web Service exposed by Company B to place an order for products or services. The Web Service is completely self-describing , and because Web Services rely on cross-platform standards like HTTP and XML, there's no need for the two firms to be using the same programming language, operating system, or data formats.

Remoting is useful in more tightly- coupled scenarios. XML can be verbose, and Web Services use XML to describe everything. Each time you call a Web Service that returns a data set, it also sends you the schema for that data set, just to be sure that the data is self-describing. In contrast, two applications that communicate using remoting are rather like an old married couple who can finish each other's sentences. The example in this chapter relies on conveniences such as both client and server applications having a reference to the Greeter class library. These shared definitions allow the applications to exchange information in a more compact manner.

Which should you use? If you are writing only half the application, and relying on a business partner to write the other half, agree to use Web Services and you need not agree on anything else. If you're writing a distributed application, with both halves developed by the same team, consider remoting. It's convenient and efficient.