Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

To EJB, or not to EJB?

Addressing the issues and decisions that go into adopting an EJB-based solution

By Humphrey Sheil, JavaWorld.com, 12/07/01

To EJB, or not to EJB: that is the question.
Whether 'tis nobler in the mind, to suffer
The slings and arrows of outrageous licensing;
Or to take arms against a sea of potential overheads and features,
And by opposing end them? To roll your own: to reinvent the wheel;
No more; and by reinvent, to say, we continue
The heart-ache of low-level systems maintained in-house,
and the thousand natural shocks
That flesh is heir to; 'tis a consummation
Devoutly to be avoided.

(For Shakespeare's original "To be, or not to be," speech from Hamlet, see the sidebar.)

Once you have forgiven me for taking Hamlet apart with a chainsaw, you will realize that the lines above sum up the quandary every J2EE (Java 2 Platform, Enterprise Edition) architect faces: Are you over engineering your solution by employing EJB (Enterprise JavaBean) technology when the signs point to a different approach, indeed, perhaps a different technology? On the other hand, if you decide not to specify an EJB-based solution, have you subsequently found that a sizeable chunk of your code (that must be maintained) handles tasks best addressed by a container or a server?

This article shares with you how I methodically answer these questions.

Before I begin, let me set your expectations and explain my motivations for writing this article. First up, I do not answer the EJB/not EJB question for you, but I do provide a toolkit with which you can answer that question for yourself. Second, I have no hidden agendas: I do not represent an EJB server vendor, so I won't push EJBs for everything. On the other hand, I do not represent a technology or technique competing with EJB, apart from presenting it to you here as an alternative, so I won't deride an EJB solution where it makes sense.

Indeed, my motivation for this article stems from reader requests following my last JavaWorld article, "J2EE Project Dangers." In that article, I briefly touched on the danger of over-engineering, specifically around EJBs. Many readers requested a more in-depth treatise on the subject -- so here it is!

With that in mind, I propose to proceed as follows: In order to understand if you need EJB, you must understand an EJB solution's main advantages and disadvantages. As with all technologies, EJB has its weak points, and knowing these weak points is the first step to avoiding them. Following the discussion on EJB's weaknesses, I briefly outline alternatives to an EJB-based solution, both inside and outside the Java/J2EE world.

The final section is a proofing check. When you reach this part of the article, you should be comfortable applying the principles previously outlined to any business scenario. In that section, I present a progressive scenario that requires a solution (I promise not to pick either a pet store or an ATM machine!), make my call on the EJB/no EJB decision, and let you agree or disagree with my reasoning.

EJB advantages and disadvantages

Moving along, let's look at EJB's strong and weak points. In the disadvantages section, I also give solutions to commonly encountered EJB weaknesses.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.