Customer Reviews

The J2EE Architect's Handbook

5 star:		(8)
4 star:		(1)
3 star:		(0)
2 star:		(2)
1 star:		(2)

 

 

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!

I develop applications using J2EE and .NET. I found that most concepts found in this book are equally applicable to the .NET arena as well. Good work.

In The J2EE Architect's Handbook : How To Be A Successful Technical Architect For J2EE Applications, Derek Ashmore draws upon his more than fifteen years of experience as a technical architect, consultant, and J2EE expert to show a new generation of software developers how to design and build J2EE applications that will be on-time and on-budget. Readers will learn how to design easily maintained J2EE applications; apply commonly used design patterns effectively; identify and address application architectural issues before they hinder the development team; avoid common mistakes known to derail project budgets and timelines; guide the development team through the design and construction process; set up effective procedures and guidelines to enhanced stability and decrease error reports; document and communicate the application design to target the development team's work; identify and address application architectural issues; and effectively estimate needed resources and project timeline. To put it simply, The J2EE Architect's Handbook can justifiably be considered to be the "bible" for J2EE based application designers and project managers.

This book is worth for the investment, a Senior Developer like me gets a great values by reading this book.

I don't know why it get One start from a reviwer, may be his expections and knowledge is very high.

Conclusion

A Great book , worth reading it, some times you can refer this book depends on your project requirement

This is a practical book targeted toward working architect's and designers in a business setting. This book concentrates on making you successful in an architect role and manage the project.

I liked the fact that it concentrated on the most heavily used portions of J2EE and didn't bog me down with stuff I don't use. It's also organized well and concise so I can get the important points in very little time.

There are a lot of J2EE books on the market and many of them are very good, but they are all focused on one or two aspects of a J2EE project. The J2EE Architect's Handbook is unique in that it is the only book I have found that takes you through the complete process of delivering a J2EE based project.

I would highly recommend this book to anyone involved in delivering J2EE based applications, regardless of whether you are new to J2EE or have been delivering J2EE projects for years.

This book has outstanding breadth of information for system architecture. Some details are quite basic, while others are quite indepth. Overall though, what's most important is that the book is very well written and serves its purpose well. It has many excellent strategies, along with a comprehensive feature list of most J2EE projects.

Definately a 5 star.

Overall, I feel as if the author must have skimmed a number of J2EE books, and then, borrowing from these sources, compiled a hodge-podge of spotty, dated, inaccurate, and often misleading advice. Please do not waste your money on this monstrosity. If you are curious to see just how bad this book is, the book is available for free in PDF format at theserverside.com (you can also find a more detailed list of the problems, and some additional reviews thers)

FYI, the best books I have read, that cover the topics that this book was intended to cover, are: Expert One-on-One J2EE Design and Development (a.k.a. the J2EE Bible), by Rod Johnson and Applying UML and Patterns, by Craig Larman. Although these books are not free, they both contain invaluable knowledge for aspiring J2EE Architects.