Encapsulating Reconfigurations as Separate Concerns

David et al. propose SAFRAN [40], an open-source extension of the Fractal component model to support the development of self-adaptive components, i.e. autonomous software components which adapt themselves to the evolutions of their execution context.

SAFRAN is composed of three sub-systems on top of Fractal:

• FScript[41] is a domain-specific language used to program the component recon- figurations which will adapt the application. It provides a custom notation which

makes it possible to navigate in a Fractal architecture and offers certain guarantees on the changes applied to the target application, for example the atomicity of the reconfigurations.

• WildCAT[39, 26] is a generic toolkit to build context-aware applications. It is used by SAFRAN policies to detect the changes in the application’s execution context, which should trigger adaptations. WildCAT (v2) is based on the Esper [1] event monitoring framework that allows designers to query, aggregate and sort events using a SQL-like syntax. Note that SAFRAN is based on a previous version of Wild- CAT, which does not integrate Esper.

• a Fractal controller that binds FScript and WildCAT through the reactive rules of adaptation policies. These rules follow the Event-Condition-Action pattern, where the events are detected by WildCAT and the actions are FScript reconfigurations. The adaptation controller allows the dynamic attachment of SAFRAN policies to individual Fractal components and is responsible for their execution.

SAFRAN proposes to clearly separate the adaptation logic from the application logic. The adaptive behavior is seen as a particular aspect of the system. Such a separation of concern eases the evolution and maintenance of the adaptive behavior. Using an aspect- oriented approach, the possible configurations of the system are not explicitly described. The whole possible set of configurations is defined in intention by ECA rules. However, as noticed in [51], fully specifying an adaptive system by means of ECA rules can rapidly becomes difficult, because of the interactions between rules. SAFRAN proposes no mech- anism to detect or resolve conflicts and interactions between rules.

Similarly to Fractal, SAFRAN does not propose to maintain a higher-level representa- tion of the running system. Consequently, it is difficult to determine the impact of a re- configuration before actually performing this reconfiguration. Even if FPath and FScript propose to abstract the API provided by Fractal, developers still have to write verbose reconfiguration scripts. These scripts manipulate low level primitives that have to be or- dered in order to produce consistent scripts.

In [57], Garlan et al. present Rainbow, an architecture-based framework to support self-adaptation of software systems. It allows designers to define adaptation policies that are triggered when the associated invariant is not respected. Similarly to SAFRAN or Plastik, adaptation rules are based on the ECA paradigm. In a later work [37], they admit that ECA alone is not able to properly deal with multiple goals that a DAS needs to cope with, because the number of cases to consider grows intractable and because of the diffi- culty to define and maintain meaningful trade-offs between potentially conflicting rules. To better reason about the adaptation logic, they make a clear distinction between observ- ableand actionable states of a DAS. The observable state space is the infinite set of states we can observe using probes integrated in the runtime. Typically, a bandwidth sensor will

provide the instant value of the bandwidth every seconds, in kbits/s. Even if this value is bounded by the physical medium of the network, there exist (in theory) an infinite num- ber of real numbers in this interval. The actionable state space is a finite set of states, relevant for decision making. Typically, the bandwidth is discretized as {high, medium or low}. This drastically reduces the set of states to consider.

To reduce the effort needed to implement trade-offs between conflicting goals, they propose to extend their ECA rule system with goals. They also define goals as enumera- tion e.g., response time = {low, medium or high}. Each goal is associated with a relative importance (a real in [0..1]). Finally, each ECA rule additionally describes its impact on the objectives. Depending on the context, the most useful ECA rule is triggered. This simply consists in computing a weighted sum for each rule.

The MADAM European project13_{and its follow-up MUSIC}14_{focus on providing tech-}

niques and tools to reduce the time and effort to develop self-adaptive mobile applica- tions [132, 133]. They rely on the notion of component framework to describe their appli- cations [53]. A component framework is an assembly of component types i.e. a template of architecture where component types will be substituted by actual implementations. Quite similarly to Rainbow, the choice of the actual implementations of the component types is realized via goal policies, expressed as utility functions. Each component implementation is associated with some predictors, which precisely specify the impact of a particular im- plementation on (QoS) properties. For example, the response time of a given component implementation could be defined as follows: response = if context.bandwidth > 80 then 10

else 10 + 100 * (80 - context.bandwidth)/80). Finally, a global utility function (which can

aggregate intermediate utility functions) computes the overall utility of the application. This way, the system can evaluate different configurations and choose the most useful one, using brute force (i.e., by exploring the space of possible configurations). In [134], the MUSIC approach is used to weave AspectJ-like aspects, similar to aspects in FAC (see next subsection).

In [59, 164] Georgantas et al.present their work carried out in the AMIGO European project15_{. They are particularly interested in uncontrolled distributed reconfiguration in}

pervasive computing systems, based on the SOA paradigm. They rely on WSAMI [76], a lightweight Web Services middleware suitable for mobile devices with limited resources, as the underlying platform. They define the notion of pervasive configuration to deal with the dynamic reconfigurations of pervasive applications, which is supported by various entities (mobile or stationary) available in the environment:

• a set PS of provided application services, defined in WSDL and BPEL

13_{http://www.ist-music.eu/MUSIC/madam-project}

14_{http://www.ist-music.eu/MUSIC}

• a set PR of orchestration processes, defined in BPEL

• a service discovery service SD, which periodically checks the environment for other instances of SD, and maintains a registry

• a process execution engine PEE, which constitutes the reconfiguration manager (RM) that is completely distributed across the pervasive configuration,

• a changes detection service D, which is a simple push-based notification service, • a checkpointing service CH, which requires the web-service to describe their con-

versations in a set of atomic sub-conversations that can easily be roll-backed. • a recovery service RE responsible for managing the roll-back mechanism, and pos-

sibly

• a state transfer service ST to ensure the consistency of stateful services before and after an adaptation.

These entities realize a distributed reasoning in the context of service-oriented perva- sive computing systems that drive the dynamic adaptation of such application.