Comparison with the J2EE Design and Development Implementation

As we already noted, the requirements for our sample application are essentially the same as for the sample application presented in Expert One-on-One J2EE Design and Development by Rod Johnson. This book introduced an Interface21 application framework that has been greatly enhanced to become the Spring Framework. Because these two implementations have much in common, it is informative to compare them and to note some of the differences.

Simpler Technology

The biggest differences stem from the fact that the framework has undergone some important enhancements that allow us to use simpler technology. There is no longer a good reason to use EJBs for this type of application. The framework now provides declarative transaction management, which was one of the advantages of using EJBs in the past.

Hibernate simplifies the data access layer and there is no need to provide a custom caching solution for infrequently changing data. We simply enable Hibernate's second level cache for the appropriate classes.

Because we are not using EJBs or other more advanced J2EE features, we can deploy our application as a WAR file to any servlet container that is compatible with the Servlet Specification version 2.3 or later. This greatly simplifies the deployment step, and tends to improve portability between servers.

Yet we could still take this application and run it in a high-end application server using JTA. We haven't ruled out any options here.

Database Changes

We are also using an open source database instead of the proprietary Oracle database that was used earlier. This eliminates any use of stored procedures because the target database, MySQL, does not currently support stored procedures. They will be available in an upcoming 5.0 release, but we have decided to use the production-ready 4.1 version. We are also using Hibernate as the O/R mapping framework and this allows us to move any custom caching from the application layer to the O/R mapping layer. This also eliminates the need for the Message Bean that was used to invalidate some of this caching in the earlier implementation.

The data model is essentially the same as it was. We are treating this as a "legacy" database and any existing data can safely be imported into the new database. It has been adjusted for MySQL and we are using the INTEGER datatype for the keys instead of NUMERIC. The reason for this is that the INTEGER datatype clearly defines this as a number without any decimals, while the NUMERIC datatype is defined to receive a default precision and scale unless one is provided. This does not have an impact for Oracle because Oracle uses a proprietary NUMBER datatype internally, but it could have some impact for other databases.