Frederico Alvares De Oliveira

Eric Rutten

Lionel Seinturier

High-level Language Support for the Control of Reconguration in Component-based Architectures

Keywords: Component-based Architectures, Self-adaptation, Control Theory

Architecting in the context of variability has become a real need in nowadays software development.

Modern software systems and their architecture must adapt dynamically to events coming from the environment (e.g., workload requested by users, changes in functionality) and the execution platform (e.g., resources availability). Component-based architectures have shown to be very suited for self-adaptation purposes, not only because of their intrinsic characteristics like reusability and modularity, but also as virtue of their dynamical reconguration capabilities. The issue, nevertheless, remains that adaptation behaviors are generally conceived by means of ne-grained reconguration actions from the very initial congurations. This way, besides the complexity in managing large-sized architectures, the space of reachable congurations is not know in advance, which prevents ensuring well-mastered adaptive behaviours. This paper presents Ctrl-F, a domain-specic language whose objective is to provide high-level support for describing adaptation behaviours and policies in component-based architectures. The proposed language lies on synchronous reactive programming, which means that it benets of an entire environment and formal tooling allowing for the verication and control of recongurations. We show the applicability of Ctrl-F by rst integrating it to FraSCAti, a Service Component Architecture middleware platform, and then by applying it to Znn.com, a well known self-adaptive case study.

Support langage de haut niveau pour le contrôle des recongurations dans les architectures à composants Résumé : La conception des architectures logicielles dans le contexte de la variabilité est devenue un vrai besoin du développement logiciel de nos jours. Les systèmes logiciels modernes et leur architectures doivent s'adapter dynamiquement aux événements provenant de l'environnement (par exemple, la charge de travail demandée par les utilisateurs, les modications apportées aux fonctionnalités) et la plate-forme d'exécution (par exemple, la disponibilité de ressources). Les architectures à base de composants ont montré être très appropriées à l'autoadaptation, en raison non seulement de leurs caractéristiques intrinsèques, comme la réutilisation et la modularité, mais aussi grâce à leurs capacités de reconguration dynamiques. Néanmoins, la question demeure que les comportements d'adaptation sont généralement conçus au moyen d'actions de reconguration à grain n à partir des congurations initiales. De cette façon, en plus de la complexité de gestion, notamment dans le cadre des grandes architectures, l'espace de congurations accessibles n'est pas explicitement connu à l'avance, ce qui empêche d'assurer des comportements adaptatifs bien maîtrisés. Cet article présente Ctrl-F, un langage dédié dont l'objectif est de fournir un support de haut niveau pour décrire des comportements et politiques d'adaptation pour les architectures à base de composants. Ce langage s'appuie sur la programmation réactive synchrone, ce qui signie qu'il bénécie de tout un environnement et outillage formels permettant la vérication et le contrôle de recongurations par la voie de la synthèse de contrôleurs discrets. Nous montrons l'applicabilité de Ctrl-F d'abord par l'intégration à FraS-CAti, une plate-forme middleware pour la Service Component Architecture, puis en l'appliquant à Znn.com, une application auto-adaptative utilisée comme cas d'étude.

Mots-clés : Architecture à composants, auto-adaptation, théorie du contrôle [START_REF] Batista | Managing dynamic reconguration in componentbased systems[END_REF]

Introduction

From tiny applications embedded in house appliances or automobiles to huge Cloud services, nowadays software-intensive systems have to fulll a number of requirements in terms safety and/or Quality of Service (QoS) while facing highly dynamic environments (e.g., varying workloads and changing user requirements) and platforms (e.g., resource availability). Thus, it becomes a real necessity to engineer such software systems with principles of self-adaptiveness in mind, i.e., to equip software systems with capabilities to dynamically change themselves in order to cope with such a level of variability.

In this direction, software architectures and more specically software components have played a very important role. Besides the usual benets of modularity and reuse, adaptability and recongurability are key properties which are sought with this approach: one wants to be able to adapt the component assemblies in order to cope with new requirements and new execution conditions occurring at run-time. However, in the current state of the art, there is no explicit, rst-class language-level support for the specication of dynamic recongurations. In general, initial assemblies (or congurations) are dened with the help of Architectural Description Languages (ADLs) and recongurations are achieved by programming ne-grained actions in either general-purpose languages within component-based frameworks [START_REF] Seinturier | A component-based middleware platform for recongurable service-oriented architectures[END_REF], or with the support of reconguration domain-specic languages (DSLs) [START_REF] David | FPath & FScript: Language support for navigation and reliable reconguration of Fractal architectures[END_REF]. Hence, the space of congurations that can be reached as well as the possible switchings between them are only considered through side eects. As a further matter, dealing with recongurations at such a low level may easily become a very exhaustive, tedious and error-prone task, especially for large-scale architectures.

We claim that there is a need for language support not only for the declaration of congurations in the form of assemblies, but also for the explicit specication of policies driving recongurations with respect to when or under which conditions recongurations shall be triggered or even which congurations in the reconguration history should be avoided. Furthermore, designing well-mastered behaviors of recongurable systems, with assurances on the way they navigate in the conguration space while respecting policies dened separately, requires tool-supported design methods.

The control of these recongurations has to be managed in reaction to ring events and conditions from observations on the component-based architecture and its environment, to take decisions depending on the current state of the architecture as well as its reconguration history and its constraints. The result is a set of actions to be performed for going to the next conguration. This forms a feedback control loop, as in autonomic computing [START_REF] Kephart | The vision of autonomic computing[END_REF], whose design can benet from a whole methodology, programming environments and tools that have been developed for the design of reactive systems, and hence be empowered with specication, verication, validation, implementation and automatic generation of executable code capabilities [2]. More precisely, it is possible to have controllers conceived with synchronous languages [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF], which in turn, combine, among other things, techniques of Discrete Controller Synthesis (DCS) to generate correct controllers, from a Finite State Automata (FSA) based model of the controlled system, and a given strategy expressed as a safety property. The advantage with respect to manual programming of a controller are: automation of the design, correctness of the synthesized controller, and optimality in the sense of maximal permissiveness. This paper presents Ctrl-F, a language that extends classic ADLs with high-level constructs intended to express the dynamicity of component-based architectures. In addition to the usual description of assemblies (congurations), existing in other ADLs, Ctrl-F also comprises a set of constructs that are dedicated for the description of: (i) behavioural aspects, that is, the order and/or conditions under which congurations should take place; and (ii) policies that have to be enforced all along the execution. We provide full translation from Ctrl-F to the RR n°8669 synchronous reactive language Heptagon/BZR [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF], which allows us to benet from tools for: (i) formal exploitation of programs, for verication and controller synthesis purposes; and (ii) the compilation towards executable code in general purpose languages (e.g., Java or C). We validate the applicability of our language through Znn.com [6], a self-adaptive news website that is commonly used as case study.

The remainder of this paper is organized as follows: Section 2 introduces the main concepts and tools necessary for the good comprehension of our approach. Sections 3 presents the case studied that is used all along the paper. Sections 4 and 5 present the Ctrl-F language itself and how it is translated into Heptagon/BZR. Section 6 provides some details on the integration of Ctrl-F with a real component platform. The related work is discussed in Section 7 and Section 8 concludes this paper.

Background

This section aims at introducing the main concepts and tools used to develop this research work.

First, we provide an overview on Component-based Architecture along with its suitability for self-adaptiveness. Then we survey some concepts regarding Reactive Programming, which is the formal paradigm we rely on in order to ensure correct reconguration behaviours.

2.1

Component-based Architecture

Basic Concepts

