Back in 1999, I enthusiastically embraced J2EE and started developing applications with servlets, JSP pages, and EJBs. Even though I was an uncritical fan of those frameworks, I found that I could simplify development by using what came to be known as "Plain Old Java Objects" (POJOs). For example, in the presentation tier I wrote servlets that delegated to POJOs. And in the business tier I wrote session beans that delegated to POJOs and entity beans that extended POJOs. Using POJOs enabled me to test my code without having to wait for it to be deployed in the server. Because POJOs were not directly supported by the servlet and EJB frameworks, however, I had to jump through a few hoops to use them.
Ironically, it wasn't until after writing an article describing some of those hoops that I started to use lightweight frameworks which support POJOs directly. A couple of reader comments were along the lines of "Why bother with entity beans - why not use an object/relational mapping framework instead? It's a lot simpler." Another reader suggested using Hibernate and another suggested JDO, which were two technologies that I was only vaguely aware of. After experimenting with them for a couple of weeks, I realized that they made persisting objects a lot easier. I found I could develop and test most of the business logic outside of the server. I was hooked!
Hibernate and JDO replaced entity beans, but what to do about those pesky session beans? They need to be deployed in a server, which slows down development. The solution came in the form of the Spring framework. I'd read a few articles about Spring, but its significance did not sink in until I went to TheServerSide.com?s Java Symposium (TSSJS) 2004. For the three days I was there, I was indoctrinated in the joys of dependency injection, Spring, and aspect-oriented programming (AOP). I realized that I could replace the session beans with Spring-managed POJOs. I started using Spring right away and immediately found that I could do most development without going near a server. And if a server was required, I could mostly use lightweight servers such as a Jetty. The impact on development was remarkable.
Somewhere along the way, I decided to write this book to share what I had learned. My goal is to teach other developers simpler and faster ways to write enterprise Java applications. I also want to contribute to the Java community from whom I had learned a lot by reading all of those books, articles, and blogs. Originally, this book was going to cover EJBs, JDO, and Hibernate. I had planned to write about how to use POJOs and EJBs together. But when I discovered that a pure POJO and lightweight framework design was a much better approach for many enterprise Java applications, I decided to write a book that focused on POJOs.
Writing this book has been an "interesting" experience, to put it mildly. It has occupied all of my spare time for so long that I've worn out my desk chair and occasionally I'm surprised that I have three children instead of two. (When did that happen?) Along the way I've learned a lot. I've been challenged to think hard about what works and what doesn't. I hope that in this book you will find simpler and faster ways to develop your enterprise Java applications.