Distributed computing – putting it all together - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 551

20.3 Server interfaces
We begin by implementing the server design from Chapter 16. Since we are
writing both the client and the server, and since we assume that we do not need
to support non-Java clients, we implement the server using RMI. Following the
pattern of the rmi18 and cor19 packages, we use the javatech.all20 pack-
age for this application. The “ 20 „ part indicates Chapter 20 while “ all „ is
intended to be a mnemonic abbreviation for “putting it all together,” the title of this
chapter.
20.3.1 The factory interface
We first need to define the interfaces for the factory and server objects. From
Chapter 16, both interfaces are quite simple. The factory has only one method,
getInstance (id) ,which returns a reference to an object that implements
the server interface when given an ID parameter.
Recall that the purpose of the factory pattern is that multiple clients can call
the factory, each receiving its own private server object. The ID parameter serves
to distinguish clients from one another. If the server needs to store any temporary
data during runs, then the ID parameter is a good way for the server to keep data
from each client separate from other clients, most likely by creating a subdirectory
on the server side named with the client's ID. The server might also keep log files
in that subdirectory logging the progress of the calculation. If an error occurs on
the server, then the log files can be examined during debugging. In this case, the
ID might be a project name or a run number - anything that the client can supply
as identifying information for the run so that the log files on the server side can
be identified. Note that it is not essential to the design that the client supply the
ID. The factory could simply make up a unique ID for each client using, say,
the millisecond clock time. Debugging, however, is often easier if the client has
supplied a meaningful ID of some sort.
If the server uses any proprietary information, then the ID might be a username
or even a username/password pair used to authenticate the user and authorize
that user's access to the proprietary data. For security purposes, the password
should be encrypted since the client/server communication will be occurring
over the Internet. Encryption and user authentication and authorization are very
important topics but beyond the scope of this topic. But not at all beyond the scope
of Java! See, for example, the Java Authentication and Authorization Service
(JAAS)[1], the Java Cryptography Extension (JCE)[2], and the Java Cryptography
Architecture (JCA)[3].
While a general design might require three parameters - a username, an
encrypted password, and a project name, we implement this example assum-
ing that a single string specifying a project name is given as the ID. In practice,
we won't store any data files on the server side in this example, so we won't
actually do anything at all with the ID parameter except log it.