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

Simulation and Compute objects is straightforward. In the case of a legacy
code, however, particularly codes written in Fortran, ensuring thread safety is
more difficult because Fortran codes are almost never reentrant due to their use
of global variables in the form of Fortran common blocks. This situation is one
reason we broke out Compute as a separate object in the collaboration diagram
above. If several Server objects exist, each of which creates Simulation
objects, each of which uses its own instance of the Compute object to perform
the legacy calculations, then the legacy Fortran code will almost surely cause
data corruption when it attempts to access global variables. The reason is that
multiple clients accessing the single Fortran image will overwrite each other's
global variables, resulting in incorrect answers for at least one of the clients at
the very best. More likely, an outright core dump could result.
The best solution for such legacy codes is often to run the legacy code in
a separate OS process. Separation between OS processes is maintained by the
operating system, with each process getting its own memory map. In that way,
the Fortran images are isolated from one another, preventing data corruption as
they internally access their global variables. Some kind of inter-process commu-
nication (IPC) is required in order for each Simulation object to communicate
with its per-client Compute process. Since the spawning of a new process is
an asynchronous task, special care must be taken to enforce the synchronous
nature of the interaction. Notice that the compute() call (i.e. sequence 3.2 in
Figure 16.6) is synchronous. It does not return until the computation is complete.
But if the computation is to run in a new process, the method call that spawns the
child process returns immediately. This issue can be solved through careful use
of IPC.
Another option to protect legacy code is for ServerFactory to create each
Server in a new per-client OS process (i.e. the entire Server is in a new
process, not just the Compute object). Then the object returned to the requesting
client during the getInstance() method (i.e. sequence 2 in Figure 16.4) will
in fact be running in a separate process instead of as a separate thread within the
same JVM.
16.6.3 UML class diagrams
We described earlier the grouping of the server's publicly exposed methods into
aJava interface. To illustrate this grouping, we now introduce the UML class
diagram. A class diagram shows classes along with their variables and methods
(called attributes and operations , respectively, in UML) and how those classes
are related to one another. The collaboration diagrams seen previously deal with
objects, not classes, and the sequence-ordered messages among them. By contrast,
class diagrams deal with static relationships among classes. A class in a UML
class diagram is shown as a box divided horizontally into three sections. The
top section is the class name, the middle section contains the attributes, and