An architectural model for building distributed adaptation systems Mohamed Zouari, Maria-Teresa Segarra, Franc¸oise Andr´e and Andr´e Th´epaut

Abstract Dynamic adaptation allows the modification of an application configuration at runtime, according to changes in the environment and/or in users’ requirements. The case of adaptive distributed applications has not been substantially addressed. In particular, the distribution of the adaptation system itself has been rarely considered. We address this issue by proposing an architectural model of distributed adaptation systems. Our model allows dynamic adaptation management in a distributed and coordinated manner and expresses variation points of the system. In this paper, we present our model and its use to build distributed adaptation systems. We have applied our results to build an adaptive distributed data replication system used in a medical environment dedicated to remote health care delivery for patients at home.

1 Introduction Dynamic adaptation [4] is a fundamental requirement of applications running in fluctuating and heterogeneous environments. An adaptation engine generally monitors the execution context in order to trigger dynamic adaptation whenever it detects significant variations. It makes decisions regarding the adaptation and controls the modification of the application in order to achieve the appropriate configuration. When a decentralized application is running in heterogeneous environments, distributed adaptation mechanisms are needed to improve their quality such as efficiency, robustness, and scalability. The distributed management of adaptation leads Mohamed Zouari - Franc¸oise Andr´e INRIA/IRISA, Campus de Beaulieu, 35042, Rennes, France, e-mail: {mohamed.zouari, francoise.andre}@irisa.fr Maria-Teresa Segarra - Andr´e Th´epaut T´el´ecom Bretagne, Technopˆole Brest-Iroise, 29238, Brest, France e-mail: {mt.segarra, andre.thepaut}@telecom-bretagne.eu

1

2

Mohamed Zouari, Maria-Teresa Segarra, Franc¸oise Andr´e and Andr´e Th´epaut

to the concurrent execution of multiple adaptation processes performed by several engines. Conflicting decisions and inconsistent modifications may occur if the interdependences among the application components are not considered. Therefore, coordinating the activities of multiple adaptation engines is critical in order to preserve the overall consistent state of the application. From this point of view, the development of a distributed adaptation system is challenging. In this paper, we propose an approach to build a component-based software architecture supporting the distributed and coordinated management of dynamic adaptation. We define an architectural model of adaptation systems that allows the variability of system configuration and provides coordination mechanisms. This model abstracts the adaptation mechanisms in a modular way and allows their specialization so as to facilitate the development process. The remainder of the paper is organized as follows. Section 2 analyses related work. We describe the general principles underlying our approach for building selfadaptive applications in Section 3. Next, Section 4 presents our architectural model of distributed adaptation systems. Finally, we conclude and discuss future work in Section 5.

2 Related work A lot of research has been done in the area of dynamic adaptation [4]. However, we distinguish a limited number of works interested in coordinating activities of multiple adaptation engines [1, 3, 5]. They enable the engines to cooperate for decisionmaking and/or the control of adaptation actions execution. These works, nevertheless, do not propose reusable and flexible coordination mechanisms. Regarding the decision making, no work proposes mechanisms for distributed and parallel decision making, each based on a local view of the system, in the same adaptation process. To the best of our knowledge, the problem of resolving conflicts among the decisions of several engines has not been addressed in previous works. Concerning the reconfiguration mechanisms, only Cactus [3] proposes a protocol that provides distributed control over modifications. However, it lacks flexibility as the type of modifications (component’s implementation), the steps of their achievement, and the participants in the coordination process are predefined. Regarding the facilities for setting up the mechanisms for distributed adaptation management, only [5] provides a solution to customize the adaptation system behaviour. Moreover, no tools are proposed to customize the structure or the distribution of an adaptation system. In order to facilitate the task of the adaptation system designer, it is important to propose adaptation mechanisms that are reusable, easily specializable, and supporting the coordination of multiple adaptation engines’ activities when necessary. In addition, tools and methods are required in order to make the specialization tasks easier.

An architectural model for building distributed adaptation systems

3

