Oct 19, 2014

Still using EJB's: Is EJB dead - Not Yet

EJB - Server side components to hold business logic with lot server provided capabilities.

EJB evolution - 

EJB 1.0 was released in 1998. EJB 1 had basic component features like RMI, deployment descriptor, Security, transaction, along with bean types: Stateful session beans, Stateless session beans, and Entity beans. Session beans hold business logic. Stateless session bean is request scoped, where as Stateful session bean holds conversational state. Entity beans were not just POJO. Entity beans were coarse-grain object(bean) with functionality, data, and dependent objects. Creating Entity bean means fulfill following -
Create remote interface for bean, create home interface for bean, define primary key, implement remote interface methods, implement EntityBean interface and its methods, methods that match home interface methods, deployment descriptor. This was tough.

EJB 2.0 introduced local interfaces and message driven beans. CMP beans were extended with capability to define relationships (CMR). Multiple entity beans were allowed to have relationship.

EJB 2.1 added web service and timer service support. MDBs and EJB-QL were enhanced.

EJB 2.1 and earlier required deployment descriptor.
EJB 2.1 & earlier required two minimum interfaces - home & remote.

EJB 3.0(2006) was giant leap which excluded the need for deployment descriptor, home & remote interfaces, introduced annotations, EJB's are now POJO and expose POJI, Interceptors, and new persistence model JPA 1.0 to supersede Entity bean components.

EJB 3.1 further simplified EJBs and added new features; No-interface view, .war packaging, Singleton session beans, application initialization & shutdown events, timer enhancements, and @Asynchronous in session beans.
Subset EJB 3.1 lite excluded features - remote interfaces, RMI-IIOP interoperability, JAX-WS endpoint, persistent timers, and message driven beans.

The current EJB's have complete capabilities to write server side layer with business logic, transactional, secure, and persistence.

EBJ is used as a business layer in a 3 tier architecture. We can almost everything using EJB and design complete application/business layer using EJB's only.
All we need to know, how easy is to develop a EJB layer, that can process any request of presentation layer. Because EJB is just like any other java class with some annotations. But since it is an EJB, container does lot behind the scene, which we take for granted like -
Concurrent EJB access by multiple clients in thread safe manner.
Scalable layer with load balancing & clustering.
Provide JNDI for lookup
Dependency Injection
Transaction management
Message handling using MDB's
Scheduling using Timers
Interceptor service
Web service support

3-tier architecture -

Stateful session bean had bad reputation since its inception and was rarely used. Stateless session bean was the most commonly used EJB. Clients (like servlet) call the Session Bean (stateless) generally remotely and session bean interacts with entities (or entity beans of 2.1 or earlier). Session bean responds back to client. Session bean provided remote & local interfaces. In case a asynchronous call was required, a common approach is to use JMS, send message over queue, and use MDB (Message driven bean) to handle message and respond back asynchronously. So Session bean and MDB's act as facade which manage entities and hold business logic.

A call between Servlet and EJB (session bean) might be remote or local.
We can have several session beans implementing business logic. Each session bean encapsulating a business case, and interaction between session beans is always possible. A session bean can call other session beans and involve one or more entities, all these can be done in single transaction or in multiple transactions based on how we configure. Best part of using EJB's is how container manages transactions.
Transactions involving different resources like (Database, JMS destination, IBM MQ, etc.) can be merged into one so if rollback happens it is done on all resources.

I was working on a project of stock market - middle office in 2009 where we used EJB 3.0 + JPA.
We decided on using UI JSF as presentation, EJB for business layer and any ORM solution.
We went for Oracle, and used ADF for presentation layer and EJB and Toplink as ORM. The development was damn fast and complete middle office was developed in 6 months.
User actions on ADF (UI) are mapped to EJB (session bean) methods, Managed beans (ADF backing beans) are mapped to entities, and its done.
Drag and drop components from pallette, double click action buttons to map to EJB methods, map backing bean to entities, set cache settings in Toplink, and its done. Project is ready.
Possibly you can check below tutorial -
But JSF's are dead already, above design is old and most probably no longer will be used.

