EJB 2.X Vs EJB 3.0 Vs EJB 3.1

Overview:

In JavaEE world, EJB has gained lot of momentum and in recent years java community has worked hard to simplify its development.To achieve that EJB architecture has gone through tremendous amount of changes. In this post, we will try to compare and see how things have been drastically changed over the years from EJB 2.x to EJB 3.0. At the end, we will see list of brand new features which were introduced in EJB3.1.

Development:

EJB2.X	EJB3.0	EJB3.1
Supports both Remote and Local EJB. In order to develop and publish Remote or Local EJB, developers have to write minimum 3 java classes as follows: Remote or Local Interface by extending EJBObject or EJBLocalObject. Remote or Local Home Interface by extending EJBHome or EJBLocalHome. Bean Class which implements Remote or Local business methods and EJB Framework interface like SessionBean, MessageDrivenBean etc… Checked Exceptions needs to be declare at every point like RemoteException etc...	EJB 3.0 made life easy by removing the restrictions to implement mandatory interfaces, eliminating the need of Home interface and providing a luxury to developers to write an EJB using POJO (Plain Old Java Object) style. Decorate or Annotate an POJO using EJB specific annotations like @Stateless, @Stateful or @MessageDriven etc... Remote or Local EJBs methods are exposed using POJI (Plain Old Java Interface). Decorate EJB class to provide Remote or Local Interface details using @Remote (ClassName) or @Local (ClassName).	EJB 3.1 supports same features as EJB 3.0 with few enhancements such as No-Local-Interface view. That means, if you are writing an EJB whose methods will be invoked within same JVM as its running on, then NO need to write and implement POJI. Simple POJO decorated with @Stateless,@Stateful or @MessageDriven can be published as Local EJB. In EJB 3.1, by default EJB is Local. New EJB @Singleton is introduced. More about it along with brand new features discussion. @Asynchronous Method processing.

Configuration or Deployment Descriptor:

EJB2.X	EJB3.0	EJB3.1
Deployment descriptor is must in EJB2.X. Container won’t even recognize your EJB code until and unless you provide its details in META-INF/ejb-jar.xml.	EJB3.0 gives us relief by following “Convention Over Configuration” (Configuration by Exception) paradigm. Deployment descriptor is Optional. If supplied, then descriptor configuration takes priority over Annotations. Default values are used whenever possible.	Same as EJB3.0.

Container Callback methods:

EJB2.X	EJB3.0	EJB3.1
EJB2.X force developers to implement (even empty implementation) container callback methods like ejbCreate (), ejbPassivate (), ejbActivate (), ejbRemove (), setXXXContext () etc… for each EJB.	Fortunately, these restrictions are relaxed in EJB3.0 as there is no need to implement any mandatory interface. If at all any callback methods required, you can write your own(custom) method and annotate it with @PreDestroy or @PostConstruct etc… and container will call them appropriatley.	Same as EJB3.0

Interceptors:

EJB2.X	EJB3.0	EJB3.1
EJB2.x also provides in-built Interceptor support such as transactions and security via deployment descriptor by specifying security and transactions details at method level. BUT Let’s say, I want to know how much time each method call is taking in my EJB modules. There is no easy way except going to each and every EJB code and method and adding log statements at entry and end of the method etc…	You can write your own (custom) Interceptors and configure them at different levels such as Method Level, Class Level or Default Level. Class Level interceptors are applicable to all the methods in the class. Method Level Interceptors are specific to that method. Default Levels are configured in deployment descriptors and applicable to all EJBs. @AroundInvoke annotation used at the method in EJB class or separate Interceptor class indicates to Container that Interception is needed. Separate Interceptor class can be referred in any class using @Interceptors(CLASS_NAME) annotation.	Same as EJB3.0

Dependency Injection:

EJB2.X	EJB3.0	EJB3.1
We know that resources deployed in JAVA EE server can be accessed using JNDI names. Boiler-plate code needs to be written in order to get any resource reference before using it.	Dependency Injection made life easy. No need to write any code but annotation to have that resource injected for you by the container. e.g. @Resource private DataSource testDS;	Same as EJB 3.0

Persistence Model:

