FESAS Middleware

The deployment of the system follows the process described in Section 6.1.2. As this process involves different types of activities, the FESAS Middleware in- tegrates various components for enabling a separation of concerns. At start, the FESAS Middleware components on each subsystem read files that specify the information of the system model, start the corresponding MAPE compo- nents, adjust settings of the components, and load the specified functional logic elements. Furthermore, these configuration files determine the communication structure between MAPE components. Appendix B.4 shows the syntax and ex- amples of these model files. In the following, this section presents the components of the FESAS Middleware and how it supports deployment of a SAS.

Figure 6.7 shows the components of the FESAS Middleware. The starting method of the SAS (e.g., the main() method in Java) triggers the start of the FESAS Middleware – i.e., the component Middleware Starter is started – and hands over the configuration files as parameters for the starting process. Ap- pendix B.7 presents these configuration files in detail. The middleware starter uses the configuration files with the start parameters to configure the SAS and controls the deployment process. Next, it configures the JSON Parser, loads the specified JSON files containing the system model for the SAS, parses them, and loads the adaptation logic components with the specified functional logic ele- ments using the FESAS Repository (cf. Section 6.1.3). The Local Repository is the connection of the FESAS Middleware to the FESAS Repository. It acts as a local storage of the code of functional logic elements.

The SAS needs to implement the FESAS Adaptation Logic Template as well as to offer the SAS Setup Service specifically implemented for the used platform,

6.1. System Model for the FESAS Framework

Request Data Instruction

Managed Resource Probe Probe Probe Actuator Actuator

Analyzer

Monitor

Executor

Sensor

Adaptation Logic

Knowledge

Context Actuator Physical Sensor

Effector

Context

Manager

Planner

Start

Procedure

SAS Setup

Service

FESAS Middleware

Local

Repository

Proxy ALM

JSON Config

Parser

Middleware

Starter

ALM

Config

files

Start

params

start

loads

FESAS

Repo-

sitory

Figure 6.7.: The FESAS Middleware components – JSON Config Parser, Proxy ALM, Middleware Starter, and Local Repository – inter- act with the FESAS Repository and the ALM (in case of self- improvement). Developers additionally have to implement the SAS Setup Service for the target platform of the SAS.

i.e., the used programming language or communication middleware. Therefore an interface defines methods for (i) creating adaptation logic components, (ii) ini- tializing communication channels between adaptation logic components, (iii) ini- tializing communication with the managed resources, as well as (iv) starting the system after the completion of the initialization (cf. Appendix B.8). The FESAS Middleware uses this service to integrate the code of the functional logics – which is loaded into the Local Repository – in the skeletons of the MAPE components, i.e., for initializing the adaptation logic with its specific MAPE functionality.

Afterwards, the FESAS Middleware controls the initialization of the com- munication between the MAPE components and between adaptation logic and

6.1. System Model for the FESAS Framework

managed resources. Therefore, the specified communication modules are loaded into the MAPE components and are configured according to the system model

using the methods of the SAS Setup Service (addressing requirement RDev3ii).

Additionally, the FESAS Middleware establishes the connection of adaptation logic and managed resources. Therefore, it loads the functional logics for sensors and effectors of the adaptation logic and configures them (addressing require-

ment RDev6.ii). This configuration might range from specifying IP addresses

and ports for 1:1 push-based socket connections, opening ports for pull-based socket connections, or setting up more advanced approaches, e.g., a web server,

bus system, or publish/subscribe middleware. It is possible to integrate ap-

proaches from related work, e.g., such as the Probe/Gauge Reporting Bus from the Rainbow Framework [77, 141], the Touchpoint concept from the IBM Auto- nomic Computing Reference Model [193], or the ProbeMeister system [74]. For offering the highest possible configurability and flexibility, again, the sensors and effectors support the definition of own functional logic elements and the FESAS Frameworks supports the integration of own communication modules (addressing

requirement RDev6.i). Developers just have to ensure that the managed resources

are compatible with the chosen communication approach, e.g., if a sensor shall use a pull-based socket communication, the managed resources must open a socket according to the information of the system model.

Additionally, the start of the middleware invokes the start of the Proxy ALM if the self-improvement functionality is enabled in the configuration files. The Proxy ALM connects to the Adaptation Logic Manager (ALM) which controls the self-improvement of the SAS at runtime. Through this connection, the ALM receives information about the SAS (i.e., its adaptation logic and managed re-

sources) and can trigger adaptation of the adaptation logic. Therefore, the

Proxy ALM is informed by the MAPE elements in case of structural or parameter changes, such as the integration or substitution of functional logic elements. Ad- ditionally, the Proxy ALM periodically checks the adaptation logic for changes. On request of the ALM, the Proxy ALM sends the current system state and re- ceived data from the managed resources. The next section presents the design of the ALM and the Proxy ALM.

In document A framework for engineering reusable self-adaptive systems (Page 93-96)