Sorting Out the EJB 2.0 Rumors

In my last article I wrote about some potential ambiguities that may exist with dependent objects. In this article I want to focus on some rumored solutions to the dependent objects issues.

In my last article I mentioned that I was not aware of any application server that supported dependent objects in their implementation. A clever reader pointed out that the Orion Server 1.2.9 might support dependent objects. After following up, I learned that the Orion Server does have beta support for an EJB 2.0 container and CMP entity beans, but there isn't any reference to an implementation of dependent objects.

ObjectFrontier has released ePersistJ, a development, deployment, and runtime engine for EJB 2.0, which has very extensive runtime support for the public draft EJB 2.0 specification, including dependent objects, object navigation with active and lazy loading, support for a variety of application servers, and distributed object caching.

Back to dependent objects

I've heard a variety of rumors about the EJB 2.0 specification. The biggest rumor is that the dependent object portion of the specification is under review and will be modified in the near future.

I've heard all kinds of interesting rumors and proposed recommendations to better clarify the role of dependent objects with entity EJBs. In particular:

1. I've heard a lot of interest in developers incorporating Java Data Objects (JDO) into the entity EJB model. The JDO model is based on the Java Connector Architecture and supports pluggable persistence managers. Additionally JDO Instance objects are designed to represent simple and complex, persistent and transient data. The JDO model could easily be leveraged to support dependent object-like instances. In particular, a JDO implementation could easily support local and life cycle objects that participate in relationships. JDO can best be viewed as an integration point between application components and EIS systems (most importantly, data stores). JDO does not, however, provide component and container feature definition outside of a persistence manager. This includes techniques for making JDO Instance objects remote and manageable by a container. Despite some overlap with the EJB specification, JDO could be used to represent persistent data at the lowest layers with the EJB specification evolving into a container-based wrapper for JDO Instance object management. You can find out more about Java Data Objects here.
2. I've heard rumors that dependent object, local object, and life cycle object support will be eliminated in the EJB specification until the next major revision. This would make things simpler for application server vendors, but could harm developer in the long run. Application server vendors that opted to provide support for dependent object-like behavior would be forced to provide a proprietary implementation that would make future migration complicated. I don't see this as a likely option for the EJB specification authors, especially since they have already given the public a taste of dependent objects and removing them would only make us salivate even more!

3. I have heard of the possibility of incorporating local interfaces into the EJB specification. Their exact usage at this point is unclear, but I'll take a guess at their intent. Right now, session and entity beans have remote interfaces that require any methods listed in that interface to be accessed through RMI. This is typically RMI/JRMP or RMI/IIOP. An EJB with a local interface would have methods that are accessible by reference and bypass any RMI networking semantics, creating an interesting dilemma. Any object that accesses the local interface of an EJB would likely have to be resident in the same virtual machine as the EJB's container. In particular, how does an EJB container enforce a local method invocation, and how does an EJB with local methods behave in a clustered environment? Additionally, do local methods interface with persistence managers and persistent attributes differently than remote methods? Local interfaces appear to be a possible solution for an implementation of local objects, but it is vague as to whether they provide a fine-grained persistent object implementation and support any life cycle characteristics.

4. The final rumor I'm presenting appears to be more of a quick fix patch given the current CMP implementation. Since the EJB specification already supports an implementation of the <method> tag for identifying a specific method in the home or remote interface of an EJB, for defining security and transaction attributes, this tag could be used to provide a pseudo-implementation for local interfaces. Since developers are already familiar with implementing remote interfaces for entity EJBs, why bother changing the way they are currently developed? The ejb-jar.xml deployment descriptor could be extended to identify those methods that are listed in the remote or home interface that should be accessible remotely, locally, or through both techniques by using the <method> tag. For example, the <assembly-descriptor> tag could be extended to include

   <assembly-descriptor>
<!--Security and transaction attributes defined here as always -->  
<local-methods>
  <method> <!--Already exists in DTD specification -->
   <ejb-name>EngineEJB</ejb-name>
   <method-intf>Remote</method-intf>
   <method-name>*</method-name>
  </method>
  <local-behavior>Both</local-behavior>
</local-methods>
</assembly-descriptor>

   Using this format, any method in the remote interface could be accessible locally (by reference only), remotely (the default and over RMI) or both (by reference, if being accessed by an object in the same VM, otherwise remotely). It's pretty easy to see how this technique could be a superset of the local interface technique described above (unless local interfaces are much more robust than indicated in this article).

   Additionally, dependent object-like behavior can be achieved using this technique. Since the EJB relationship technique is relatively well understood, and EJB-QL is robust enough to navigate relationships, a developer could implement a local persistent object quite easily. The developer would merely create a CMP entity EJB that participates in a relationship with another CMP entity EJB. The deployer would then set all of the methods to be accessed locally using the <local-methods> tag listed above. The parent CMP entity EJB that is participating in this relationship could recognize that the other object is only accessible locally and implement it as a dependent object. The only drawback to this solution is that since entity EJBs are required to have a primary key, this implementation could not support local persistent objects that didn't have an identity. This would defeat the purpose of dependent objects as they are currently implemented since they are designed to work with and without primary keys.

Conclusion

Whatever solution the EJB specification authors choose for dependent objects will likely be closely scrutinized. I've heard that most of the major application server vendors that participate in the EJB expert group are making individual recommendations as to possible solutions beyond those discussed here. By the release of the next article, it is likely that a new version of the EJB specification will be released for all of us to see.

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.

Read more EJB 2 columns.

Return to ONJava.com.