13.4 Overview of RMI

 < Day Day Up > 



13.4 Overview of RMI

The purpose of using RMI is to allow objects that exist on remote computers (or in a separate process on the same computer) to be accessed as if they are local objects. This section describes the process that is involved in creating an RMI program. It first describes the components required to run an RMI program and then describes the steps for making a program run using RMI. A simple example of a program that illustrates these concepts is given in Section 10.5.

The simplest type of RMI program is a client/server program. A client/server program is really a program with two separate programs. The first is the server that provides a resource to a client program, and only runs in response to requests from the server; thus, the server is normally a component. The second is the client program that implements the program to solve the user's problem. Because these two pieces are separate programs, they need some mechanism to pass messages back and forth. If this mechanism supports messaging over a network, the program can be distributed to remote computers, as in RMI.

The five basic components required to run this type of program using RMI, as illustrated in Exhibit 1, are:

  1. Server, which is simply a passive object that sits on a remote computer and waits for requests to come to it from client computers

  2. Client, which is an active process and makes requests of the server by calling the methods of the server using the RMI protocols

  3. rmiregistry, which is a program that allows the client to find server objects with which it can communicate

  4. Skeleton class, which is a Java class used by the server to handle the communications with the client

  5. Stub class, which is a Java class used by the client to handle the communications with the server

Exhibit 1: Components That Make Up RMI

start example

click to expand

end example

RMI uses these classes as follows. First, rmiregistry is run; rmiregistry is used to store a handle to the server object so that the client can retrieve these handles and begin communicating with the server. Once rmiregistry is running, the server calls the method Naming.rebind to register a handle that is associated with a name for this server object. The Server object then suspends its execution and waits for a client object to access one of its methods. This process is shown in Exhibit 2. When the server is running and registered with rmiregistry, the second step is for the client program to start and to call Naming.lookup with the name of the server object. If the name of this object exists in rmiregistry, the handle for the server object registered with the name is returned. This is shown in Exhibit 3. When the client has the handle for the object, the client and the server communicate using the stub and skeleton classes (see Exhibit 4). Note, however, that in this scenario all messages must originate from the client when it makes calls to methods on the server.

Exhibit 2: Registering the Server Object

start example

click to expand

end example

Exhibit 3: Retrieving the Handle for the Server Object

start example

click to expand

end example

Exhibit 4: Client and Server Communicating

start example

click to expand

end example



 < Day Day Up > 



Creating Components. Object Oriented, Concurrent, and Distributed Computing in Java
The .NET Developers Guide to Directory Services Programming
ISBN: 849314992
EAN: 2147483647
Year: 2003
Pages: 162

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net