Local and Remote Client Views of the Object Model
A client (meaning either an application client, a web component, or another EJB) accesses an EJB
through its home and component interfaces. There are two varieties of component interfaces: remote
and local. Remote interfaces have been part of the EJB specification from the beginning. Local
interfaces are an addition made by the EJB 2.0 specification. This section will first briefly review the
concept of local interfaces. Then it will discuss the utility of local interfaces for developing your object
model. Finally it will talk about local interfaces, remote interfaces, and their implications for the client
view of your object model.
Local Interfaces Reviewed
A local interface is a component interface, much like the remote interface, for a session or entity bean.
An EJB component can have both a local and remote interface. They are both described in the
deployment descriptor and made available through a home interface for the component. A local
interface differs from a remote interface in several important respects.
- The local interface must always be located in the same Java Virtual Machine
- One of the advantages of a remote interface is that it provides location transparency. In other words, the
client can use that remote interface without knowing or caring if the EJB it represents is deployed in the
same JVM, the same container, the same application server, or even in the same company. A local
interface must be used on the machine to which the EJB component is deployed. This limits your
flexibility during deployment, although in practice performance considerations dictate that tightly
coupled EJB components should be located in the same container anyway.
- Parameters and return values to a local interface are passed by reference, not by value
- A remote interface must always enforce pass-by-value semantics, even if the call is in reality a local call.
Pass-by-value semantics require that copies be made of all objects, unless they are immutable or they are
remote references. This is to ensure that a bean's behavior is not different depending on how it is
deployed, and is a requirement of location transparency. In practice, there are situations where this
copying can be expensive, for example if a large XML document were passed as a parameter or returned
as a result. (Potentially remote calls use pass-by-value semantics because a copy of a non-remote object
must of course be made when it is streamed from one JVM to another, say across a network.)
- Methods on a local interface do not throw java.rmi.RemoteException
- Methods that are called remotely are subject to various interruptions, such as transport difficulties and
remote object availability, which are not relevant to methods that are called locally. These interruptions
are represented by a checked exception of class java.rmi.RemoteException, which must be
declared in the throws clause of a remote method. A method on a local interface must not throw
java.rmi.RemoteException.
Due to this rule, certain exceptions that derive from java.rmi.RemoteException
(NoSuchObjectException) need to have local equivalents that derive from
javax.ejb.EJBException instead (TransactionRequiredLocalException,
TransactionRolledBackLocalException, and NoSuchObjectLocalException).
The Utility of Local Interfaces for Your Object Model
Local interfaces make it practical for entity components to represent fine-grained aspects of your object
model, in terms of performance. Consider the following passage from the EJB 1.1 specification that
describes why an entity should be coarse-grained:
"Every method call to an entity object via the remote and home interface is potentially a remote call.
Even if the calling and called entity bean are collocated in the same JVM, the call must go through
the container, which must create copies of all the parameters that are passed through the interface by
value (i.e. all parameters that do not extend the java.rmi.Remote interface). The container is also
required to check security and apply the declarative transaction attribute on the inter-component
calls. The overhead of an inter-component call will likely be prohibitive for object interactions that
are too fine-grained."
Here are the problems, and the corresponding solutions of local interfaces:
-
Every method call is potentially a remote call
This is not true of local interfaces.
-
The container must create copies of all the parameters that do not extend java.rmi.Remote
This is not true of local interfaces, which pass parameters by reference.
-
The container is required to check security and apply declarative transaction attributes
This is still true of local interfaces. However, the ability to have methods without security
checks was introduced to the EJB 2.0 specification, which allows the application assembler to
mitigate this problem. (Use the <unchecked> element rather than a role name in the
<method-permission> element to indicate that a method should not be checked for
authorization.)
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