3 Principles for self-adaptive applications building Our approach aims at facilitating the component-based development of distributed self-adaptive applications. We define a software component as a reusable software entity that provides and requires functional interfaces (related to business logic) and may provide a set of control interfaces. The provided interfaces are called server interfaces and the required interfaces are the client interfaces. The control interfaces allow to manage the non-functional aspects such as suspend/resume the component execution and connect/disconnect components. We externalize the mechanisms of adaptation control for reusability. Some application components provide control interfaces that define primitive operations to monitor and reconfigure them. The adaptation system is connected to the application trough these interfaces to produce a self-adaptive application. We design the adaptation mechanisms in a modular way and we offer two tools, an architectural model and a factory, to facilitate their specialization according to the target application. As shown in Figure 1, an expert provides an architecture description for his system to the factory. The architecture description specifies the components that compose the adaptation system, the connections among them, the values of configuration parameters, and the connections with the application components. The factory verifies that the constraints of the architectural model are satisfied, deploys the adaptation system and connects it with the application. The architectural model specifies the type of components composing the system, variation points, and constraints. We extend the standard modelling language UML 2.3 to model components and their assembly. This language does not provide the concept of component type. We define a graphical notation and its semantics for modelling such a type (Figure 2) and expressing the variability concerns. The stereotype type is used to denote a type of component. We specify below the stereotype the type’s name. We represent on the left server interfaces types, on the right the client interfaces types, and at the top the control interfaces types. A mul-

Adaptation  expert

provides

Adaptation  architectural architectural  model

Self‐adaptive  application

uses Architecture  description description  of  adaptation adaptation  system

Ad i Adaptation  system Factory observe Environment for  p y adaptation system  building

Fig. 1 Building a self-adaptive application

modify

Adaptive  application

4

