+1 for this idea. Future proofing our tech is certainly a good idea! I think this could also lead to some consolidation of code in the future, if I understand correctly.
On 2024/04/09 07:21:30 Enrique Gonzalez Martinez wrote: > At present, it is very difficult adding new nodes and new states to > the workflow engine. > > In the medium/long term, additional node types that only serve certain > requirements will be needed. The reasons for adding them can be really > different and they might only be useful in certain situations or > process definitions. > > The idea of the proposal is to create a set of extension points for > making the engine more reusable and allow other process definitions > add their own node types and execution types without polluting the > engine with basic primitives of execution. > > This will have an impact at three different levels. > > * Add capability to create node instances (node states) from the > nodes. This will impact the NodeInstanceFactory. > * Add capability to store that node instance This will impact the > marshaller and unmarshaller > * Add capability to extends the flow builder to allow code generation > > As the responsibility of compiling into an intermediate representation > relies on parser, that should not impact other modules. > This will allow a clear boundary among compilers and a clean > responsibility among modules to accept new features. > > This is a general idea of how this would look at the end: > > > * jbpm-flow: > - will contain the compiled process definition > - will contain the execution algorithm > - primitive nodes that cannot break down into smaller pieces > > * jbpm-marshaller > - contains the extension point for new nodes. > > * jbpm-flow-builder > - contains the extension point for generating code. > > * jbpm-flow-bpmn2-extension > - will contain nodes related exclusively to bpmn2 like human task > or ruleset > - contains marshall/unmarshalling logic for the new nodes > > * jbpm-flow-bpmn2-builder-extension > - contain logic for code generation > > * jbpm-flow-cmmn-extension > - nodes related to cmmn like sentries, plan, stages, milestones.... > - contains marshall/unmarshalling logic for the new nodes > > * jbpm-flow-cmmn-builder-extension > - contain logic for code generation > > * jbpm-flow-swf-extension > - will contain any special/optimized node for serverless workflow > execution. > - contains marshall/unmarshalling logic for the new nodes > > * jbpm-flow-swf-builder-extension > - contain logic for code generation > > As this is considered a Java component the mechanism to be used would > be the service loader approach without relying on any runtime like > quarkus or spring boot. > > This impact in the code should be rather small in this case but allow > more independency around working on process definitions > implementations (swf, bpmn2 or event future cmmn) > It reduces the friction among process definition implementations > It allows to focus in implementation details of process definitions > instead of changing primitives in the workflow engine causing > unnecessary changes. > > > > Cheers :) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > For additional commands, e-mail: dev-h...@kie.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org For additional commands, e-mail: dev-h...@kie.apache.org
