Wizard API updated!
Tim Boudreau has released a new version of the Swing Wizard library (version 0.997) that fixes the WizardException bug reported in JavaWorld's recent Open Source Java Project profile. The article's examples have been reworked to test out the new, improved WizardException. Thanks, Tim, for this helpful fix!
Open Source Java Projects: The Wizard API

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Get smart with proxies and RMI

Use dynamic class loading to implement smart proxies in RMI

By M. Jeff Wilson, JavaWorld.com, 11/10/00

Java Remote Method Invocation (RMI) gives clients access to objects in the server virtual machine (VM) in one of two ways: by reference or by value. To access a remote object by reference, the object must be an instance of a class that:

  • Implements an interface that extends java.rmi.Remote
  • Has a properly generated RMI stub class that implements the same interface
  • Is properly exported to allow incoming RMI calls


The interface implemented both by that class and its stub is referred to as the object's remote interface, and the methods declared in that interface can be invoked remotely. Clients only need to know about the remote interface. When they request a reference to a remote object that implements that interface, RMI substitutes an instance of the stub class and returns a copy of that stub to the client. Method calls on the RMI stub are forwarded to the remote object, which is still in the server VM. The substitution of a stub for the remote object happens automatically -- you just need to ensure that the server object implements the remote interface and is properly exported.

With pass-by-reference, all methods on the object are remote calls. That lets the remote object have access to the server's resources and services and, because multiple clients can talk to the same object on the server, changes made to that object's state by one client are visible to all clients. However, all the problems of network communications -- latency, disconnects, and time-outs, for example -- still apply.

Clients access an object by value when a remote call results in a return value of an object that implements java.io.Serializable instead of java.rmi.Remote. In that case, the returned object is serialized, sent to the client's VM, and deserialized, instantiating a copy of the object in the client's VM. Methods invoked on this copy are just like any other Java method -- they execute locally, without communicating with the server.

For pass-by-value, none of the network communication problems occur; however, the copy does not have easy access to server-side resources and services. Further, each time a client makes the remote method call to get the object, a new copy is created in the client VM. Since each copy maintains its own state, the changes made in one object cannot be seen by any other object.

Situations may arise that require a blend of those two strategies: an object in which some methods execute locally, without network latencies and other problems, and some methods that execute on the server. Ideally, some parts of the object's state could be shared, so that all clients could see changes, and other parts of the state kept private. In the CORBA world, that problem is solved with a construct called a smart proxy.

Smart proxies

A smart proxy is a class, instantiated in the client VM, that holds onto a remote object reference. It implements the object's remote interface and typically forwards most of the calls on the interface to the remote object, just like an RMI stub. However, a smart proxy is more useful than the RMI stub in that you can change the behavior of the remote interface to do more than forward calls to the remote object. For instance, a smart proxy can locally cache state from the remote object to avoid the network overhead on every method call.

1 | 2 | 3 |  Next >
Resources