Before determining the best solutions for various requirements, let's go over the implementation details that are common to all cases:
- When an inheritance relationship is defined between enterprise beans, all home methods that are not part of an association are copied to the child bean. In order to have specific create methods on subtypes without having to support the supertype create methods, the child Home interface will not extend the supertype enterprise bean's Home interface.
- The bean class of the new child enterprise bean extends the bean class of the parent enterprise bean.
- If any of the parent bean methods or callback methods is overridden in the child method, the implementer has to call the parent method in the child implementation if required.
- The Local and Remote interfaces will extend the supertype enterprise bean's remote interface.
- Key classes are common to all inherited enterprise beans. Therefore, the key class in the child enterprise bean is identical to the key class in the parent enterprise bean.
- You can add to the key only at the root bean.
- In case of standard class inheritance, the EJB references defined on the parent had to be copied manually to the child bean. With EJB inheritance, all references marked to the parent bean automatically transfer to child beans.
- All the beans referencing child beans automatically have references to parent beans and not vice versa. So the implementer has to ensure that all the references are changed to child if he needs to access a child (especially in the case of standard class inheritance, in which the parent bean would be deleted and all the references to it lost). Make sure the references are moved to child if you are moving to standard class inheritance.
By default, EJB inheritance hierarchies are mapped to a single table; that is, the base and all derived enterprise beans are mapped to the same database table. Additional options exist that support generating joined tables for the leaf enterprise beans.
To create an inheritance map, select the enterprise bean and the corresponding table. Just like in secondary tables, you need to have a primary-key to primary-key/foreign-key relationship. The rest of the beans in the inheritance structure are then mapped as a root/leaf inheritance map. You can regenerate the default map and schema using the Mapping wizard or by clicking Re-execute Mapping Commands in the Mapping editor.
The Discriminator column is used for distinguishing between the various entity beans stored in the table. Set this property in the Bean to the Table Strategy section on the Property view of the Mapping editor.
For standard class inheritance mapping, where you want to maintain the superclass mappings before deleting the super class deployment description, simply copy the mapping from the superclass EJB into the deployment description of the subclass EJB. Next, manually add the additional attribute to the subclass's table and define the mapping for it.
For EJB inheritance, you need to deploy both the child and parent entity beans. In WSAD, the child entity bean definition sets the inheritance relationship. In standard class inheritance, removing the deployed parent EJB makes sense. In this scenario, avoid deploying the superclass EJB if they are not instantiated directly (This eliminates cluttering the JNDI tree with things that are never requested). So remove all the definitions in both deployment and mapping descriptions to the superclass EJB, and add the undeployed superclass EJB (home, remote, and bean class) as utility classes (e.g., using a Java Project in WSAD).
Note: When you add a child class and then delete the deployment description of a parent class, WSAD automatically removes the class inheritance code from the child class. So you have to be sure to maintain that code.