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

server that are not exposed to the remote client appear in the server class itself but
not in ServerInterface . This grouping makes explicit the separation of the
publicly exposed client-callable methods and the internal methods. We illustrate
this separation graphically later when we introduce the UML class diagram.
What we have so far been calling the server class is really just the front
end to everything that the server does. In reality, in an object-oriented solution,
the “server” consists of multiple objects interacting in such a way to provide
the services advertised to remote clients in ServerInterface . Internally, the
workings of the server are necessarily more complex, as described next.
16.6.1 Model-View-Controller design pattern
Another useful design pattern that we employ is the Model-View-Controller
(MVC) design pattern [15]. The Java Foundation Classes (aka Swing) use the
MVC pattern. As a reminder, in MVC the model is the data. In our distributed
computing problem, it is the data generator - i.e. the part of the calculation that
creates the data - or what we've previously called the server. The view is the
user, or consumer, of that data - generally thought of as the presentation to the
human user, or the graphical user interface seen by the user. The MVC controller
is the component that manipulates the data and the view. For example, the user
controls the calculation by providing input through the GUI and also, perhaps, by
adjusting the graphical output - choosing the variables to observe, for instance.
This latter choice may involve communicating to the server which variables to
calculate. In any case, it is clear that the user actually does control the server.
From the client's point of view, the client provides both the view and the
controller to the user, and the server is the model. That is, the client both consumes
the data that the server generates and also controls the behavior of the server. We
consider the client's implementation in the next chapter. For now, we concentrate
on the server.
Even though the server represents just the MVC model to the client, it is
also convenient to design the server's internal architecture using an MVC design
pattern. The entire server is composed of various parts. The most important part,
of course, is the scientific calculation that the server provides. If we break the
server down into its various components, the calculation component can be called
the “compute engine.” Since this is a client/server system, we must assume that
the client application is remote, connected via the Internet. Because of network
delays, or because of client-side presentation costs, the client may not be able to
request and process data as fast as the compute engine generates it. Therefore,
the data that is generated must be stored somewhere until the client requests it.
The component that stores the calculation data is obviously the MVC data model.
The ultimate consumer of the data is the client, but recall that the client obtains
the data by calling a method on the server - referred to as retrieveData()
above. When the client calls retrieveData() , the front-end server object that