to ejb, or not to ejb?

addressing the issues and decisions that go into adopting an ejb-based solution

summary
–>

summary
since j2ees (java 2 platform, enterprise edition) earliest days, enterprise javabean (ejb) technology has caused much controversy, with developers and architects constantly struggling to make best use of ejb in their projects. consequently, our industry has spawned folklore and rules of thumb to guide us how best to use ejb — some true, some out of date, and some pure fabrication. in this article, humphrey sheil explains when and how to use ejb in your j2ee application, as well as how to know when ejbs are not the right solution for you. (3,500 words; december 7, 2001)

–>by humphrey sheil

o 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 shakespeares 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 wont 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 wont 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 solutions 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 ejbs 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, lets look at ejbs strong and weak points. in the disadvantages section, i also give solutions to commonly encountered ejb weaknesses.
ejb advantages
first, lets examine the advantages that the ejb architecture and programming model provides:

1. the underpinning ejb specification: funnily enough, ejbs main advantage — its specification — also represents its biggest disadvantage, as youll see below. the specification stipulates everything for ejb, from the various types, lifecycles, and restrictions, right through to roles and responsibilities. many vendors application servers conform to the specification, allowing you to select a best-of-breed solution.
   ejbs universal nature offers application developers well-defined roles (ill write the container and server, you write the business logic according to my apis). moreover, developers enjoy the certainty the spec delivers. indeed, by choosing an ejb solution, developers benefit from a large skills pool, along with established best practices and open standards. finally, found a show-stopper bug in your current server? if you have paid attention to portability issues in your design and implementation, with ejb you can circumvent it by moving to another vendor with minimum effort.

2. integration with the j2ee platform: since sun microsystems introduced ejb in 1997, a strong enterprise computing environment has grown up around it, including technologies such as servlets, jms (java message service), jsp (javaserver pages), the jca (java connector architecture), jdbc (java database connectivity), security, and transaction management. such integration enhances ejbs attractiveness as the j2ee platform includes so much other complementary technology.
   for you, the application architect or developer, you can rest easy because no matter how complex your application, the integrated, fully featured j2ee platform can handle your requirements.

3. almost transparent scalability: because you delegate so much to the container, the vendor can scale server-side resources to meet fluctuations in demand. i say "almost transparent" because developers are somewhat affected. in the case of horizontal scaling and entity beans, for example, where application servers are clustered, you usually need to modify deployment descriptors to let individual server instances know they are not the only processes accessing and modifying a persistent store.
4. free access and usage of complex resources: when you buy a specification-compliant ejb server, you receive important features for free, namely transaction and security management, resource pooling, jndi (java naming and directory interface), component lifecycle management, and more — representing heaps of systems-level code you would otherwise have to design, build, and maintain in-house.
5. a strong and vibrant industry and community: all the major it players, with the exception of microsoft, support ejb and j2ee, which means you are investing in a technology in which many other people have also invested. that investment commitment means the technology will be around for a long time. additionally, enterprise java technology continuously improves. for example, the ejb specification is currently at 2.0, having evolved from 1.0 and 1.1; a pattern likely to continue.