by Chris Richardsom
Publisher: Manning Publications Co.
Publication Date: January 2006
Reviewed by Robert Eckstein
I've always been a proponent of simplicity. That's why I feel that an integrated development environment (IDE) that has a decent set of refactoring tools is worth its weight in gold -- I'm constantly trying to simplify my code. Perhaps that's also the reason why I'm attracted to the idea of POJOs: plain old Java objects. There's nothing more attractive to a programmer than working with a simple, efficient API.
If you're not familiar with the definition of POJO, this Wikipedia entry does a good job explaining it:
As of November 2005, the term "POJO" is mainly used to denote a Java object which does not follow any of the (major) Java object models, conventions, or frameworks.... The term [POJO] has most likely gained widespread acceptance because of the need for a common and easily understood term that contrasts with complicated, special object frameworks. It is more attractive than the Java "bean" terms because of the naming conflict between JavaBeans and Enterprise JavaBeans . The former is to large extent a POJO that follows rigorous naming conventions and is serializable, whereas the latter is not a single class but an entire component model ([although] EJB 3 reduces the degree of difference).
The simplicity of POJOs is attractive, especially to those working with the older Enterprise Java Beans (EJB) specification. The topic assumes a simple axiom: The simpler a framework's design, the more extensible it is to programmers. For example, in an open letter to the Java community, Linda DeMichiel and Craig Russell talk briefly about adopting POJOs for both Java Data Objects (JDO) API 2.0 and the new EJB 3.0 specification, pronouncing the need for a single, simple persistence model. As the FAQ notes, this API "is an evolution of the work started in the JSR 220 Expert Group, which has been expanded to include several members of the JSR 243 (JDO 2.0) Expert Group." JSR 220 covers the creation of the EJB 3.0 specification, with a stated mandate "to improve the EJB architecture by reducing its complexity from the developer's point of view."
Consequently, we now have the first of several books on POJOs: Chris Richardson's POJOs in Action (Manning, January 2006). Manning was nice enough to let me see an advance copy of this book -- at my request -- and it was a very interesting read. The majority of the book discusses how POJOs work with a number of lightweight technologies, including JDO, Spring, and Hibernate. It also discusses POJOs in conjunction with the upcoming EJB 3.0 specification, which was still progressing through the Java Community Process (JCP) at print time.
The book's initial chapter helps define POJOs. It assumes that you are reasonably familiar with the design of an enterprise system, including the presentation, business, and persistence layers. Here, the author quickly exposes the issues by comparing the newer POJO design with the older EJB 2.1 architecture design, pointing out strengths and weaknesses of the current "procedural" versus the ideal "object-oriented" business layer design.
Using the classic example of a transfer between bank accounts, the author sets up the justification for POJOs by illustrating many of the common criticisms of the EJB 2.1 specification: difficulty in testing, constricted design, complex maintenance, and overreliance of Data Access Objects (DAOs) to encapsulate entity beans or JDBC API/SQL calls. The author introduces the EJB 3.0 specification, gives a step-by-step introduction to how POJOs attack each of the shortcomings just mentioned, and discusses persistence and transactions.
Chapter 2 then dissects the business and persistence layers and discusses situations in which POJOs may or may not be appropriate. How should you organize the business logic? Again, the author makes a rallying cry to get back to true object-oriented design. How should you encapsulate the business logic? The book discusses respective implementations of the façade pattern. How should you access the database? This is a simple choice, because most of us would rather jump off a bridge than get stuck maintaining complex and database-dependent SQL statements. How do you handle brief and lengthy concurrent data access? With various forms of optimistic and pessimistic locking, says the author. In essence, this chapter introduces the rest of the book's topics but doesn't leave you drowning, and at times you'll hear echoes of professors past when they were espousing the original object-oriented benefits of C++ over C, or encouraging you to use a testing framework for more solid code.
Then things get interesting. Chapter 3 introduces the "domain model," which forces modern business logic to step back in time and take a run through object-oriented analysis and design. Remember Booch or Rumbaugh's canonical texts on those topics? This was one of the book's most interesting chapters, and the author lays out some good arguments as to where things started to deviate from the doctrines of old. I won't ruin it for you, but I will say that I found myself scratching my head several times and saying, "Oh, yeah... When did we stop doing that?"
From this point on, the author addresses the questions presented in Chapter 2 in more detail. Chapter 4 introduces the persistence of the previous chapter's domain model, including design strategies and testing. Chapters 5 and 6 discuss implementation-specific details for JDO 2.0 and Hibernate 3.0, respectively. Because I'm primarily a JDO user, I delved deeply into Chapter 5 and only glanced at Chapter 6. Chapter 7 was also a good read: It discusses placing a POJO façade, as opposed to a session façade, on top of the domain model. Recall that a façade pattern is essentially an intermediate object that provides a simplified interface to a larger body of functionality underneath. Not only is this a good idea for interfacing the presentation tier with the business layer, but it also helps when hooking in testing frameworks.
Chapter 10 is probably the most interesting to me, with its discussion of the upcoming EJB 3 specification. I should point out that the book concentrates on the public review draft of June 27, 2005, which is a little dated now. The proposed final draft is available on the JSR 220 web site. If you haven't heard yet, the EJB 3.0 architecture allows you to replace those annoying deployment-descriptor files that seem to change from one app-server to another with annotations, a language feature that was introduced in Java 2 Platform, Standard Edition (J2SE) 5.0. Unfamiliar with annotations? That's OK, because before the EJB 3.0 specification, there really wasn't a need to be familiar with them. However, with the EJB 3.0 architecture, it's safe to say that you'll be using them quite a bit, and they appear in earnest in this chapter. Also, recall that one of the primary goals of the EJB 3.0 specification is simplicity, including an enhanced focus on vendor independence. So although JBoss's EJB 3.0 specification implementation is based on Hibernate, and Oracle's implementation is based on TopLink, you shouldn't have to be learning any proprietary APIs. As far as I know, the EJB 3.0 specification has that as a shining distinction. Put succinctly, Chapter 10 is a fair discussion of how POJOs and the EJB 3.0 specification intersect.
Chapter 12 presents a good discussion on database transactions and concurrency. Again, I tended to gravitate toward the JDO aspects of this chapter, yet I found the section on recovering from database concurrency failures using the Spring aspect-oriented programming (AOP) framework an eye-opening read. Note that the author gives fair treatment as well to Hibernate users, as well as those using straight JDBC technology or Apache iBATIS. Chapter 13 continues the discussion of more lengthy offline locking patterns that Chapter 2 introduced.
The good news is that nothing in the book is hard to follow, so long as you're familiar with basic enterprise design. And it serves as a gentle introduction to the road that enterprise design will be traveling in the future, illustrated with a late 2005 snapshot of the technology that can help you get there. On that note, you may be slightly curious as to why I would review a book on a topic such as POJOs. As the EJB 3.0 specification progresses, it's nice to see a fair and healthy debate on the strengths and weaknesses of each of the various frameworks that are out there -- JCP and open-source frameworks included. Healthy debate helps future technologies get better, and I'm sure that many of these will result in improvements in the final EJB 3.0 spec.
The author clearly states in the middle of the book, "No technology is perfect," and it's refreshing to see that he has skirted the holy wars that have long polarized enterprise Java developers. In doing so, he has done his best to keep the debate on level ground. The text occasionally shows the author's frustration from his past experience with the EJB specification, most notably in the earlier chapters, and he makes no effort to hide that he loves Spring, although I should point out in fairness that Spring does not use a standardized API. Thankfully, none of this is enough to distract you from the underlying design principles that make this book shine.
So although individual technologies and frameworks may fall in and out of favor with programmers in the next five years, the design possibilities that POJOs and their implied simplicity bring to programming will not. And that alone may be one of the best reasons to add this book to your bookshelf, no matter which road you take in your enterprise Java programming.
Curious about this book? Take a look at more information at the publisher's web site.
You can order Chris Richardson's POJOs in Action from the following sites:
If you are a Java technology publisher and would like me to review your Java SE, Java ME, or Java EE book, don't hesitate: Send me an email right now. No, I mean it. Stop what you're doing and write me. Have you contacted me yet? OK, good. And now for my standard disclaimer: I won't review every book I receive, but we all know that there are some gems out there that really deserve the limelight. So let me know what they are.