The intended work is to create a clean boundary between runtimes and the engine like it was in the past so we can identify certain points and avoid entagling the code at this between components.
The main ones are (At least these should be packaged in different jars)
Engine Service API -> façade to interact with the engine: coarsed grained operations that involveds several low level operations or boilerplate code to perform a functionlity. For instance: boot up engine, process lifecycle operations, Admin operations. This goal of this api should be the ones used by the runtimes. descriptors for setting up the engine, etc...
Engine Low level API -> focus on fine grained interactions with the engine (wih extension points, listeners, access, executors, schedulers, tx....). Not intended to be used by runtimes just embedded.
Human Task API -> Human task has its own identity (it is important enough to make it a API it self and its own evolution). It should be also dettached from the workflow engine and human task has a different lifecycle itself. From the engine point of view it is just an activity.
SPI runtime identification -> This should be a collection of interfaces in order to extend the engine. In the case of runtimes it should be those interfaces that allows the engine to communicate with the outside world like persistence, timer manager, queues / streams, etc...
The scope of this work is not to refactor any code, namespace or functionality. Just to clean dependencies and identify the API and SPI involved in runtimes and engine.
Ideally the target of this work should be something like:
Runtimes depends on Collection sets of API, SPI
Process Engine depends on Collection sets of API, SPI
tiagobento
commented
1 year ago
The intended work is to create a clean boundary between runtimes and the engine like it was in the past so we can identify certain points and avoid entagling the code at this between components.
The main ones are (At least these should be packaged in different jars)
Engine Service API -> façade to interact with the engine: coarsed grained operations that involveds several low level operations or boilerplate code to perform a functionlity. For instance: boot up engine, process lifecycle operations, Admin operations. This goal of this api should be the ones used by the runtimes. descriptors for setting up the engine, etc...
Engine Low level API -> focus on fine grained interactions with the engine (wih extension points, listeners, access, executors, schedulers, tx....). Not intended to be used by runtimes just embedded.
Human Task API -> Human task has its own identity (it is important enough to make it a API it self and its own evolution). It should be also dettached from the workflow engine and human task has a different lifecycle itself. From the engine point of view it is just an activity.
SPI runtime identification -> This should be a collection of interfaces in order to extend the engine. In the case of runtimes it should be those interfaces that allows the engine to communicate with the outside world like persistence, timer manager, queues / streams, etc...
The scope of this work is not to refactor any code, namespace or functionality. Just to clean dependencies and identify the API and SPI involved in runtimes and engine.
Ideally the target of this work should be something like:
Runtimes depends on Collection sets of API, SPI Process Engine depends on Collection sets of API, SPI