Migrating EJB 2.x applications to EJB 3.0

Gradually and iteratively adopt the benefits of the newest EJB specification

1 2 Page 2
Page 2 of 2

Migrating EJB 2.1 session beans to EJB 3.0

The EJB 2.1 session beans that implement the SessionBean interface become POJOs under EJB 3.0. The business interface that extended EJBObject or EJBLocalObject can now extend a business interface that makes sense in the particular context. The home interface is not required any more and hence can be ignored or removed. The unused lifecycle methods can be removed.

A session bean could be specified as stateless or stateful using annotations (Stateless and Stateful) or by the previous means of specifying the state in the deployment descriptors. For stateful session beans, the removal methods are marked with the Remove annotation.

EJB 3.0 clients access the other EJB components with the help of dependency injection. The EJB annotation can be used to specify the enterprise bean component.

Migrating EJB 2.1 entity beans to EJB 3.0

EJB 2.1 entity beans that implement the EntityBean interface become POJOs under EJB 3.0. A CMP and CMR entity bean in EJB 2.1 has getter/setter methods in line with the JavaBeans paradigm. In EJB 3.0, the Persistence API defines metadata annotations to define persistence and relationship criteria on the lines of object-relational mapping concepts. The home and local interfaces are not required for entity beans in EJB 3.0.

In the new specification, an entity bean or an entity object is simply a POJO with the Entity annotation. NamedQuery and NamedQueries annotations are used to annotate the finder methods. The Column annotation maps persistent entity bean properties to the corresponding database table columns, and the identifier or primary key for a persistent entity is defined using the Id annotation. As in the case of object-relational mapping tools, the property name is assumed to be the same as the column name if the Column annotation is not explicitly defined. The table name and schema is specified using the Table annotation. Each property value has getter/setter methods defined for it. Properties that are not persistent are annotated as Transient.

CMR is specified using the OneToMany, OneToOne, ManyToMany, and ManyToOne annotations, depending on the multiplicity and the directionality of the relationships.

In EJB 3.0, the Persistence API defines an EntityManager class in line with similar classes in object-relational mapping tools such as Hibernate. The lifecycle management (creation and removal) and search of a persistent entity is done using the persist(), remove(), and find() method calls on the EntityManager class.

A phased approach

The migration from an earlier EJB specification to the EJB 3.0 specification can be planned in a phased manner to minimize risk and any possible adverse impact on the existing applications that interact with these beans. The discussions above clearly illustrate that multiple strategies can be utilized for a piecemeal implementation.

Automating the migration

The migration to EJB 3.0 involves removal of the redundant home interface definitions, removal of the empty callback implementations, replacement of the JNDI lookups with metadata annotations to facilitate dependency injection, and modification of the business interface and the bean class implementation. It also involves conversion of deployment descriptor configurations to annotations within the code. Many of these tasks can be automated. Third-party companies and IDE vendors already have offerings to automate part of the migration effort.

Conclusion

Migration to EJB 3.0 is a fairly uncomplicated task and can be carried out in a phased and piecemeal manner. Some of the migration tasks can be automated, and tools and IDEs can be leveraged to ease the process. With the current emphasis on backward compatibility and ease of migration, now may be the best time to move EJB applications to EJB 3.0. As the EJB specification continues to evolve, moving legacy EJB code (from version 2.1 and earlier versions) to the newer specifications may grow more difficult.

Shashank Tiwari (a.k.a. Shanky) is a software architect at Saven Technologies, an information technology company based in Illinois. He has, for more than seven years, been involved with architecting high-performance distributed applications using J2EE. He advises investment banking and financial service companies in building robust quantitative, data intensive, and scalable software applications. He is also an ardent supporter of open source software. He is one of the maintainers of the Python GUI framework called anygui. He lives with his wife and two sons in New York. More information about him can be accessed at www.shanky.org.

Learn more about this topic

1 2 Page 2
Page 2 of 2