Client Server Architecture - Programming GPS and OpenStreetMap Applications with Java - page 146

11.4.1 External Configuration with Property Files
In order to avoid hard-coded relations, the server's parameters are stored
in an external properties file, which is loaded via command line. If the
properties file does not exist, it will be created. In practice, the properties
help to make the server not abstract by supplying mandatory parameters,
like a bounding box. The path and file must be specified as command
line arguments, when launching the ServerEngine along with the policy
le (VM argument) to set the RMI security manager|as congured in the
server batch file LondonChase.bat .
The class ROServerProps is a wrapper class for java.util.Properties

TheJavaTutorial>EssentialClasses>ThePlatformEnvironment

Properties are configuration values managed as key/value
pairs. In each pair, the key and value are both String values.
The key identifies, and is used to retrieve, the value, much as
a variable name is used to retrieve the variable's value.

This class extends a java.util.Hashtable to hold properties as pairs of keys
and values and has the ability to keep them persistent in the file system.
The class is initially designed to hold the parameters for the server's host
portname values. Once in place, the designer can easily add values dur-
ing the modeling process. The class ROServerProps resides in the common
package to be extended by server, application, and client:

ROAppProps extends ROServerProps

Note that interfaces can also be used to store common information, like
server name, port, and maximum population, and they can provide Helper
classes. Also, interfaces can be part of a hierarchy, like classes.

11.5 The RealObjectsServer

The main purpose of the RealObjectsServer , or ROServer, is the collection
of RO clients and the implementation of methods to serve their invocations.
By design, any ROApp should extend the ROServer to manage a num-
ber of remote ROs. Note that the server is coded against RemoteObject s,
not RealObject s nor their extending implementations. The extending real-
object application should be able to override the methods to modify or
enrich functionality according to its \rules." Extending classes can be seen
as programming in layers, and it makes sense to create a class for each
semantic layer early in the design and modeling process.