Rolling out a ROApp - Programming GPS and OpenStreetMap Applications with Java - page 169

later development cycles, the real public-transportation schedules could be
added to make the game more realistic, and then, the scenario can become a
candidate for a real-world application. Actors (and their developers) could
access schedules via the internet as a third-party source. Players in the
United States would have to play with the adjusted time from London.
As a general design rule, a ROApp should not be set to real time to
indicate that it is not trying to reflect the real world. Therefore, the default
ROServer constructor is standardized to the beginning of this millennium,
which is convenient to tell the server uptime. With namehostport it is
easy for RO clients to look up a server and find out the where and when of
a scenario:

String rmiURL = "rmi://" + host + ":" + port + "/" + name;
Remote connection = RMI.lookupRMIURL( rmiURL );
RemoteObjectsServer
roServer = (RemoteObjectsServer) connection;
RemoteObjectsApplication
roApp = (RemoteObjectsApplication) connection;
serverBox = roApp.getServerBox();
serverTime = roApp.getGPSinfo();

12.3 Server Architecture

Although the ROApps support the ROAF, there is no RealObject
Application class in the roaf.roa package! There are simply too many
(actually an infinite number of) ROApp candidates in the real world. You
decide which part of the world you would like to model, and how. At de-
velopment time, the ROServer can not account for all future ROApps. Yet
the ROServer is the place to implement controlling mechanisms (supported
by scientific laws) as they occur.

12.3.1 Components and Responsibilities
In the previous chapter, a rough client-server architecture was developed.
With the concrete application LC, the architect can refine the right-hand
side of the four-layer architecture shown in Figure 12.1. The language
analysis of LC (see Section 12.2.1) provides the basic components for the
scenario. The components of Figure 12.1 provide an overview of server
and application responsibilities as well as subcomponents accounting for
separate tasks. On the left-hand side, we see that the server is open for
remote client objects like cars (taxis), busses, trains (subways), and houses
(or stations). The client candidates are collected in the ROBox after they
have identified themselves. Next the server can class -ify the clients to
familiar classes. While the ROServer code should only use the (abstract)
base classes defined in the roaf.ros package, the ROApp can use the final