An Introduction to the Enterprise JavaBeans 3.0 (EJB 3) Specification

Callback Methods

In the EJB 2.1 specification, the developer had to implement a variety of callback methods in the bean class, such as ejbActivate(), ejbPassivate(), ejbLoad(), and ejbStore(), most of which were never used. With 3.0, there is no compulsion to implement any of these methods. In EJB 3.0, bean developers do not have to implement unnecessary callback methods and instead can designate any arbitrary method as a callback method to receive notifications for life cycle events. Any callback method has to be annotated with one of the pre-defined life cycle event callback annotations. Examples of life cycle event callback method annotations include PostConstruct, PreDestroy, PostActivate, or PrePassivate. Some of the event callback methods are common to all types of enterprise beans, while some are specific to bean types such as PostPersist for entity beans.

Callback methods can be defined either in the bean class itself or in a bean listener class. A bean listener class is denoted using the CallbackListener annotation on the bean class with which it is associated. The annotations used for callback methods are the same in both cases; only the method signatures are different. A callback method defined in a listener class must take an object as a parameter, which is not needed when the callback is in the bean itself. This object parameter can be used to pass the bean instance to the method in the listener class. Here's an example of putting a callback method in an entity bean:

@Entity
public class AccountBean{
  @PostPersist insertAccountDetails(AccountDetails accountDetails)
  public void createAccount(){}
}

Let's look at an example of creating a listener class and adding it to a bean class. The following code defines the callback listener AccountListener:

/* Adds callback listener to bean class */
@CallbackListener AccountListener
  public class AccountBean{
  public void createAccount(){}
}

The following code will add the callback listener AccountListener to the Account Bean:

/* Callback method defined inside a Listener class*/
public class AccountListener{
 @PostPersist insertAccountDetails(
         AccountDetails accountDetails){}
}

Since the @PostPersist is used to register a method to be called on an object that has just been inserted into the database, in this case, the method insertAccountDetails() will be invoked every time as soon as an account has been inserted using the createAccount() method in the AccountBean.

Configuration by Exception

The "Configuration by Exception" approach is the guiding methodology used in all aspects of EJB 3.0 to simplify the development effort. The intent is to simplify things for developers by forcing them to code things only where defaults are not adequate.

For instance, in many cases, defaults can be used instead of explicit metadata annotation elements. In these cases, a developer doesn't have to specify a metadata annotation to obtain the same result as if the annotation was fully specified. For example, by default, an entity bean (annotated by @Entity) has a default entity type of CMP, indicating that it has container-managed persistence. These defaults can make annotating enterprise beans very simple. The defaults always represent the most common specifications. For example, container-managed transaction demarcation (where the container, as opposed to the bean, manages the commitment or rollback of a unit of work to a database) is assumed for an enterprise bean if no annotation is specified. Similarly a default business interface is generated for session and message-driven beans which exposes all the public methods of the bean in the interface, since that is the most common use case.

Object-relational Mapping

The O/R mapping or persistence model has significantly changed from the abstract-persistence-schema-based approach, to one inspired by the various POJO-related approaches en vogue today. The O/R mapping is specified using annotations. The O/R mapping metadata expresses requirements and expectations of the application to map entities and relationship of the application domain to the database.

In EJB 2.1, developers used their own mechanisms to do certain database-specific operations like primary key generation. With EJB 3.0, support for several database-specific operations has been provided. The O/R mapping model has intrinsic support for native SQL. In this article, we do not provide details on the persistence framework, although we do provide an outline while discussing the changes in entity beans. For details check the EJB 3.0 API specification and download the EJB 3.0 persistence documentation.

Encapsulation of JNDI Lookups Using Annotations

EJB 3.0 addresses the encapsulation of environmental dependencies and JNDI access through the use of annotations, dependency injection mechanisms, and simple lookup mechanisms.

The enterprise bean's context comprises its container context and its resource and environment context. The bean may gain access to its resource references and other environment entries in its context in two ways:

1. Having the container supply it with those references such as using injections; for instance, @EJB public AddressHome addressHome; automatically looks up the EJB with the JNDI name "AddressHome."
2. Use the method Object lookup(String name) that is added to the javax.ejb.EJBContext interface. This method can be used to look up resources and other environment entries bound in the bean's JNDI environment naming context.