Sometimes we need the server to actually act on the client’s object, not a copy. How can RMI allow a remote method call to modify the original object on the client side?
In RMI, objects that implement the Remote interface are passed by reference. Instead of serializing the object, Java sends a stub that acts as a network proxy. All method calls on the stub are forwarded to the original object in the client’s JVM.
- Client calls: remoteObj.method(remoteObject) where remoteObject implements Remote
- RMI sends a stub for remoteObject instead of serializing it
- Server receives stub as a reference
- When server calls methods on this stub, the calls go back over network
- The calls execute in the client’s JVM on the original object
- The server is actually modifying the client’s object
- This creates the illusion of shared memory across JVMs
- Stub-based: A proxy is sent instead of the actual object
- Shared behavior: Server’s actions affect original object
- Network calls: Every method call on stub goes over network
- Only for Remote objects: Regular objects cannot use this
- Identity preserved: Original object is shared, not copied
- Bidirectional: Communication can happen both ways
- Built from: RMI Remote Method Invocation — mechanism for remote calls
- Built from: EJB Object — is essentially a pass-by-reference stub
- Contrasts with: Pass-by-Value in RMI — normal objects are copied
- Performance overhead: Every call on stub is a network call
- If client JVM goes down, stub becomes invalid
- Only Remote objects can be passed by reference
- Latency: Calls can fail or be slow
- Security: Remote object on client must be accessible