lain old Java object (POJO)-based architectures and lighter-weight development models using tools such as Spring and Hibernate have gained considerable acceptance in the enterprise Java space during the past few years. Meanwhile, specification-supported component architectures that use standards such as Enterprise Java Beans (EJBs) have lost ground. However, the new Java Platform, Enterprise Edition 5 (Java EE 5) specification has introduced significant changes to the component architecture, primarily addressing the drawbacks that prevented more widespread acceptance of previous versions.
Incorporating feedback from the industry and users, Java EE 5 lays out a new lightweight POJO-based architecture built on the concepts of Inversion of Control (IoC) for dependency management and object relation mapping (ORM) for persistence. Previous EJB versions were relatively cumbersome to build and support, but the latest EJB 3.0 specification featured in Java EE 5 can be implemented easily with very little code intrusion. (Read the previous DevX articles "Getting Started with EJB 3.0 and Enterprise Bean Components", "Banish Your Resistance to Persistence with the EJB 3.0 Persistence API", and "A Test-Driven Exploration of the Advanced Features of EJB 3.0" to learn about EJB 3.0.)
Java EE 5 provides all the features and functions necessary to build a robust enterprise application right in the EJB 3.0 container, but you still can use the power, flexibility, and relative strengths of Spring and Hibernate to further improve the productivity and quality of your applications. This article demonstrates how to build a Java EE application that uses EJB 3.0, Spring 2.0, and Hibernate together. By implementing a component architecture, the application employs EJB 3.0 while using Spring 2.0 as a dependency-injection, AOP container and Hibernate as an ORM persistence provider.
The goal is not only to introduce the idea of using these popular technologies as complements to the new EJB 3.0 model, but also to provide a development model for teams who already have made significant investments in using these technologies. The article doesn’t recommend one architecture over another, but merely proposes an option for you to add to your toolbox. You can also choose pieces of the proposed solution to incorporate in your application architecture.
Leveraging Spring with EJB 3.0
EJB 3.0 caters to the growing preference among enterprise Java developers for a POJO-based development model and IoC support in the container. However, this does not mean that tools like Spring don't have a place, or that EJB 3.0 and Spring have to be an either/or proposition. They certainly can be complementary. In fact, you can continue using the same development pattern you do with Spring and seamlessly integrate it with EJB 3.0 components—all while filling in some holes in the EJB 3.0 specification.
The composite model proposed in this article enables you to combine EJB 3.0 features such as message-driven beans, web services implementation, declarative component security, clustering, component pooling, and stateful components with Spring features such as strong AOP (using tools like AspectJ), POJO injection, productive helper classes, Java Persistence API (JPA) integration, and resource integration.
You can use either of the following two methods to leverage Spring effectively in J2EE applications using EJB 3.0 components:
- Use Spring as a general IoC-AOP container, and then integrate EJB components as regular beans to implement business functionality.
- Use Spring as a provider of EntityManager for the underlying JPA implementation. In this case, Spring goes beyond basic container support to manage the state of the EntityManager and ensure compatibility with third-party JPA providers, automatic participation in transactions, exception handling, and so on.
The application example in this article explains how you can implement method #2 in a solution. It uses Hibernate as the JPA implementation.