Browse DevX
Sign up for e-mail newsletters from DevX


Entity Bean Inheritance in WebSphere Application Server : Page 3

The lack of guidelines for EJB inheritance in the EJB specification does not mean entity bean inheritance isn't a required feature for J2EE applications. Learn about the inheritance of entity beans so you can develop hierarchal, persistent objects.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Inheritance Case Studies
This section examines different inheritance scenarios, suggesting when to choose standard or EJB inheritance for each according to your requirements.

Case 1: Inheritance with only one child bean and abstract parent
A single child bean, parent bean acts as just a template and it is never used/created as a sole entity bean. For example, consider a company that deals only with U.S. customers. It wants to use "Address" and extend it to USAddress (Figure 1 shows a class diagram for this scenario).

Figure 1. Inheritance with Only One Child Bean and Abstract Parent

This is a typical case for which you should use standard class inheritance. For Address, AddressBean would just be two Java classes and USAddress would be the actual entity bean. AddressBean's home is not required now.

If your Address bean already exists, its deployment description has to be deleted. Again, before deleting the entity bean, you need to keep a copy of the database mapping . Also, make sure that you delete only the bean description and not actual classes. Removing the bean and unselecting the option "Delete Bean classes" in the "Delete Enterprise Bean" dialog box can do this.

Now you can copy back the mapping descriptions, ejb-queries, and references. You already have a parent entity bean mapped to its table. Here are the steps you would follow:

  1. Copy the newly generated child entity beans code to ejbModule\packagename directory.
  2. Refresh and rebuild the project.
  3. Open ejb-jar.xml in a text editor, and replace the parent entity bean's name with the child entity bean.
  4. Add additional cmp fields into this entity bean.
  5. Open the parent entity bean table configuration in the table editor.
  6. Change the table names to the child bean name, and add the additional required columns to this table.
  7. Open mapping in Mapping editor, and create the mapping between the renamed table and child bean. Also, you may be required to manually create mapping between new columns.
  8. Save everything and generate the deploy and RMIC code.

Case 2: Multiple child beans and abstract parent
A multiple child bean, parent bean act as just a template and are never used/created as a sole entity bean. You encounter this scenario in a lot of places, and you cannot use the solution provided in Case 1 for it. Deleting the parent entity bean would case the child beans to act like independent, non-related entity beans.

Figure 2. Multiple Child Beans and Abstract Parent

This case manifests itself in two ways:

  1. When two-child beans need to be connected only logically (i.e., they do not share the common persisted data), you remove the parent entity.
  2. When two children are not connected only logically through a common parent but also share common database columns for storing persistent data, you keep the parent entity bean but make it logically abstract so that it cannot be initiated. (Figure 2 shows an example in a class diagram.)

In scenario number 2, you have a parent Address bean that you already have created and deployed. Now you have two child entity beans: one for USAddress and another for RestOfWorldAddress (see Figure 2).

To make a parent entity bean logically abstract, make the following changes:

  1. Give Home a findByPrimaryKey method, but no create methods.
  2. Give HomeHelper a findByPrimaryKey, but no create and remove methods.
  3. Give HomePolicy the same methods as HomeHelper.

You would already have a parent entity bean mapped to its table. Here are the steps you would follow:

  1. Copy the newly generated child entity bean's code to the ejbModule\packagename directory.
  2. Make the parent bean logically abstract (following the changes defined above). Refresh and rebuild the project.
  3. Open ejb-jar.xml and add the newly generated child entity beans to the project. Also, add any extra fields.
  4. Open ejb-jar.xml in the deployment description editor, go to the inheritance section, edit both the child entity beans, and select Inherits from supertype. This ensures that the cmp_ids used in ejb-jar.xml are common for all three entity beans. This may also add an additional ejbFindByPrimaryKey method, which has to be removed.
  5. Open parent entity bean table configuration in the table editor.
  6. Add additional required columns, and add an extra discriminator column.
  7. Open mapping in the Mapping editor, select Parent bean, and go to the property pane. Name the newly created column discriminator column, with the value "ParentBeanName".
  8. Create the mapping between the parent table and child beans. Also, you may be required to manually create mapping between new columns. Make sure the values and column name for discriminator are the same for all three entity beans.
  9. Save everything and generate the deploy and RMIC code.

Figure 3. Class Diagram for Case 3

Case 3: Inheritance with one child bean, and parent bean
In this case, child and parent entity beans can be created and accessed independently. The standard class inheritance cannot help you in any way here. The only solution is to deploy both the parent and child entity beans independently. As shown in Figure 3's class diagram, both the Address entity bean and the EmployeeAddress entity bean can be used and created.

The solution for this scenario is quite similar to that for Case 2. You define the EmployeeAddress bean as a child bean in the inheritance section of ejb-jar.xml, and then map the child bean on the same or a different table depending upon the mapping technique you choose. The only difference between this and Case 2 is that the parent entity bean would also have the create methods. So you do not need to make the parent entity bean logically abstract. So all the steps for this transformation are the same as Case 2, except for Step 2 (which is not required).

Figure 4. Class Diagram for Case 4

Case 4: Inheritance with multiple child beans and parent bean
This case is very similar to Case 3—in fact, the solution to this case is the same as Case 3. Consider the case where you want to use EmployeeAddress for Employees, OfficeAddress for Offices, and Address for the rest of the addresses (see Figure 4). Here, you would select entity bean inheritance with Address as the parent bean and EmployeeAddress/OfficeAddress as the child beans. Again, you would use discriminator in this case.

Object-oriented Design for Your Beans
Using inheritance to design your beans gives you the real advantage of using object-oriented designing. Most application servers provide a process for inheriting session beans, but entity bean inheritance is not yet covered in the EJB specification. This article provided instructions for using entity bean inheritance in IBM's WebSphere Application Server. The different scenarios presented give you an idea of how you can use inheritance for entity beans.

Rakesh Midha is a staff software engineer with IBM Software Labs, Bangalore. He currently works on IBM WebSphere Business Components development and has five years' experience in Java and C++ server-side programming on multiple platforms and various relational database systems.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date