Also in EJB 2:
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.
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:
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.
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,
<assembly-descriptor> tag could be extended to
<!--Security and transaction attributes defined here as always -->
<method> <!--Already exists in DTD specification -->
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.
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.
Copyright © 2009 O'Reilly Media, Inc.