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

with the naming service, the naming service then knows how to locate that object
by name when a lookup() request is received.
16.6 Server details
So far we have learned enough UML to illustrate the Factory Pattern and the
naming service. We understand the value of the Factory Pattern as a technique to
support multiple clients wanting to access the same server, and we know how a
client object obtains a reference to its own private server object. But exactly what
the server does and how the client interacts with it is yet to be determined. Of
course, the behavior of the client and server is highly dependent on the problem
at hand. Below we develop a fairly generic client/server interaction that can be
used for typical scientific computing problems in which the main computational
portion of a problem is performed on a server. As explained previously, the
reason for moving the computation to a server might be because of performance
concerns, it might be because the computation involves the use of legacy (non-
Java) code, or it might be a way to protect intellectual property when a code's
services are made available over the Internet. The reason for using distributed
computing is not really important to the discussion at hand. We're just going to
learn what a server does in a generic client/server application.
In the simplest possible client/server interaction, the client merely prepares
input, calls on the server to perform some calculation, and displays the results.
This technique might be called “batch mode” and, because it is quite uninteresting,
we do not discuss it further.
More interesting is an interactive simulation in which the client prepares the
input and receives output on a continuous basis as the calculation is running,
perhaps with graphical display of the results. A time-dependent calculation is
a good example. Such an arrangement requires the server to output the results
in a periodic fashion and the client to retrieve those results and display them
somehow.
The server comprises all the code necessary to perform the simulation and
communicate with the client. In a simple simulation, the server class typ-
ically exposes just a few public methods to the client - methods such as
initialize() , receiveInput() , and retrieveData() . There are, of
course, other methods internal to the server that are not publicly exposed. In a
more complex example, the server would expose additional methods to support
the client. These methods might involve storing and retrieving user preferences on
the server, retrieving data needed in the simulation from a server-side database,
merging user input with static data on the server, etc. The purpose of all these
publicly exposed methods is to permit the client to cause the required operations
on the server to occur when needed. It is convenient to group all of the pub-
licly exposed remote methods into a Java interface that the actual server class
implements. We call this interface ServerInterface . Methods internal to the