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

player.init( gameSet ); // defer init call ...
... // continue identify
return feedback;

// finish identify

} // ... initialize client

12.5 ROF : The RealObject Framework

By following the client call identify and server callback player
.init(gameSet) , the architect has gained a feeling for the client-server di-
alog. The ServerObject was introduced to simplify the actual application
scenario. With the execution framework, the SO is able to buffer client
calls and provide the result without blocking the application flow.
ServerObjectextendsRealObject indicates that it also is a real object
as is the remote object. Both are actors of a real-object application. Tech-
nically, they are counter parts to each other describing the what and how
of the client implementation.
A sketch reveals the ROF , the RealObject framework that is built around
the RealObject

server client

------ ------

RealObject < compare >
OBSERVER /\ \ CONTROLLER
ServerObject < remote API > RealObject
------------------- /\ ------------------------ /\ ---
application: ServerAppObject < remote API > AppObject

WHAT? - ServerPlayer HOW? - ClientPlayer

While the client RO implements actual behavior, the SO is dedicated to
validating the clients' actions. From a programming side, this constellation
can be seen as a generic controller observer pattern. The client RO has full
control over its behavior, while the SO can use its local RO to reflect,
compare, reproduce, and communicate to the server logic.

12.6 ROApp clients: LCPlayerExtends

RealObject

The server construction of a ROApp scenario begins with

LondonChase extends RealObjectsServer

and the associated ROApp clients 3 are constructed with

LondonChasePlayer extends RealObject

3 In the long run, application and client development should be decoupled to gradually
become more and more independent.