Mohamed Zouari, Maria-Teresa Segarra, Franc¸oise Andr´e and Andr´e Th´epaut Attributes: ‐ algorithm= g $algorithm ‐ algoParameters= {$ 1..$p {$p $ n}

Interface type min..max min max min..max

Component type Component type

‐ node=$node

Interface type Interface type min..max min..max

Fig. 2 Graphical notation of a component type

tiplicity is indicated for each interface type as well as for the component type. The multiplicity of a component type refers to an interval that specifies the allowable number of component instances for a concrete system. The multiplicity of a server interface represents the allowable number of client interfaces that can use it. The multiplicity of client interface indicates the allowable number of the interface instances. Moreover, a list of the component’s attributes, which values can be fixed at specialization time, is represented by an annotation. We distinguish three kinds of possible attributes: the algorithm, its configuration parameters, and the node that hosts the component instance. Concerning a composite component type, it is defined by the component types that compose it, the possible connections among them, and the type of its external interfaces. Variation points in our model correspond to the number of component and interface instances, the values of the attributes, and the topology to connect components together.

4 Architectural model of distributed adaptation systems Our architectural model specifies two composite component types ContextManager and AdaptationManager to perform the dynamic adaptation control. An adaptation system is composed of several components of each type (the two types have multiplicity 1..*). A component type ContextManager collects, interprets, aggregates contextual data and detects the context changes. It collects the information about the execution context provided by physical sensors (e.g., a camera to locate a patient at home) or control interfaces exposed by logical sensors that allow adding probes to application components. For example, the data access requests can be intercepted to calculate the frequency of data reads and writes. A component type AdaptationManager determines which components of the application must be adapted and the means to achieve it and controls the execution of adaptation actions. Such actions modify the associated component like changing a parameter value or removing a connection. An adaptation manager may reconfigure an arbitrary number of application components. A publish/subscribe mechanism provides asynchronous inter-

An architectural model for building distributed adaptation systems

5

action between both types of components to trigger adaptation. Moreover, an adaptation manager can query a context manager for specific contextual information in request/response mode. Each adaptation manager may collaborate with one or several context managers depending on their spheres of action. In the following we will give only an overview of the adaptation manager architecture. Our architectural model defines a component type AdaptationManager as a composite that contains three mandatory component types DecisionMaker, Planner, and Executor (Figure 3). An adaptation manager contains a single instance of each type (multiplicity 1). The component type DecisionMaker is responsible for decision making. Such a decision results in an adaptation strategy that specifies the appropriate changes to the actual application configuration (e.g., changing the replica placement algorithm). The component type Planner identifies a sequence of adaptation actions as a plan to apply the strategy chosen by the decision maker. The application of this adaptation plan is controlled by the component type Executor. Our architectural model supports the coordination of adaptation managers’ activities. First, the coordination of decision making aims at enabling a group of adaptation managers to make a collective decision in order to ensure non-conflicting and complementary decisions. A component type DecisionMaker can assign the task of applying a specific strategy or notify its adopted strategy to an arbitrary number of decision makers using interfaces type CoordinateItf. The optional component type Negotiator enables a manager to take part in a strategy negotiation process. Second, the plans execution coordination addresses the problem of applying several plans in parallel by a group of adaptation managers when plans contain dependent actions. In such a case, the execution control of these plans must be coordinated in the sense that

AdaptationManager

1..* 1

DecisionMaker NegotiateItf g f 0..1 CoordinateItf CoordinateItf 0..* 0 * 0..* S b ib f SubscribeItf 1..* NotifyItf MonitorItf 1..* 1.. 1 * 1..* PlanItf 1 1

Planner ExecuteItf Pl Itf PlanItf 1 1 MonitorItf 0..*

Attributes: ‐ algoParameters={$policy} g {$p y} 0..1 ‐ node=$node Negotiator ProposeItf ProposeItf 0 * 0..* 0..* NotifyItf NegotiateItf 1 0..1

Attributes: ‐ node=$node

1

Executor ExecuteItf CoordinateExecItf 0..1 1 PublishItf OrderItf 0..1 0..1 ModifyItf 1..*

Fig. 3 Architectural model of an adaptation manager

Coordinator CoordinateExecItf 0 1 0..1 PublishItf OrderItf 0..1 1 PropagateItf PropagateItf 0 * 0..* 0 * 0..* 0..1

6

Mohamed Zouari, Maria-Teresa Segarra, Franc¸oise Andr´e and Andr´e Th´epaut

a specific sequence of their actions execution must be performed to achieve a consistent configuration of the application. For this purpose, each component type Executor can delegate the control to the optional component type Coordinator which interacts with other coordinators. In our previous paper [6], we discussed the steps required to negotiate a strategy and apply adaptation plans in a coordinated manner. Each of these primitive component types has one or two attributes to specialize the behaviour (attributes policy) and the distribution (attributes node) of each adaptation manager. The value of each attribute policy references an external policy describing the adaptation logic.

5 Conclusion In this paper, we have presented the main concepts related to our approach for building self-adaptive distributed applications. We are particularly interested in the definition and use of an architectural model that specifies the structure and semantics of a software architecture for distributed adaptation management and imposes explicit constraints when building the system. The flexibility of our model allows customizing the behaviour, the structure, and the distribution of adaptation systems using our factory. We have implemented a prototype based on the Fractal component model [2], which is a hierarchical, reflexive and extensible model. We have applied our results to build an adaptive distributed data replication system used in a medical environment dedicated to remote health care delivery for patients at home [6]. As future work, we intend to automate some specialization tasks and make the adaptation system self-adaptive.

References 1. Birman, K.P., Constable, R., Hayden, M., Hickey, J., Kreitz, C., Renesse R.V., Rodeh, O., Vogels, W.: The horus and ensemble projects : Accomplishments and limitations. Technical report, New York (1999) 2. Bruneton, E., Coupaye T., Leclercq M., Qu´ema V.: The FRACTAL component model and its support in java. Softw, Pract. Exper, 1257–1284 (2006) 3. Chen, W.K., Hiltunen, M.A., Schlichting R.D.: Constructing adaptive software in distributed systems. In ICDCS ’01 : Proceedings of the 21st Inter. Conf. on Distributed Computing Systems, 635–643, Washington (2001) 4. Cheng, B. H., Lemos, R., Giese, H.: Software engineering for self-adaptive systems: A research roadmap. In: Software Engineering for Self-Adaptive Systems. LNCS, vol. 5525. Springer, Heidelberg (2009) 5. Dowling, J., Cahill, V.: Self-managed decentralised systems using K-Components and collaborative reinforcement learning. In WOSS ’04: Proceedings of the SIGSOFT workshop on Self-managed systems, 39–43, New York (2004) 6. Zouari, M., Segarra, M.T., Andr´e, F.: A framework for distributed management of dynamic self-adaptation in heterogeneous environments. In 10th IEEE Inter. Conf. on Computer and Information Technology, 265–272, Bradford (2010)