Inheriting from ProcessDefinition
aguizar Feb 15, 2007 7:17 PMThe class org.jbpm.graph.def.ProcessDefinition describes jPDL processes. Some of its properties are useful for BPEL processes as well. Some of these properties are *not* useful for BPEL and merely bloat ProcessDefinition instances that describe BPEL processes. Further, BPEL processes require some additional properties not defined by ProcessDefinition.
Unlike Node, ProcessDefinition does not have subclasses in the jPDL model and does not define a discriminator. This prevents inheritance using the table per class hierarchy strategy. There are at least two ways to work around that limitation:
1. Use table-per-subclass (i.e. an additional BPEL_PROCESSDEFINITION table)
2. Override the default ProcessDefinition mapping with an alternate mapping that contains the same properties and adds a discriminator
So far (2) has been the option of choice, as a few extra fields in the JBPM_PROCESSDEFINITION table do not seem to justify the table join overhead imposed by (1). However, (2) has a big drawback: the alternate mapping can get out of sync with the default mapping.
I'm looking for a way to avoid overriding the default ProcessDefinition mapping. The options, in increasing order of complexity, are:
0. Do nothing. Keep synchronizing.
1. Switch to table-per-subclass.
2. Add the discriminator to the ProcessDefinition mapping, even if unused in jBPM jPDL.
3. "Pull up" the fields from BpelDefinition to ProcessDefinition.
->In this regard, jPDL has an edge over BPEL because it can add properties to the core graph objects even if they don't make sense for BPEL. Since the BPEL subproject resides in a separate codebase, it is not just as easy.
4. Abandon inheritance for aggregation.
->Perform complex refactoring to move the fields and methods from BpelDefinition to a new ModuleDefinition.
5. Introduce an "AbstractProcessDefinition" class.
->This implies analyzing each occurrence of ProcessDefinition in the jBPM codebase to determine whether it means "generic process" or "jpdl process".
With the PVM in sight, (4) and (5) are not worth the effort. (1) or (2) seem fair. What do you think?