Server-side callbacks Define a client-side callback interface

} }

21.2.2.3 Server-side callbacks

The second common solution for printer-type methods involves having an RMI server inside the client application. The server application receives a reference to this client-side server and uses it to call the client back when the server has finished the original request. That is, we have the following sequence of actions: 1. The client application makes a remote invocation on the server application. As part of this invocation, it passes in a reference to an RMI server inside the client application. 2. When the server application finishes handling the request, it makes a remote method invocation on the RMI server inside the client application. Server-side callbacks have several advantages over client-side polling. The most important of these advantages are decreased bandwidth and decreased server-side processing. The longer it takes a document to print, the greater the advantage server-side callbacks have. If each client polls 20 times, and receives 20 nope-not-finished-yet return values for every print job, then switching to server-side callbacks can result in significant savings. Of course, how much of a gain this is depends on the frequency of polling versus the typical duration of a garbage collection lease. Because the server maintains a reference to the client, server-side callbacks still have the overhead of maintaining and renewing the distributed garbage collectors lease. This usually has a lot less traffic than polling, however. The downside to server-side callbacks is that the code itself and its deployment becomes slightly more complex. To implement server-side callbacks, we need to perform the following three steps: 1. Define a client-side callback interface and change the Printer interface to accept instances of our callback interface, often referred to as the callback objects. 2. Implement the client-side interface, using the reporting code weve already written inside the callback objects, to report to the user. 3. Rewrite the server to track print requests, associate requests with the callback objects, and call the client back when requests are completed. In the rest of this section, well walk through the first two steps in more detail.

21.2.2.4 Define a client-side callback interface

This is pretty simple. The only complication that arises is that the client may actually want to print more than one document. When a document is done printing, and the server wants to tell the client that the document is done, the server needs to also tell the client which document has finished printing. There are two basic approaches to this. The first approach is to create multiple servers on the client side. That is, the client creates an instance of CallbackClient for each print request e.g., if the client is printing three documents, it has three instances of CallbackClient , each waiting for a message from the server. In this case, the interfaces are: public interface CallbackPrinter extends PrinterConstants, Remote { public void printDocumentCallbackClient clientMakingRequest, DocumentDescription document throws RemoteException, PrinterException; public void printDocument DocumentDescription document throws RemoteException, PrinterException; for when we dont need a callback } public interface CallbackClient extends Remote{ public void documentIsDone throws RemoteException; public void documentFailedToPrintString reason throws RemoteException; } The second approach is to use a single instance of CallbackClient on the client side, which receives all the documentIsDone messages. In this case, an extra piece of information, which uniquely identifies the printRequest , also needs to be passed back and forth. One way to do this is via the following interfaces: public interface CallbackPrinter extends PrinterConstants, Remote { public void printDocumentCallbackClient clientMakingRequest , DocumentDescription document, String documentKey throws RemoteException, PrinterException; public void printDocument DocumentDescription document throws RemoteException, PrinterException; for when we dont need a callback } public interface CallbackClient extends Remote{ public void documentIsDoneString documentKey throws RemoteException; public void documentFailedToPrintString documentKey, String reason throws RemoteException; } In this second set of interfaces, the client is responsible for generating a unique-to-the-client documentKey . In both of these approaches, the same general flow of control occurs: 1. The client sends a print request to the server and gets back an immediate response. 2. After the document is done printing, the server calls either documentIsDone or documentFailedToPrint on the client.

21.2.2.5 Implement the client-side interface