The Decentralized Adaptation Management

the adaptation process, Passivate messages are used between adaptation managers to facilitate reaching a stable application state among the remote instances of the managed application. More specifically, Passivate messages are used to gracefully stop ongoing collaborations of the role instance involved in the execution of the current adaptation operations, and the remote roles involved in the collaboration. The exchanged Passivate messages are locally translated by the adaptation manager to Passivate methods, which trigger the transition of the role to the Passive state in its life cycle and which are provided by the previously discussed interface of the role-based runtime. While all protocol- related prototypical implementations follow the developed state chart and make use of the specified interfaces, no actual means were implemented in LyRT to prevent method dispatches from happening when a role is supposed to be passive. Since the adaptation- specific parts of the coordination protocol, i.e., the coordination of the adaptation steps and the detection and handling of the assumed error models (cf. Chapter 4.1), are subject to the evaluation presented in this chapter, the assumption that roles at run time behave according to the proposed life cycle is sufficient. Future work, however, that also considers reaching a stable application state prior to the actual adaptation process will have to make dedicated extensions to LyRT in order to support RRQ 1.

Following this rationale, no additional implementations were made within LyRT to es- tablish support for collaborating roles located on mutually remote devices. Consequently, RRQ 3 was also not necessary to be implemented for the conducted evaluation.

5.2. The Decentralized Adaptation Management

Conceptually, the adaptation management is responsible for the external adaptation of role-player relations within the local role-based runtime. Since LyRT only supports intrinsic adaptations, i.e., role bindings are established and released through code state- ments, the runtime had to be extended to support external adaptations triggered and coordinated by the adaptation manager co-located on the respective node. As a conse- quence, the conceptual adaptation manager (cf. Figure 4.1 on Page 54) was split into two components. The adaptation manager implements the coordination protocol and manages the decentralized execution of adaptation transactions. The management end- point serves as extension of the adaptation management and is incorporated into the role runtime providing a communication interface to the adaptation manager. This results in two executable software artifacts that follow the external control approach, which was already used conceptually to describe the system architecture of the self-adaptive soft-

Node 1 Adaptation Manager Management Endpoint LyRT Application Local Transaction

Local Adaptation Interface (cf. 3.2.2)

Node N

Adaptation Manager

Result

Managed Application

Execution Phase of Adaptation Management

..

.

Figure 5.1.: Overview of system artifacts representing the prototypical implementation of the approach.

ware system. The adaptation manager, which is the first software artifact, implements the proposed coordination protocol and thus represents the distributed and decentralized execution phase of the feedback loop. The managed application composed of an arbitrary application implemented using the LyRT runtime and the management endpoint denotes the second software artifact. An overview of the components’ part of the implementation including their communication relations is depicted in Figure 5.1.

The management endpoint does not only provide a communication endpoint to the adaptation management, but also implements the translation of adaptation operations presented earlier in this thesis to the interface operations provided by the role runtime, thus providing the implementation for IF_3, and reports the execution results to the adaptation manager. This execution of adaptation operations affecting role-player rela- tions on the local device is implemented as adaptation transaction through the communi- cation interface between adaptation manager and management endpoint. The execution of an adaptation group by an arbitrary adaptation manager exemplifies the ongoing com- munication between the two artifacts. In a first step, adaptation operations within this group are determined that affect role-player relations of the local role runtime. These adaptation operations are wrapped in a Transaction message, which is sent to the man- agement endpoint. Within the management endpoint, the adaptation operations en- capsulated in the received adaptation transaction are executed in accordance with the mappings of adaptation operations to local interface operations provided by LyRT. This mapping was summarized in Tables 4.1 and 4.2 on Pages 68 and 69, respectively. A Re- port message is sent from the management endpoint to the adaptation manager in order to report the successful execution of the respective adaptation transaction that represents

5.2. The Decentralized Adaptation Management the currently executed local adaptations. The adaptation manager component maintains a mapping of the adaptation transactions representing the locally executed adaptation operations and the globally executed adaptation transaction. The management endpoint also determines the type of the adaptation operations and executes them appropriately, e.g., if it is the source node of a migrate operation, the role will be passivated and state information will be retrieved. The adaptation manager, however, keeps track of the overall progress of the distributed adaptation operation since the management endpoint is only aware of its local knowledge on the operations’ execution progresses. In this re- gard, the adaptation manager requests the retransmission of Report messages from the migration’s target node in the case of lost coordination messages or issues the activa- tion of changes or the rollback in either case in accordance to the specifications of the coordination protocol to the management endpoint.

All executable software artifacts are Java implementations. Since LyRT is a Java- based role runtime, implementing both adaptation manager and management endpoint as Java applications, too, allowed for a high degree of code reuse through shared libraries for the exchange of messages between adaptation managers, but also between adaptation manager and management endpoint. The communication among all executable software artifacts is based on the standard UDP implementation of Java 1.8. Adaptation managers use two distinct ports to exchange transaction and execution control messages among each other, which is a decision made to ease the automated execution of adaptation transactions during the protocol emulation. We will outline and discuss the details of that implementation decision in the following section.

A configurable part of the coordination protocol, which may also be application- specific, is the timeout to determine lost coordination messages exchanged between adaptation managers. In the implementation used for the emulation, this timeout was implemented with 2.5 seconds for each escalation step.

When adaptation managers report the progress information of locally performed adap- tations, more messages are sent within a few milliseconds than are processable in time by the prototypical implementation. The limitation becomes increasingly obvious with a growing number of nodes participating in the execution of adaptation transactions and results in a behavior that adaptation managers interpret as message losses and act ac- cordingly, which negatively affects the emulation of the coordination protocol. Details on the observed behavior within the emulation process itself will be given in Chapter 5.3.4. To partially reduce the observed execution behavior for a majority of test cases, at the end of the execution of every adaptation group, i.e., when an adaptation manager detects its currently executed adaptation group to be finished, an additional Report message will

be sent to all peers. These additional messages sent to all peers report the progress infor- mation of all locally executed adaptation operations within the just-finished adaptation group. These additionally sent messages, however, are not part of the original protocol specification.

In order to evaluate the protocol, which will be discussed in detail in the following section, the execution flow of the protocol needs to be logged to be available for the subsequent evaluation. This requires each adaptation manager involved in the execution of adaptation transactions to log information about received messages and when the ex- ecution of an adaptation group was started and finished. Consequently, each adaptation manager maintains a log file in which the received messages as well as the execution process were persistently stored including timestamps when a significant event such as a received coordination message or the beginning of the execution of a new adaptation group occurred. Since this logging constitutes a writing operation on the hard-drive of the system, typical delays and inaccuracies within the range of a few milliseconds at most are to be expected.