Wow! I picked up a copy of Expert One-on-One J2EE Development without EJB by Rod Johnson and Juergen Hoeller and it is very good. I guess this book has actually been out for about a year now, but I just recently saw a copy at my local bookstore. I read the first book by Rod, Expert One-on-One J2EE Design and Development a while back, and it is actually a recommendation in my meet the authors profile
This book, like the first one is a great read. I'm currrently heads down with performance testing on a project so the only chance I have had to read so far has been a couple of chapters in a plane. Rod is a great writer and speaks a lot from experience. I usually have trouble just sitting and reading technical books, rather I use them as resources when I have a problem or question, but with this book that is not the case. In fact if you try and do that with this book, you will be missing out on a lot of good stuff. I was excited by many of the things that Rod talks about in this book, many of his points are topics that I have alluded to in earlier blogs. Except for the fact that Rod just comes out and says what he thinks, and then he backs it up with experience and examples. Fun stuff to say the least!
I have to concur (it's hard to disagree) with many of the comments Rod makes about the use, or maybe the mis-use, of EBJs, although it's been years since I've actually written a full EJB application, and that was in the late 90's when the spec was still young. Anyway, to make a point, this book got me thinking about how we use EJBs in portal projects. For the most part, we don't. I can only think of a handful of portal projects that have used EJBs in the last few years, and those were mostly migration projects that attempted to reuse as much from the legacy app as possible. I'm actually happy about this. Most of the projects that I get involved with are complex enough. Thinking back, rarely have my projects not had a B2E focus, or rather what we call an "On Demand WorkPlace". These types of projects, for the most part, do not have a lot of transactionality requirements, and those that do have that aspect of the portal usually integrate or launch a separate application that provides the heavy lifting.
Rod's message is very consistent with my constant badgering of folks about keeping things simple. He says it much nicer then me of course. For portal this is especially true when you are just starting out with your first release. This is pretty much all I do with most of my time. That is, either help people deliver a first release, or help fix a portal that has tried to go live (or is about to go live) and is having problems. Obviously complexity is a common factor in many of these issues, and EJB's can be very complex components. There are other things that add complexity also. Most of you know my thoughts on using Struts, and now JSF in portlets. I tend to think they may cause more problems then they help solve (read this for more background), and I am still asking the question as to whether the added business value (i.e., lowered cost and greater functionality) is worth the overhead, learning curve and limitations that they can also sometimes bring with them. These are important questions that architects have to seriously ask themselves before they dive headlong into adopting an approach and sending their team on a path toward potential disaster.
For now read this book if you get a chance, I promise you will learn a thing or two!