EJB Inheritance, Part 1

6. Home Methods

Note that since home interfaces are not inherited, if you want to allow someone to invoke a home method on a subclass you will have to manually copy the home method's signature from the base class home interface to the subclass home interface.

When a home method returns an EJB object in the hierarchy, write the method signature so that it returns Object. Then the home method can be polymorphic (you can override them in subclasses). The only issue is that you'll have to cast the result to one of the local interfaces on the client side.

Home method implementation requires a similar approach to that for create and finder methods. Business logic of the superclass can be used by calling super.ejbHomeSomething(). The result can then be used or augmented in the subclass' home method. I didn't write an example, but you can refer to the create and finder methods above if you need inspiration.

7. Table Mapping

We're all done with the coding part. Up until now, our code followed the EJB 2.0 standard. Now comes the vendor-specific part. Once our entity beans are written, we must map them to database tables. I have chosen to map each bean to a different, unrelated table. Figure 2 gives a diagram of the database schema:

Figure 2. Database schema

Note the following:

• There are three distinct tables.
• The column names are repeated in all tables.
• There are no relationships between the tables.

This design is known as "horizontal mapping." There's a one-to-one correspondence between the fields in the database tables and the fields in the entity beans.

Since this part is vendor-specific, I didn't quote any code here. If you want to look at an implementation, look at the one I wrote using WebLogic Server 7 (with the provided PointBase database). You can download the complete RTM example as a zip file.

In the next article, we'll talk about more options for mapping entity beans to database tables.

Other Considerations

Primary Keys

In our example, the primary key was a String. This example relies on the rule that all keys must be unique across objects of all types. You can't have a GoldCustomer and a PlatinumCustomer with the same key. This rule is essential for the locate methods to work properly.

In the case where the key is compound, a primary key class must be written. This class can be shared among all related classes in a hierarchy, but sometimes an entity bean subclass has a different set of fields. In that case, multiple key classes can be provided.

Primary keys can also inherit from one another. This means a key for an entity bean subclass can inherit from the key of its base class. Note that primary key subclasses are specializations of their superclasses. This means, by subclassing, you can't remove or modify fields of the primary key base class. You can only add fields. This will very rarely be useful.

If you use different keys for the entity beans of your hierarchy, you must modify your system as follows:

• Initialize the additional key fields in the ejbCreate() methods of the subclasses.
• Locate methods must construct the right key field when calling finder methods. The key must "mutate" between each finder invocation.
• Make sure the keys remain unique in order for locate methods to work. For example, imagine a hierarchy where two objects of different types exist with keys (A,B) and (A,B,C). Locating (A,B,C) will result in the object (A,B) being returned. If you want to locate objects of a single type, use a finder instead.

EJB Container Providers

Not all EJB containers behave the same. Some vendors prohibit entity beans from extending other classes. This is due to the different ways the specification can be interpreted.

The example I provided works fine under WebLogic Server 7, and should be easily adaptable to other EJB containers. I didn't have the time to test the example under other products. If you're using another product, please let us know if the example works, and what changes need to be done to make it work.

In the future ...

The EJB specification (2.0, and even 2.1 public draft) mentions a few things regarding inheritance:

• Session beans enable inheritance.
• Message-driven beans do, too.
• Inheritance is allowed in entity bean implementations and business interfaces (home interfaces are mentioned in the specification, but that doesn't work, since create and finder methods must return objects of a specific type).

In the future, the EJB specification may be changed to allow inheritance in entity beans (see specification, appendix A). In order to do that, a couple of things will have to change:

• Object should be a valid return type for create and finder method signatures in the home interfaces.
• Finder methods will have to become polymorphic.

What will the EJB committee come up with?

Reality Check

Entity bean inheritance isn't going to make your life that much easier. It may make the code smaller, with less repetition, and more maintainable. But there is some work involved (especially for finders and table mapping), which may negate these benefits.

Before you go ahead and merge all of your entity beans into a hierarchy, ask yourself what kind of improvement and effort are involved. If the repeated code is small, it may take less effort to isolate it into a utility class. That's what I would do if I had to refactor a COBOL program (*wink*).

But if you have many objects that are based on each other, using inheritance may result in the most maintainable system.

Emmanuel Proulx is an expert in J2EE and Enterprise JavaBeans, and is a certified WebLogic Server 7.0 engineer. He works in the fields of telecommunications and web development.

Return to ONJava.com.