What's Wrong with the EJB 2 Specification?
Pages: 1, 2

So What's My Problem?

With all these options available to developers, this must be the right approach to take for incorporating fine-grained objects, right? Wrong. All of this supposed flexibility will ultimately cause more problems than it's meant to solve:

1. Dependent objects are meant to be all things to all people. There are two things that developers currently need to be successful with fine-grained objects in the near future:

   1. Local fine-grained objects that have all of the benefits mentioned earlier -- including local method invocations and bypassing container enhancements, if necessary -- thus allowing developers to model different persistent objects which are to be managed by a single persistence manager employed by a parent, coarse-grained object.

   2. Life cycle objects that follow the same life cycle of a parent object. A life cycle object is created when its parent is created and destroyed when its parent is destroyed. The child object is preferably created and destroyed automatically by the parent's container or persistence manager. This is particularly useful for modeling composition UML relationships where a child object cannot exist without its parent object. In the earlier example, if credit card information is only ever associated with a customer profile, the credit card information may be modeled as a life cycle object where the life of the credit card is managed automatically by the persistence manager of the customer profile object.

2. Dependent objects have a cascading delete deployment descriptor option that instructs a container to manage the destruction of dependent objects attached to parent objects. This is needed to manage life cycle objects. The other characteristic needed to support life cycle objects, an automatic creation mechanism, does not exist, which makes the intentions of the specification developers murky. If the intent is to make dependent objects behave like life cycle objects, which they are according to objectives listed in section 9.3.1 of the EJB 2.0 public final draft specification, then why include cascading delete behavior without including a mechanism for tying the creation of a dependent object to its parent? Presently if you want a dependent object to be created at the same time its parent object is created, you have to create it manually during a creation callback of the parent object. It would have to be done as part of invoking the ejbPostCreate() method of an entity bean that was the parent of a life cycle dependent object.

3. Dependent objects are written differently than entity EJBs. Since dependent objects can only be accessed locally, home and remote interfaces are not necessary. Only an abstract implementation class has to be provided as part of a dependent object's implementation. The container still provides a concrete implementation similar to entity EJBs. The additional syntax that an EJB developer will have to learn will confuse new developers.

I want to emphasize the confusion and ambiguity introduced by dependent objects by raising a final issue. If the point of dependent objects is to standardize local, fine-grained objects, which it must be since dependent objects only partially support life cycle requirements, then they are a small step forward at best. Many developers believe that dependent objects are necessary since there isn't another way to achieve CMP management of a local, fine-grained object.

To the contrary, many application servers have the hooks, flags, and proprietary measures needed to model two entity EJBs in a remote-local fashion. Using these proprietary flags, it's possible to achieve behavior and performance very similar to a dependent object implementation. How? Using BEA's WebLogic Server 6.0 container implementation,

1. implement the parent object and the child object as entity EJBs with CMP;
2. in the WebLogic-specific deployment descriptor set the child EJB to be accessed by reference; (the EJB will be accessed over a local method invocation instead of RMI if the child EJB is in the same virtual machine as its parent);
3. set the transaction attribute of the child EJB to SUPPORTS so that it will inherit any transaction context that the parent EJB uses; (this will insure that any database updates that are performed as a part of the child's ejbStore() callback will be done at the same time that the parent's updates are performed);

Other application servers support similar proprietary flags that achieve the same affect. The disadvantages of this technique are twofold: first, it's proprietary; second, a persistence manager will likely not be able to batch database SQL invocations at the end of a transaction as it would be able to do with a parent object that has a dependent object.

A more detailed analysis of the point of fine-grained objects is obviously warranted. Even without that analysis, the intended use of dependent objects as defined by the specification developers seems fuzzy. Despite addressing a real need identified by developers in the EJB community, this dependent object approach confuses the conceptual issues and ultimately confuses developers too.

Conclusion and What Should Be Done?

1. Get rid of dependent objects.

2. Emphasize the importance of life cycle and local objects. Allow developers to specify objects as life-cycle, local, or both.

3. Develop a technique for fine-grained objects that doesn't introduce more syntax for developers to learn. Consider leaving CMP entity EJBs as the only persistent object implementation, but include deployment descriptor flags that specify fine-grained object.

Is all of this controversial? You bet it is. Despite the number of vendors that have embraced the EJB 2.0 specification, I'm not aware of a single vendor that's implemented dependent objects, including BEA WebLogic and JBoss Server, which are usually the most updated implementations. It's likely that the confusion described here is felt by others in the industry too.

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.

Tyler Jewell has pointed out errors in the EJB 2.0 specification, the primary delay in the final J2EE 1.3 release. What are your thoughts?
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 3 of 3.

• Is ejbRemove really that bad?
  2002-09-05 09:33:44  sbalan [Reply | View]
  
  
  Hi,
  
  I am not an expert at EJBs but I think the basic reason why ejbRemove behaves differently for session beans and entity beans is that session beans and entity beans are fundamentally different. when a client calls remove on a session bean, the session bean can be resued for some other client. it is not a shared entity. however entity beans are shared entities which means remove actually frees it up for access by someother client.
  
  i think since this fundamental difference exists it is reasonable that ejbRemove behaves differently for session and entity beans.
• Is ejbRemove really that bad? - Correction
  2002-09-05 09:38:32  sbalan [Reply | View]
  
  
  Well,
  i shld probably rephrase. entity beans go into persistent stores however session beans don't. so ejbRemove can't actually remove the session bean. it can only move it to the pooled state.
  
  however for entity beans, ejbRemove will actually remove it from the database. so in this case, you need two calls one to take the bean back to the pool and one to actually destroy it. so we have two different methods.
  
  for session beans, its all the same coz there is no actual destruction involved. so I guess its oj there is only method.
  
  once someone understands the fundamental differences between session and entity beans, i think they can see why ejbRemove behaves differently for each of them.

• Another viewpoint
  2001-08-04 16:48:12  aramallo [Reply | View]
  
  
  So it seems to me that the underlying message is that finally J2EE developers agree that they needed a fine grained object model in the first place.(EJB's dependent objects, JDO spec...)
  Do you guys know Apple's EOF (Enterprise Object Framework) ? It provides a better and cleaner contract than EJB...in your terminology it is a fine grained object model that manages persistence in a CMP fashion, with a lot of benefits...no deployment descriptors, local and remote (you can even split your business logic is an Enterprise Object by specifying which methods are executed locally and which are executed remotely - HTTP or IIOP) and more ...