TAPAS-Final/doc/architecture/decisions/0002-seperate-service-for-executor-pool.md

@@ -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

TAPAS-Final/doc/architecture/decisions/0012-separate-service-for-each-executor.md

@@ -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)

doc/architecture/decisions/0002-seperate-service-for-executor-pool.md

@@ -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