Entity EJB sends shiver down my spines, I have to admit. Recently, I had to evaluate Entity EJBs (2.0) for a client of mine. I have had used propretiory Entity EJB extensions to implement persistence in enterpise applications, but the standard and portable Entity EJB of today is still dispappointing and no way a serious candidate.

The immaturity of EJB-QL alone was enough to convince me that Entity EJBs are not the way to go. I would get no where with a syntax that does not support the SQL semantics that we all have come to live with - ORDERBY, GROUP BY, HAVING etc. And then there is of course the lack of support for Date in the EJB-QL. There were more of course. But I had to do an unbiased evaluation keeping aside my personal preferences & prejudices. It was not if, but when I would stumble into a show stopper. And then came the inheritance. That was some interesting beast that is worth a blog.

We all know EJB specification does not support component inheritance. Per the spec, the Bean provider can take advantage of the Java language support for inheritance in the Remote & local interfaces and the implementation class. What does this really boil down to for application developers like me?

It means one thing. Suppose that you have a finder method on the Home interface for a parent EJB. You would expect that a finder on the parent Home interface would have the capability to return the child EJBs (remote or local) too. The lack of component inheritance implies this is not possible. Couple of work arounds have emerged to address this scenario.

Adapter Strategy:

This strategy has a lot of variation. I will go over one. In this strategy, an Adapter for the Base EJB is introduced. The Adapter implements the finders on the Base Home interface. All invocations for Base EJB Finders go through the Adapter. The Adapter will then issue queries on Homes for each subclass EJBs and aggregate the results. That this is a performance hog goes without saying. What should have been accomplished with 1 query resulted in n + 1 queries, where n is the number of sub classes.

Containment Strategy:

I think this name was first coined in a ServerSide article (http://www.theserverside.com/articles/article.tss?l=EJBInheritance) by Daniel O’Connor. Some vendors also advise to use this strategy with their application servers. In this strategy, the Base EJB has CMR with local interfaces of its subclass EJBs. The finder on the Base EJB performs a database “batch read” to get the subclass EJBs. The business methods on the Base EJB will use aggregate the results from the children (CMR) to return the EJB(s).

Then there is the third option to “flatten the EJBs, get rid of your inheritance”. I don’t like any of these. With the first option, performance is compromised, while richness of the domain model is compromised in others. I believe any technology (not just EJB) should be non-invasive This example of EJBs (read technology) driving the domain modeling and making it unnecessarily complex is just one example of invasiveness. Domain model should be logical and simple (and no simpler).

Bottom line:

Technologies come and go. If your business needs to survive, don’t tie the heart & core - your domain model and business logic to technology. Technology should complement, not compete or alter your design.