A software architecture denes the high-level structure of a software system, by describing how it is organized as a means of a composition of components [START_REF] Jacobson | Software reuse: architecture process and organization for business success[END_REF]. Architecture description languages (ADL) [START_REF] Medvidovic | A classication and comparison framework for software architecture description languages[END_REF] are usually used to describe the architecture of a system. Although the diversity of ADLs, the architectural elements proposed in almost all of them follow the same conceptual basis [START_REF] Garlan | Acme: Architectural description of component-based systems[END_REF].

A component is dened as the most elementary unit of processing or data and it is usually decomposed into two parts: the implementation and the interface. The implementation describes the internal behaviour of the actual component, whereas the interfaces denes how the component should interact with the environment. A component can be dened as simple or composite (composed of other components). A connector corresponds to interactions among components.

Roughly, it mediates an inter-component communication in diverse forms of interactions. A conguration corresponds to a directed graph of components and connectors describing the application's structure and/or a description on how the interactions among components evolve over the time. Other elements like attributes, constraints or architectural styles may also often appear in ADLs [START_REF] Garlan | Acme: Architectural description of component-based systems[END_REF]. For sake of brevity we omit further description on this regards.

Nowadays software applications require the possibility to continuous change so as to adapt to execution conditions or cope with new user requirements. Thus, it becomes imperative that an architecture/congurations once dened may be evolved while leading to new congurations that are more appropriated to the current context.

Dynamic Reconguration

Dynamic reconguration is denoted a reconguration (the passage from one conguration to another) in which it is not necessary to stop the system execution or to entirely redeploy it in order for the modication to take eect. As a consequence, the number interferences on the system execution is reduced and the availability is increased.

Inria

Component-based architectures are very suitable for dynamic recongurations. Indeed, thanks to their native characteristics of modularity and reuse, it is possible to isolate the modications so that the interference on the system execution is mitigated. In addition, with the advent of reexion, modern component models like Fractal [5] and OpenRec [START_REF] Warren | An automated formal approach to managing dynamic reconguration[END_REF], among others, bring reection capabilities to software architectures, by providing a meta level, in which components are equipped with control interfaces so as to allow for the introspection (observation on the architectural elements e.g., assemblies, interfaces, connectors, and so forth) and intercession (reconguration e.g., creation/suppression of components, connectors, etc.).

At rst glance, as can be seen in Figure 1, the Fractal Component Model seems pretty much like any other component model, allowing for hierarchical composition of components, specication of required (client) and provided (server) interfaces and bindings connecting components' interfaces. However, Fractal was rather conceived with separation of concerns design principle in mind, which separates a component implementation into two parts: content and membrane. The content manages the functional concerns and its operations are exposed by a set of functional interfaces. The membrane embodies a set of controllers that takes care of the non-functional concerns. Control interfaces are access points to membrane controllers, which in turn implement some introspection and/or intercession capabilities, making Fractal a distinguished Component Model concerning the support for dynamic reconguration. Examples of controllers are the life-cycle and the binding controllers. The former controls the component's behavioural phases (e.g., starting, started, stopping, stopped, etc.), while the latter provides means for dynamically establishing or breaking bindings between component's interface and its environment. In short, component-based architectures and especially the ones equipped with reection capabilities like Fractal have capabilities that are particularly interesting and applicable in the domain of self-adaptive software systems, in which software systems should adapt to context changes while mitigating the interferences on their execution.

Service Component Architectures

While Component Models usually focus on the modularity, reuse and adaptability, they do not fulll a number of requirements regarding interoperability, platform and protocol diversity in distributed environments over the Internet. Service-Oriented Architecture (SOA), on the other hand, is an architectural style in which applications are conceived as composition of loosely coupled, coarse grained, technology agnostic, remotely accessed, and interoperable (i.e. accessed via standardized protocols) services. In the other sense, SOA requires appropriate infrastructure to conceive, deliver and manage distributed applications based on the SOA principles [START_REF] Seinturier | A component-based middleware platform for recongurable service-oriented architectures[END_REF].

Therefore, Component-based Architecture and SOA can be seen as complementary approaches.

RR n°8669

Reactive Programming

In this work we rely on the synchronous reactive language Heptagon/BZR [START_REF] Delaval | Contracts for modular discrete controller synthesis[END_REF] to formally model Ctrl-F and thus benet of an entire ecosystem including specication language environments, verication, control and executable code generation tools.

Heptagon

Synchronous Reactive Languages based on Finite State Automata (FSA) constitute the basic formalism for Discrete Control Theory. The general execution scheme of a reactive program is that at each reaction, a step is performed taking input ows, computing transitions, updating states, triggering actions, emitting output ows.

Heptagon is a language allowing for the denition of reactive systems by means of generalized Moore machines, that is, with mixed synchronous data-ow equations and automata [START_REF] Colaço | A conservative extension of synchronous data-ow with state machines[END_REF]. An Heptagon program is modularly structured with as a set of nodes. One important characteristic of Heptagon/BZR is the support for hierarchical and parallel automata composition. Listing 1 illustrates an example of hierarchical composition, in which a single-stated super-automaton embodies the lifecycle automaton. It has a self-transition that results in the resetting of the containing automata (i.e., lifecycle) at at every occurrence of signal b. A stream of input/output values for this automaton can be seen in Table 2.2.1. In particular, we can see at step 9, the resetting of the sub-automaton, which brings it from state active back to idle (at step 10), without any explicit transition. Next section provides an example on the parallel composition. . . .

r 0 1 0 0 0 0 1 0 0 0 . . . c 0 0 1 0 0 0 1 0 0 0 . . . e 0 0 0 0 1 0 0 0 0 0 . . . a 0 0 0 1 1 0 0 1 1 0 . . . s 0 0 1 0 0 0 1 0 0 0 . . .

Contracts and Discrete Controller Synthesis

BZR is an extension of Heptagon with specic constructs for Discrete Controller Synthesis (DCS).

That makes Heptagon/BZR a distinguished reactive language, since its compilation may involve

RR n°8669

formal tools such as Sigali [START_REF] Marchand | Synthesis of discrete-event controllers based on the signal environment[END_REF] and Reax [3] for DCS purposes. A DCS consists in automatically generating a controller capable of acting on the original program to control input variables such that a given temporal property is enforced. In Heptagon/BZR, DCS is achieved by associating a contract to a node. A contract is itself a program with two outputs: e A , an assumption on the node environment; and e G , a property to be enforced by the node. A set {c 1 , c 2 , . . . , c q } of local controllable variables is used for ensuring this objective. Putting it dierently, the contract means that the node will be controlled by giving values to {c 1 , . . . , c q } such that given any input ow resulting in e A , the output will always result in e G . When a contract has no controllable variables specied, a verication that e G is satised in the reachable state space is performed by model checking, although no controller is generated.

Listing 2 shows an example of contract. The example presents a node enclosing a parallel composition of two instances of node lifecycle (c.f. Figure 2.2.1). As can be seen, the contract is composed of three blocks. The assume block (line 3), which in this case, states that there is no assumption on the environment (i.e., e A = true). The enforce block (line 4) describes the property to be enforced by the node, which in this case is e G = ¬(a1 ∧ a2), meaning that both components are mutual exclusive, i.e., they cannot be active at the same time. Lastly, the with block (line 5) denes two controllable variables that are used within the node (lines 7 and 8). In practice the controllable variables (c1 and c2) will be given values in a way variables a1 and a2

are never both true at the same instant. node twocomponents ( r1 , r2 , e1 , e2 : bool ) returns ( a1 , a2 , s1 , s2 : bool ) contract assume true enforce not ( a1 and a2 ) with ( c1 , c2 ) let ( a1 , s1 ) = lifecycle ( r1 , c1 , e1 ) ;

( a2 , s2 ) = lifecycle ( r2 , c2 , e2 ) tel

Compilation and code generation

