Expert One-on-One™ J2EE™ Development without EJB™

Introduction

This is a fairly short book, given its scope, because its subject is less complex than you've been led to believe.

J2EE orthodoxy makes heavy work of many simple problems. Indeed it sometimes seems that the J2EE industry is committed to the belief that there are no simple problems.

Many—probably most—J2EE applications are over-engineered, with unnecessarily complex architectures. Over-engineering can be very costly. J2EE developers tend to assume that increased cost up front will be more than balanced by reductions in future costs. Unfortunately, karma doesn't apply to software engineering, and this is often a fallacy. Greater complexity up front means more code to write and maintain, more potential for bugs, more delay in demonstrating functionality to users: ultimately, greater chance of failure, and at greater cost.

J2EE over-engineering usually involves EJB. As I pointed out in Expert One-on-One J2EE Design and Development, EJB is often used inappropriately. This is a real problem, because EJB can introduce more complexity than it conceals. Some services provided by EJB are also overrated. For example, few experienced developers or architects who have worked with entity EJBs to access relational data want to repeat the experience—at least, given the alternatives of JDO, Hibernate, and other transparent persistence technologies.

Critiques of EJB have become commonplace since late 2002. It's easy enough to pick the flaws in an imperfect existing technology, without suggesting ...