We will now examine the two types of business interface access in more detail.
As we have seen already, every session bean must have a business interface that enables a client to invoke methods on it. Session beans can have no Java interface and the EJB container will generate one dynamically as a hidden proxy.
The @javax.ejb.Local annotation denotes the local business interface. It is the default if the session bean does not specify an interface. A local business interface can only be invoked if the EJB component runs on the same JVM. If your architecture is different then you should favor creating a remote business interface instead of adding to the local one.
A local business interface is certainly comparable to a direct invocation call and depending on the Java EE product and its implementation it will translate to dynamic invocation across a proxy to the singleton bean instance. It will certainly be faster than the equivalent network call. Therefore, the arguments and results of the local access are passed by reference. There is no marshaling or serialization of the arguments or return types to be expected here.
Local access is location dependent for obvious reasons.
The remote business interface is purely for a remote invocation from one JVM to another JVM, therefore these calls travel across the network, even if they are co-located on the same physical server.
In order to enable remote access, the session bean requires an annotation called @javax.ejb.Remote declared on the implementing class or the Java interface.
Remote access is more expansive than local access because the parameters, the arguments, and return type must be marshaled and serialized, if only for byte-order encoding. The arguments and the return type are passed by value.
Remote access is location independent.
Here is a table summarizing the two types of business interface:
|
Local |
Remote |
|---|---|
|
Location dependent |
Location independent |
|
Object are passed by value |
Objects are passed by reference |
|
Object serialization is not required |
Objects must be serializable |
|
Almost direct coupling between the target and client components |
Proxy and loose coupling between the target and client components |
|
Invocations are cheap – 2 step JVM dispatch calls |
Invocations are expensive across the network |
|
No network error costs |
Adds the extra cost of supporting remote access to handle communication error |
The annotation @javax.ejb.LocalBean is designed for session beans that do not expose a business interface to clients. By default any session bean that does not declare an implementing interface representing a local or remote view is taken by the specification as a no-interface view. EJB specification allows local business interfaces to be optional. This means the developer does not have to define a local interface.
Here is an example of a no-interface stateless session EJB:
package je7hb.basic.ejb;
import je7hb.basic.ejb.examples.*;
import javax.ejb.*;
import javax.inject.Inject;
@Stateless
@LocalBean
public class PostTradeProcessor {
@EJB DataRepository dataRepository;
@EJB EnrichmentManager enrichmentManager;
@Inject MatchingEngine matchingEngine;
public void preProcess( Product product ) { /* ... */ }
public void process( Product product ) { /* ... */ }
public void postProcess( Product product ) { /* ... */ }
}In this class PostTradeProcessor
there is no business interface defined as a local view. The annotation @LocalBean informs the EJB container that the business interface locally is derived from all of the public methods called inside the EJB. In the example, the methods preProcess(), process(), and postProcess() are exposed as the client view.
As you witnessed in the previous example, PostTradeProcessor actually relies on dependency injection of references through the annotations @Inject and @EJB.