EJBs vs POJO?
The Lifecycle Mismatch
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?