Deciding Whether to Use a Local or Remote Client

Because the local component interface is new to the EJB 2.0 Specification, we can't really say that there's years of practical experience that you can leverage when determining whether an enterprise bean should be exposed to a local client view or a remote. It really depends on many different factors, all of which are specific to your particular application.

However, there are some truths about each type of component interface that might help provide some guidelines when trying to decide. The following sections describe some of the more important characteristics about each type of component interface.

The Local Model Normally Will Provide Better Performance

Remote method calls typically are very expensive and usually are performed with coarse-grained access . Course-grained access is where objects attempt to expose a larger set of data with a smaller number of method invocations. This is done when the cost of invoking the method is very expensive, normally due to network- related issues.

Because local calls are within the same JVM, they can take advantage of pass-by-reference and not suffer the performance disadvantages of pass- by-value semantics.

Remote calls also can suffer network latency, overhead of the client and server software stacks, argument copying, and other RMI issues. Local clients don't have to deal with any of these problems and, therefore, typically perform better.

Fine-Grained Access Is Better with the Local Model

As mentioned previously, remote method access can be very expensive. Therefore, a remote client typically will want to get all the data it needs from the remote object with one call. Because local clients don't have the same performance disadvantage when invoking operations, they can afford to use more of a fine-grained access and not worry about making more than a single call on the enterprise bean.

The Remote Model Provides Better Location Transparency

With the remote programming model, no assumption is made about the location of the enterprise bean, with respect to the client. Local clients must be located within the same JVM as the enterprise bean, but this is not true of remote clients. Therefore, the deployment considerations for enterprise beans that are accessed by remote clients are much simpler. Local clients must be deployed within the same container as the enterprise beans they access. This is not true of remote clients.

Remote Clients Must Deal with Remote Exceptions

Because many things can go wrong when accessing a remote object, a remote client must be prepared to handle these exceptions. Things such as communication loss due to network errors are unexpected, but can happen nevertheless with the remote model. Local clients don't have to handle remote exceptions and, therefore, are a little less complicated from an error-handling standpoint.