i recently realized that pluggable architecture should be replaced with inheritence as much as possible.

currently, jPDL and the jBPM GOP implementation is designed according to the pluggable architecture mechanism. This means that you can plug new features into the core engine by means of aggregation.

You can add new process definition information (e.g. the average time it takes for a node to execute or the odds of taking a specific transition) that results in new runtime information and add new logs.

The pluggable architecture made sure that you can develop process features and deploy them in any process language.

In practice, users do not compose and customize their process langauge a lot. They might only tweak here and there.

But the pluggable architecture also has a downside. The main downside is that all modules have to operate independently. We were lacking some kind of notification mechanism by wich modules could listen to events generated by other modules.

This all becomes much easier if you take an inheritence approach. Meaning that we forsee base classes ProcessDefinition and ProcessInstance. And that for the jPDL language we create subclasses JpdlDefinition and JpdlInstance. In the latter case, we implement a JpdlDefinition with a fixed set of modules. That makes it easier to tightly integrate the different modules with each other.

Probably we still want to keep some kind of extensibility mechanism, but e.g. the context and the taskmgmt should definintely be an integral part of jPDL, whereas now those are treated as independent extension modules.

This should improve the database schema and the lengthy object graph navigations that you now regularly encounter in the API.

i realize this explanation is not very clear. i just want to throw it out in the open. feel free to ask for more explanation or share thoughts.