Enterprise Java Beans (EJB) technology has always been heart of an enterprise application. There are many reasons to use this technology – encapsulation of business logic, allowing remote access, asynchronous access and data persistence in permanent store. As this technology evolved over past few years, there were drastic changes and additions in the open source technologies, which tried to address problems in EJB. These technologies have forced EJB to change itself completely, and use the simplified new features to make EJB competent with the open source technologies.

In this article, we take a brief introductory tour of EJB and try to see what new has come in EJB 3.0. Also, we will try to find out the reason behind these changes. Let us start with the concepts of EJB.

What is EJB?

Enterprise Java Beans, simple, isn’t it? But this EJB word involves a lot more than these three words.  Enterprise means the organization, the IT infrastructure of organization, the application clusters. Java is the language of implementation of this technology. Bean word may make you to think like the Java bean technology.  Java beans are reusable components that can be used to assemble the application. Collectively, EJBs are reusable components, implemented in Java, which represent one or more enterprise services. In short, you have a business functionality to be exposed to other organizations/applications/your own application front end and other services, then EJB can do this work for you.

What are Types of EJBs?

Types of EJB are driven by the kind of business services you want to expose.

• Caller opening a synchronous session with the business service for one time work – Stateless session bean
• Caller opening a synchronous session with the business service and expecting to remember what was done in previous session – Stateful session bean
• Caller sending an asynchronous message to the business service: Message driven bean

In short, there are two primary types – Session and Message driven. Session bean has two types stateful and stateless.

What is an EJB Container?

EJB Container is provided by the application server. We can say that the EJB is hosted in the EJB container, which takes care of hosting as well as providing the supporting services to the EJB. These services include – transaction management, JNDI lookup, security etc. We can control these services through configuration (using deployment descriptor). Container is provided by the application server vendors, while EJB is developed and deployed by the developers. There has to be a contract between these two parties. This contract is defined by Sun Micro Systems by giving the specification. When the application server vendor says that they are compliant with so and so specification then they abide to the contract.

What is new in EJB 3.0? Why?

Though EJBs in previous version were matured enough to support the features required by a business service, there were many things which could have been done better. Because of this, when there were better alternatives to those things, the user community gave preference to those over EJBs. Let us take the changes one by one and try to guess the rational/driver behind those things.

Interfaces:

• Home interface not required
• Component interface not required
• No need to implement javax.ejb.EnterpriseBean interface

After availability Spring framework, it became clear that it is possible to provide container services to POJOs (Plain Old Java Objects). We don’t need to extend these objects from any framework class to host and manage them using a container. This must have lead to removal of Home and Component Interfaces. Home interface was used to get handle of remote interface and it required the stub to be available with client. Similarly, Component interfaces needed to be implemented by the bean class to make available few callback methods to the container. Now this is not needed. The call back methods can be added to the bean class only by annotating them as interceptor methods.

The core class of EJB implementation, the bean class does not need to implement javax.ejb.EnterpriseBean interface. This thing has been achieved directly by annotating the POJO. Thus the dependency injection is used to introduce required behavior.

Simple APIs:

EJB requires many environment attributes in the methods. These attributes are mainly configured in deployment descriptor or in application server’s container configuration. Just for example, connection is an attribute which is required in the EJB methods. With EJB 3.0, the accessibility of these attributes is simplified through annotations.

Annotations:

Annotations are introduced with Java 5. This concept is applied to EJBs as well. The configurable properties, which used to be in deployment descriptor, can be configured through the annotations. This is one more change to reduce complexity.

Object Relational Mapping:

This is a big change. Reducing popularity of entity beans, and availability of better technology like object relational mapping (ORM) frameworks. ORM technology has brought a paradigm shift in the way of dealing with database. With availability of ORM framework, developer can avoid learning the database languages. EJB 3.0 also introduces another language in line with the languages introduced by ORM frameworks, EJB Query Language (EQL). The syntax is close to Java than database query languages.

More Related Posts in JEE, Tech Notes