The Heptagon/BZR compilation chain is depicted in Figure 2.2.3. From a source code (1), the Heptagon/BZR compiler produces as output an sequential code in a general-purpose programming language (e.g., Java or C) corresponding to the system model (2). At the same time, if the code provided as input contains any contract, the compiler will also generate a intermediary code that will be given as input to the model checker (2, in this case either Sigali or Reax), which will, in turn, perform the DCS and produce as output an Heptagon/BZR code corresponding to the generated controller (3). The latter is then compiled again so as to have an executable code also for the generated controller (4).

*.ept Heptagon/BZR

Sigali/Reax C System Model & Controller DCS (2) (1) (3)
(2)(4)

Inria

High-level Language Support for the Control of Reconguration in Component-based Architectures9

The executable code comprises two function/methods: reset and step. The former initializes the internal state of the program, whereas the latter is executed at each logical step to compute the output values based on a given vector of input values and the current state. These functions/methods are typically used by rst executing reset and then by enclosing step in an innite loop, in which each interaction correspond to a reaction, i.e., a step to be performed.

Example Application

This section provides an overview of a motivating scenario that is used throughout the following sections to explain several aspects and concepts of our proposed Ctrl-F language. The scenario is an extension of the well-known Znn.com [6] use case.

3.1

Overview of Znn.com Znn.com [6] is an experimental platform for self-adaptive applications, which mimics a news website. As in any web application, Znn follows a typical client-server n-tiers architecture, as illustrated in Figure 4. Znn.com relies on a load balancer to redirect requests from clients to a pool of replicated servers. The number of active servers can be regulated in order to maintain a good trade-o between response time and resource utilization. Hence, the objective of Znn.com is to provide news content to its clients/visitors within a reasonable response time, while keeping costs as low as possible and/or under control (i.e., constrained by a certain budget). There might be times where only the pool of servers is not enough to provide the desired Quality of Service (QoS). For instance, in order to face workload spikes, Znn.com could be forced to degrade the content delity so as to require fewer resource to provide the same level of QoS.

For this purpose, Znn.com servers are able to deliver news contents in three dierent ways: (i) with high quality images, (ii) with low quality images, and (iii) with only text. Hence, content delity can be seen as another criteria. In summary, the objectives are as follows:

Keep the performance (in terms of response time) as high as possible;

Keep content delity as high as possible or above a certain threshold;

Keep the number of active servers as low as possible or under a certain threshold.

In order to achieve them, we may tune:

The number of active servers;

The content delity of each server.

RR n°8669 3.2 Znn.com Instantiation

We extend Znn.com by enabling its replication in presence of dierence content providers. Figure 5 illustrates the case with two dierent content providers: one specialized in soccer and another one specialized in politics. These two instances of Znn.com will be running/sharing on the same physical infrastructure (machines m 1 , . . . , m k ). Depending on the contract signed between the service provider and his/her clients that establishes the terms of use of the service, Znn.com

Service Provider can give more or less priority to a certain client. For instance, during the World Cup the content provider specialized in soccer will always have priority over the other one. Conversely, during the elections, the politics-specialized content provider is the one that has the priority.

Ctrl-F Language

Ctrl-F is our proposal for a domain-specic language that extends the common concepts of classic ADLs by providing high-level constructs for describing recongurations' behaviour and policies to be enforced all along the execution of the target system.

Overview and Common Concepts

Figure 6 presents a meta-model of the language's abstract syntax. It can be divided into two parts: a static one, which is related to the common architectural concepts (components, connections, congurations, etc.); and a dynamic one, which refers to reconguration behaviours and policies that must be enforced regardless of the conguration.

The static part of Ctrl-F shares the same concepts of many existing ADLs (e.g., Fractal [5],

Acme [START_REF] Garlan | Acme: Architectural description of component-based systems[END_REF]). A component consists of a set of interfaces, a set of event ports, a set of attributes and a set of congurations. Interfaces dene how a component can interact with other components. So they are used to express a required functionality (client interface) that may be provided by another component and/or to express a provided functionally (server interface) that might be used by other components. Event Ports describe the events of given Event Type a component is able to emit (port out) or listens to (port in). A conguration is dened as a set of instances of components, a set of bindings connecting server and client interfaces of those instances (i.e., an assembly), and/or a set of attributes assignment to values. That is to say that a conguration is a snapshot of the attributes valuation, the current (sub) components instances within the concerned (super) component and the bindings connecting interfaces of these instances.

The dynamic part, in turn, consists of a behaviour that can be dened for each component and a set of policies. A behaviour takes the form of orders and conditions (with respect to events and attribute values) under which transitions between congurations (recongurations) take place. Regarding the policies, they are high-level objectives/constraints, which may imply in the inhibition of some of those transitions. The Znn.com example application of Section 3 can be modeled as a hierarchical composition of four components: (i) Main; (ii) Znn; (iii) LoadBalancer ; and (iv) AppServer. These components are instantiated according to execution conditions, the system's current state (architectural composition), adaptation behaviours and policies dened within each component. The following paragraphs details the denition of such components with the static part of Ctrl-F.

The Ctrl-F description for the Main component is shown in Listing 3. This is the top-most component and it encompasses two instances of component Znn, namely soccer and politics within a single conguration (lines 7 and 8). The server interfaces of both instances (lines 9 and 10), which provides access to news services, are bound to the server interfaces of the Main component (lines 3 and 4) in order for them to be accessed from outside. Here we also dene a some policies to be enforced (line 13), but these aspects are discussed in more details in the coming sections. through which news can be requested. The component listens to events of types oload (overload) and uload (underload) (lines 5 and 6), which are emitted by other components. In addition, the component also denes two attributes: consumption (line 9), which is used to express the level of consumption (in terms of percentage of CPU) incurred by the component execution; and delity (line 8), which expresses the content delity level of the component in question.

