Evaluation Criteria Catalog
In order to evaluate different technological approaches concerning the Saga pattern, some criteria have to be defined against which the evaluation can be performed. The following sections consider several areas of interest related to characteristics of microservices and the Saga pattern as well as some quality attributes of the ISO/IEC 25010 Quality Models1. For each area, the aspects that an evaluator should examine are explained and described. Some of the described criteria have been taken from the previous paper published by Dürr et al. [3]. The aim is to create a criteria catalog that can be used to analyze other technologies in this context.
General Saga Characteristics
The Saga pattern includes different characteristics like the definition of compensating transactions. Thus, the following criteria examine how the implementation technology supports realizing those characteristics or related matters.
Saga definition
As this paper focuses on orchestrated Sagas, the sequence of the included transactions has to be defined, for example in a JSON file or programmatically via a DSL. Therefore, this criterion describes the different possibilities the examined technology offers to define the individual Saga process with its included steps.
Orchestrating services
Depending on the particular implementation, the Saga orchestrator can be an additional service that exclusively orchestrates the Saga or an existing one that also participates in it. However, some technologies might already provide an orchestrating engine that orchestrates the actual process single–handedly. Hence, an existing self–implemented service cannot be used as the real orchestrator. Instead, it might have to register the Saga definition with the technology’s orchestrator but otherwise constitutes merely a participant. As a result, this criterion analyzes which service or services represent the Saga orchestrator. The criterion idea was based on the "No. of services for orchestration criterion" in [3, p. 79].
Specifying compensating transactions
Compensating transactions represent an essential aspect of the Saga pattern to undo previously done changes. Consequently, the technology should provide the possibility to define compensating transactions. This criterion was also part of the evaluation in [3, p. 79 f.].
Compensation transaction allocation
Compensating previously done changes can be ensured using two ways: starting the compensation only for transactions that have been executed or always starting all compensating transactions of a Saga. This has different implications for the implementation, such as introducing the necessity to prevent failures if the orchestrator tries to compensate non–executed transactions. Therefore, this criterion examines if a compensating transaction is allocated to the corresponding transaction or simply to the entire Saga. It is related to the "Compensation only where needed criterion" in [3, p. 79 f.].
Parallel execution of transactions
To reduce the Saga’s duration and improve performance, parallel execution of transactions can be preferable. Therefore, the technology’s support of this is investigated here. Dürr et al. also used this in their analysis [3, p. 79 f.].
Parallel execution configurable
There might exist transactions that have to be executed sequentially. Therefore, for technologies that allow parallel execution of transactions, the question arises if it is also possible to configure only certain transactions to be executed in parallel.
Participant communication selectable
The orchestrator and the participants can communicate in multiple ways, for example, using message brokers or HTTP requests. Therefore it is investigated whether a technology facilitates different communication possibilities or only one.
External compensation trigger
Situations might arise that require aborting a running Saga externally, for example to update the system. However, since some services might have already committed their changes, simply terminating the Saga will not be sufficient. So instead of aborting the Saga, it is advantageous if a possibility is offered to trigger the compensation mechanism for a running Saga. An example of such a possibility can be an API endpoint or a UI feature.
Choreographed Sagas
Sagas can also be organized using choreography instead of orchestration, which is why this criterion considers if a technology also supports implementing a choreographed approach. Another criterion that Dürr et al. also evaluated [3, p. 79 f.].
References
-
https://iso25000.com/index.php/en/iso-25000-standards/iso-25010?start=0, last accessed 2021-07-06 ↩