Separating the RO Client and the ROApp Server - Programming GPS and OpenStreetMap Applications with Java - page 138

Here are the steps of the client-server dialog written out:

1. The ROApp statically (creates and) locates a registry (and port) on
the host.

2. A ROApp instance is created and exported into a remote object.

3. The ROApp is bound to the registry, which makes it reachable via
URL.

4. The RO connects to the registry and looks up the ROApp via URL.
At this point, the client has a direct connection (reference) to the
server.

5. The RO can cast the ROApp to any remote interface to invoke remote
methods.

6. The RO needs to get the server space and time in order to: instantiate
RO with server space and time.

7. The RO creates a remote client and passes its reference to the server
via login. At this point the server has a direct connection (reference)
to the client and server and client can interact asynchronously.

10.3 ROAF Client Software

With the separation of client and server to different JVM, the RealObject
vision is technically defined. This might appear a little surprising at this
point, since the RO can only provide its latitude and longitude on request.
On the other hand, the mission was to come up with a concrete design|our
minimal implementation is an idealized object.
Technically speaking, all clients in the ROApp framework serve the task
of enriching any real object connected via RealObject with additional in-
formation.
The client software consists of three major components (see Figure 10.1):

1. A GPS unit to manage (UTC) time and (WGS84) space coordinates
and to convert geographic coordinates to metric units (meters). The
GPS software can be driven by a real GPS device or a software sim-
ulation.

2. A RealObject to connect hardware or to implement software to reflect
real-world behavior.

3. A RemoteObject interface as the representative of a RealObject on a
ROApp server. The remote server can inquire the RO coordinates at
any time.