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

If you have already set up the application (see Section 13.2.1), you can
look at the player identification sequence. The RandomPlayer is an ab-
stract LCPlayer , which is a RealObject . The identification can be found in
LCPlayer.identifyPlayer() . The server implementation is in RealObjects
Server.identify(client) .
The (to be returned) ServerInfo is a serializable exchange object
between client and server. It is a record of well-defined server responses to
interactive actions to let the client know what has happened, if the action
was successful, etc. In addition to the predefined int values, the server
can add a human-readable message String . ServerInfo can be a useful
and flexible return value for most client invocations on the

server.

Server callback: ObjectgetIdentity() . Many server applications use a
server-side generator to provide a client ID. In the case of the ROAF,
each RO is required to provide its own unique global identity. In the real
world, people are identified by passports; computers can be identified by a
MAC or IP address; more and more consumer articles (and animals) are
identified by transponders like RFID tags, etc.
To leave the choice open, the java.lang.Object will be used as the most
general (Java) identifier. This general ID can be cast, if client and server
agree on a more concrete identifier. In the long term, a digital fingerprint
like a X.509 certificate should do the trick (and can be approved with
ROApp signatures).
The inner class RealObject.RemoteClient implements getIdentity() re-
quired by the RemoteObject interface without declaring a RemoteException .
The reason for this is that any remote object is exported before it can be
addressed. Internally, the RMI technology creates a hidden object with all
remote methods throwing RemoteException is Generally, if an exception is
thrown in a base class method, the subclass method can throw the same
exception, a more specic exception type, or no throw's clause at all. Nev-
ertheless, the constructor needs to throw the remote exception, and it's
good practice to add the throw's clause.
With the client reference, the server could immediately invoke the
clients methods:

Object ID = null;
try { ID = client.getIdentity(); }
catch (RemoteException e) { return null; }
return ID;

A closer look with a simple sequence diagram reveals a typical server chal-
lenge: