The J2EE Architect's Handbook: How to be a successful technical architect for J2EE applications [Paperback]

This is a book helping an architect to achieve the success of conducting a project from both managerial and technical side. Unfortunately, I don't think it serves its objectives.

The first section "Planning J2EE Applications" is ok. It explains an architect's role and functionalities in project planning, how to scope and define the project, how to estimate the timeline, etc., it generally applies to every commercial project not necessarily the J2EE projects.

The second section "Designing J2EE Applications" is not too bad either. It suggests taking "a layered approach" to J2EE application design, and talks a little bit both object model and data model, very shallow yet still common basic techniques. The author uses "Deployment Layer" which is confusing, since most people would use either service layer or facade layer instead.

Section 3 "Building J2EE Applications" is really the place that technical stuff was filled in. However, it is also the place that contains a lot of the contents that I can not agree with, or at least contradict with my experience. For example, Considering VO (value object, data transfer object would be more appropriate) as architectural component is way too heavy for me, since it is just data holder/carrier between layers, it does not impact the collaboration and interaction of the core architectural components; the business layer components are the core components and should be built first instead of any other layer components; allowing business object to manage its own transaction and database connection would defeat its minimal dependency (to achieve maximum reusability) design purpose; good design should use service layer to wrap the transaction (if it can not be applied declaratively); data access should also be transparent to business object, database connection is really implementation details (to access data from a specific data source as database) and should be encompassed in data access object itself. There are a lot of such advises that I consider technically wrong.

Section 4 "Testing and Maintaining J2EE Applications" is good start, it touches some areas such as performance and scalability briefly, but too way to lightweight to be any helpful.

Overall, the author starts with good intents but fails to accomplish the tasks. Also, I have the impression that the author is trying hard to "sell" his open source project, "CementJ".

The other night I was helping put into context the concepts in this book with a colleague of mine. And in the process, we both came to understand that though this book (ignoring the title) is a great architectural road map for an undescribed and predefined business issue for a three tier web based application, it is not a handbook, nor is it for an architect.

This is a book that would be a great book for someone who's building a web based application and is looking for a blueprint to follow instead of having to come up with one themself. This is mostly because of the rather heavy handed approach the author declares how a system should be built. It's always good to have a point of view, but tools for how to design are always better than the design itself for a practitioner. This book seems to provide few tools to learn how to design.

Based on that, if this book was titled differently with a different forward I would have given it a much better rating, but as it stands and the misleading nature of the title and forward, I've given it a low rating.

If you are an aspiring architect or are looking to learn more about the architectural process there are the following books, which are a good read and reference books:

A Software Architecture Primer

Beyond Software Architecture: Creating and Sustaining Winning Solutions (Addison-Wesley Signature Series)

Simple Architectures for Complex Enterprises (PRO-best Practices) (Best Practices (Microsoft))

For those looking for patterns of implementation beyond "The Gang of Four" patterns book, there are the following books (I normally keep multiple copies of them):

Implementation Patterns (Addison-Wesley Signature Series)

Analysis Patterns: Reusable Object Models (Addison-Wesley Object Technology Series)

Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)

Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Addison-Wesley Signature Series)

Please ignore the 1-star reviewer's damning comments on this book. Comparing this book with Larman is ridiculous - to begin with this book has an entirely different focus to Larman's. I can only assume that the reviewer in question didn't really understand the value of what he was reading because he was really looking for something else from this book: something it wasn't ever intended to deliver. Thus, I imagine, he was disappointed and gave a staggeringly unbalanced view as a result.

I read this book this evening and found it an outstanding piece of work. Even if you're a whizz with UML, a genius at writing use cases, a dab hand at programming and a guru on OOAD you'll find a quite contrasting chunk of knowledge in these pages.

Yes, I'm sure that if you look around on a well-stocked technical bookshelf you'll find a lot of the material covered in this book.Much if it you won't, regardless of how big your library is.

This book is a guide to fulfilling the role of a J2EE architect, from project inception through coding standards and logging strategy on to rollout and beyond. That the author considers a large number of technical issues on top of this material is a credit to him - the book is only 280 or so pages long yet delivers, for the most part, sound guidance on technical and administrative issues alike.

The moderate page count and writing style make the book a pleasurable read. I believe you can pick up much of geniune value and finish the book within a day without your eyes glazing over.

I take issue with a small number of the author's suggestions: particularly avoiding the use of checked exceptions in favour of the unchecked variety. His argument is that code becomes less cluttered (i.e. less explicit exception handling) and that programmer productivity is enhanced. His justification for this (including references to the Sun documentation) is really rather flimsy. Although a dogmatic checked exception programmer in the past he now takes the opposite approach. To his credit the author acknowledges that his views are controversial.

My view on this subject is that life ain't so simple and there are horses for courses. Checked and unchecked exceptions each have their own merit and are each more suitable in certain circumstances. I think the author needs to re-examine his convictions: he must surely realise why checked exceptions are such a strong selling point for Java in the first place.

In many other languages unchecked exceptions are the norm, often leading to exceptionally poor exception handling practices: recoverable exceptions tend to get treated as unrecoverable at higher levels in the call stack. The semantics of an exception are often completely lost in the stack trace and understanding why an exception was thrown becomes harder...particularly as personnel changes during the project. We know where the exception happened but finding out why and its ramifications becomes much harder - human laziness shouldn't be underestimated as a source of future problems.

Nevertheless, I found the book is an excellent handbook for the practioner, apart from my major disagreement with the author over exception handling. If possible I'd take a half a star away from the five I've given because of this. However, since the book is short, useful and great value (because of it's usefulness) I'm giving it 5 stars. If it helps to offset the 1-star review a little bit then I can live with that!