http://www.ftponline.com/javapro/2005_07/magazine/features/dpanda/Default.aspx
Migrate J2EE Applications for EJB 3.0
Avoid inherent complexities when migrating applications to use the new standard in server-side business logic programming
by Debu Panda

July 21, 2005

The programming model for Enterprise JavaBeans (EJBs) has been simplified dramatically in EJB 3.0 and is being hailed by Java developers as the new standard of server-side business logic programming. Meanwhile, the existence of thousands of J2EE applications written with earlier versions of the EJB API has raised concerns about both the interoperability of EJB 3.0 with these applications and migrating the applications to use EJB 3.0.

Major application server vendors that already provide EJB 3.0 features will continue to support EJB 2.x in the new EJB 3.0 container. This support means that applications written with EJB 2.x will continue to run without any change whatsoever. However, some organizations will certainly want to migrate their applications to use the EJB 3.0 API to improve maintainability by simplifying their code and take advantage of the performance and scalability benefits of the persistence API.

Let's look at some of the issues relevant to migrating applications to EJB 3.0. The topics discussed here compose a subset of all possible issues a migration effort will encounter, and because the spec is not finalized other issues may still arise.

The main goals of EJB 3.0 are to simplify the programming model and to define a persistence API for the Java platform. Some general changes to the EJB spec that will simplify life for EJB developers are: EJB artifacts are Plain Old Java Objects (POJOs), XML descriptors are no longer necessary, annotations may be used instead, defaults are assumed whenever possible, unnecessary artifacts and life-cycle methods are optional, and the client view is simplified by dependency injection.

Standardization of the POJO persistence model (such as the one used by Oracle TopLink and JBoss Hibernate) within the context of J2EE finally provides users with the inheritance and polymorphism that have until now been available only outside the container or in proprietary products. Furthermore, the POJO entity beans can now be used and tested both inside and outside the EJB container.

Migrate Session Beans
The main changes in EJB 3.0 session beans simplify development by making beans POJOs that use annotations instead of XML descriptors and dependency injection instead of complex JNDI lookup. Hence, it is very easy to migrate the session beans to use the EJB 3.0 programming model. The changes in EJB 3.0 sessions fall into two categories: the server side and the client side. By client side we mean using resources, EJBs, and so on from other EJBs. Using EJBs from other types of clients outside the EJB container will be standardized with the J2EE 5.0 specification.

Some application servers allow migration of server-side components without affecting the clients, thus allowing incremental migration of applications.

There are some changes that need to be made to EJB 2.x session beans to migrate to EJB 3.0. In EJB 3.0 the remote and local interfaces do not have to implement javax.ejb.EJBObject or javax.ejb.EJBLocalObject. The component interface can become a business interface, and @Remote annotations can be used to mark remote interfaces.

Let's look at two examples of the same EJB 2.x interface, before and after migration to EJB 3.0. RemoteExceptions are no longer thrown by the methods on the EJB 2.x remote interface:

import javax.ejb.EJBObject;
import java.rmi.RemoteException;

public interface HelloWorld 
	extends EJBObject {
	void sayHello(String name) 
		throws RemoteException;
}

and the EJB 3.0 remote interface:

import javax.ejb.Remote;

@Remote
public interface HelloWorld {
	void sayHello(String name);
}

Bean classes do not need to implement javax.ejb.SessionBean—rather, their business interfaces. Life-cycle methods that are not required do not need to be present on the bean class, and callbacks may be indicated by annotations. Here is the EJB 2.x stateless session bean:

import javax.ejb.SessionBean;
import javax.ejb.SessionContext;

public class HelloWorldBean 
	implements SessionBean {

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

	public void sayHello(
		String name) {
	System.out.println(
		"Hello " + name);
	}
}

and here is the stateless session bean migrated to EJB 3.0:

import javax.ejb.Stateless;

@Stateless
public class HelloWorldBean 
	implements HelloWorld {
	public void sayHello(
		String name)  {
		System.out.println(
			"Hello " + name);
	}
}


Stateful session bean ejbCreate() methods become business methods used at initialization time. Removal methods are annotated with @Remove. Optionally, you can migrate session bean code to use annotations for transactions and security.

EJB 3.0 simplifies the use of resources and EJB references by making use of the principle of dependency injection. Injection of resources or references can occur through either annotation of the injection target or specification of the target in the ejb-jar.xml descriptor. Table 1 lists some of the differences.
EJB 2.xEJB 3.0
Using another EJB:ejb-ref in XML descriptor Do JNDI lookup to get the home interface

Call home.create to obtain instance
ejb-ref no longer requires the home interface Change the home interface to the business interface

Remove home.create and directly invoke the methods on the EJB

Optionally annotate the EJB business interface property/field to obtain an instance
Resource access:Do JNDI lookup to obtain a resourceOptionally annotate a resource property/field to obtain a resource

Table 1 Inject Simplification

EJB 3.0's principle of dependency injection simplifies the use of resources and EJB references. Annotation of the injection target or specification of the target in the ejb-jar.xml descriptor provides for the occurrence of resources or references. Compare the differences.