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?

In This Series

EJB Free and Open Source Tools Summary
What's the best platform for J2EE development? Emmanuel Proulx finds himself answering that question time after time. In this article, he explores several free-as-in-speech and free-as-in-beer EJB 2.0 tools and gives his suggestions for choosing an application server.

EJB Inheritance, Part 4
This series has demonstrated all sorts of ways to handle inheritance in beans. With web and message services, though, how do you handle inheritance with remotely-invoked beans? The EJB 2.0 specification allows it; Emmanuel Proulx demonstrates how.

EJB Inheritance, Part 3
Session beans can take advantage of inheritance, just like entity beans. Indeed, implementing session bean inheritance is nowhere near as hard as it is with entity beans. Part 3 of this series shows the proper technique for implementing inheritance in session beans and addresses the use of factories.

EJB Inheritance, Part 2
Part two of this series on inheritance with Entity Java Beans focuses on the various options for table mapping.

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.