Did you use EJBs in your last J2EE project? Many Java programmers (and their managers and CIOs) would consider this a strange question. "How can it be a J2EE project if it doesn't include EJBs?" they might ask. The answer is: Sun currently lists 11 J2EE component technologies of which EJB is but one; of equal importance are servlets, JavaServer Pages (JSP), and JDBC. In fact, a recently released research report by Gartner, Inc., reveals that most Java projects do not use EJBs, but rely exclusively on servlets/JSP. (While not specifically mentioned in the Gartner report, I would guess that a high percentage of those projects also use JDBC.)

How is it that EJBs have become synonymous with J2EE in the minds of so many people? One answer is the natural tendency of software vendors to try to sell you the most expensive product. Is a commissioned salesperson going to sell you an inexpensive servlet/JSP solution if he or she can convince you to buy an "enterprise" application server (with EJB!) for 10 times as much? The tendencies of human nature should make the answer to that question fairly obvious.

Sun has contributed to the perception that J2EE requires EJBs through the J2EE licensing program and by not offering a separate certification program for servlets/JSP. The only way for a vendor to achieve Sun certification for a servlet/JSP implementation is by becoming a J2EE licensee. The costs of becoming a J2EE licensee are structured toward the "enterprise" vendors and are prohibitive for smaller companies. Therefore, you'll find the role of J2EE licensees dominated by EJB server vendors. Contrast this with JDBC (a J2EE technology), which has a separate certification program with a much more reasonable cost structure and a higher participation rate by smaller vendors.

Finally, we must not overlook the role of Java programmers, developers, and engineers in forming the equation that J2EE equals EJB. We (yes, I put myself in this group) naturally want to work with the latest, hottest, coolest, biggest, sexiest, most important new technologies. We sometimes overspecify and overdesign, and say things like, "Sure, we don't have a requirement for that now, but..." And we always have an eye on what will look good on our résumés.

Why is this bad? Because it creates waste. In the same study mentioned above, Gartner estimates that over $1 billion has been wasted since 1998 on purchases of EJB servers for projects in which EJB was not used at all. Instead, those projects were based entirely on servlets/JSP. Gartner projects that if this continues, another $2 billion will be wasted from 2001 through 2003. Interestingly, their numbers include only the cost of the application server purchase; they don't include the wasted engineering man-hours due to the added complexity of working with an "enterprise" application server, despite the fact that only limited use is made of the full functionality of these servers.

What does this mean to you and what should you do? Wasting $1 billion in the go-go dot-com and high-flying stock market era may not have been such a terrible thing. But wasting another $2 billion in the current economic climate is foolishness. Make sure you understand your project requirements. Yes, there are good and valid uses for EJBs, but there are many more projects for which servlets/JSP (and JDBC) are more than sufficient. Make sure you have a simple, inexpensive, easy-to-administer servlet/JSP application server in your technology arsenal. And the next time someone asks, "Is your project based on J2EE?" smile as you reply, "Yes, but we're not using EJBs."