Discuss this Article

Introduction

I was excited to see J2EE Development without EJB come across my desk at work. This is the new book by Rod Johnson and Juergen Hoeller, both known well partly for being the lead developers of the Spring Framework.

Rod’s first book was J2EE Design and Development, also in the “Expert one-on-one” series from Wrox (now owned by Wiley). The first book took a bold step. Rod discussed his real world experience with J2EE, and offered up some advice, some patterns, and some good thoughts on architecture and development in our world. This book takes that to the next level.

It is very important to mention what this book is NOT.

• It isn’t about bashing EJBs, and anyone who uses them
• It isn’t about patting the Spring Framework on the back, and suggesting that you have to use it, or that it is the only good solution to your problems

This is very important. It would be very easy to make the book a rant on EJB, and to make the rest of it be Spring 101. Thankfully, this is far from the tack of this book. The book actually offers different information for different purposes. I would say the book has three sections that could have been their own book even :)

1. Architecture: There is a thorough high level view of architecture in the enterprise Java arena. We learn from history, from real projects, and look to the current trends.
2. The lightweight container movement: Here we look into what the movement is about, what it is helping us solve, how AOP fits in, and finally about the Spring Framework itself.
3. The sample application: At the end we get to discuss a case study (unfortunately the PetStore :/) and are walked through various decisions that were made.

Let’s walk through these sections and see what they have to offer:

PART ONE: Architecture

• Why “J2EE without EJB”
• Goals
• Architectures
• J2EE Architectures in Practice
• The simplicity dividend
• EJB, Five years on

PART TWO: Lightweight containers and Spring

• Lightweight contains and Inversion of Control
• Introducing the Spring Framework
• Declarative middleware using AOP concepts
• Transaction management
• Persistence
• Remoting
• Replacing other EJB services
• Web tier design
• Unit testing and testability
• Performance and scalability

PART THREE: Sample App

Part One: Architecture

I feel that I have to stress again that this book is NOT about, nor a huge plug for Spring. If you never use the Spring Framework in your life you would still get as much out of the book.

One of the reasons I like Spring is the pragmatic, practical approach. It gives you the developer tools to get your work done. The book is written in a similar way. You can tell all the way through that that authors have really thought about what they are talking about, and come with much experience.

The first few chapters are the type that you will read with a smile on your face. You will nod too yourself, and most of it will make perfect sense to you. You have been there. You have seen the problems that are discussed.

Every effort has been made to not specifically get into Spring at this point. It is very politically correct, in fact almost too much so. You will see “Hibernate, or JDO” a lot in the text. Maybe we should create a new acronym H/JDO which means the same thing. I think they did a great job in not favouring a particular project (although of course Spring is gone into detail).

If someone in management jumps to the conclusion of “Use EJB” you can have them read these first chapters. It isn’t a pure rant on EJB, but discusses the issues at hand, and how EJB isn’t necessarily the best choice for every solution. However, they do talk about how EJB can be a good solution, in a few scenarios.

A good read, my only complaint is that it gets a little long in some places.

Part Two: Lightweight containers and Spring

There is a lot of meat to the chapters in the middle of the book. We are systematically walked through the tiers, and subsystems that we often require. Again, they spend time discussing the system in question in the abstract before rushing into the Spring-way.

For example, if you open up the web tier chapter, you will be shown the parts and pieces of that tier, and the various types of solutions to the problem. You will get the authors opinions of Struts, WebWork, Tapestry, and JavaServer Faces, before you get to Spring MVC. It gives you a good overview of the playing field. This style is mimicked throughout the other chapters in this section as well.

I really enjoy how practical these chapters are. Read the chapter on AOP and you will not only understand a little about AOP in general, but you will understand where Spring stands, and how to USE IT in your applications. A lot of knowledge is passed on here.

I also would be willing to wager that the Remoting chapter will offer some new insight. We have more choices in our tool belt that just the classic remoting of RMI / EJB, and the heavyweight WSDL based services. There is a good discussion on the lightweight remoting of Hessian and Burlap (from Caucho). A very interesting read indeed!

Near the end of this section we get into a few different chapters. We get a take on unit testing and Test Driven Development. The Spring Framework itself eats this dog food, and we are shown how it all works. We also get a glimpse at some tools for code coverage and such.

Many books pass the buck when it comes to tasks which we all need to do. My most common peeve is that there isn’t anything out there on handling complicated enterprise build systems. Performance and scalability is another item that is often overlooked, or skimmed. This book discusses both the architectural choices, as well as implementation ones. It also promotes an evidence-based approach to performance, and shows us a few tools. This all leads us to the sample application…

Part Three: Sample Application

This area is both interesting, yet probably the weakest part of the book, in my opinion. There is a lot of good information here on the PetStore application, and the Spring version. I really like how they made some of their decisions not based on “what is the theoretically best thing to do here”, but rather “what makes sense for us”.

For example, since they adapted the iBATIS version, they didn’t bother re-architecting the areas that were working fine. This meant that they ended up with iBATIS SQL MAPS for persistence, rather than a Hibernate.

I am probably more sick of the PetStore than most ;) so would have liked another case study too. However, the book is already plenty long, and they had to stop somewhere!

Conclusion

If you are working with enterprise Java you should read this book. It is as simple as that. This isn’t just about Spring, it is about the problems we currently face daily in our projects. The book is written by one of us, for us. It is really refreshing to be able to say that, as often I find that authors are technologists in their own worlds… people who sit on committees and plan the future.

Although the book goes into good detail on Spring itself, don’t look for it to be Spring: Every API that you can ever use. There is definitely room for other books such as Spring Live!

If you haven’t played with Spring much yet, this book will probably have you downloading it and giving it another look.

PRINTER FRIENDLY VERSION