Rating: 
Summary: Certainly NOT the J2EE Bible !!!
Review: This book covers many topics, unfortunately it does not go into great detail on any of them. I don't know what the author was trying to do with this book, but I do know that this is not the new J2EE bible as some of the other reviewers have stated. Some of the topics covered have nothing to do with J2EE, they are project management topics.
If you are looking for a real J2EE book look elsewhere.
Rating: 
Summary: Concepts applicable in J2EE as well as .NET
Review: 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.
Rating:
Summary: Practical for beginners
Review: I'm a Junior J2EE Technical Architect and I just finish reading your book. It's really interesting and instructive. It helps me a lot on my project planning.
Rating:
Summary: The "bible" for J2EE based application designers
Review: 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.
Rating:
Summary: The worst J2EE book available
Review: 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.
Rating:
Summary: An excellent book on the role of a J2EE Architect
Review: 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!
Rating:
Summary: No Other J2EE Book Like It
Review: 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.
Rating:
Summary: No Other J2EE Book Like It
Review: 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.
Rating:
Summary: Great Book
Review: 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
Rating: 
Summary: Miss the Mark
Review: 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".
|
