Traditional objects live in a single JVM—if you want to call a method on an object running on a different server, you can’t just use object.method(). Network programming is complex: you need sockets, serialization, protocol handling, and error recovery.
A distributed object is a Java object running on a remote server, but it can be accessed as if it were local. The EJB container (via RMI-IIOP) handles all network complexity—the client calls methods on a proxy, and the container forwards the call to the actual object on the server.
- Server side: The EJB object (proxy) is registered with the naming service (JNDI)
- Client lookup: Client uses JNDI to find the home object reference
- Proxy creation: Home object creates an EJB object (proxy) for the client
- Method invocation: Client calls methods on the proxy; proxy forwards via network to the actual bean
- Result return: Bean’s response travels back through proxy to client
- Objects can be accessed across network boundaries (different machines, different JVMs)
- Location transparency: Client doesn’t know or care where the object physically lives
- RMI-IIOP protocol: Standard wire protocol for EJB distributed objects
- Proxy pattern: Client never talks directly to the bean—always through EJB object
- Built from: RMI, JNDI, EJB Naming Service
- Builds into: EJB Object, Home Interface, Distributed Objects
- Related: Middleware (handles network complexity), Location Transparency (clients don’t know object location)
- Contrasts with: Local objects (in-process, no network overhead), Local Home Interface (same JVM, no RMI)
- Network failures: Remote exceptions (
RemoteException) can occur—not present with local objects - Serialization overhead: Parameters must be serializable for network transfer
- Latency: Network calls are 100-1000x slower than in-process calls
- Stateless beans preferred for distributed access: No client-specific state to transfer