EJB Inheritance, Part 2

by Emmanuel Proulx
09/25/2002

Implementing EJB inheritance is not straightforward. In my previous article, I described a technique to implant inheritance into entity bean objects, by emulating inheritance-like behavior in some areas. These areas are create and postCreate methods, home methods, and finder and ejbSelect methods.

I must admit, hacking inheritance behavior into these methods is not natural. This is especially true for the finder and ejbSelect methods, which don't behave polymorphically. In other words, finding objects of the base class doesn't fetch objects of subclasses. I have shown you how to work around this problem using a technique I call locate methods.

A locate method must know the following in order to perform its duty:

• The list of all subclasses of the current class.
• The finder and ejbSelect methods that are associated with the invoked query.
• The type of table mapping used.

The two first items are simple; either you know this information or you will find out. The last item is not so simple to grasp.

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 1 The principles of object-oriented programming are encapsulation and inheritance. Enterprise JavaBeans handle encapsulation just fine, but what about inheritance? In this article, the author attempts to apply inheritance to EJBs.

About Table Mapping

Table mapping is the action of connecting in-memory objects to database tables. In the case of entity beans, we're mapping the bean's fields to table columns. In the EJB world, table mapping is not standard at all. Vendors implement this differently.

Yet there are general trends, or options, to map a hierarchy of entity objects to database tables. Choosing which option works for you depends on:

• The current design of your database schema.
• What features are available in your application server product.
• How simple the resulting code must be.

Now let's explore the various options.

Table Mapping Options

There are three different ways to map a hierarchy of EJBs to a database (that I'm aware of):

1. Horizontal mapping: each object maps to completely separate tables.
2. Vertical mapping: objects map to a hierarchy of tables linked with relationships, to avoid duplicate columns.
3. One-table mapping: objects map to a single table, with a "category" field.

Table 1 offers a summary of the three table mapping options, and their characteristics:

Table 1. Table mapping options, characteristics

Characteristics	Horizontal	Vertical	One-table
Number of tables	One per class	One per class	1
Relationships?	No	Yes	No
Repeated columns?	Yes	No	No
"Category" column?	No	No	Yes

Let's explore each table mapping alternative, mention how they are used in our RTM example, and provide code that supports them. We'll also discuss when each alternative is appropriate.

Horizontal Mapping

Horizontal mapping was covered in the first article of this series. The database schema is composed of disconnect tables, one for each class. This diagram illustrates the database schema used in our RTM example:

Figure 1. Horizontal mapping database schema

As mentioned in part one of this series, the code for locate methods follows this logic:

• For a locate method returning a single object, find the object in the current bean using its finder. If no object was found, try in each subclass until it is found.

• For a locate method returning multiple objects, create a list to accumulate the results. Find the objects in the current bean and add them to the list. Find or locate the objects in each subclass and add them to the list.

Refer to the first article for the source code snippets (the methods ejbHomeLocate() and ejbHomeLocateAll()). This code is also included in the zip file for this article.

NOTE: One thing I forgot to mention in the previous article: it makes more sense to use the subclasses' locate methods to recursively go through the whole hierarchy, instead of using finders. In my examples, subclasses didn't need any locate methods because they were "leaves" in that hierarchy. But it may be a good idea to write locate methods for all classes, even for those "leaf" classes. Such locate methods would just call the finders directly. This is done for consistency, but also, if new classes are added under a "leaf" class, you won't have to modify its base class.

Assessment: This is the most portable way to implement EJB inheritance, with the simplest table-mapping configuration.

Pages: 1, 2, 3

Next Page