03-11-2012, 02:24 PM
Remote Method Invocation (RMI)
RMI Architecture.docx (Size: 80.42 KB / Downloads: 27)
RMI Architecture
RMI’s purpose is to make objects in separate JVM’s look alike and act like local objects. The JVM that calls the
remote object is usually referred to as a client and the JVM that contains the remote object is the server.
One of the most important aspects of the RMI design is its intended transparency. Applications do not know
whether an object is remote or local. A method invocation on the remote object has the same syntax as a method invocation on a local object, though under the hood there is a lot more going on.
• In RMI the term “Server” does not refers to a physical server or application but to a single remote objecthaving methods that can be remotely invoked.Similarly the Term “Client” does not refer to a client m/c but actually refers to the object invoking a remote method on a remote object.
• The same object can be both a client and a server. Although obtaining a reference to a remote object is somewhat different from doing so for local objects. Once we have the reference, we use the remote object as if it were local. The RMI infrastructure will automatically intercept the method call, find the remote object and process the request remotely. This location transparency
even includes garbage collection. A remote object is always accessed via its remote interface. In other words the client invokes methods on the
object only after casting the reference to the remote interface.
Parameters in RMI
You have seen that RMI supports method calls to remote objects. When these calls involve passing parameters or accepting a return value, how does RMI transfer these between JVMs? What semantics are used? Does RMI support pass-by-value or pass-by-reference? The answer depends on whether the parameters are primitive data types, objects, or remote objects.
Parameters in a Single JVM
First, review how parameters are passed in a single JVM. The normal semantics for Java technology is pass-by-value. When a parameter is passed to a method, the JVM makes a copy of the value, places the copy on the stack and then executes the method. When the code inside a method uses a parameter, it accesses its stack and uses the copy of the parameter. Values returned from methods are also copies.
When a primitive data type (boolean, byte, short, int, long, char, float, or double) is passed as a parameter to a method, the mechanics of pass-by-value are straightforward. The mechanics of passing an object as a parameter are more complex. Recall that an object resides in heap memory and is accessed through one or more reference variables. And, while the following code makes it look like an object is passed to the method println()
in the mechanics it is the reference variable that is passed to the method. In the example, a copy of reference variable s is made (increasing the reference count to the String object by one) and is placed on the stack. Inside the method, code uses the copy of the reference to access the object.
Remote Object Parameters
RMI introduces a third type of parameter to consider: remote objects. As you have seen, a client program can obtain a reference to a remote object through the RMI Registry program. There is another way in which a client can obtain a remote reference, it can be returned to the client from a method call. In the following code, the BankManager service getAccount() method is used to obtain a remote reference to an Account remote service.