Printer-Type Methods Report-Type Methods

Consider, once again, the Account interface: public interface Account extends Remote { public Money getBalance throws RemoteException; public void makeDepositMoney amount throws RemoteException, NegativeAmountException; public void makeWithdrawalMoney am ount throws RemoteException, OverdraftException, NegativeAmountException; } Each of the methods contained in the Account interface shares the following five characteristics: • Their arguments dont require a lot of bandwidth to send over the wire. • Actually performing the business logic doesnt require much computational effort on the part of the server. • All the methods require similar amounts of bandwidth and computational effort. Distinct calls, even ones from different clients accessing different accounts, have the same computational profile. • They require a timely response. • Its hard to say that one request is more important than another. [ 1] [ 1] This is partially because the requests are so computationally insignificant. You could conceive of ways to prioritize requests based on the customers total deposit, for example, but any implementation of a prioritization scheme would consume a significant percentage of the servers total processing time. When all five of these characteristics are present, requests are fairly small, and theres no clear benefit, in terms of server resources, to postponing or delaying some requests while immediately serving others. In this scenario, system architects usually opt for a limited model of client-server interaction known as request-response cycles. [ 2] In this model of client-server interaction, the client makes a request and the server responds immediately with the entire answer, and the transaction is over. [ 2] And well call the associated methods request-response methods. There is very little large-scale control over the sequence of remote method invocations e.g., any sequence of remote method invocations is equally valid, and the server handles requests to a large degree on a first-come, first-served basis. Request-response is sometimes used to mean something a little stricter than the preceding definition. In particular, some authors also require that request-response systems be memoryless. That is, the server and the client shouldnt have any knowledge about each other between cycles, and there is no shared state. The early web servers and browsers were request-response systems in this stronger sense. However, the advent of Java, Javascript, and cookies quickly pushed the Web into our weaker definition.

21.1.1 Printer-Type Methods

If all five characteristics arent present, request-response cycles can break down. For example, consider our Printer interface again: public interface Printer extends PrinterConstants, Remote { public boolean printerAvailable throws RemoteException; public boolean printDocumentDocumentDescription document throws RemoteException, PrinterException; } The first method, printerAvailable , certainly has our five characteristics. printDocument , however, does not. It can require substantial bandwidth to send the request, and it can take a long time to print a document. Moreover, while the client needs to be told whether the document was accepted in a timely manner, the really important piece of information the client wants is whether the document was successfully printed. And that information cannot be returned immediately. Well call methods like this printer-type methods. Our solution to this problem was to simply return the answer to whether the print request had been accepted by the server and not tell the user if the request succeeded. However, that wasnt a very good solution; wed like the application to track that information for the user automatically. Whats more, the natural extensions to the basic Printer interface dont have our characteristics either. For example, in Chapt er 3 , our list of future requirements included: Users will want to have different priorities for print jobs. Important documents should be moved to the top of a print queue; less urgent jobs should wait until the printer isnt busy. This directly violates our fifth characteristic.

21.1.2 Report-Type Methods

Thinking about the bank example leads to another way these five characteristics can be violated. Suppose we wanted, in our banking application, to support certain types of reports. For example, our loans manager might think the following: Id really like to look at all the checking accounts with a low balance and a large number of transactions. Accounts like that are really good sales prospects for overdraft protection. This functionality, while important, is very different from what weve been implementing. Its computationally expensive, very low-priority in comparison to, say, people or businesses seeking to access their accounts, and it doesnt have a bound on the bandwidth consumed e.g., it could conceivably return all the accounts. In addition, unlike the printer, partial results are possible. A request to print a document takes a long time, and the outcome we want, while a simple boolean value, is completely unknown until the printer finishes. A partial answer to our accounts query, however, is quite reasonable: when the method is halfway finished, we ought to know half of the accounts that we will eventually return. Ill call methods like this report-type methods.

21.2 Handling Printer-Type Methods