A client hosting a distributed object
Consider the following definitions:
- A server is an application that "hosts" a distributed object.
- A client is an application that "uses" a distributed object.
- A distributed object is the only entity that can receive a remote
method invocation.
- If a client wants to receive a "callback" from a distributed object,
it must "host" a distributed object that can receive the remote method
invocation.
- A server is an application that "hosts" a distributed object.
- The distinction between a server and a client has just become
circular.
This example has a server that hosts a "Barney" instance of the
PersonTalk distributed object class (line 41), and, a
client that binds to the remote "Barney" instance (line 58) and hosts a
local "Fred" instance (line 59). Once they each hold a "reference" to
the other object (to be discussed next), either instance can be told to
talk() (lines 60 and 61) and the other instance is
subsequently sent the message listen() (line 29). The
order in which the output occurs in the two different windows is lines:
46, 47, 64, 65, 48, 49, 66.
Let's see how each instance comes to hold a reference to the other.
Line 41 causes the 1-argument constructor at line 15 to be invoked.
Line 58 returns a remote reference to the "Barney" instance. Line 59
causes the 2-argument constructor at line 19 to be invoked. "Fred" can
now message "Barney" with the remote reference that it holds (lines 21
and 25). "Fred" sends the meet() message to "Barney",
passing its "identity" as an argument. "Barney" can now message "Fred"
with the remote reference that it holds (lines 22 and 25).
The previous example only introduced the topic of "security managers"
(step 5). Java insists that a security manager be in place to oversee
the segment of its security architecture associated with dynamic class
loading. Applets are automatically configured with a security manager
to make sure that the applet code does not do any harm. But,
applications do not have a default security manager, so one must be
explicitly created when RMI is in use (see lines 39 and 55).