Why do we need separate Remote and Local interfaces for EJB 3.0 session beans

Question

I was wondering why do we need separate Remote and Local intefaces for EJB 3.0 Session beans. I guess most of the time they would both be defining the same contract. Why can

Answer 1

Clients access a session or entity bean through the bean's interfaces. The EJB container generates the interface implementations to enforce and manage this behavior, acting as a conduit for communication between the client and the bean. In versions before the EJB 2.0 specification, all beans were defined and implemented as distributed, remote components. As a result, the two interfaces required of beans were termed the home interface (which, in general, defines life cycle methods) and the remote interface (which, in general, defines functional business methods).

 Internally, J2EE uses the Java Remote Method Invocation over Internet Inter-ORB Protocol (RMI-IIOP) to enable remote, distributed method calls and applications. While this approach provides many benefits, it also generates a large amount of overhead, with a corresponding performance hit as stubs are referenced, parameters go through the marshaling process, and objects are tossed around the network.

 Considerations of performance, practicality, and typical usage in the field resulted in the introduction of local interfaces in the EJB 2.0 specification. As noted, prior terminology referred to the home interface and the remote interface; at this point, depending on which approach is used, local interface and local home interface or remote interface and remote home interface are better terms. Either of the local home or remote home interfaces is referred to as the home interface; either of the local or remote interfaces is referred to as the component interface. This tutorial refers to the interfaces in these terms and uses these conventions for names.

 When using J2EE technologies, it is normal to focus on distributed, or remote, beans, but you should keep the local option in mind, when applicable. It may be surprising to learn that a bean can have local interfaces, remote interfaces, or both. However, the client must write to a specific (that is, local or remote) interface. There are some issues to keep in mind when using local interfaces:

The beans must run in the same VM — they are, after all, local. Parameters are sent by reference rather than being copied, as is the case for remote interfaces and objects. Unexpected side effects can result if you ignore this distinction and do not code accordingly. Typically, the decision to use local or remote access is affected by:

The type of client — Unless you always expect the client to be a Web component or another bean, choose remote access.

Whether the beans are tightly or loosely coupled — If beans depend on each other and interact frequently, consider local access.

Scalability — Remote access is inherently scalable and should be used if scalability is an important factor. With the advent of local interfaces in the EJB 2.0 specification, most sources recommend that entity beans should almost always be based on local access. With local interfaces, most performance issues regarding very fine-grained data access go away. If the client is remote, the standard design pattern has the client use a remote interface to access a session bean, which then acts as a liaison to the entity bean. The session bean communicates with the entity bean through a local interface (from a patterns viewpoint, this technique is called a Session Façade, and it can actually be used in either a remote or local context).