Downfall of EJB and Rise of Spring - 

Coming back to EJB's, why EJB's got bad reputation was because of two reasons -
1. Over complicated EJB 2.1 & previous versions
2. Highly advanced Spring framework in 2004.

Some nicely engineered features of Spring like APO, Inversion Of Control, MVC framework, and integration with Hibernate - changed the complete design of Java EE software's.
Declarative transactions can be applied to any POJO and can be deployed in Tomcat.
Spring+Hibernate ruled the Java EE software architecture from 2005 to 2010 and is still most popular framework.

Reinvention of EJB - 

EJB was reinvented with EJB 3.0, which included annotations, Dependency Injection, and POJO's.
EJB+JPA became alternative to Spring+Hibernate. But EJB was limited to few types of beans and annotations, compared to full fledged framework Spring. The power of Sping was in beans and its modules like Spring Webflow, Spring MVC, etc. In Spring it was easy to create layer's of beans, inject beans into one another, define scope of beans (session, request, singleton, prototype, etc.), integration with EL, etc. We can create a layer of Controllers beans, layer of Service beans, layer of Business objects, etc. And inject one layer beans into another using DI which means ability to choose at deployment time which implementation to use.

CDI - 
CDI (Context Dependency Injection) was introduced in Java EE 6 and below was mentioned on Oracle site for Java EE -
"Contexts and Dependency Injection (CDI) for the Java EE platform is one of several Java EE 6 features that help to knit together the web tier and the transactional tier of the Java EE platform. CDI is a set of services that, used together, make it easy for developers to use enterprise beans along with JavaServer Faces technology in web applications. Designed for use with stateful objects, CDI also has many broader uses, allowing developers a great deal of flexibility to integrate various kinds of components in a loosely coupled but typesafe way.
The most fundamental services provided by CDI are as follows:
Contexts: The ability to bind the lifecycle and interactions of stateful components to well-defined but extensible lifecycle contexts
Dependency injection: The ability to inject components into an application in a typesafe way, including the ability to choose at deployment time which implementation of a particular interface to inject
In addition, CDI provides the following services:

  • Integration with the Expression Language (EL), which allows any component to be used directly within a JavaServer Faces page or a JavaServer Pages page
  • The ability to decorate injected components
  • The ability to associate interceptors with components using typesafe interceptor bindings
  • An event-notification model
  • A web conversation scope in addition to the three standard scopes (request, session, and application) defined by the Java Servlet specification
  • A complete Service Provider Interface (SPI) that allows third-party frameworks to integrate cleanly in the Java EE 6 environment "
CDI's are so impressive that many feel that CDI is replacement of EJB. 

More about CDI can be read on Oracle websites, but for sure most of the things done using EJB or Spring are possible doing with CDI. But CDI should not be thought as replacement of EJB since because features like timers, asynchronous, declarative transactions, monitoring, and pooling are only available to EJBs. In future CDI might include all aspects currently available in EJB 3.1, but for now a Java EE design will have EJB as a layer with CDI's injected. 

One more major reason of still using EJB's is that  -
"Although an EntityManager injection works also for CDI maanged beans, the beans cannot be directly exposed to the UI layer. 
The EntityManager in a stateless environment can be configured only with the 
@PersistenceContext(type=PersistenceContextType.TRANSACTION) annotation, which is also the default value. Every interaction with the EntityManager requires, therefore, an active transaction; otherwise a javax.persistence.TransactionRequiredException is thrown. Transactions cannot be started in CDI managed beans - out of the box. An EJB solves the problem elegantly, because neither manual transaction management nor realization of CDI extensions is required to start a transaction. A single, no-interface view bean, such as a facade, manages the transactions without any further configuration, frameworks, or manual coding" - Stateless Session bean.
Above is the extract from "Real World Java EE Patterns" book by Adam Bien
And thus our current Java EE design (suitable for all Java EE softwares) will be -
EJB 3.1 + CDI + JPA

A continued discussion is in below blog post -


No comments

Post a Comment


© Shift, ShEkUP, Shape, and Surprise | All rights reserved.
Blogger Template Crafted by pipdig