How is this Book Different?

First, it's an independent view, based on my experience and that of colleagues working with J2EE in production. I don't seek to evangelize. I advocate using J2EE, but caution against J2EE orthodoxy.

Second, it has a practical focus. I want to help you to implement cost-effective applications using J2EE. This book aims to demystify J2EE development. It shows how to use J2EE technologies to reduce, rather than increase, complexity. While I don't focus on any one application server, I discuss some of the issues you're likely to encounter working with real products. This book doesn't shy away from real-world problems that are not naturally addressed by the J2EE specifications. For example, how do we use the Singleton design pattern in the EJB tier? How should we do logging in the EJB tier?

This book doesn't seek to cover the whole of J2EE. It aims to demonstrate effective approaches to solving common problems. For example, it focuses on using J2EE with relational databases, as most J2EE developers face O/R mapping issues. In general, it aims to be of most help in solving the most common problems.

We'll look at a single sample application throughout the book. Rather than use an unrealistic, abstract example as we discuss each issue, we'll look at a small part of a larger, more realistic, whole. The sample application is an online ticketing application. It is designed not to illustrate particular J2EE technologies (like many sample applications), but common problems facing J2EE architects and developers.

This book is about quality, maintainability, and productivity.

This is the book I wished I'd had as I worked on my first J2EE project. It would have saved me a lot of effort, and my employer a lot of money.

My Approach

This book is problem-oriented rather than specification-oriented. Unlike many books on J2EE, it doesn't aim to cover all the many services and APIs. Instead, it recognizes that not all parts of J2EE are equally useful, or of interest to all developers, and focuses on those parts that are used in building typical solutions.

Software design is as much art as science. The richness of J2EE means that it is often possible to find more than one good solution to a problem (and many bad solutions). While I make every effort to explain my views (or prejudices), this book naturally reflects my experience of and attitude towards working with J2EE. I present an approach that I've found to work well. However, this doesn't mean that it's the only valid approach.

The book reflects my attitudes towards software development in general:

• I try to avoid religious positions. I've never understood the energy and passion that so many developers devote to flame wars. This benefits no one.

• I'm a pragmatist. I care about outcomes more than ideology. When I work on a project, my primary goal is to deliver a quality result on time and budget. The technology I use is a tool towards that goal, not an end in itself.

• I believe that sound OO principles should underpin J2EE development.

• I believe that maintainability is crucial to the value of any deliverable.

Note 

In keeping with this pragmatic approach, I'll frequently refer to the Pareto Principle, which states that a small number of causes (20%) are responsible for most (80%) of the effect. The Pareto Principle, originally drawn from economics, is highly applicable to practical software engineering, and we'll come across it repeatedly in approaching J2EE projects. For example, it can suggest that trying to solve all problems in a given area can be much harder (and less cost-effective) than solving just those that matter in most real applications.

My approach reflects some of the lessons of Extreme Programming (XP). I'm a methodology skeptic, and won't attempt to plug XP. This isn't an XP book, but I feel that XP offers a valuable balance to J2EE theory. In particular, we'll see the value of the following principles:

• Simplicity. XP practitioners advocate doing "the simplest thing that could possibly work".

• Avoiding wasted effort. XP practitioners don't add features they may never need. This approach is captured in the acronym YAGNI (You Aren't Going to Need It).

• Focus on testing throughout the development process.