J2EE Development Without EJB, Expert One-on-One (Paperback)

The development methodolgies and architectures in practice today, particularly in large corporate environments, are heavily influenced by marketing literature from the major vendors. It's texts such as this (and in particular Johnson's earlier book J2EE Design and Development) that should go some way to filling the information gap surrounding J2EE development in general.

All of the criticism of EJB made in the book is amply backed up with a mixture of common sense and practical experience. Make no mistake about it, this is not someone on a crusade, this is someone who has used EJB in many large projects (and with success) but simply realised there were better alternatives in many, even most, situations. The first third of the book details EJB history and the authors' opinions on its limitations. It also deals pragmatically with the requirements that make EJB the right implementation choice to make and this is valuable infomation too. If there's one criticism I would make here, it's that it's a little excessive and repetitive on the failings of EJB. But maybe that's just because I didn't need much convincing anyway.

The remainder of the book focuses on real world alternatives, heavily biased towards the Spring Framework which Johnson invented and continues to devote much effort to. Spring is a solid, mature framework that has already been deployed in production applications (including a major global investment bank) even before it's official 1.0 release. The framework leverages many of the key J2EE services traditionally associated with use of EJB such as declarative transaction management and business object life-cycle management. Lightweight "IoC" frameworks impose far fewer dependencies on domain objects and seek to integrate external components that already do an excellent job such as Hibernate/iBatis and templating technologies that offer good alternatives to JSP. Once again though, there is no attempt to evangelise or to push a preferred technology without reams of practical back up based on real world experience.

If you're stuck in EJB hell, buy this book and discover the road to recovery. If you're an "EJB everywhere" advocate, buy this book and find out what the growing number of EJB refugees are using as alternatives. If it changes nothing about the way you work, you'll at least be better informed as you go about it.

Top marks.

"Without EJB" basically simplifies the concepts of J2EE development by revisiting the reasons why we choose to use Object Oriented technology in the first place. The great thing about this book is that it doesn't oversimplify the solution by leaving out parts of the problem.

The technology purists among you will welcome this refreshing and surprisingly unbiased look at J2EE. This is not just a book telling you to use Spring and IoC instead of EJB. This book explains when EJB works well and when it doesn't (and mostly when it doesn't for that matter!) It also considers other IoC solutions (e.g. PicoContainer) and represents these without bias - well as much as can be expected really!

This book is a welcome read for the hands-on architect. It clearly describes a number of practical and simplified ways of rewriting the bloated reference PetStore J2EE application, without changing the data model. The solutions presented are downloadable and executable and serve as good starting points for your own applications.

My only complaint with this book is that it tends to repeat itself on the advantages and disadvantages of certain architectures throughout. If you read this page-to-page, it actually takes a while to get into the practical stuff of what IoC and Spring is all about, by which time some may lose interest. However, the style of writing allows you to dive straight in to the detail. Each chapter reads fairly independently.

Overall, an enlightening read for many people I'm sure... Rod Johnson is clearly an interesting guy who can write well, and I look forward to his next publication on Spring, or any other subject for that matter.