Also in EJB 2:
With little fanfare, Sun released the second public final draft of the EJB 2.0 specification last week. Even though the specification is in the final stages before acceptance, this update contains extensive changes. Application server vendors and developers who have been unhappy with a proposed implementation of dependent objects have pushed for changes. Some background information on these issues can be found in my earlier articles
Most of the significant changes in this latest revision involve the removal of dependent objects and the introduction of local interfaces. This article will discuss local interfaces, their proposed implementation, and issues that developers may expect to encounter when dealing with this technology.
As everyone knows, session and entity beans have had home and remote interfaces, where business operations are defined. The latest EJB specification introduces the possibility of having local home and local interfaces in addition to the existing remote home and remote interfaces. Developers should be aware that remote interfaces have been renamed to "component" interfaces in the latest, public, final draft. The rest of this article will continue to use "remote" interfaces for simplicity.
The specification now separates clients that access an EJB into two types:
As a result of this distinction, it makes sense to expect local clients to have optimized access to an EJB's operations as opposed to remote clients that are required to use RMI semantics.
The EJB specification defines just that.
Local clients that access the local home or local interface of an EJB are granted optimized access by bypassing RMI semantics in favor of direct method invocation (using pass by reference). Local interfaces provide an appealing new aspect to developers. Methods invoked on a local home or local interface of an EJB will only be invoked using pass by reference semantics. Essentially, it's nothing more than a method invocation on a local Java object.
Writing local home and local interfaces is very similar to writing remote and remote home interfaces. Generally, they follow the same rules with a few exceptions:
In the first public final draft of the EJB 2.0 specification, dependent objects were the proposed mechanism for adding finer-grained access to entity EJBs. For example, a Person entity EJB describing all the personal information of a human being might be a coarse-grained object accessed directly by a presentation layer. The Person entity EJB may want to have a reference to a fine-grained Address persistent object. The bean developer will want to maintain a separation between the Person EJB and the Address persistent object that it references. In the previous public final draft specification, there were two ways to implement this using CMP.
First, create Person and Address as CMP entity EJBs that participate in a relationship. This would require Address to be a coarse-grained persistent object that is accessible to all objects in the system via RMI. The Person EJB would not have optimized access to the Address bean since it must use RMI semantics.
Second, create Person as a CMP entity EJB and create Address as a dependent object that participates in a relationship with Person. The Address dependent object would be accessible by local method invocations but has a different implementation technique than entity EJBs.
Entity EJBs have always been considered coarse-grained persistence objects due to a variety of factors. In the first place, the only portable technique that could be used to access an entity EJB was an RMI invocation. Second, every method invocation had request-level interception that added security, persistence, and transaction overhead that may or may not be necessary. And, third, the the 1.1 CMP model of entity EJBs that mapped attributes of the bean class to persistent fields made it extremely difficult to perform optimized data access techniques. These techniques include partial field loading, optimized writes of modified fields, and lazy loading of fields. Since it was impossible for a container to determine which fields were being accessed on any given method invocation, most containers had to treat the persistent fields of the bean as a holistic group as opposed to multiple groups of fields that can be managed separately.
It was well understood by the development community that a mechanism to provide fine-grained, local access to persistent objects was needed. The dependent object implementation ultimately fell into unfavorable status because of its awkward implementation style.
Enter local interfaces. The specification authors wanted to come up with a mechanism that allowed developers to create entity EJBs that are coarse-grained and fine-grained. By adding an additional interface to an entity EJB, developers would not have to change the techniques which they've already mastered. Local interfaces allow developers to take existing entity EJBs and quickly separate the way in which the bean is accessed by placing different operations into the remote or local interfaces. Local interfaces provide all sorts of benefits and headaches that are discussed below.
If the specification authors wanted to allow methods to be accessible remotely and locally, why didn't they just include a deployment descriptor tag that allows the bean developer or deployer to specify how any given method should be invoked? This was debated heatedly, and there are several reasons for creating separate remote and local interfaces, as opposed to allowing a container to optimize access to certain methods of a remote interface:
There are several interesting doors that open as a result of developers having local interfaces in their toolset. Developers can pass non-serializable arguments into a local method on an EJB. Most notably, Java reflection classes generally are not serializable and cannot be passed as an input parameter to a remote method. With local methods, however, an EJB can take advantage of reflection semantics. A similar argument can be made for other objects that are not serializable.
Also, local interfaces make EJBs location dependent. The local view of an EJB can only be from those objects that are collocated on the same server. This provides an issue for application server vendors that will have to restrict the visibility of local home interfaces.
Clients and EJBs have to be prepared to assume that the state of any object that is passed as an input parameter to a local method can be changed. Since local methods make use of pass by reference semantics, input parameters are not decoupled between clients and EJBs. It is expected that clients and EJBs can be coded to expect pass by reference semantics.
CMP entity EJBs that participate in a relationship can only make use of the local interfaces of other entity EJBs that are participating in the relationship. Each entity bean that is participating in a relationship can have a remote interface, but the view that an entity bean presents to other beans in a relationship is only exposed in the local interface. This will allow beans participating in a relationship to have optimized access to each other's methods by bypassing method permission checking that will be invoked for every RMI invocation.
RemoteException objects cannot be propagated to EJB
clients that use a local interface. As a result, for system
exceptions that are generally propagated to a container, wrapped into
RemoteException, and propagated back to a client, the
specification has made special concessions for propagating system
exceptions directly to a client.
For example, if a client attempts to invoke a remote method without
a transaction context when one is required, the client will receive a
exception inherits from
RemoteException and cannot be
used for local clients that invoke a local method that requires a
transaction context. The EJB specification has introduced a variety of new exceptions that extend
get around this limitation. These exceptions are
TransactionRolledBackLocalException. The important point
here is that since system exceptions such as
do not have to be included in the signature of methods in the local
interface, local clients will have to be coded to expect to receive
system exceptions at runtime. This ambiguity does not exist with
remote clients since compilers can enforce proper exception handling
at compile time since
RemoteException is declared in
every remote method.
EJB specification has introduced a variety of new exceptions that extend
Since local interfaces provide optimized access to an EJB, entity EJBs that participate in a relationship must do so through their local views. An argument could be made whether an entity EJB should even have a remote interface. Almost every major EJB deployment uses entity EJBs, in which a session EJB fašade layer is typically used to abstract away business logic, business process management, and business rules from the data abstraction layer of entity EJBs. Effectively, this business abstraction layer provides the remote business view of the system. And since session EJBs are almost always collocated on the same server with the entity EJBs that they are using, it doesn't make a lot of sense to force the business layer session EJBs to access entity EJBs through their remote interfaces.
In fact, if a session bean only accesses an entity EJB, what methods would have to be exposed in the remote interface? The only situation where an entity EJB would need to expose methods as part of its remote interface would be when the session EJB fašade and the entity EJB data abstraction layer are not collocated on the same virtual machine (perhaps they reside in different clusters for availability purposes) or if a remote Java client needed to access an entity EJB directly. One might object that any design that proposed a Java client accessing an entity EJB directly could be redesigned to have the Java client access a session EJB that in turn uses the local view of the underlying entity EJB.
The creation of local interfaces is sure to spark additional debate among developers and application server vendors. Additionally, for those developers that are about to go into production with an application server that supports a pre-release version of EJB 2.0, those developers will likely have to address the semantic changes in the new version of the specification. Developers will not likely be faced with a redesign but could be impacted with a re-implementation of certain Java files and deployment descriptors.
Local interfaces are a step in the right direction, however, and will provide developers with a better infrastructure than available with EJB 1.1. Once the EJB specification is officially released in the next couple of months, a close look will be given to those early adopters that choose to use the EJB 2.0 model. It's almost a guarantee that their successes will be more prolific than those with EJB 1.1.
Tyler Jewell , Director, Technical Evangelism, BEA Systems Tyler oversees BEA's technology evangelism efforts that are focused on driving early adoption of strategic BEA technologies into the ISV and developer community.
Return to ONJava.com.
Copyright © 2009 O'Reilly Media, Inc.