Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
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.
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.