Register for Real-World Java Seminar

The Java Platform, Enterprise Edition, or Java EE, is the most popular middleware platform for developing and deploying enterprise applications. Java EE offers developers a choice of vendors, portability, scalability, and robustness. However, it has been criticized for its complexity and its need for a lot of redundant and procedural code. In addition, lightweight frameworks such as Spring and scripting platforms such as Ruby on Rails have emerged to challenge the platform's supremacy in the middleware world.

In response, the Java Community Process has made great efforts to simplify the developer's life with Java EE's latest incarnation: Java EE 5. Innovations such as radically simplified models for Enterprise JavaBeans (EJB) and Web services have changed how enterprise applications are built using Java EE 5 technologies. Combining the robustness of the Java EE platform with lightweight frameworks such as Spring further enables developers to rapidly develop portable, maintainable enterprise applications.

In this two-part series, I will discuss how Java EE 5 simplifies enterprise application development, then uncover how you can utilize the Spring Framework to fill the gaps left by Java EE 5.

Simplified Programming Model with Java EE 5
Java EE 5 radically simplifies the development of enterprise applications by:

• Adopting a plain old Java object (POJO) programming standard and setting intelligent defaults for EJB components
• Eliminating the need for deployment descriptors and using Java metadata annotations for deployment settings instead
• Introducing a simplified POJO persistence model similar to Oracle TopLink and JBoss Hibernate
• Using dependency injection instead of the Java Naming and Directory Interface (JNDI) to locate resources and EJB components

Let's briefly examine these changes.

Simplified Persistence
Most developers who used the EJB 2 container-managed persistence were disappointed with its complexity and performance. As a result, POJO persistence frameworks such as Hibernate and TopLink became popular, compelling the Java Community Process to standardize a persistence API for the Java platform on a POJO persistence model.

If you've used an object-relational (O/R) mapping framework to build the persistence tier of your application, you'll notice that each framework provides three facilities:

• A declarative way to perform O/R mapping. This method, called O/R mapping metadata, lets you map an object to one or more database tables. Most O/R frameworks use XML for storing O/R mapping metadata.
• An API to manipulate entities (for example, to perform create, read, update, and delete - or CRUD - operations). The API lets you persist, retrieve, update, or remove objects. Based on the use of the API and the O/R mapping metadata, the O/R framework performs database operations on your behalf. The API shields you from writing Java Database Connectivity (JDBC) or SQL code to persist your domain objects.
• A query language to retrieve objects. This is one of the most important aspects of persistence because improper SQL statements may slow down your database. A query language also protects your applications from being cluttered with proprietary SQL, and lets you retrieve entities or objects without writing SQL SELECT statements.

The EJB 3 Java Persistence API (JPA) standardizes the use of persistence for the Java platform by providing a standard mechanism for O/R mapping, an EntityManager API to perform CRUD operations, and a way to extend the EJB query language (EJB-QL) to retrieve entities.

Introducing JPA Entities
An entity is a lightweight domain object - a plain old Java object that you want to persist in a relational database. Like any POJO, an entity may be either an abstract or a concrete class, and it can extend another POJO. You can use the @javax.persistence.Entity annotation to mark a POJO to be an entity, as shown in Listing 1.

(The code examples that follow are taken from my recently published book, EJB 3 in Action, published by Manning Publications.)

I've used annotations to define the mapping of entities to tables; you can also use XML. It's worth mentioning that JPA provides support for rich domain modeling capabilities such as inheritance, and polymorphism. JPA supports several inheritance mapping strategies: single table, joined subclass, and table per class. Unlike EJB 2 container-managed persistence (CMP), JPA is simple and supports automatic generation of primary keys.

Now that you've seen an entity, let's examine how you can manipulate entities by using the EntityManager API.

The EntityManager API
The javax.persistence.EntityManager manages entity lifecycles and exposes several methods to perform CRUD operations on entities. JPA supports two types of EntityManager: container-managed and application-managed. The application-managed EntityManager is really useful when using JPA outside a container. Let's look at an example of using a container-managed EntityManager to manage an entity.

You can use the persist() method to save an instance of entity. For example, if you want to persist an instance of Bid, use the following code:

@PersistenceContext(unitName="actionBazaar")
private EntityManager em;
...
Bid bid = new Bid();
bid.setItem(item);
bid.setBidder(bidder);
bid.setBidPrice(price);
em.persist(bid);

Now that you have a sense of how easy it is to use the persistence feature of EJB 3, we'll examine how EJB 3 simplifies the development of business components.

Simplified EJB 3 Components
EJB 2 was one of the primary technologies responsible for the complexities that have plagued enterprise Java development. Some detractors ridiculed it as a "fat elephant" for its heavyweight nature. It required a lot of redundant code, even to build a simple "HelloWorld" EJB.

EJB 3 simplifies development by adopting the POJO programming model, and simplifies usage of EJB and resources by using dependency injection. It also depends heavily on intelligent defaults and makes the deployment descriptor optional.

Listing 2 provides an example of a simple stateless EJB 3 session bean with a remote interface. In this example, PlaceBidBean is a simple POJO class that implements a regular Java interface - or a plain old Java interface (POJI). The @javax.ejb.Remote converts the POJI to a remote interface and @javax.ejb.Stateless converts the POJO to a stateless EJB.

You can use @Stateful and @MessageDriven annotations to define stateful and message-driven beans, respectively.