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

As any object, the application can work with states reflecting the current
status and these can be influenced, as, for example, setting the status to a
radical GAMEOVER state.

11.7.4 A Fallback Scenario for getGPSinfo() .

So far, the RealObject was only used in playback mode. If the RealObject is
actually running on (or receiving from) a (Java-enabled) GPS device, like
a modern smart phone, the virtual GPSunit is actually fed from this device
via hardware interfaces (drivers). On the server side, the ServerObject can
not distinguish the client's mode and simply receives the information as if
it is all coming from a GPS device.
The SO remote concept provides a notch for a \fallback strategy" 2 in
case the connection gets lost similar to a real GPS device. The effects can
be seen on GPS traces with bad positioning of way points due to obscured
satellites. A validation against a street geometry always needs a certain
tolerance. An application could also implement a tolerance to connected
RO clients, which again is a realistic scenario. If you travel with your smart
phone, you can record a trace oine and connect to a server every once in
a while to submit (fragments of) the trace or the current position|while
remaining an actor in a scenario.
This constellation can be implemented easily. The SO applies the re-
mote method getGPSinfo to check where the client is and setGPSinfo to
synchronize SO and RO location. If the RO is oine, the SO can guess
the RO position by extrapolating the current position from the last-known
position, direction, and speed and return the SO.GPSinfo to the server logic.
This fallback strategy is plausible and nothing more. It is similar to letting
go of your steering wheel|in a curve! The car is driven by inertia and hits
anything in the way.

Remote concept catch. All in all, the remote concept is very convenient.
Nevertheless, it does not cover every concurrent case, and the programmer
has to be aware of typical pitfalls. No matter what kind and what size of
executor service you might apply to your application, keep in mind that
threads are always competing due to a restricted number of CPUs.
The sequence diagram on page 149 indicates that the server.identify
method can never end without a prior return of client.getIdentity . Dur-
ing development, one should always be aware of sequential methods that
rely on one other. Since the executor framework has different implementa-
tions, a simple working queue can get problematic, if a method is submitted

2 To satisfy the RO vision (page 18): every RealObject must provide a location . . . at
any time.