Migrating EJB 2.x applications to EJB 3.0

Gradually and iteratively adopt the benefits of the newest EJB specification

By Shashank Tiwari, JavaWorld.com, 08/14/06

Enterprise JavaBeans 3.0 simplifies the enterprise bean architecture and provides enhanced and more powerful features. The new specification leverages the annotations metadata facility introduced in Java 5, persistence and object-relational mapping best practices from tools such as Hibernate and TopLink, and the Dependency Injection pattern made popular by lightweight Java frameworks such as Spring.

This article discusses possible migration strategies for moving applications written using EJB 2.1 or an earlier specification to an EJB 3.0-based architecture. The possible migration paths are evaluated from both the perspectives of design and implementation. This article does not intend to be exhaustive in illustrating the migration options. After reading this article, you should be able to choose the best option, within your own specific context, for migrating the legacy EJB code to the new specification.

This article assumes you are familiar with the enterprise bean, Java 5, and object-relational mapping features and concepts.

EJB 2.1 to EJB 3.0: What has changed?

To provide a context for this article's discussion of possible migration paths, I begin by discussing the changes in the new specification in the context of each of the different bean types and then at a generic level pertinent across multiple bean types.

Session bean

In EJB 2.1 and earlier specifications, two interfaces—the home and the local, or remote, business interfaces—and the bean implementation class were required for each session bean. The home interface was required to extend the EJBHome or the EJBLocalHome interface and declare the lifecycle method, such as create(). The local, or remote, business interface was required to extend the EJBObject or the EJBLocalObject interface and declare the business methods. The bean implementation class itself was an EnterpriseBean type and, in the case of session beans, extended the SessionBean sub-interface. Callback method implementations in the bean class had to be provided so that the container could trigger them on occurrence of the appropriate lifecycle events. In addition, critical elements of the bean, including its transaction and security definition, and whether it was stateful or stateless, were defined in the associated deployment descriptors.

Listing 1 illustrates an example of a stateful session bean defined using the EJB 2.1 specification.

Listing 1. An EJB 2.1-based banking service stateful session bean

 public interface BankingService extends EJBObject {
        
    public void deposit(int accountId, float amount) throws RemoteException;
        
    public void withdraw(int accountId, float amount)throws RemoteException;
        
    public float getBalance(int accountId) throws RemoteException;


    public void doServiceLogout() throws RemoteException;
 
}


public interface BankingServiceHome extends EJBHome {
    public BankingService create() throws CreateException, RemoteException;
}


public class BankingServiceEJB implements SessionBean {


    public void deposit(int accountId, float amount) throws RemoteException {
    //Business logic to deposit the specified amount and update the balance
    }


    public void withdraw(int accountId, float amount)throws RemoteException {
    //Business logic to withdraw the desired amount and update the balance
    }


    public float getBalance(int accountId) throws RemoteException {
    //Business logic to get the current balance
    }


    public void doServiceLogout() throws RemoteException {
    //Service completion and logout logic
    }


    public void ejbCreate(){}
    public void ejbActivate(){}
    public void ejbPassivate(){}
    public void ejbRemove(){}
    public void setSessionContext(SessionContext context){}


} 

In the EJB 3.0 specification, a session bean needs to define only a business interface and a bean implementation class. The home interface has been removed. The business interface is a regular Java interface, also sometimes called POJI, or the plain-old Java interface. The business interface does not need to extend the EJBObject or the EJBLocalObject interface; instead, if required, it could be defined within the interface hierarchy that represents the business domain model.

The bean implementation class is a regular Java class, also sometimes called a POJO, or a plain-old Java object. It does not implement an EnterpriseBean type. The declaration and the configuration in the deployment descriptor can be defined within the Java code, using the annotations metadata facility. In addition, default values are provided for most configurations, thus minimizing the bean-specific configuration requirements. Under the new specification, one could deploy session beans without any ejb-jar.xml deployment descriptors, though they still exist and could be used if the developer prefers that to the annotations model.

In the case of EJB 3.0 session beans that implement a Web service, the methods exposed as Web service operations are annotated with the WebMethod descriptor. Session beans that serve as Web service endpoints are annotated as a WebService.

Listing 2 illustrates the earlier example (from Listing 1) of the stateful session bean using the EJB 3.0 specification.

Listing 2. An EJB 3.0-based banking service stateful session bean

 @Remote
public interface BankingService {
    public void deposit(int accountId, float amount);
    public void withdraw(int accountId, float amount);
    public float getBalance(int accountId);
    publlic void doServiceLogout();


}





@Stateful
public class BankingServiceBean implements BankingService {


    public void deposit(int accountId, float amount) {
    //Business logic to deposit the specified amount and update the balance
    }


    public void withdraw(int accountId, float amount) {
    //Business logic to withdraw the desired amount and update the balance
    }


    public float getBalance(int accountId) {
    //Business logic to get the current balance
    }


    @Remove
    public void doServiceLogout () {
    //Service completion and logout logic
    }


}

Message-driven beans

In EJB 2.1, a message-driven bean class implemented the MessageDrivenBean interface and the message listener interface. The callback methods were implemented in the bean class and the container, on a particular event called the corresponding method. Message-driven beans never involved the concept of a home and a remote, or local, interface.

Discuss

Subject	Replies	Last post
Migrating EJB 2.x applications to EJB 3.0 By JavaWorld	1	04/22/08 06:02 AM by Anonymous
Wrong example By Anonymous	0	07/23/07 05:52 AM by Anonymous

Free Download - 5 Minute Product Review. When slow equals Off: Manage the complexity of Web applications - Symphoniq

Free Download - 5 Minute Product Review. Realize the benefits of real user monitoring in less than an hour. - Symphoniq