The next methods we identified were report-type methods. Recall my original description of report-type methods:
[They’re] computationally expensive, very low-priority in comparison to, say, people or businesses seeking to access their accounts, and it doesn’t have a bound on the bandwidth consumed...In addition, unlike the printer, partial results are possible.
These method calls have three major problems:
There’s a potential for a long delay while the server fully computes an answer.
They’re very “bursty” in terms of bandwidth consumption. That is, they have long periods where no bandwidth is used at all, followed by a period of intense bandwidth consumption.
There’s a potential for a long delay while serialization and deserialization occur.
This third problem is one we haven’t really discussed yet. Suppose, for example, we have a system with the following remote method:
public Account getAllAccountsWithBalanceOver(Money minimumOwed);
When a client calls this method, the following occurs:
The server figures out the list of people who owe money and returns it to the skeleton.
The RMI runtime serializes the instance of
sends it over the wire.
The RMI runtime deserializes the instance of
then returns it (to the stub).
The client code gets the instance of
One of the helpful aspects of serialization, along with being stream-based, is that the second and third steps actually occur simultaneously. That ...