Remote Versus Local Interfaces
One of the most significant improvements in the EJB 2.0 specification over previous versions is the inclusion of local interfaces as well as remote interfaces.
All beans that you have seen on previous days have provided only a remote interface. That is, both their home and remote interfaces have extended from javax.ejb.EJBHome and javax.ejbEJBObject, both of which, in turn, extend the java.rmi.Remote interface.
This ability to invoke methods on a bean without regard for its location is crucial for Session beans, but for Entity beans it is less useful, even positively harmful. Very often, a client must deal with many Entity beans to transact some piece of work, and if each of those Entity beans is remote, this will incur substantial network traffic. There is also the cost of cloning any serializable objects to enforce the required “pass-by-value” semantics.
Even more frustratingly, the client of the Entity bean may well be a Session bean. Indeed, it is generally considered bad practice to use anything other than a Session bean to interact with Entity beans. More often than not, this Session bean will be co-located (running in the same JVM) as the Entity beans that it is using. The EJB container is obligated to make all Session-to-Entity bean calls via the network and to clone all serializable objects, just because the Entity beans are remote.
By now, you probably have guessed what local interfaces are. They are alternative non-remote interfaces that the Entity bean can specify. Again, the home and proxy idea is used, with the home interface being extended from javax.ejb.EJBLocalHome and the proxy for the bean extending from javax.ejb.EJBLocalObject. Otherwise though, these are regular Java interfaces, and the normal “pass by reference” semantics for objects passed across these interfaces apply.
Note
“Pass by reference” is a simpler way of saying “object references are passed by value.”
An Entity bean can provide a regular home/remote interface, or it can provide a local-home/local interface. Indeed, there is nothing to prevent an Entity bean from offering both interfaces, although any clients using the remote interface would incur the performance costs already noted. Local interfaces are not specific to Entity beans either; Session beans can also provide local interfaces. For Session beans (especially stateless Session beans), there might well be reason to offer both a remote and a local interface. In general, it would be expected for the two interfaces to offer the same sorts of capabilities, although there is nothing in the EJB specification that enforces this.
Figure 6.3 shows the two sets of interfaces that a bean can provide.
Figure 6.3. EJBs can have local and remote interfaces.
In both cases, the EJB home/local-home and proxy objects take responsibility for security (Day 15, “Security”) and transactions (Day 8, “Transactions and Persistence”), while home/remote interfaces also make the physical location of the bean transparent to the remote client.
Local interfaces are more than just a performance boost for EJBs though, they are the cornerstone on which container-managed persistence and also container-managed relationships (CMR) are founded. You will learn about these in detail tomorrow.
In the case study and examples for today and tomorrow, you will see that the Entity beans define only a local interface.