Last month's article on EJB 3.0 (Vol. 9, issue 11) focused primarily on the basic features of the specification. Part 2 dives much deeper into the specification to talk about more advanced features like dependency injection, dependent objects, secondary tables, and inheritance.

Dependency Injection
Dependency injection is the opposite of jndiContext.lookup(). The idea of dependency injection is that objects and services specify which resources and configuration values they require, and their container automagically injects these values. Dependency injection is supported for any session bean type and will also be supported in the greater J2EE specification in items such as servlets. This approach requires no JNDI lookup at all and can greatly simplify code. Let's look at an example.

@Stateful
public class ShoppingCartBean implements ShoppingCart
{
   @Inject private UserTransaction userTx;
   @Inject private EntityManager entityManager;

   private Petstore store;

   @EJB(name="petstore") public void setPetstore(Petstore store) {
      this.store = store;
   }

When an instance of ShoppingCartBean is allocated, the EJB container will look up the UserTransaction service and set the userTx variable. It will also get a reference to the EJB whose ejbName is "petstore" and call the setPetstore() method. Values can be injected either with an explicit field set or by calling a setter method. A great side effect of injection is that it becomes possible to test beans outside the context of a container. @Resource is another annotation for injecting things like DataSources and JMS connections.

Dependent Objects
The EJB 3.0 specification defines a full object/relational mapping for dependent value classes. You can map the properties of an aggregated value object in your entity to specific columns of the entity's table.

@DependentObject(access=AccessType.PROPERTY)
public class Address implements java.io.Serializable {

   private String street;
   private String state;
   private String city;

   public String getState() { return state; }
...
}

Your dependent value class can either have its properties defined as get/set methods or directly as fields. Next, define the mapping of a @DependentObject within your entity bean (see Listing 1).

Multi-Table Mappings
Many application developers find it necessary to map an entity bean to multiple tables within a database, especially when they have to map objects to a legacy data schema. EJB 3.0 provides mappings for this using the @SecondaryTable annotation.

@Entity
@SecondaryTable(name="ADDRESS", join={@JoinColumn(name="address_id")})
public class Customer {
...
   @Column(name = "street", secondaryTable = "ADDRESS")
   public String getStreet()
   {
      return street;
   }
...

The @SecondaryTable is defined as a class annotation and specifies the table's name as well as the columns to use to join the main and subtable together. The @JoinColumns of the secondary table must map directly to the primary key of the entity.

To map a specific property to the secondary table, specify the secondaryTable annotation member value from the @Column annotation.

Entity Inheritance
Another missing feature in EJB 2.1 is the ability to support inheritance and map a complex class hierarchy to a relational database. EJB 3.0 supports inheritance and polymorphic queries. Three types of inheritance mapping strategies are supported: one table per class hierarchy (SINGLE_TABLE), a join table per subclass (JOINED), and a distinct table per class (TABLE_PER_CLASS). Only SINGLE_TABLE is required by the EJB 3.0 specification, so we'll focus on an example covering that.

SINGLE_TABLE Strategy
The SINGLE_TABLE specifies that there should be one and only one table per class hierarchy. This table should have a column for each unique field for every class in the hierarchy. The table must have an additional column that identifies the object's type. By default, its type is a string with the default value being the fully qualified class name of the object stored. The @DiscriminatorColumn maps the object identity to a specific database column. The SINGLE_TABLE strategy is the optimal strategy for performance as the persistence engine doesn't have to do any complex joins when loading such an object. For example, say we have an Animal superclass entity bean, and a Dog subclass. The Java code would look like Listing 2.

The table mapping would be one gigantic table:

create table Animal (
ID Number,
TYPE varchar(255),
AVG_WEIGHT Number,
BREED varchar(255)
);

All entities that subclass from Animal can be queried polymorphically:

Query query = entityManager.createQuery("from Animal a where a.averageWeight > 10");

This query could return an instance of a Dog, Cat, Elephant, whatever entities that are currently defined in the Animal hierarchy.

Finally Usable
EJB 3.0 finally makes EJB persistence a reality. With EJB 2.1 entities you continually had to escape to direct JDBC, rely on vendor proprietary extensions, or move to an entirely different object/relational mapping strategy altogether. Features such as a full object relation mapping including a fully featured query language, inheritance, secondary tables, and dependent objects finally make the EJB specification.

With the use of annotations, XML deployment descriptors that have long been the bane of EJB developers can be completely removed if so desired by the developer.

All in all, EJB has come a long way since the 1.0 days and is morphing itself to the specifications of the community for which it was written.

References