In distributed systems, clients need to know where a service lives (machine name, IP address, port). If the service moves to a different server, you must rewrite and recompile all client code. This creates tight coupling between clients and server locations.
EJB achieves location transparency through JNDI (Java Naming and Directory Interface). Clients look up beans by a logical name (nickname) like "HelloHome", not by physical address. The JNDI naming service maps this nickname to the actual Home Object reference—change the server, update JNDI, client code stays the same.
- Deployer binds nickname: During deployment, container registers Home Object with JNDI using a nickname (e.g.,
"HelloHome") - Client looks up by nickname:
ctx.lookup("HelloHome")— no machine names in client code - JNDI resolves location: JNDI service (LDAP, COS Naming, or in-process) finds the actual object reference
- Server moves?: Just update JNDI — client code unchanged
- “Write Once, Run Anywhere”: Client code portable across different server deployments
- Naming services: JNDI supports LDAP, CORBA Naming, in-process JNDI trees
- Vendor-independent: The lookup code is standard JNDI—works on any EJB container
- Purchased components: If you buy pre-written beans (no source), location transparency is essential—you can’t rewrite them
- Built from: JNDI, Home Interface (what gets looked up)
- Builds into: Distributed Objects (clients can access beans anywhere)
- Related: Middleware (JNDI is a middleware service)
- Contrasts with: Hard-coded addresses (client breaks if server moves)
- JNDI properties still machine-specific:
Context.PROVIDER_URLspecifies naming service location—but this is configuration, not code - Network partition: If JNDI service is unreachable, lookup fails (even if bean is running)
- Nickname collisions: Two beans with same JNDI name cause deployment errors