| CONTENTS | PREV | NEXT | INDEX | Designing Enterprise Applications with the J2EETM Platform, Second Edition |
The EJB 2.0 specification introduces a local client view for session and entity beans, in addition to preserving the remote client view defined by the EJB 1.1 specification. As described in the previous sections, a session or entity bean can implement a local home interface and local component interface instead of (or in addition to) a remote home interface and remote component interface.
An enterprise bean defines a remote client view when it is designed for use in a distributed environment; that is, when its clients may potentially reside in a different JVM. Each method call on a bean's remote home or component interface results in a remote method invocation. Although necessary for distributed systems, remote method invocations have a certain amount of network overhead and can have performance limitations. In addition, the overhead of a remote invocation occurs even if the client and the bean are located on the same JVM. This can be particularly problematic in situations that require fine-grained access to objects. (See Section 5.7.3 on page 158 for a more complete discussion of how to handle fine-grained access.) While these limitations are unavoidable for distributed systems, proper design can reduce their impact.
Use of a local client view avoids the performance overhead of remote method invocation. To use a local client view, the enterprise bean and its client must be guaranteed to be located on the same JVM. By implementing a local home interface and local component interface, co-located enterprise beans can make direct, local method calls on the methods of other beans and avoid the remote invocation overhead. It is thus feasible to implement fine-grained access between beans using local interfaces.
In certain situations it is preferable to use a local client view (local home and component interfaces) for an enterprise bean. In other situations, a remote client view (remote home and component interfaces) is more appropriate. Keep in mind that most of these considerations apply to session beans as well as entity beans, because both can implement local and remote client views.
- Use remote interfaces when the distribution of components (or their potential distribution) requires location independence in the deployment environment.
- Use remote interfaces when loose coupling between a bean and its client is desirable.
- Use remote interfaces to ensure that parameters are passed between a bean and a client using pass-by-value semantics rather than pass-by-reference semantics. Passing parameters by value prevents the bean from inadvertently modifying the client data, as the bean gets its own copy of the data separate from the client's copy. With local interfaces, which use pass-by-reference semantics, a reference to the same copy of the data is passed between the client and the bean. Both the client and the bean view and act on the same single copy of the data. Any actions the bean performs on the data affects the client's view of the data.
- Use remote interfaces for entity beans that require only coarse-grained access to the underlying data objects.
The use of local interfaces for enterprise beans may be better suited to some applications. Consider using local interfaces for session and entity beans under these circumstances:
- Use local interfaces for a session or entity bean if they are required to be located in the same container as their clients. For local interfaces to be used, the session or entity bean must be deployed in the same JVM as the client.
- Use local interfaces when tight coupling between a client and a bean is desirable.
- Use local interfaces when pass-by-reference semantics is preferable for parameter passing between a client and the bean. This is typically done to achieve higher performance by avoiding the overhead of object copying.
- Use local interfaces for entity beans that expose fine-grained access to the underlying data objects.
An entity bean that uses local interfaces is referred to as a lightweight entity bean because it avoids the performance costs of remote interfaces.
An entity bean is generally used with a local view. If the application is such that a remote view is necessary, the developer can use a session bean with a remote client view as a facade to entity beans with local views. See Section 5.7.2 on page 157 for more information.
Local interfaces offer other advantages for entity beans. Local interfaces enable entity beans with container-managed persistence to participate in container-managed relationships with other entity beans. With container-managed relationships, the EJB container manages the persistent relationships between entity beans, much like it manages the persistent state of entity beans. Container-managed relationships are described further in Section 5.4.2.2 on page 146.