|
12 of 12 people found the following review helpful:
4.0 out of 5 stars
A nutshell review of Java Enterprise (in a nutshell), May 13, 2003
Disclaimer: I am an avowed O'Reilly technical series fan, and proud of it. Whenever I want to understand a new technology I head to the O'Reilly shelf in my local Borders before I look anywhere else. So adjust your expectations accordingly.As the name implies, this massive tome (971 pages stem to stern) covers a mind numbing range of technologies associated with "Enterprise" Java software development. There are 17 sections in all, as well as your standard API reference pages. As you would expect, all of the usual suspects are there - Servlets, JSP's, EJB's, JNDI, RMI, CORBA, etc. In addition there were other enterprise technologies that I found useful as well - Messaging, SQL, Java Mail and so on. When I sat down with this book my intention was to skim through each section, look to see if there was anything that they missed, and crank out the 'ol review. What I found was enough content in each of the technical sections to draw me into actually reading the whole section. I mean, who would take the time to read a full section on CORBA nowadays unless there were interesting things there (yes, I see all of you CORBA proponents shaking your fists out there - don't you have some IDL to write?). Once I completed the reference sections I cracked open the latter half of the book to take a peek at the API section. I found it well organized, asthetically pleasing, and about as useful as a screen door on a submarine. Note that this API publishing is NOT unique to O'Reilly - It seems that most of the technical publishing companies still commit arboreal mass murder to publish these API sections. Note to publishers: When the half life of the information you are printing is measured in months, think about a different delivery mechanism. I actually timed how long it took to find a reference using JavaDoc API info and a book. IIRC the JavaDoc lookup was about 3 times faster. Enough of that drivel. Back to the review. As you read through the different technical sections of this book the individual styles of the authors become apparent - you can tell that different sections are written by different authors. This is A GOOD THING - you are getting the technical poop from the one that knows the subject best. To rely on a single author for this size of reference would leave a lot of gray area. There is one specific area that I want to drill into, and that is the technical examples. I consider myself a relatively informed and skilled enterprise software architect (in the J2EE world - don't get me started on that Dot Net [stuff]). When I see a manual entitled Java Enterprise - I am expecting not only an API reference (see API rant above), but some real meat as to best practices in building enterprise level applications using this technology. So how did this book due in the technical example area? I'd have to give it a B. In most cases the examples were adequate to explain the technology at hand, but not really give deep insight into how best to take advantage of said technology. Now, don't get me wrong - this book has earned a place on the "near" bookshelf (the place where I keep all of my most referenced manuals). My opinion is that when you are trying to serve to very different purposes (desktop reference / enterprise technology primer) something has to give. Let me give a couple of examples of what I am talking about: 1) In the JDBC section there is a point where the book identifies OODBMS (Object Oriented DBMS) databases as a possible alternative to the rigors of Object/Relational mapping. Yes, the technology exists and does work, but how many companies out there run enterprise systems off of OODBMS's? It's a small market, and with the massive investments that most US companies have in RDB's that equation is not going to change soon. To say that OODB's are an alternative is a good thing in a quick reference, but in my opinion needs a disclaimer if mentioned in an enterprise java book. Along those same lines it wouldn't have hurt to mention some of the available O/R mapping tools out there (go Open Source!). 2) In the Servlets section there is a point where an application implementation is mentioned to illustrate a technical point (binding a java.sql.Connection instance to a HTTP session). Right in the same paragraph the author mentions that this is a "bad idea" (no kidding - unless you are an Oracle sales rep...). Now why go to all of the effort of painting this example, and then telling the reader that they shouldn't ever do it? Guys - take the time to figure out a valid example that illustrates the part of the API that you are explaining, 'kay? Again, don't get the wrong idea here. I'm definitely not panning this book. It's a valuable resource and worth the $...that you are going to plunk down for it. But if you are going to write a desktop reference for Enterprise Java make sure that the examples are restauraunt quality. After all, there is enough bad code out there in the world, and we can't have our beloved O'Reilly contributing to it, can we? In Summary (Finally! he's almost done!): As I mentioned before, this book has earned the right to be within arms reach from my little work pod. Not only is it a comprehensive reference, it makes a handy workout aide as well (971 pages...). And do yourself a favor. If you haven't checked out the O'Reilly line of technical books, head down to the nearest bookstore, grab yourself a double latte (try the Irish Cream and Hazelnut mixed together), find a comfy chair and give the series a once-over. You'll be glad you did. Jonathan House
|
by David Flanagan
by Chuck Musciano
by Elliote Rusty Harold
by David Flanagan
See all 9 books citing this book
