Rod Johnson on J2EE Without EJB
A little over a year ago I wrote a critique of Rod Johnson's book J2EE Design and Development. The refreshing point about the book back then was that it was dancing around the argument that "J2EE != EJB".
Yesterday evening, I got my hands on his latest book "J2EE Development without EJB". I usually don't read entire books, I simply don't have the time. So a bit of disclaimer here, I didn't read the entire book. Actually, I just read one chapter, that is I headed straight for the one that caught my eye. Chapter 5, EJB Five Years on.
This is the chapter where he and his co author Juergen Hoeller tear apart the very foundations of EJB. The authors discuss several features provided by EJB and for each one argue why they are inadequate:
Feature Argument Declarative Transactions Good but not always appropiate. Remoting Best choice today for remoting. Clustering Entity and SFSB have weak implementations.SLSB clustering isn't rocket science. Clustering more important on the web and database tier. Thread Management Locking entire bean instances is naive. Multi-threaded services without read/write instance variables make better sense (i.e. Servlets). Instance Pooling Doesn't make sense with today's more modern garbage collectors. Resource Management Not truly tied to the EJB container. Security Security requirements tend to be more complex than what EJB role-based security provides. Business Object Management Use of JNDI unnecessarily complex.
Of course, arguments in favor of EJB have never truly tended to be technical in nature. For the semi-technical arguments that are brought up to support EJB (i.e. Deciding whether EJB is appropriate), the authors also tear up those arguments to shreds.
Overall, the chapter was extremely good, it confirmed in writing all my arguments against EJB. To top it all off and to my surprise, the authors quote my "Post-EJB" blog entry back in 2002. It's a weird feeling when you read yourself in a book that you didn't write. Well that surely made my day, it makes me appear like a visionary, when in true reality the technology was a plain disaster to begin with. But the authors seem to forget to cite the "101 EJB Damnations Piece" also back in 2002. Maybe they felt that a more concise statement bests out a long list of arguments.
What amazes me really is how quick this book was written. I mean it is over 500 pages. I'm writing a book right now and I'm already struggling to get it over 200 pages. One thing I noticed was how the authors use URLs instead of references to a bibliography. I was always uneasy of how to include them in print media, but I think they've shown the way, that is, just simply spell out the URL with the text. Finally, this might have been one of the first books I've seen that has quoted blogs! That should be a lesson to all bloggers, "Cool URIs don't change".
Once you've shown that the emperor has no clothes, people will begin to feel really naked. Fortunately, the book provides alternative clothing in the form of Lightweight Conatiners, Spring Framework, AOP, JTA transactions, O/R Persistence and alternative remoting. That is, nuggets of wisdom from the authors, where it "It is better to avoid gratuitous complexity than to rely on tools to manage it." In other words, that's a hell of a good tip towards better manageability of complexity.
With an Amazon sales rank of 500 (July 2004), this book has little need for additional recommendations.
Last modified 2004-07-26 06:39 PM