The EJB 3.0 RosterApp didn't require the existing DTO baggage, but I had to make sure that the Team, League, and Player POJOs implemented java.io.Serializable. I also had to get rid of extra methods such as getPlayersofTeamCopy() in the Session facade of the EJB 2.1 RosterApp, which were doing the grunt work of managing data between DTOs and entity beans. On top of eliminating the extra overhead, I had to simplify the business methods in the Session façade of the EJB 3.0 RosterApp, as they were using DTOs all over the place. Listing 3 shows the sample migrated code.

Migrating the Session Beans
After eliminating the DTOs from RosterApp, I migrated the Session façade (RosterBean). First, I had to remove the home interface and clean up the remote interface to make it a business interface. To do so, I made sure the interface wasn't extending EJBObject and was annotated with @Remote. I annotated the bean class with @Stateless. The RosterBean in EJB 2.1 had a number of business methods that interacted with the Team, League, and Player entity beans. The largest chunk of the porting exercise was simplifying the business methods to use the EntityManager API, creating NamedQueries for ejbSelect methods, setting up the parameters for standalone named queries that were defined in POJOs, and making sure the methods didn't interact with DTOs that had already been removed (see Listing 4). (Listings 4-5 can be downloaded from www.jdj.sys-con.com.)

Migrating the Client
Once the Session façade task was completed, it was time to clean up the client code. The main difference between the EJB 2.1 and EJB 3.0 client is the lookup code, and minor changes to make sure the objects returned by the business methods were POJOs instead of DTOs (see Listing 5).

Comparing EJB 2.1 to EJB 3.0
Once the migration was done, I compared the lines of code and the number of Java and XML files in both versions. The biggest difference between the existing EJB 2.1 and new EJB 3.0 application was the number of descriptors. The EJB 2.1 application had a number of deployment descriptors, while the newer application had eliminated all of them except for application-client.xml and application.xml (see Table 1).

I used the numlines (www.gammadyne.com/cmdline.htm) utility, which gives the line count for uncommented and non-blank lines - the only types of lines added for the old and new applications. In the EJB 2.1 application, XML files were counted based on the deployment steps recommended in the J2EE 1.4 tutorial (see Table 2).

Conclusion
EJB 3.0 definitely makes it easier to develop entity and session beans, thanks to its simplified model and its leverage of well-known artifacts like POJOs and interfaces. The new EntityManager API is a plus; I was able to change the business methods quite easily without reading the specification.

There are other neat features in EJB 3.0, such as the ability to use database sequences; I used this for one of the POJOs, but backed out the changes to make the existing and new applications more similar. There doesn't seem to be support for native SQL queries, though the specification claims there is. I would have loved to use those queries instead of EJBQL, as database portability wasn't an issue for this exercise.

While the specification is a step in the right direction, I'd like to see more tool/IDE support for EJB 3.0 so that more Java application developers can get up to speed on it. While any standard IDE with decent support for Java SE 5.0 will be a good start, I'd like to see better tooling to support complex mappings (such as many-to-many), and to facilitate inline or immediate feedback on the validity of NamedQueries instead of waiting for deployment.

Maintaining applications can't be ignored, as applications will live for few years after the development cycle. All the features that make application development easier will also provide returns in the application maintenance cycle.

I recommend that developers take a fresh and unbiased look at the EJB 3.0 specification by checking out its features and giving the publicly available EJB 3.0 containers a spin.

(Oracle Application Server EJB 3.0 Preview was used for this exercise.)

References

• Software used for EJB 2.1 application (as recommended in the J2EE 1.4 tutorial): http://java.sun.com/j2ee/1.4/docs/tutorial/doc/About.html#wp80138
• Software used for EJB 3.0 application (Oracle Application Server EJB 3.0 Preview): www.oracle.com/technology/tech/java/ejb30.html
• Source files for the migrated application: www.jroller.com/resources/raghukodali/howtoRosterApp.zip
• EJB 3.0 specification: http://java.sun.com/products/ejb/docs.html