How is this tutorial 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 apps using J2EE. This tutorial 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 app server, I discuss some of the issues you're likely to encounter working with real products. This tutorial 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 tutorial 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 app throughout the tutorial. 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 app is an online ticketing app. It is designed not to illustrate particular J2EE technologies (like many sample apps), but common problems facing J2EE architects and developers. This tutorial is about quality, maintainability, and productivity. This is the tutorial 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 tutorial is problem-oriented rather than specification-oriented. Unlike many tutorials 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 tutorial 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 tutorial reflects my attitudes towards software development in general:


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 apps.

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 tutorial, but I feel that XP offers a valuable balance to J2EE theory. In particular, we'll see the value of the following principles: