Distributed computing - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 486

to a separate object. In the case of a Fortran, C or C legacy code, it is imple-

mented as a set of one or more “native” methods, the subject of Chapter 22.
Recall that we may want to provide a way for the client to send control messages
to the simulation - i.e. messages that affect the calculation while it is running.
For simplicity, we have omitted these from Figure 16.6. If control messages are
present, they would be analogous to collaborations 3.2.1.1 and 4 but in reverse
order. That is, a control message would be sent from Server to SimData
and stored until retrieved by Simulation at a convenient time. In practice,
a convenient time to retrieve the control message is as a return value from each
storeData() call. Obviously the methods for storing and fetching both control
and output data must be synchronized to prevent thread collisions.
Notice that in this scheme the computation is running in its own thread at its
own pace, providing current simulation results to the SimData object as they
are calculated. The client, on a remote machine, is also running at its own pace,
receiving simulation data with each request. The server has no control over how
fast the client requests data, or how fast the network connection between client
and server is. If the computation is time dependent, generating a data set at each
time step, it is very possible for the computation engine to take multiple time
steps between client data requests. On a fast server machine and a slow client or
a slow network, the server could calculate many time steps and produce many
data sets between client data requests. It is up to the designer to decide how to
deal with these “extra” data sets. The simplest solution is to ignore them. The
client always gets the most recent data set, with any intervening data sets lost. If
the client is unhappy about losing some data, then the client needs to request data
more often.
A slightly better approach is to design one of the control messages to permit
the client to tell the server to slow down, perhaps by sleeping a short while
between time steps. A more complicated solution is for SimData to store all
data sets received until a data request is received and then return the entire saved
set at that time. All these details are unimportant to the generic design being
presented here, but they are extremely important once an implementation is begun.
In the sample code provided in Chapter 20, we use the simplest approach of
ignoring the extra data sets. This approach generally seems to work well when
both the client and server are on a fast LAN, but might be unsuitable on a slow
network.
Let us now consider the code that does the actual computation, i.e. the
Simulation and Compute objects in Figure 16.6. First, recall that, using the
Factory Pattern, we are able to support multiple clients, each with its own pri-
vate server object. We see from the discussion above that the “server object” is
really several interacting objects, but the client only sees the interface exposed by
ServerInterface . When there are several clients, there will be several
Server objects, all in the same JVM but running on multiple threads. If the entire
code is written in Java from the ground up, then maintaining thread safety in the

++