Deciding on Remote or Local Access

<< Local Clients | Web Service Client >>

Deciding on Remote or Local Access

The local business interface defines the bean's business and life cycle methods. If the bean's
business interface is not decorated with @Local or @Remote, and the bean class does not specify
the interface using @Local or @Remote, the business interface is by default a local interface. To
build an enterprise bean that allows only local access, you may, but are not required to do one of
the following:

Annotate the business interface of the enterprise bean as a @Local interface. For example:

@Local

public interface InterfaceName { ... }

Specify the interface by decorating the bean class with @Local and specify the interface
name. For example:

@Local(InterfaceName.class)

public class BeanName implements InterfaceName { ... }

Deciding on Remote or Local Access

Whether to allow local or remote access depends on the following factors.

Tight or loose coupling of related beans

: Tightly coupled beans depend on one another.

For example, if a session bean that processes sales orders calls a session bean that emails a
confirmation message to the customer, these beans are tightly coupled. Tightly coupled
beans are good candidates for local access. Because they fit together as a logical unit, they
typically call each other often and would benefit from the increased performance that is
possible with local access.

Type of client

: If an enterprise bean is accessed by application clients, then it should allow

remote access. In a production environment, these clients almost always run on different
machines than the Application Server. If an enterprise bean's clients are web components or
other enterprise beans, then the type of access depends on how you want to distribute your
components.

Component distribution

: Java EE applications are scalable because their server-side

components can be distributed across multiple machines. In a distributed application, for
example, the web components may run on a different server than do the enterprise beans
they access. In this distributed scenario, the enterprise beans should allow remote access.

Performance

: Due to factors such as network latency, remote calls may be slower than local

calls. On the other hand, if you distribute components among different servers, you may
improve the application's overall performance. Both of these statements are generalizations;
actual performance can vary in different operational environments. Nevertheless, you
should keep in mind how your application design might affect performance.

If you aren't sure which type of access an enterprise bean should have, choose remote access.
This decision gives you more flexibility. In the future you can distribute your components to
accommodate the growing demands on your application.

Defining Client Access with Interfaces

The Java EE 5 Tutorial · September 2007

638