EJBs vs POJO?

The Lifecycle Mismatch

Jessica Thornsby

What’s wrong with EJBs?

It’s all down to the lifecycle, according to Germán Escobar. Their stateless, stateful or
singleton lifecycle is not sufficient when working on some
projects, such as a web environment or a business process. He would
much prefer a request, session and application lifecycle for
EJB.

Over the years, EJBs have dropped requirements such as XML
descriptors and Java interfaces, and become more POJO-like but, to
Escobar, this doesn’t matter: “until they don’t remove the
lifecycle restriction, you will end up creating additional layers
in your application and different component models to adapt your
required lifecycles.”

There have been some attempts to rectify the lifecycle mismatch
in EJB. These include Contexts and Dependency Injection (CDI) which
provides dependency injection and lifecycle management to EJB, but
this sits uncomfortably with Escobar as EJB already has lifecycle
management of its own.

To him, the solution lies in a combination of CDI and POJOs,
which he sees as providing all the services of EJB’s, with none of
those niggling lifecycle problems.

“So, do we really need EJB’s?” he asks “Well, not really!”

A visitor to his blog has pointed out that, although there are
inadequacies in EJBs lifecycle, the problem isn’t as bad as Escobar
believes. The stateful session bean plus CDI provides lifecycle
scoping by binding the reference to the designated context, and
when that context ends, the instance is destroyed. Escobar agrees
with him, but points out that this is not the case for the whole
EJB specification, there are still the stateless and singleton
parts of EJB to consider – and, he does have a point. If POJO and
CDI can provide everything EJB can provide, without some of the
lifecycle problems that come with stateless and singleton EJB, then
why would anyone use EJB?

Author
Comments
comments powered by Disqus