Things are fairly simple when all the web app components (model, view, controller) are on the same server, running in the same JVM. It’s just plain old Java—get a reference, call a method. But Kim and Rachel now have to figure out what to do when their model components are remote to the web app.

JNDI and RMI, a quick overview

Java and J2EE provide mechanisms that handle two of the most common difficulties that arise when objects need to communicate across a network—locating remote objects, and handling all the low level network/IO communications between local and remote objects. (In other words, how to find remote objects, and how to invoke their methods.)

JNDI in a nutshell

JNDI stands for Java Naming and Directory Interface, and it’s an API to access naming and directory services. JNDI gives a network a centralized location to find things. If you’ve got objects that you want other programs on your network to find and access, you register your objects with JNDI. When some other program wants to use your objects, that program uses JNDI to look them up.

JNDI makes relocating components on your network easier. Once you’ve relocated a component, all you need to do is tell JNDI the new location. That way, other client component only need to know how to find JNDI, without knowing where the objects registered with JNDI are actually located.

RMI in a nutshell

RMI stands for Remote Method Invocation, a mechanism that greatly simplifies the process of getting objects to communicate across a network. Turn the page and we’ll do a quick refresh, in case you’re a little rusty. Why think about RMI here? Because it will help make two of the J2EE design patterns easier to understand and appreciate.