RMI applications are often comprised of two separate programs: a server and a client. A typical server application creates a number of remote objects, makes references to those remote objects accessible, and waits for clients to invoke methods on those remote objects. A typical client application gets a remote reference to one or more remote objects in the server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application. Remote method invocation (RMI) is the action of invoking a method of a remote interface on a remote object. Most importantly, a method invocation on a remote object has the same syntax as a method invocation on a local object.
A RMI (Remote Method Invocation)
can return a remote object as its return value, but one must have a remote
object in order to perform a remote method invocation. So to obtain a remote
object one must already have one. Accordingly, there must be a separate
mechanism for obtaining the first remote object. The Object Registry fulfills
this requirement. It allows one to obtain a remote object using only the name
of the remote object.
Writing a client side application
is the easier part in our entire bidding system. All a client has to do is call
the registry to obtain a reference to the remote object, and call its methods.
All the underlying network communication is hidden from view, which makes RMI
clients simple.
RMI uses a standard mechanism (employed in RPC systems) for communicating with remote objects: stubs and skeletons. A stub for a remote object acts as a client's local representative or proxy for the remote object. The caller invokes a method on the local stub which is responsible for carrying out the method call on the remote object. In RMI, a stub for a remote object implements the same set of remote interfaces that a remote object implements.
When a stub's method is invoked, it does the following:
· initiates a connection with the remote JVM containing the remote object,
· marshals (writes and transmits) the parameters to the remote JVM,
· waits for the result of the method invocation,
· unmarshals (reads) the return value or exception returned, and
· returns the value to the caller.
The skeleton is responsible for dispatching the call to the actual remote object implementation. When a skeleton receives an incoming method invocation it does the following:
· unmarshals (reads) the parameters for the remote method,
· invokes the method on the actual remote object implementation, and
· marshals (writes and transmits) the result (return value or exception) to the caller