EJB2.X	EJB3.0	EJB3.1
Dealing with Entity beans had never been so easy. Container Managed persistence model is so complex to develop and manage.	JPA 1.0 (Java Persistence Model) was introduced as a separate spec in EJB3.0. JPA follows the same standard as EJB does i.e. Configuration by Exception. Simple POJO can be converted into Entity class by supplying few annotations which does the magic of persisting / retrieving data from persistent store without writing any JDBC style code.	Support for JPA2.0 which introduces Criteria API along with other enhancements.

Timer Service:

EJB2.X	EJB3.0	EJB3.1
NO Support	EJB 3.0 introduced support for Timer Service where we can schedule stateless EJB to run at periodic intervals to perform task. Timer notification can be scheduled to occur at specific interval or specific day etc…	Enhanced to let developers use Unix cron style schedules.

Testing:

EJB2.X	EJB3.0	EJB3.1
Testing EJB had never been so easy. It requires lot of efforts to build code, bundle into JavaEE package and deploy into application server then write additional client code which runs in different JVM and make remote call. The EJB which were developed as a LocalEJBs were difficult to test outside of container. Developers used to use different techniques to test EJB code.	Same as EJB2.x	Embeddable Ejb Containers made life easy. Now we can run EJB code within client JVM and test them out. For more details and its usage, Embedded EJB Container Using Weblogic Server

Brand New Features in EJB 3.1:

Feature	Description
Singleton Bean	One of the most awaiting features has been introduced in EJB3.1. Before this feature, developers have been working through it using Singleton pattern by writing boiler plate code and were managing concurrency using synchronized approach etc… @Singleton Bean (one instance per JVM) solves such problems and provides shared access between clients and supports concurrent access. Developers has an option to choose Container managed or Bean managed Concurrency using annotations as @ConcurrencyManagement(CONTAINER) OR @ConcurrencyManagement(BEAN). Container managed concurrency can use annotations like @Lock (READ) and @Lock (WRITE) to restrict the read/write access on the getter or setter methods by concurrent clients. Singleton classes can be loaded at Server startup and perform clean up resources at server shutdown using @Startup on Singleton class and @PreDestroy on a callback method.
EJB 3.1 Lite	The EJB specification has large set of features for developing a wide variety of enterprise applications. Many enterprise applications do not require the complete set of these features and do not use the full range of EJB APIs. So, EJB 3.1 introduced EJB Lite, a minimal subset of EJB APIs that still includes all the required features for creating an enterprise EJB 3.1 Lite is not a product. Rather, it is a proper subset of the full EJB 3.1 API that includes a small, powerful selection of EJB features suitable for writing portable transactional business logic. The defini­tion of EJB 3.1 Lite gives vendors an option to implement only a portable subset of the EJB API within their product. The EJB 3.1 Lite API is composed of the following subset of the EJB API : Stateless, Stateful, and Singleton Session Bean components Local and no-interface view only Synchronous method invocations only Container-managed transactions / Bean-managed transactions Declarative and programmatic Security Interceptors Deployment Descriptor support (ejb-jar.xml)
EJB Packaging	So far, In order to use EJB components in Web application, We used to build and package ejb-jars in separate jar file containing deployment descriptors under META-INF/ejb-jar.xml. EJB 3.1 breaks all those barriers and allows EJB components to be bundled inside .war and store the deployment descriptor under WEB-INF/ejb-jar.xml. EJB components and related classes can be placed under WEB-INF/classes or WEB-INF/lib folder.
Global JNDI Access	In case of EJB components, It wasn’t that easy to “Write Once And Run Anywhere” due to JNDI access. Different vendors have their own way to creating JNDI and storing them which makes EJB components not easily portable without making changes to their JNDI access. Java community has realized the pain and came up with standard as “Global JNDI Access” using “java: global” or “java: app” or “java: module”.
Asynchronous Session Bean	So far Asynchronous communication had been achieved via Message Driven Beans and JMS queues and Stateless Session beans act as a front wall for client. Even for small asynchronous communication, MDB and JMS infrastructure set up was required which causes an extra overhead. Now session beans can be exposed as Asynchronous using @Asynchronous annotation. This annotation can be applied at class level Or method level. Marking a class as Asynchronous makes all business methods in a given class to run in async mode.