Honestly, the book is not a bad book, it presents an interesting yet hard topic, how to design EJB (or in a broader sense, J2EE application) using design patterns. However, this book has a large intersection with Core J2EE Patterns, which not only includes more patterns (on all layers), but also is written in a more clear and comprehensive way.

Except the patterns presented in both books, (Session Facade, Data Transfer Object(DTO), DTO Factory(Assembler), EJBHomeFactory(Service Locator), Business Delegate...) the author introduced,
"EJB Command" pattern, which in practice(IMO), has limited usage in server side enterprise application, since it distributes the business logic to command objects (usually the client) and thus will cause business rules duplication and more importantly, harder to change the rules later since its distribution;

"Generic Attribute Access and Data Transfer Hashmap" pattern, which is nothing but using map to transfer data. This again will suffer in distributed applications, since both clients and server have to agree on map key protocol and it is harder to add/change the keys later;

"Data Access Command" pattern, which derives from both command and data access object(DAO, presented in Core), not only will this pattern suffer the cons of command pattern usage in enterprise distributed application, but also potential complexity in command processing to make sure dead-lock situations, data integrity, and may end up with a lot of small customized command classes.

Even though the author mentioned the cons of these patterns clearly, I think the risk outweighs the benefit in an entry-mid level enterprise application design book which tries to teach designers how make a good design.

A few good things that were missed out by Core J2EE patterns are "Business Interface", "Version Number", "Dual Persistent Entity Bean", "Primary Key Generation". But these can be find somewhere else, particularly, "Version Number" and "Primary Key Generation" are more in the database/tranaction domain than EJB domain.

Chapter6 "From Requirements to Pattern-Driven Design" is supposed to be a case study, but is presented in a vague and not derived way to step through, it also lacks the normal iterative/refactoring design style, if everything is straightforward and in place to make a perfect design decision, then I would think the example would not be real. Though, I do like the author's layering style definition from Presentation, Application, Services, Domain, to Persistence.

Chaper7 is about development, building, testing, deployment process, it is totally irrelevant to the design pattern topic, and too short to be useful, and there are a lot of good books (instead of only one chapter) in the book store.

Chapter8 is about JDO, again, a single chapter would not make readers' day.

Chapter9 is good, it is about idioms, good practices vs. pitfalls in J2EE application design. However, the list is too short and does not provide how to refactor the bad design to good one compared with Core J2EE Patterns.

Overall, there are limited useful contents presented in this book, and I had feeling that a lot of stuff (unrelated) were stuffed in just to fill up the space to make it a decent-sized book. I would recommend Core J2EE Patterns over this one if you are interested in J2EE application using design patterns. Only one of these two books will stand last...