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 architec-
tures. 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 main-
tain, 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 experi-
enced 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 alternatives. This book breaks new ground in describ-
ing and illustrating better approaches for the majority of J2EE applications that derive no benefit from
EJB. This book is no mere theoretical discussion, but a practical guide to designing and implementing
high-performance J2EE applications on time and budget. Our suggested architectures are backed up by
extensive experience, a realistic sample application, and comprehensive open source solutions that meet
typical infrastructure needs.
Despite the significant problems that have emerged with EJB, it continues to be adopted too often largely
because of fashion and fear. Fashion because even nontechnical managers have heard of EJB and because
many books on J2EE architecture barely mention alternatives to EJB for delivering enterprise services,
even where excellent alternatives exist. Fear that the alternatives are worse: for example, that without
EJB developers will be left to handle complex issues such as transaction management without the train-
ing wheels of the EJB container. This book aims to show that these fears are largely unfounded. Where
the potential complexity is real, it shows that there are alternatives that do a better job than EJB at
addressing the problems concerned.
This book demonstrates a much simpler approach to developing typical J2EE appli-
cations than the “classic” J2EE blueprints approach exemplified by the original Java
Pet Store. Our approach leads to reduced cost, shorter time to market, greater main-
tainability, and better performance.
03_558315 flast.qxd 5/28/04 12:31 PM Page xvii