Inheriting from ProcessDefinition

[aguizar]

The 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?

[kukeltje]

suppose xpdl or ebBP comes in... will that out 1 or 2 in favour of the other? (I cannot decide since it is not my field of expertise...

[tom.baeyens]

If your current design is based on inheritence, adding the discriminator in the hibernate mappings is probably the simplest. You'll have to do this for the BPEL mappings only as a modification to the jPDL mappings.

But in the current jPDL design, using the ModuleDefinition is the most 'natural'. This comes down to replacing inheritence (what you actually want) with inheritence.

If you would take this route, this is what you gotta know:

There is a configuration file that configures the default modules created when a process definition is created. You could add a BpelModule.

But of course, the module definition approach was a bad design choice and it will be replaced by inheritence in jbpm 4.


does that answer all your questions ?

[aguizar]

Adding the BPEL module will be hard at this point, because the BpelDefinition class is everywhere.

I'd rather add the discriminator to the ProcessDefinition mapping. So far, I've removed ProcessDefinition.hbm.xml from my Hibernate configuration, copied the mappings there to BpelDefinition.hbm.xml and added the discriminator myself, along with the class. This is not desirable because mappings can change between jPDL versions.

[aguizar]

"kukeltje" wrote:
suppose xpdl or ebBP comes in... will that out 1 or 2 in favour of the other? (I cannot decide since it is not my field of expertise...

If xpdl or ebXML came in they'd probably need to extend ProcessDefinition as well, by either aggregation or inheritance. Since the Node mapping already uses a discriminator, the obvious choice is taking the same path for ProcessDefinition.

[tom.baeyens]

alejandro, could you double check if you cannot revert to the ModuleDefinition ? I think it is strange that you bump into this problem now.

I could add the discriminator, but that would imply we have to write a DB conversion script for 3.1.x to 3.2.x. As up to now, we only had addition of columns, tables and constraints. This would introduce the first update statement to be executed for a port from 3.1 to 3.2.

so can you double check wether that isn't possible and give me some pointers on that ?