Three congurations are dened for Znn component: conf1, conf2 and conf3. conf1 (lines 11-18) consists of one instance of each LoadBalancer and AppServer (lines 12-13); one binding to connect them (line 15), another binding to expose the server interface of the LoadBalancer component as a server interface of the Znn component (line 14), and the attribute assignments (lines 16 and 17). The attribute delity corresponds to the counterpart of instance as1, whereas for the consumption it corresponds to the sum of the consumptions of instances as1 and lb. conf2 (lines [START_REF] Marchand | Synthesis of discrete-event controllers based on the signal environment[END_REF][START_REF] Medvidovic | A classication and comparison framework for software architecture description languages[END_REF][START_REF] Morin | Taming dynamically adaptive systems using models and aspects[END_REF][START_REF] Pascual | Run-time support to manage architectural variability specied with cvl[END_REF][START_REF] Seinturier | A component-based middleware platform for recongurable service-oriented architectures[END_REF][START_REF] Warren | An automated formal approach to managing dynamic reconguration[END_REF] extends conf1 by adding one more instance of LoadBalancer, binding it to the LoadBalancer and redening the attribute values with respect to the just-added component instance (as2 ). In that case, the attribute delity values the average of the counterparts of instances as1 and as2 (line 22), whereas for the consumption the same logics is applied so the consumption of the just-added instance is incorporated to the sum expression (line 23). Due to lack of space we omit the denition of conguration conf3. Nevertheless, it follows the same idea, that is, it extends conf2 by adding a new instance of LoadBalancer, binding it and redening the attribute values. one provided (line 2), through which the news are provided; and the others required (line 3), through which the load balancer delegates each request for balancing purposes. We assume that this component is able to detect overload and underload situations (in terms of number of requests per second) and in order for this information to be useful for other components we dene two event ports that are used to emit events of type oload and uload (lines 5 and 6). Like for component Znn, attribute consumption (line 8) species the level of consumption of the component. As there is no explicit denition of congurations, LoadBalancer is implicitly treated as a single-conguration component.

Behaviours

A particular characteristic of Ctrl-F is the capability to comprehensively describe behaviours in architecture-based software. We mean by behavior the process in which architectural elements are changed. More precisely, it refers to the order and conditions under which congurations within a components take place.

Behaviours in Ctrl-F are dened with the aid of a high-level imperative language, which consists of a set of behavioural statements (sub-behaviours ) that can be composed together so as provide more complex behaviours in terms of sequences of reconguration. In this context, a conguration is considered as an atomic behaviour, i.e., a behaviour that cannot be decomposed into other sub-behaviours.

We assume that congurations do not have the capability to terminate or start themselves, meaning that they are explicitly requested or ended by behaviour statements. Hence, a reconguration occurs when the current conguration is terminated and the next one is started.

The next sections discuss the behaviour statements while illustrating their usage in the Znn.com example application.

Statements

Table 2 summarizes the behaviour statements of the Ctrl-F behavioural language. During the execution of a given behaviour B, the when-do statement states that when a given event of event type e i arrives the conguration(s) that composes B should be terminated and that (those) of the corresponding behaviour B i are started. The case-then statement is quite similar to when-do. The dierence resides mainly in the fact that a given behaviour B i is executed if the corresponding condition c i holds (e.g., conditions on attribute values), which means that it does not wait for a given event. The parallel Inria High-level Language Support for the Control of Reconguration in Component-based Architectures15 statement states that two behaviours can be executed at the same time. That is to say that at a certain point there must be two independent branches of behaviour executing in parallel. The alternative statement allows to describe choice points between congurations or modes in atomic components, or between more elaborated sequential behavior statements. They are left free in local specications and will be resolved in upper level assemblies, in such a way as to satisfy the stated policies, by controlling these choice points appropriately.

Finally, the do-every statement allows for execution of a behaviour B and re-execution of it at every occurrence of an event of type e. It is noteworthy that behaviour B is preempted at every occurrence of e. In other words, the conguration(s) currently activated in B is (are) terminated, and the very rst one(s) in B is (are) started.

Example in Znn.com

This section illustrates the use of the statements introduced in the last section to express a behaviour for components AppServer and Znn (c.f. Section 4.1).

The expected behaviour for component AppServer is to pick one of its three congurations (text, img-ld or img-hd ) at every occurrence of events of type oload or uload. To that end, as it can be seen in Listing 7, the behaviour can be decomposed in a do-every (lines 4-6) statement, which is, in turn, is composed of an alternative one (line 5). It is important to mention that the decision on one or other conguration must be taken at runtime according to input variables (e.g., income events) and the stated policies, that is, there must be a control mechanism for recongurations that enforces those policies. We come back to this subject in Section 5. Regarding component Znn, the expected behaviour is to start with the minimum number of AppServer instances (conguration conf1 ) and add one more instance, i.e., leading to conguration conf2, upon an event of type (oload ). From conf2, one more instance must be added, upon an event of type oload leading to conguration conf3. Alternatively, upon an event of type uload, one instance of AppServer must be removed, which will lead the application back to conguration conf1. Similarly, from conguration conf3, upon an event of type uload, another instance must be removed, which leads the application to conguration conf2.

As shown in Listing 8, that behaviour can be achieved with a main do-every statement (lines 4-12), which executes a when-do statement (lines 5-11) at every occurrence of an event of type e1. In practice, the ring of this event allows to go back to the beginning of the when-do statement, that is, the conguration conf1 regardless of the current conguration being executed. According to the when-do statement, conf1 is executed until the occurrence of an event of type oload (line 5), then another do-every statement is executed (lines 6-10), which in turn, just like the other one, executes another when-do statement (lines 7-9) and repeats it at every occurrence of an event of type e2. Again, that structure allows the application go back to the beginning of the when-do statement, that is, the conguration conf2. Conguration conf2 is executed until an event of type either oload or uload occurs. For the former case (line 7), another when-do statement takes place, whereas for the latter (line 8) a conguration named emitter1 is executed. The when-do statement (line 7) consists in executing conguration conf3 until an event of type uload is red, then a conguration named emitter2 takes place.

It is noteworthy that congurations emitter1 and emitter2 are special congurations that contain, each one, an instance of the pre-dened component Emitter (omitted here due to space constraints). The purpose of this component is to emit events such as the ones of type e1 and e2. This allows the application to trigger the inner-statements within the do-every statements (lines 1-12 and 6-10) so as to be able to to back to congurations conf1 and conf2, from congurations conf2 and conf3, respectively.

Policies

Policies are expressed with high-level constructs that enable the denition of constraints on congurations in a declarative way. They can be grouped into temporal constraints and constraints on attributes. In general, they dene a subset of all possible global congurations, where the system should remain: this will be achieved by using the choice points in order to control the recongurations. An intuitive example is that two components in parallel branches might have each several possible modes, and some of them to be kept exclusive. This exclusion is a policy which can be enforced by choosing the appropriate modes when starting the components.

Constraints/Optimization on Attributes

This kind of constraints are predicates and/or primitives of optimization objectives (i.e., maximize or minimize) on component attributes. Listing 9 illustrates examples of constraints and optimization on component attributes. The rst two policies state that the overall delity for component instance soccer should be greater or equal to 0.7, whereas that for instance politics should be maximized. Putting it dierently, instance soccer must never have its content delity degraded, which means that it will have always priority over politics. The third policy states that the overall consumption should not exceed 6, which could be interpreted as a constraint on the physical resource capacity, that is, the number of available machines (k = 6).

Inria

Znn.com, the control of recongurations in such a way that policies are enforced can be easily achieved in any general purpose language. However, as applications get larger and more complex, the implementation of such a control becomes harder and error-prone. For this reason, we rely on a synchronous reactive language, namely Heptagon/BZR, to model component-based applications described in Ctrl-F in a way to benet from verication, discrete control and executable code generation tools. This section presents a set of translation schemes that enable us to model Ctrl-F-described applications into Heptagon/BZR.

General Model: The Component

A component can be modeled as an Heptagon/BZR node, as shown in Figure 7. The main node (comp in Figure 7) may contain a contract in which a set of controllable variables {c 1 , . . . , c q } (in the case there is any choice point such as a behaviour with an alternative statement) and the reference to the set of stated policies ({p 1 , . . . , p t }) in order for them to be enforced by the controller resulting from the discrete controller synthesis. The details on how policies are translated are given in Section 5.3.

Component behaviours are modeled as a sub-node (bcomp in Figure 7), which consists of an automaton describing the orders and conditions congurations take place. For this purpose, it gets as input the same request (r), end (e) and event ({v 1 , .

r subi = (r 1 ∨ . . . ∨ r m ) ∧ ¬(e 1 ∨ . . . ∨ e m ) (1)
e subi = (e 1 ∨ . . . ∨ e m ) ∧ ¬(r 1 ∨ . . . ∨ r m ) (2)
Where {r 1 , . . . , r m } and {e 1 , . . . , e m } are respectively the sets of request and end signals for the congurations conf 1 , . . . , conf m component sub i belongs to. That means that a subcomponent sub i will be requested if any conguration it belongs to is also requested (r 1 ∨. . .∨r m ) and none of them is terminated ¬(e 1 ∨ . . . ∨ e m ), which avoids emitting a request signal for a component that is already active. The same applies for its termination.

Listing 11 shows an excerpt of Heptagon/BZR model for components Znn (lines 6-23) and AppServer (lines 1-4). For node appserver, besides the request and end signals, it gets as inputs the events of type oload and uload (line 1). As output (lines 2 and 3), it produces request and end signals for congurations text (r_text and e_text), image-ld (r_ld and e_ld) and image-hd (r_hd and e_hd), apart from weights, i.e., attribute valuations (fidelity and consumption). Node znn has a very similar interface as appserver, except that it produces as output request and end signals for congurations conf1 (r_conf1 and e_conf1), conf2 (r_conf2 and e_conf2) and conf3 (r_conf3 and e_conf3). Regarding its body (lines 10-22), znn comprises one instance of the node that models the behaviour (bznn, line 17) and three instances of node appserver ( r_conf1 , e_conf1 ,...) = bznn (r ,e , oload , uload ) ; ( r_text_as1 ,... , fid_as1 , conso_as1 ) = appserver ( r_as1 , e_as2 , oload , uload ) ; ... ( r_text_as3 ,... , fid_as3 , conso_as3 ) = appserver ( r_as3 , e_as3 , oload , uload ) ; consumption = conso_as1 + conso_as2 + conso_as3 ; ... tel

Modeling Behaviours

The behavioural statements presented in Section 4 are represented in the form of automata when translated into Heptagon/BZR. In fact, as Heptagon/BZR allows for hierarchical composition of automata, we translate each behaviour statement dened inside another behaviour as subautomaton. That way, we can hierarchically decompose the whole behaviour into smaller pieces until we get to an indivisible behaviour, that is, a conguration.

The top-most automaton i.e., the automaton modeling the whole behaviour consists as a two-state model, as depicted in Figure 8. The automaton is in state Idle when the component does not take part in the current conguration. Upon a request signal (r ), it goes to Active state, from where it can go back again to Idle state again upon an end signal (e ). Active state accommodates a behaviour statement itself, which is itself modeled as a sub-automaton of state A.

When-Do

The automaton that models the statement when-do (cf. Figure 9) consists of a initial state B corresponding to the rst behaviour statement to be executed. The automaton goes to state B i (corresponding to the execution of the next behaviour) upon a signal (event) v i while producing signals for requesting the initiation of to the next behaviour (r_b i ) and the termination (e_b) the current one (for 1 ≤ i ≤ n). It is important to notice that upon two events at the same time, a priority is given according to the order behaviours are declared. For instance, if v 1 and v 2 triggers, respectively, behaviours B 1 and B 2 , then B 1 will be triggered if it has been declared before B 2 .

Case and Alternative

Both behaviour statements case and alternative can be modeled by the automaton shown in Figure 10. As the sub-behaviour statements should be executed at the very rst instant upon the request of the case or alternative statement, the automata should be composed in parallel with the automata modeling the behaviour (inside node bcomp, in Figure 7) , otherwise it would be needed two steps to go through state W and decide which branch to take, before actually executing it (i.e., the sub-behaviour corresponding to the chosen branch). In fact, a case or an alternative statement is modeled as simple state inside the automata hierarchically composed that model the behaviour. Upon a request to those statements, the main automaton emits a request signal r that will trigger a transition from state W to the next state (B 1 or B 2 ) according to variable c. The dierence between the use of this automaton for a case or an alternative statement is that for the latter the conditions c i will be considered as a controllable variables in Heptagon/BZR. Thus, a discrete controller synthesis (DCS) should be performed to guarantee a behaviour such that the stated policies are not violated.

Inria B B 1
B 2 Bn v 1 / r_b 1 , e_b v 2 ∧ ¬v 1 / r_b 2 , e_b vn ∧ ¬(∨ n-1 i=1 v i )/ r_bn, e_b
W B 1 B 2 r ∧ c / r _ b 1 r ∧ ¬ c /

Every

The automaton model for the do-every statement is straightforward, as it is shown in Figure 11. It consists of a single-state automaton, which means that it starts by directly executing statement B. It has a self-transition at every occurrence of signal s, while emitting end (e_b) and request (r_b) signals, that is, statement B is re-executed at every occurrence of event s.

Znn.com Example

In order to ease the understanding of the translation from behaviour statements dened in Ctrl-F to Heptagon/BZR automata, Figure 13 illustrates how the translation can be applied to the behaviour dened for component AppServer (cf. Listing 7) of the Znn.com example. It consists of a parallel composition of two automata: one to model the behaviour itself (on the left-hand side), and another to model the alternative sub-behaviour statement (on the right-hand side).

The rst automaton corresponds to the top-most automaton, as the one shown in Figure 8.

The active state comprises a sub-automaton representing the do-every statement, which starts by state B and restarts it at every occurrence of events oload (overload) or uload (underload) while emitting at the same time request and end signals (r_b and e_b, respectively). The request signal (r_b) is used by the second automaton in order to enable transitions to states representing congurations (txt, ld and hd ) according to the controllable variables c 1 and c 2 , while emitting proper request signals (r_b 1 or r_b 2 ) for the next congurations and end signals (e_b 1 or e_b 2 )

for the current one. The end signal (e_b), on the other hand, is used to enable transitions to other or even the same conguration, in the presence of the request signal, or to the waiting state W , in the absence of the request signal. It should be mentioned that due to the lack of space, we omitted the outgoing and incoming transitions of state hd (conguration img-hd. In the generated executable code, the output of those automata will be connected to pieces of code dedicated to trigger the actual recongurations. For instance, the presence of signals r_ld and e_txt will trigger the reconguration script that changes the content delity of given component from text to img-ld (cf. Section 6).

∧ c 1 / r _ b 1 r _ b ∧ ∧ c 2 ∧ ¬ c 1 / r _ b 2 e_b ∧ r_b ∧c 1 / r_b 1 , e_b 1 e_b ∧ r_b∧ c 2 ∧ ¬c 1 / r_b 2 , e_b 2 e/e_b 2 e_b ∧ r_b ∧ c 2 ∧ ¬c 1 /e_b 1 , r_b 2 e_b ∧ r_b ∧ c/ e_b 2 , r_b 1 e/e_b 1

Inria

High-level Language Support for the Control of Reconguration in Component-based Architectures23

Modeling Policies

As previously stated in Section 4, Ctrl-F policies can be categorized into constraints/optimization objectives on attributes or temporal constraints (i.e., constraints on the order) over congurations.

Constraints/Optimization on Attributes

Constraints on attribute values can be translated into Heptagon/BZR in a very straightforward way. Indeed, they correspond to a set of boolean equations dened within the nodes that model components where the policies are stated. Then, the references to the equations are used inside the enforce block of a contract in order to state that they always hold by the control on the values of controllable variables.

. tel

The declaration of optimization objectives are currently not supported by Heptagon/BZR. However, there are means to model an one-step optimization directly within the Discrete Controller Synthesis (DCS) tool (e.g., Sigali [START_REF] Marchand | Synthesis of discrete-event controllers based on the signal environment[END_REF] or Reax [3]) Heptagon/BZR relies on.

Temporal Constraints

Temporal constraints refer to constraints on the logical order of congurations. They are modeled in Heptagon/BZR by a set of boolean equations of request (r) and end (e) signals that are emitted by automata modeling behaviours. For simple constraints like conf1 succeeds conf2 (resp. conf1 precedes conf2), a just a predicate like e_conf 2 ⇒ r_conf 1 (resp. e_conf 1 ⇒ r_conf 2) suces. However, whenever there is a need for keeping track of the sequence of signals (to request and/or end congurations), the use of observer automata becomes necessary. Observer automata are placed in parallel with the behavior automata, and generated in Heptagon/BZR as part of the contract. The principle is to have an automaton that observes the sequence of signals that leads to a policy violation and state that the state resulting from that sequence (an error state) should never be reached. Again, here we can rely on the enforce block of a Heptagon/BZR contract. The synthesis tool will interpret this as a new synthesis objective: the invariance of the states set deprived of those where the variable error is true.

RR n°8669

Figure 14(a) depicts an observer that models the policy during (conf1 during conf2), where r 1 and r 2 (resp. e 1 and e 2 ) correspond to the request (resp. end) signal for congurations conf 1 and conf 2 , respectively. The error state (E) is reached if conf 2 terminates before conf 1 (e 2 ∧¬e 1 ) or if conf 2 terminates before conf 1 have started.

The observer that models the constraint between (conf1 between (conf1,conf2)) is depicted in Figure 14(b). Similarly, r 1 , r 2 and r 3 (resp. e 1 , e 2 and e 3 ) correspond to the request (resp. end) signal for congurations conf 1 , conf 2 and conf 3 , respectively. The automaton goes to the error state (E) whenever conguration conf 3 is started (r 3 is emitted) after conguration conf 2 (e 2 ), except when conguration conf 1 is started and terminated (r 1 and e 1 ) in the between.

Implementation

This section presents how Ctrl-F language is implemented and integrated into a target component platform. First, we give an overview on the component model and platform middleware we rely on. Then we present the Ctrl-F tool-chain as well as how the code resulting from the compilation is wrapped into a management software that actually enacts adaptation on the target system.

Finally, we show the applicability of our language through an adaptation scenario over the Znn.com application.

FraSCAti and Service Component Architecture

Despite the fact that our contribution is technology-agnostic, for the sake of proof-of-concept, we rely on the Service Component Architecture (SCA) 2 as target component model. SCA is a component model for building applications based on the Service Oriented Architecture principles.

SCA provides means for constructing, assembling and deploying software components regardless of the programming language or protocol used to implement and make them communicate. The objective is that a middleware platform implementing the SCA specications takes care of component implementation, interoperability and communication details, so architects and developers can focus only on the architecture. In this work, we rely on the Java-based SCA middleware FraSCAti [START_REF] Seinturier | A component-based middleware platform for recongurable service-oriented architectures[END_REF], since it provides mechanisms for runtime reconguration of SCA application. The FraSCAti Runtime is itself conceived relying on the SCA model, that is, it consists of a set of SCA components that can be deployed a la carte, according to the user's needs. For instance, one can instantiate the frascati-fscript component, which provides services allowing for the execution of an SCA-variant of FPath/FScript [START_REF] David | FPath & FScript: Language support for navigation and reliable reconguration of Fractal architectures[END_REF], a domain-specic language for introspection and dynamic reconguration of Fractal components.

Compilation Tool-chain and Manage Prototype

The Ctrl-F compilation tool-chain is depicted in Figure 16. As can be seen, the compilation process can be split into two parts: (i) the reconguration logics and (ii) the behaviour/policy control and verication. The reconguration logics is implemented by the ctrlf2fscript compiler, which takes also as input a Ctrl-F denition and generates as output an FPath/FScript script containing a set procedures allowing going from/to all congurations. Listing 13 shows an example of script describing a reconguration from conguration conf1 to conf2 of Znn component. In 3 http://www.w3.org/TR/soap/ RR n°8669 this example, the script just wires the reference of instance lb:LoadBalancer to the as2:AppServer instance's service, then it starts the instance as2:AppServer. reset () ; ... on event oload or uload <... , stop_conf1 , start_conf2 ,... >= step ( oload , uload ) ; reconfig_script = find_script (... , stop_conf1 , start_conf2 ,...) ; execute ( reconfig_script ) ; As illustrate in Figure 6.2, we wrap the control loop logics into three SCA components, which are, in turn, enclosed by a composite named Manager. Component EventHandler exposes a service allowing itself to be sent events (e.g., oload and uload ). The method implementing this is dened in SCA as one-way, menaing that the calls are non-blocking so the incoming events are stored in a First-In-First-Out queue. Upon the arrival of an event provenient from the Managed System (e.g., Znn.com), component EventHandler invokes the step method, which is implemented by component Architecture Analyzer. The step method outptut is sent to component Recongurator, that encompasses a method to nd the proper reconguration script to Inria High-level Language Support for the Control of Reconguration in Component-based Architectures27 be executed by the FraSCAti middleware component frascati-fscript. The frascati-fscript component relies on other components integrating the middleware, inside the FraSCAti Composite, to perform introspection and runtime reconguration on the managed system's components.

Manager

Znn.com Adaptation Scenario

We simulated the execution of the two instances of Znn.com application, namely soccer and politics, under the administration the Manager presented in the last section. The objective was to observe how recongurations are controlled, taking into account a sequence of input events as well as the stated behaviours and properties. The behaviours for components AppServer and Znn were as stated in Listings 7 and 8, respectively, whereas the properties are as dened in Listing 9.

As it can be observed in the rst chart of Figure 6.3, we scheduled a set of overload (oload ) and underload (uload ) events (vertical dashed lines), which simulates an increase followed by a decrease of the income workload for both soccer and politics instances.

The other charts depicted in Figure 6.3 correspond to the overall resource consumption, the overall delity, and the delity level (i.e., congurations text, img-ld or img-hd ) of the three instances of component AppServer contained in both instances of component Znn, namely politics and soccer, respectively. As the workload of politics increases, an event of type oload is red at step 2. That triggers the reconguration of that instance from conf1 to conf2, that is one more instance of AppServer is added within the component Znn. We can observe also the progression in terms of resource consumption, as a consequence of this conguration. The same happens with soccer at step 3, and is repeated with politics and soccer again at steps 4 and 5. The dierence, in this case, is that when the last oload event arrives, the soccer instance must not only to recongure to conf3 so as to cope with the current workload, but to keep the its delity level at the maximum (i.e., img-hd for all the instances of AppServer ). That forces politics instance to degrade the delity level of two of its instances of AppServer (as2 and as3 ). At step 9, the rst uload is red as a consequence of the workload decrease. It triggers a reconguration in politics instance as it goes from conf3 to conf2, that is, it releases one instance of AppServer (as3, which makes room on the resources and therefore allows it to bring back its delity level to the maximum level again. This is followed by a workload decrease of the soccer instance at step 10, which makes it release one instance of AppServer (as3 ). This is repeated again at steps 13 and 14 for instances politics and soccer respectively, bringing their levels of consumption and delity at the same levels as in the beginning.

While the Znn.com example was useful to show the power of expressiveness of Ctrl-F all along the Sections 4, the adaptation scenario helped us to understand, in a pedagogical way, the dynamics behind the Ctrl-F high-level description of adaptive behaviours and policies, that is, how recongurations in component-based architecture can actually be controlled in a logictemporal manner. It is important to remind that although Znn.com does not require complex adaptation behaviours, the integration with synchronous reactive programming based on FSA allows Ctrl-F, among other things, to be able to control applications while taking control decisions based sequences of states to take a decision, that is, systems with very complex behaviours.

Related Work

In the literature, there is a large and growing body of work on self-adaptive software systems. Our approach focuses on the language support for enabling self-adaptation in component-based architectures while relying on reactive systems and the underlying formal control tools for ensuring adaptation policies.

Classically, runtime adaption in software architectures is achieved by rst relying on ADLs such as Acme [START_REF] Garlan | Acme: An architecture description interchange language[END_REF] or Fractal [5] for an initial description of the software structure and architecture, then by specifying ne-grained reconguration actions with the help of dedicated languages like Plastik [START_REF] Batista | Managing dynamic reconguration in componentbased systems[END_REF] or FPath/FScript [START_REF] David | FPath & FScript: Language support for navigation and reliable reconguration of Fractal architectures[END_REF] to lead the target system to the desired state. A harmful consequence is that the space of reachable conguration states is only known as side eect of those reconguration actions, which makes it dicult to ensure correct adaptive behaviours.

Rainbow [START_REF] Garlan | Rainbow: Architecture-based self-adaptation with reusable infrastructure[END_REF] is an autonomic framework for that comes with Stitch, a domain-specic language allowing for the description of self-adaptation of Acme-described applications. Basically, the language groups a set of system-level actions (add, remove, bind component) into tactics, which in turn, are aggregated within a tree-like strategy path. The strategy path actually regroups a set of adaptation steps, whose branches are selected according to runtime conditions and the leaves corresponds to the end of a strategy, that can be evaluated as successful or failed.

We can draw an analogy between tactics and the set of actions triggered upon a reconguration; as well as strategies and behaviours in the Ctrl-F language. Nonetheless, besides the conditions-based behaviours (e.g., the case statement), our language provides an interesting set of behavioural statements including alternative and parallel, as well as the event-based ones like every and when-do. That makes Ctrl-F more expressive in terms of self-adaptation behavioural denition. Furthermore, thanks to the Ctrl-F's formal model in the reactive language Heptagon/BZR, it is possible to ensure correct adaptation behaviours either by verication or by enforcement, that is, by the generation of correct-by-construction controllers that enforce such behaviours.

In [START_REF] Morin | Taming dynamically adaptive systems using models and aspects[END_REF], feature models are used to express variability in software systems. At runtime, a resolution mechanism is used for determining which features should be present so as to constitute conguration. The approach relies on Model-Driven Engineering to ease the mapping between features and architectures as well as to automatically and dynamically generate the adaptation logics, i.e., the reconguration actions leading the target system from the current to the target conguration. In the same direction, Pascual et al. [START_REF] Pascual | Run-time support to manage architectural variability specied with cvl[END_REF] propose an approach for optimal resolution of architectural variability specied in the Common Variability Language (CVL) [START_REF] Haugen | Cvl: Common variability language[END_REF]. A major drawback of those approaches is that in the adaptation logics specied with feature models or CVL, there is no way to dene stateful adaptation behaviours, i.e., sequences of recongurations. In fact, the resolution is generally performed based on the current state and/or constraints on the feature model. While in our approach, in the underlying synchronous reactive RR n°8669 model based on FSA, decisions are taken also based on the history of congurations which allows us to dene more interesting and complex adaptation behaviours and policies.

In the domain of formal methods, Kouchnarenko and Weber [START_REF] Kouchnarenko | Adapting component-based systems at runtime via policies with temporal patterns[END_REF] proposes the use of temporal logics to integrate temporal requirements to adaptation policies. The policies are used for specifying reection or enforcement mechanisms, which refers respectively to corrective reconguration triggered by unwanted behaviours, and avoidance of recongurations leading to unwanted states.

While in this approach, enforcement and reection are performed at runtime in order to ensure correct behaviour, we rely on discrete controller synthesis so as to have correct-by-construction controllers ensuring both adaptation behaviours and policies.

As in our approach, in [START_REF] Delaval | Reactive model-based control of reconguration in the fractal component-based model[END_REF] and [4], authors also rely on Heptagon/BZR to model adaptive behaviours of Fractal components. Although those approaches provide us with interesting insights on how adaptive behaviours can be formalized, there is no general method allowing for the direct translation from a high-level description (e.g., ADL) to a synchronous reactive model.

It means that for each new application, the formal model has to be recreated. Moreover, recongurations are controlled at the level of ne-grained reconguration actions (e.g., add/remove components and bindings), which can be considered time-consuming and dicult to scale, especially for large-scale architectures. In comparison, Ctrl-F proposes a set of high-level constructs to ease the description of adaptation behaviours and policies of component-based architectures.

In addition, we propose an extensible autonomic manager that bridges Ctrl-F and a real component platform. Delaval et al. [START_REF] Delaval | Modular coordination of multiple autonomic managers[END_REF] proposes the use of components to embody autonomic managers conceived with synchronous reactive programming. The idea is to have modular controllers that can be coordinated so as to work together in a coherent manner. The approach is complementary to ours in the sense that it does not provide high-level language support for describing those managers, although the authors provide interesting intuitions on a methodology to do so. Either

Ctrl-F provides concepts dedicated for the specication of coordination between components' control. We do believe however that coordination is a major challenge that should be tackled by any modular self-adaptive software system . Hence the integration of coordination aspects to Ctrl-F should be seriously considered in future work (cf. Section 8).

Conclusion

Initiatives like autonomic computing advocate the use of feedback control loops in order to enrich software system with self-adaptive capabilities and thus cope with changing requirements and dynamical environments at runtime. In this direction, component-based software engineering has played a major role, since it enables the development of reusable, modular, recongurable and adaptable applications. In fact, by relying on architecture description languages, one can dene initial congurations, while programing adaptation behaviours as routine of ne-grained actions on languages dedicated for the reconguration of architectural elements. Besides the complexity of dealing with ne-grained reconguration actions, especially in large architecture;

another negative consequence of such an approach is that the space of reachable congurations is only known as a after-eect of those ne-grained actions, which makes it hard to ensure correction on the adaptive behaviours.

This paper presented Ctrl-F: a high-level domain-specic language that allows for the description of adaptation behaviours and policies of component-based architectures. A distinguished feature of Ctrl-F is that it is formalized with the synchronous reactive language Heptagon/BZR, and hence we can benet, among other things, from formal tools for verication, control, and automatic generation of executable code. In order to show the expressiveness of our language, we applied it Znn.com, a self-adaptive news website; and integrated it with FraSCAti, a Service Inria High-level Language Support for the Control of Reconguration in Component-based Architectures31

Component Architecture middleware.

In addition to applying and experimenting Ctrl-F with other case studies and benchmarks, we indent to pursuit research to address issues related to modularity and coordination of controllers.

We believe that there might be cases where the modular control of components becomes necessary.

In particular, for communication cost reasons, one may want to distribute or deploy controllers in the same physical place (e.g., a distributed node) of the component it is intended to control.

Moreover, one may want that (distributed) controllers react to their environments at their own paces. That creates a sort of asynchrony and independence among controllers that might be harmful, especially if they have conicting behaviors. In this regards, it becomes imperative to conceive mechanisms for the coordination among component controllers as well as the appropriate high-level language constructs. Prior work such as [START_REF] Delaval | Modular coordination of multiple autonomic managers[END_REF] seem to be a good start point.

Figure 1 :

 1 Figure 1: Fractal Architectural Concepts.

Figure 2 :

 2 Figure 2: Graphical and Textual Representation of Component Life-cycle.

Listing 1 :

 1 Example of Hierarchical Composition. node reset (b ,r ,c , e : bool ) returns (a , s : bool )

Listing 2 :

 2 Example of Contract in Heptagon/BZR.

Figure 3 :

 3 Figure 3: Heptagon/BZR Compilation Chain.

Figure 4 :

 4 Figure 4: Znn.com Architecture.

Figure 5 :

 5 Figure 5: Znn.com Instances.

Figure 6 :

 6 Figure 6: Language Abstract Syntax.

Listing 3 :

 3 Main Component in Ctrl-F. the denition of component Znn. It consists of one provided interfaces (line 2)

Listing 4 :

 4 Znn Component in Ctrl-F. bind lb . ci1 to as1 . si bind lb . si to si set fidelity to as1 . fidelity set consumption to sum ( as1 . consumption , lb . consumption ) } configuration conf2 extends conf1 { as2 : AppServer bind lb . ci2 to as2 . si set fidelity to avg ( as1 . fidelity , as2 . fidelity ) set consumption to sum ( as1 . consumption , as2 . consumption , lb . consumption ) Inria } configuration conf3 extends conf2 {...} behaviour {...} policy {...} } Listing 5 shows the description of component LoadBalancer. It consists of four interfaces:

Listing 5 :

 5 Load Balancer Component in Ctrl-F. component LoadBalancer { server interface si client interface ci1 , ci2 , c3 port out oload port out uload attribute consumption =0.2 }Lastly, component AppServer (Listing 6) has only one interface (line 2) and listens to events of type oload and uload (lines 4-5). The component has also two attributes: consumption and delity (lines 7 and 8), just like component Znn. Three congurations corresponding to each level of delity (lines 10-13, 14-17 and 18) are dened within the component, and its attributes are valuated according to the conguration in question, that is, the higher the delity the higher the consumption.Listing 6: AppServer Component in Ctrl-F.

Listing 7 :

 7 Behaviour of AppServer Component.

Listing 8 :

 8 Behaviour of Znn Component. do ( conf3 when uload do emitter2 end ) ,

Listing 9 :

 9 Example of Constraint and Optimization on Attributes.

Figure 7 :

 7 Figure 7: Translation Scheme Overview.

(lines 18 -

 18 20). The request and end signals for these instances can be derived from the request and end signals for congurations (lines 10-15). At last, attributes are values based on the values of attributes of the instances of node appserver (line 21). Listing 11: Heptagon/BZR code for Znn and AppServer. node appserver (r ,e , oload , uload : bool ) returns ( r_text , e_text , r_ld , e_ld , r_hd , e_hd : bool ; fidelity , consumption : int ) let ... tel node znn (r ,e , oload , uload : bool ) returns ( r_conf1 , e_conf1 ,... , r_conf3 , e_conf3 : bool ; fidelity , consumption : int ) let r_as1 = r_conf1 or r_conf2 or r_conf3 and not ( e_conf1 or e_conf2 or e_conf3 ) ; r_as2 = r_conf2 or r_conf3 and not ( e_conf2 or e_conf3 ) ; r_as3 = r_conf3 and not ( e_conf3 ) ; e_as1 = e_conf1 or e_conf2 or e_conf3 and not ( r_conf1 or r_conf2 or r_conf3 ) ; e_as2 = e_conf2 or e_conf3 and not ( r_conf2 or r_conf3 ) ; e_as3 = e_conf3 and not ( r_conf3 ) ;

Figure 8 :

 8 Figure 8: Top-most Automaton for Behaviours.

Figure 9 :

 9 Figure 9: Automaton for When-Do Statement.

r _ b 2 e 2 e ∧ ¬r/ e_b 2 e, r_b 2 e ∧ r ∧ c/ e_b 2 , r_b 1 e ∧ ¬r/ e_b 1 Figure 10 :

 22221110 Figure 10: Automaton for Case and Alternative Statements to Be Composed in Parallel.

Figure 11 :Figure 12 :

 1112 Figure 11: Automaton Modeling the Every statement.

Figure 13 :

 13 Figure 13: Translation of the component AppServer behaviour.

Listing 12 shows

 12 an example of how a policy is translated into Heptagon/BZR. It refers to a policy on the attributes consumptions dened inside the main component of Znn.com example (cf. Listing 9, line 10). Basically, it states an equation (line 9) that depends on the integer outputs soccer_consumption and politics_consumption, which are produced by the respective instances of node znn (lines 7 and 8). Finally, as shown, this equation is used in the enforce block of the contract (line 3). Listing 12: Example of Constraint on Attribute in Heptagon/BZR. node main (r , e : bool ;...) returns (... , p1 : bool ) contract enforce p1 and ... with (...) let ... (... , soccer_consumption ) = znn (...) ; (... , politics_consumption ) = znn (...) ; p1 =( soccer_consumpton + politics_consumption ) < 3 ..

E e 1 r 2 ∧ r 1 r 2 ∧ ¬r 1 r 1 ∧ ¬e 2 e 2 ∧ ¬e 1 e 2 ( 2 e 1 ∧ ¬r 3 ∧ r 2 e 1 ∧ ¬r 3 ∧ ¬r 2 r 2 ∧ ¬r 3 r 3 ∧ ¬e 2 r 3 e 1 ∧ r 3 (

 12112222112233313

Figure 14 :

 14 Figure 14: Observer Automata for Temporal Constraints.

Figure 15 depictsFigure 15 :

 1515 Figure 15 depicts the basic concepts of SCA model illustrated with the Znn.com example. A component can be dened as simple or composite, that is, composed of other components. A simple component is dened by an implementation implementation, a set of services, references and properties. The implementation points to the actual implementation of the component (e.g.,a Java Class). A service (resp. reference) refers to a business function provided (resp. required) by the component and is specied by an interface (e.g., via a Java Interface). Properties are attributes dened within components whose values can be set/got from outside the component.In order for services, references and properties be accessible from/or access outside the composite,

Listing 13 :Figure 16 :

 1316 Figure 16: Ctrl-F Compilation Chain and Manager Wrapper

Figure 18 :

 18 Figure 18: Execution of the Adaptation Scenario.

Table 2 :

 2 Summary of Behaviour Statements. i execute B i e n do B n end case c 1 then B 1 , Execute B i if c i holds ... , c n then B n end B 1 | B 2 Execute either B 1 or B 2 B 1 || B 2 Execute B 1 and B 2

	Statement B when e 1 do B 1 ,	Description While executing B when
	... ,
		in parallel
		Execute B and re-execu-
	do B every e	tes at every occurrence
		of e
	configuration img -hd {...}
	behaviour {...}
	policy {...}
	}

e

  It receives as input external request (r) and end notication (e) signals, and a set of events {v 1 , . . . , v k }, which corresponds to the event types the component in question (comp) listens to. As output, it produces a set of request (resp. end) signals {r 1 , . . . , r m } (resp. {e 1 , . . . , e m }) for each conguration conf i , for i ∈ [1, m], dened within the concerned component. In addition, it also returns a set of weights {w 1 , . . . , w l }, which correspond to attribute valuation for each attribute dened in the component.

	Idle	conf1	conf2	...

  . . , v k }) signals of the main node. As Inria High-level Language Support for the Control of Reconguration in Component-based Architectures19 a result of the reaction to those signals, it produces the same signals for requesting ({r 1 , . . . , r m }) and ending ({e 1 , . . . , e m }) congurations as the weights ({w 1 , . . . , w l }) corresponding to the attributes valuation in the current state (conguration) of the behaviour. We provide further details on the translation of behavioural statements in Section 5.2.Lastly, there might also be some other sub-nodes ({sub 1 , ..., sub n }) referring to components instantiated within the concerned component, i.e., comp. They have interfaces and contents which are structurally identical to those of the main node. That is to say, that sub-nodes may have, in turn, a contract, a behaviour sub-node and a sub-node per component instance dened inside it. It is noteworthy that the request (r subi ) and end (e subi ) signals for a sub-component sub i ∈ {sub 1 , . . . , sub n } are dened as equations of request and end signals for the congurations the concerned component belongs to (cf. Equation1).

RR n°8669

http://www.oasis-opencsa.org/ Inria

Temporal Constraints

Temporal constraints are high-level constructs that take the form of predicates on the order of congurations. These constructs might be very helpful when there are many possible reconguration paths (by either parallel or alternative composition, for instance), in which case the manual specication of such constrained behaviour may become a very dicult task.

In order to ease the specication of such kind of constraints, Ctrl-F provides four constructs, as follows: conf 1 precedes conf 2 : conf 1 must take place right before conf 2 . It does not mean that it is the only one, but it should be among the congurations taking place right before conf 2 . conf 1 succeeds conf 2 : conf 1 must take place right after conf 2 . Like in the precedes constraint, it does not mean that it is the only one to take place right after conf 2 . conf 1 during conf 2 : conf 1 must take place along with conf 2 . conf 1 between (conf 2 , conf 3 ): once conf 2 is started, conf 1 cannot be started and conf 3 , in turn, cannot be started before conf 2 has been terminated. Listing 10 shows an example of how to apply temporal constraints, in which it is stated that conguration img-ld comes right after the termination of either conguration text or conguration img-ld. In this example, this policy avoids abrupt changes on the content delity, such as going directly from text to image high denition or the other way around. Again, it does not mean that no other conguration could take place along with img-ld, but the alternative statement in the behaviour described in Listing 7 leads us to conclude that only img-ld must take place right after either text or img-hd has been terminated.