Book Review: Core J2EE Patterns
Jul 18th, 2005 by phil
Patterns are all the rage is the software development community these days, and with good reason. Patterns can help simplify the software design process and provides well understood solutions to common problems. J2EE development can be especially complex as it encompasses many challenging problem domains. Clearly, a good set of design patterns would help any J2EE architect sleep better at night.
The focus of Core J2EE Patterns: Best Practices and Design Strategies is design patterns for the J2EE family of technologies. The emphasis in the book is on the J2EE technologies and many of the patterns suffer from a too narrow focus on specific technologies. Most of the patterns in the book solve general problems in the enterprise development space, and do so in a fairly generic way. However, the authors have presented these patterns in a narrow J2EE only way and have thus diminished the value of the patterns. The book is obviously intended to address patterns in a J2EE environment, but that goal could have been achieved by presenting the problem and pattern in a technology-neutral way and then presenting strategies for implementing the pattern with J2EE technologies. The authors did themselves and their readers a disservice by not focusing first and foremost on the patterns and keeping the specific technologies in the background.
The presentation of the “Session Facade” pattern is a perfect example of this problem. The pattern describes providing a course grained facade for a set of remote fine grained business objects. The name of the pattern comes from the fact that the authors based the entire pattern around the use of EJB session beans, which is obviously their preferred implementation. The problem with this is that there are many ways to effectively implement this pattern that do not involve EJBs. In fact, this is a very valuable pattern in enterprise development and could just as easily be implemented with web services or RMI. The authors even admit as much when discussing the “Application Service” pattern where they draw a distinction between a “Session Facade” and a “POJO Facade”. They then settle on the name “Service Facade” for the pattern. This is just silly. The pattern is the same whether it is implemented with EJB session beans or a web service.
Some of the patterns, such as the “Composite Entity” pattern, are not so much good design as a bandage for a weakness in the J2EE technology. In this case, the pattern seeks to solve a problem with remote entity beans. While this particular pattern has been of dubious value since local interfaces for EJBs were introduced, it does hilight a common problem. The book assumes that you want to use EJB and that assumption affects the presentation of many of the patterns.
The book has a few other flaws as well. There is quite a bit of repitition in the description of the patterns. In fact, in some places it looks as though there was some cut and pasting going on. Also, the authors’ insistence on describing every variation on a pattern as a distinct strategy becomes tedious. In fact, the book can be somewhat difficult to read due to its repetitive and tedious presentation.
All of that having been said, the patterns themselves are, for the most part, very good. Unfortunately you have to wade through EJB propaganda and endless repitition to get to the real gems. In spite of that I recommend the book to any J2EE architect. Some of the patterns are presented in other books, but I think this particular collection is very valuable. You have to approach each pattern with a critical mindset and consider carefully how you would use it. It is important to separate the core pattern from the technology-laden presentation and apply the pattern in a way that makes sense for the circumstances.
You hvae to take the context of the book into consideration. That book was published over two years ago so it was most likely written three years ago. Back then EJB was they only way to go. I also don’t think you’ll find many Sun press books bashing EJBs or even Entity Beans. This book is also called J2EE Patterns, not Software Patterns or OO Patterns. You really thought they would keep these patterns technology neutral?
I read this book two years ago and agree there are some gems in there but sounds like what you where expectiong was “Design Patterns” by Erih Gamma. Maybe you should look at that one. It stays technology neutral.
Brian, Thanks for stopping by. I understand the context that the book was written in. However, I am reviewing it today and not two years ago. I still think the book is valuable for experienced architects, I recommended it after all, but the reader has to be prepared to dig for the gems in some places.
I read the Gang of Four book (Gamma, et al) 3 years ago, and I was not looking for that. I think that it is possible to describe the problem and the pattern as technology neutral and then describe the strategies as technology specific. When the problem and pattern definition are tied to a specific technology it makes it difficult to apply the pattern in scenarios that do not match exactly what the author had in mind. Patterns that are tightly coupled to specific technology are also unlikely to remain valid as the technology progresses.
The session facade pattern is an example of where the focus on a specific technology (session EJBs) made the pattern less valuable, even in a J2EE environment. This is a case where the reader has to dig for the real value in the pattern even though they may be working in a J2EE environment.