Over the past few years, the Enterprise JavaBeans (EJB) specification has evolved significantly. In the early days of EJB, application developers faced a burden of overwhelming complexity: they had to manage several component interfaces, deployment descriptors, and unnecessary callback methods; work within the limitations of the EJB Query Language (EJBQL); and learn and implement the design patterns used to overcome the limitations of the specification.

The introduction of the EJB 2.1 specification did improve things, although many still say the specification is too complex - and that criticism is often seen as a reflection of the problems of the entire J2EE platform.

The next major release of the J2EE 5 platform is focused on ease of development. As a cornerstone of the platform, much of the effort centers on reducing the complexity of EJB. The EJB 3.0 specification simplifies development by removing the requirements for interfaces, deployment descriptors, and callback methods and by adopting regular Java classes and business interfaces as EJBs.

The specification also leverages metadata annotations that are standardized with JSR-175, and the proven Plain Old Java Object (POJO) persistence architecture used by object-relational (O/R) frameworks such as Oracle TopLink and Hibernate. These last two features have greatly reduced much of the specification's complexity. Now you can take a regular Java class, add annotations to it, and deploy it to an EJB 3.0 container as an entity. A configuration by exception approach is taken so that the container accepts the defaults whenever possible.

Sample Entity Bean with Annotations

@Entity
@Table(name="PLAYER", schema="CMPROSTER")
@NamedQuery(name="findAll",queryString="SELECT OBJECT(p) FROM Player p");
public class Player implements Serializable
{
  @Id
   @Column(name = "ID", primaryKey = true, nullable = false)
   public String getId()
   {
    return id;
   }
//………………..
}

The features I've mentioned above are only the tip of the iceberg - the EJB 3.0 specification provides a slew of new features and enhancements.

This all sounds great on paper, but I wanted to find out just how much easier it is to develop applications with EJB 3.0. So, I decided to give the specification a spin and see for myself. I chose an existing EJB 2.1 application that implements some common use cases with design patterns such as a Session façade, and migrated the application using the new features of EJB 3.0. I used the publicly available demo application RosterApp (included with the J2EE 1.4 tutorials), which lets you maintain team rosters for players in leagues.

I took the bottom-up approach to migrate RosterApp with EJB 3.0 technology, starting with:

• Entity beans
• Data transfer objects (DTO)
• Session bean
• Utility and client classes

The EJB 3.0 specification lets you specify O-R metadata via annotations. It provides a wide range of annotations that cover different types of relationships between POJOs, constraints, column information, sequence generators, composite primary key, and inheritance.

Once you migrate all the O/R mappings as annotations in the POJOs, the next step is to convert a bunch of finder methods with EJBQL from EJB 2.1 to new POJOs. Most of these finder methods were already defined for the player bean. EJB 3.0 provides the NamedQueries annotation to group together individual NamedQuery objects. I took all the EJBQL from the existing application and created a NamedQueries annotation, which looks like Listing 2.

The EJB 3.0 specification provides a Query API that can be used for both static and dynamic queries. A named query can be defined as a standalone query or attached to a query method of the bean class. You can define named queries in EJBQL or SQL. This is a boon for Java developers familiar with SQL syntax, as they can become EJB developers without having to learn another query language.

Mappings and finders covered almost 90-95% of the entity bean migration. The remaining part of the project consisted of ejbSelect statements and methods that perform add and remove operations on the Team POJO. I needed to simplify these methods. The following code shows one of the methods before and after migration. ejbSelect methods were migrated as NamedQuery in the Session facade (which is discussed later in this article).

// remove operation on Player before migration

public void dropPlayer(Player player)
{
Debug.print("TeamBean dropPlayer");
try {
Collection players = getPlayers();
players.remove(player);
}
catch (Exception ex) {
throw new EJBException(ex.getMessage());
}
}
//remove operation after migration

public void dropPlayer(Player player) {
Debug.print("TeamBean dropPlayer");
getPlayers().remove(player);
}

Migrating DTOs
DTOs are the next layer in RosterApp. The entities in EJB 3.0 are POJOs; you can directly transfer them between the business and client tiers without first having to create a separate set or layer of classes as in EJB 2.1. The existing RosterApp used DTOs to transfer Teams, Players, and Leagues data collections between the client and Session facade. The new EntityManager API in the EJB 3.0 persistence specification, which is used to create, remove, find, and query entities, works nicely to attach and detach objects from the persistence context. The EntityManager's merge operation lets you propagate state from detached entities onto persistent entities managed by the EntityManager.