EJB 2.0 Specification Release Review

Interesting Tidbits of Working with Local Interfaces

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 a 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 javax.transaction.TransactionRequiredException. This 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 extendjavax.ejb.EJBException to get around this limitation. These exceptions are AccessLocalException, NoSuchObjectLocalException, TransactionRequiredLocalException, and TransactionRolledBackLocalException. The important point here is that since system exceptions such as EJBException 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. The EJB specification has introduced a variety of new exceptions that extend

The New Entity EJB Design

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 faade 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 faade 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.

Conclusion

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.