28 lines
2.3 KiB
Markdown
28 lines
2.3 KiB
Markdown
|
# 13. Use Choreography For Task Execution Workflow
|
||
|
|
|
||
|
|
Date: 2021-12-10
|
||
|
|
|
||
|
|
## Status
|
||
|
|
|
||
|
|
Accepted
|
||
|
|
|
||
|
|
## Context
|
||
|
|
|
||
|
|
The Task Execution Workflow (workflow that takes a task from created to executed) is the main workflow in the whole TAPAS system. It can either be orchestrated, or choreographed. If it is choreographed then it should follow one of the following patterns: Front Controller Pattern, Stateless, or Stamp coupling.
|
||
|
|
|
||
|
|
## Decision
|
||
|
|
|
||
|
|
The Task Execution Workflow will be choreographed and will follow the Front Controller Pattern, storing the workflow state in the Task List.
|
||
|
|
|
||
|
|
The reason for why it should be choreographed is that this will optimise the for responsiveness, scalability, and fault tolerance. There are all driving architectural characteristics for our system.
|
||
|
|
|
||
|
|
Moreover, the workflow should utilise the Front Controller Pattern as this pattern fits the architecture naturally. The tasks in the Task List already have a Status property. This property can be used to keep track of the state of the task within the execution workflow. Moreover, since updating this state is already a part of the architecture, the system will not suffer greatly from the normal drawback of using this pattern (additional state property, increased communication overhead).
|
||
|
|
|
||
|
|
Using this pattern will make querying the state trivial since we just need to look up the status of the task in the Task List. Moreover, it makes the Task List a pseudo-orchestrator within our choreography which will reduce the complexity for error handling as much of it can be added to the Task List. Lastly, since the Task List is accessible by the users that created the task, they can then make ultimate decisions for error handling. For example, when no executor has been found for a task (neither internal nor external) then the end user could either delete the task or ask for it to be re-run through the roster and auction house at a later date.
|
||
|
|
|
||
|
|
## Consequences
|
||
|
|
|
||
|
|
Making the Task Execution Workflow choreographed will make error handling more complex. For now it seems manageable, but if the complexity becomes to great we could implement the Workflow Event Pattern in order to mitigate the increased complexity.
|
||
|
|
|
||
|
|
Recoverability and state management might also suffer, but a good implementation of the Front Controller Pattern should mitigate more of the negatives for those aspects.
|