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

Abstract

The Enterprise JavaBeans (EJB) technology is a J2EE technology for the development and deployment of component-based business applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multiuser secure.

In spite of the rich features, however, the complexity of the EJB architecture has hindered its wide adoption. Competing technologies are making inroads in the EJB space. For example, O/R mapping technologies such as Toplink and the open-source Hibernate framework have overtaken EJB as the preferred choice for developing persistence solutions. The introduction of the EJB 3.0 specification is a giant step forward and will go a long way toward luring developers back to EJBs. The goal of the specification is twofold:

  • Make it easier for developers to develop EJBs.
  • Standardize the persistence framework.

EJB 3.0 brings us closer to the dream of treating enterprise beans like regular JavaBeans. It decreases the number of programming artifacts for developers to provide, eliminates or minimizes callback methods required to be implemented, and reduces the complexity of the entity bean programming model and O/R mapping model. With EJB 3.0, J2EE now seems accessible to a much wider audience.

In this article, we first briefly discuss the limitations of EJB 2.1. Next, we describe how EJB 3.0 addresses these difficulties by describing the proposed significant changes one by one, including the impact on types of enterprise beans, the O/R mapping model, the entity-relationship model, and EJB QL (EJB Query Language). We conclude with code examples using EJB 3.0-based enterprise beans.

Limitations of EJB 2.1

Developing EJBs with EJB 2.1 hasn't been the easiest thing to do. The reasons are easy to find:

  • To create a single EJB you need to create a multitude of XML deployment descriptors.
  • A set of three source files must be created.
  • Multiple callback methods must be implemented that usually are never used.
  • You have to throw and catch several types of unnecessary exceptions.
  • Yet another complaint is that the EJBs are completely untestable outside the context of the container since components like container-managed entity beans are abstract classes.
  • Finally, EJB-QL in its current form is limited in functionality and difficult to use. These limitations force developers to use straight JDBC and SQL, or to use other persistence frameworks such as Toplink and Hibernate.

The sheer verbosity of the API has been one big annoyance, and EJB 3.0 makes a significant attempt to address most issues. This article covers the important aspects of this specification.

The End of the Road for Deployment Descriptors

The configuration of XML deployment descriptors was a major bottleneck in the path to simplifying development of EJBs. Therefore one of the primary goals of the EJB 3.0 specification was to shield the developer from having to work with XML files. This is accomplished by the use of metadata annotations that have been added to JDK 5.0 as part of the JSR 175 JCP specification. Annotations are a kind of attribute-oriented programming and are similar to XDoclet. However, unlike XDoclet, which requires pre-compilation, annotations are compiled into the classes by the Java compiler at compile-time. From the developer's point of view, annotations are modifiers like public/private and can be used in classes, fields, or methods:



import javax.ejb.*; 

@Stateless

public class MyAccountBean implements MyAccount

{

  @Tx(TxType.REQUIRED) 

  @MethodPermission({"customer"})

  public void deposit(double money) {...}

}

The annotations generally are self-explanatory. The @Stateless annotation indicates that the bean is stateless. The @Tx attribute specifies the transactional demarcation for the method, and the @MethodPermission attribute specifies the users who are allowed to access the method. So this means that there's no longer a need to write XML deployment descriptors to describe these properties. However, this does not eliminate the use of XML; it just makes it optional. The specification allows the use of XML deployment descriptors to override these annotations.

POJO Programming Model

The critical point to note is that the above stateless session bean example is complete in itself. Disregarding the annotations, this file is a JavaBean, also known as a Plain Old Java Object (POJO). Interfaces are optional for entity beans and required for session beans and message-driven beans. However, that does not mean that you have to define an interface for your session bean or message-driven bean. If you do not implement an interface, a bean interface will be generated for you. The type of generated interface, either local or remote, is dependent on the annotation you used in the bean class. All the public methods of the bean class will be included as part of the automatically generated business interface:



public interface ShoppingCart

{

  public void purchase(Product product, int quantity);

  public void emptyCart();

}

It is recommended that you generate the interface explicitly if you want to pick and choose the methods of the interface that should be exposed to the client, or want to give the interface a name different from the automatically generated name.

This interface class is a Plain Old Java Interface (POJI). Both the interface and the bean class do not have to throw unnecessary exceptions such as RemoteException.