Final submission draft

This commit is contained in:
reynisson 2021-12-22 15:55:48 +00:00
parent cab63d6b76
commit 8faabb4d44
18 changed files with 56 additions and 21 deletions

View File

@ -0,0 +1,29 @@
# 2. Seperate service for Executor Pool
Date: 2021-11-21
## Status
Accepted
## Context
The Executor Pool has to keep track of which Executors are online and what task types they can execute. The Roster keeps track of tasks that need to be executed and assigns Executors to tasks. The Executor Pool functionalty could be implemented in a seperate service or as a part of the Roster.
## Decision
The executor pool will be implemented as a seperate service.
Most importantly, the Executor Pool and the Roster have quite different responsibilities and reasons to change. On one hand, the Executor Pool manages the Executors, and therefore it will change if we want to add functionality that impacts how Executors log onto the system and how we keep track of them. For example, if we want to check if an executor fulfills some requirements before logging on. On the other hand, the Roster manages the execution of tasks. TODO
Single responsibility
Potential Code volatility
Scalability - Roster needs much more scale
## Consequences
The one funcionalty that is duplicated is error handling when an executor disconnects nongracefully...
TODO

View File

@ -0,0 +1,27 @@
# 12. separate service for each executor
Date: 2021-11-21
## Status
Accepted
## Context
Executors must receive tasks of different types and execute them. The executors could either all be implemented within one service or as multiple services, one for each type of executor.
## Decision
We will have a seperate service for each type of executor.
Firstly, execution time differs significantly between task types. Therefore, having seperate services will allow the executos to scale differently based on their tasks' specific needs.
Secondly, the systems functioning should not be disrupted in case an Executor fails. Having each type of executor in a seperate service will increase fault tolerance in this regard.
Lastly, extensibility is one of the systems most important non-functional requirement and providers of executors need to be able to easily add executors to the executor pool. These factors are also positively impacted by having seperate services.
There should not be any shared data between the executors. Additionally, there should be no flow of information between them. Thus, there should be no issues due to workflow and data concerns due to this decision.
## Consequences
Executors share a lot of functionality when it comes to connecting to the rest of the system. Therefore, this decision means that we will either have to duplicate the code that implements the common functionality, or we have to have a way to share the code (e.g. through a common library)

View File

Before

Width:  |  Height:  |  Size: 2.0 MiB

After

Width:  |  Height:  |  Size: 2.0 MiB

View File

@ -1,21 +0,0 @@
# 2. Seperate service for Executor Pool
Date: 2021-11-21
## Status
Accepted
## Context
The Executor Pool has to keep track of which Executors are online and what task types they can execute. The Roster keeps track of tasks that need to be executed and assigns Executors to tasks. The Executor Pool functionalty could be implemented in a seperate service or as a part of the Roster.
## Decision
The executor pool will be implemented as a seperate service. (TODO decision might change. Need to reevaluate)
TODO explain why.
## Consequences
TODO