Structural Reconfiguration of Systems under Behavioral Adaptation

Transcription

1 Strutural Reonfiguration of Systems under Behavioral Adaptation Carlos Canal a, Javier Cámara b, Gwen Salaün a Department of Computer Siene, University of Málaga, Spain b Department of Informatis Engineering, University of Coimbra, Portugal Grenoble INP, INRIA, Frane Abstrat A major asset of modern systems is to dynamially reonfigure themselves to ope with failures or omponent updates. Nevertheless, designing suh systems with off-the-shelf omponents is hardly feasible: omponents are blakboxes that an only interat with others on ompatible interfaes. Part of the problem is solved through Software Adaptation tehniques, whih ompensate mismathes between interfaes. Our approah aims at using results of Software Adaptation in order to also provide reonfiguration apabilities to blak-box omponents. This paper first formalizes a framework that unifies behavioral adaptation and strutural reonfiguration of omponents. This formalization is used for statially deteting whether it is possible to reonfigure a system. In a seond part, we present five notions of reonfiguration: history-aware reonfiguration, future-aware reonfiguration, property-ompliant reonfiguration, one-way reonfigurability, and full reonfigurability. For eah of these notions, its relevant properties are presented, and they are illustrated on simple yet realisti examples. Keywords: Components, dynami reonfiguration, behavioral adaptation 1. Introdution The suess of Component-Based Software Development omes from reating omplex systems by assembling smaller, simpler omponents. Nevertheless, building systems based on off-the-shelf omponents is a diffiult task beause these must ommuniate on ompatible interfaes. The task beomes even more diffiult when the system needs to reonfigure beause in that ase omponents must provide reonfiguration apabilities. Here, we understand by reonfiguration the apaity of hanging the omponent behavior and/or implementation addresses: anal@l.uma.es (Carlos Canal), jmoreno@dei.u.pt (Javier Cámara), gwen.salaun@inria.fr (Gwen Salaün) Preprint submitted to Elsevier September 18, 2011

2 at runtime [17]. For example, we are interested in upgrading or substituting a omponent by another one, adding new omponents to a running system, and so on. Components are blak-box modules of software that ome with speifiations of their interfaes. Therefore, we have no aess to their soure ode, although it is possible to use tool-assisted tehniques to analyze the behavior of a omponent assembly [5, 9]. Some appliations of this analysis are used in Software Adaptation [26] to work out behavioral mismath among omponent interfaes. In [20], an adaptation ontrat defines rules on how mismath an be worked out and a tool generates an adaptor that orhestrates the system s exeution while ompensating inompatibilities existing among interfaes. On the ontrary, there is little support to analyze whether a reonfiguration preserves ertain properties. Enabling system reonfiguration requires designers to define (i) when a omponent an be reonfigured, (ii) whih kind of reonfiguration is supported by the omponent, and (iii) whih kind of properties are hold by reonfiguration operations; for instane, ensuring that some parts of the system an be reonfigured without system disruption. Our approah aims at providing a formal framework that helps answering these questions. There are several related approahes in the literature. For instane, SOFA 2.0 [9] proposes reonfiguration patterns in order to avoid unontrolled reonfigurations whih lead to errors at runtime. This enables the addition and removal of omponents at runtime, passing referenes to omponents, et., under predefined strutural patterns. Several other more general approahes dealing with distributed systems and software arhitetures [14, 15], graph transformation [1, 25] or metamodelling [13], also address reonfiguration issues. They will be disussed in Setion 6. Our goal is to reonfigure omponents that have not been designed with reonfiguration apabilities in mind. Moreover, we target reonfiguration of omponents that may be involved in an ongoing exeution without stopping the system. This fits in a ontext where reonfiguration may be triggered at any moment and a omponent must be substituted at runtime. We build on the basis that omponents are provided with both signature and behavioral interfaes, and their omposition is desribed by means of an adaptation ontrat. The standard way for ensuring that a omponent an replae another one is by means of a bisimulation equivalene [24]. Thus, substituting a omponent requires finding a perfet math, and reonfiguration is usually limited to instanes (or subtypes) of the same omponent. Instead, our approah aims to exploit behavioral adaptation to further allow reonfiguration. That is, we target reonfiguration senarios in whih both the former and the new omponent need some adaptation in order to allow substitution. Thus, bisimulation does not fit our purposes sine the need for adaptation makes the omponents to behave differently in the onfigurations being onsidered. This paper is strutured as follows: First, Setion 2 provides some bakground that will be used throughout the paper. Next, Setion 3 introdues a lient/server system that is used as running example through all the text. Then, 2

3 Setion 4 provides the formal framework that unifies strutural reonfiguration and behavioral adaptation. In a seond part, Setion 5 ontains the ore of our work. It presents five notions of reonfiguration ompliane: (i) history-aware reonfiguration, (ii) future-aware reonfiguration, (iii) property-ompliant reonfiguration, (iv) one-way reonfigurability, and (v) full reonfigurability. This setion also presents proofs of properties of interest for eah of the notions, and several related algorithms. These notions of ompliane indue different reonfiguration senarios that allow replaing a omponent by another one that may present a ompletely different interfae, while ensuring the preservation of several interesting system properties. Eah notion is illustrated on a simple yet realisti example. Finally, Setion 6 presents related work on reonfiguration and behavioral adaptation, and Setion 7 onludes this paper. This artile is a revised and extended version of our previous work presented in [12]: ˆ We propose a reonfiguration notion whih preserves ations ourring in the future (wrt. the moment when we apply the reonfiguration). We also define a reonfiguration whih is both history and future-ompliant. ˆ We propose a less restritive notion of reonfigurability based on the verifiation of temporal properties ˆ We give a formal haraterization of all the reonfiguration notions, inluding theorems proving properties of interest, and (when suitable) algorithms for heking whether a reonfiguration satisfies a partiular notion. 2. Bakground This paper builds on our previous works on Software Adaptation, mainly [11, 10]. We reall in this setion some of the onepts and definitions that are used in this paper Component interfaes We assume that omponent interfaes are desribed by a signature and a protool. The signature delares both the operations that the omponent provides, and those it requires from other omponents. A signature is represented by a set of ations L, relative to the emission and reeption of messages orresponding to operation alls. An ation is a tuple (M, D) where M is the operation name, and D stands for the ommuniation diretion (! for emission, and? for reeption). On the other hand, the protool represents the behavior of the omponent i.e., the order in whih the operations in the signature are performed. We model the behavior of a omponent by means of a Labelled Transition System (LTS). The transitions in the LTS enode the ations that a omponent may perform in a given state. 3

4 Definition 1. [LTS]. A Labelled Transition System is a tuple S, s 0, L, where S is the set of states, s 0 S is the initial state, L is the set of ations, is the transition relation: S L S. We write s α s for (s, α, s ). The set L orresponds to the ations in the omponent s signature. Thus, we represent omponents just by the LTS that desribe their behavior. Finally, we avoid non-determinism in LTSs. That is, we assume that for any (s, α, s ), s s.t. s s and (s, α, s ). We will use traes for representing both the state of a omponent and the history of ations that it has performed up to a given point. Given an LTS S, s 0, L,, a trae (usually denoted by σ, σ, et.) is a sequene α 0... α n of ations from L. ɛ represents the empty trae (ɛ = ). We assume an operation of trae onatenation (written σ σ ) defined in the usual way. We also assume an operation of omplementary of a trae σ or a set of traes R (written σ and R, respetively), defined by omplementing all the ations in the trae or the set (i.e., replaing α! by α? and vie versa). Finally, we will say that two traes σ and σ are disjoint if they have no ation in ommon, i.e., if the sets of ations over whih σ and σ are defined are disjoint. Then, we an define the traes of an LTS as the sequenes of ations that an be observed aording to its transition relation and starting from its initial state: Definition 2. [Traes]. Let p = S, s 0, L, be an LTS. We define its traes Σ p = {ɛ} {σ σ = α σ s.t. α L, (s 0, α, s ), and σ Σ p, where p = S, s, L, }. The definition above onsiders the (possibly infinite) set of traes of an LTS, inluding any partial trae that an be derived from it. In some situations, we will be just interested in maximal traes, i.e., those whih are not ontained in any other trae. Definition 3. [Maximal Traes]. Let p be an LTS. We define its maximal traes Σ p = Σ p \ {σ σ Σ p s.t. σ, σ ɛ, and σ σ Σ p } where \ stands for set subtration. Synhronization between a group of omponents, eah one represented by an LTS, is defined by means of their synhronous produt. Definition 4. [Synhronous Produt]. The synhronous produt of n LTS p i = S i, s 0i, L i, i, i {1,..., n}, is the LTS p 1... p n = S, s 0, L, suh that: ˆ S = S 1... S n, ˆ s 0 = (s 01,..., s 0n ), ˆ L = L 1 { }... L n { }, 4

5 ˆ is defined as follows: (s 1,..., s n ) S, i, j {1,..., n}, i < j suh that (s i, α, s i ) i, (s j, α, s j ) j, then (x 1,..., x n ) S and ((s 1,..., s n ), (l 1,..., l n ), (x 1,..., x n )), l k = α, x k = s i if k = i where k {1,..., n}: l k = α, x k = s j if k = j l k =, x k = s k otherwise where the operator stands for the artesian produt. The states in the produt orrespond to tuples of states of the omponents (alled substates). For instane, a state (s 1,..., s n ) denotes that omponent p 1 is in state s 1,..., omponent p n is in state s n. Initially all omponents are in their initial state (i.e., s 0i for p i ), whih means that the initial state of the produt is (s 01,..., s 0n ). The omputation of the transitions expresses that, given some omposite state (s 1,..., s n ) in the produt, there is some transition outgoing from this state iff there are two omponents, p i and p j, that may perform from states s i and s j in their LTS a omplementary ation (i.e., (s i, α, s i ) i, (s j, α, s j ) j ), one sending a message and the other one reeiving it), while the other omponents do not perform any ations (denoted ). The resulting target state of the transition orresponds to its same soure state, exept for the substates of omponents p i and p j, whih are now s i and s j, respetively. Transitions in the produt are labelled with ations from the omponents ation sets (extended with ), one from eah omponent Adaptation ontrats and adaptors While building a new system by reusing existing omponents, behavioral interfaes do not always fit one another, and these interoperability issues have to be faed and worked out. Mismath may be aused by different message names, a message without ounterpart (or with several ones) in the partner, et. The presene of mismath results in a deadloking exeution of several omponents [3, 11]. Adaptors an be automatially generated based on an abstrat desription of how mismath situations an be solved [11]. This is given by an adaptation ontrat. The adaptation ontrat is speified by a set of orrespondene vetors (or vetors for short). Definition 5. [Vetor]. A orrespondene vetor for a set of omponents { S i, s 0i, L i, i } i {1,...,n}, is a tuple e 1,..., e n with e i L i { }, meaning that a omponent does not partiipate in a synhronization. Vetors express orrespondenes between messages, like bindings between ports or onnetors in arhitetural desriptions. Eah vetor establishes a orrespondene among ations of the different omponents involved in the adaptation. Eah ation appearing in one vetor is exeuted by one omponent and the overall result orresponds to a generalized synhronization (performed in several onseutive steps) between all the omponents involved. A vetor may involve 5

6 any number of omponents and does not require interations to our on the same names of ations. Vetors also allow representing omponent ations that have no ounterpart. These ations will be mimiked when required, in order to make the omponents in the system progress. This way, our adaptation model an be applied to both losed and open systems. Definition 6. [Adaptation Contrat]. An adaptation ontrat for a set of omponents { S i, s 0i, L i, i } i {1,...,n}, is a set of orrespondene vetors defined over the ation sets L i of these omponents. From a set of LTS P = {p 1,..., p n } representing a number of omponents we want to adapt to eah other, and an adaptation ontrat AC, we an build an adaptor A P (see Algorithms 1 and 3 in [11] for details) that solves the interation mismath among the omponents, taking into aount the orrespondenes between ations desribed in the adaptation ontrat. The adaptor is given by an LTS whih, put into a non deadlok-free system, renders it deadlok-free [11]. The behavior of the adapted system is given by the synhronous produt of the adaptor and the LTS of the omponents (A P p 1... p n ). In order to avoid any diret synhronization between the omponents being adapted, we assume that the sets of ations L 1,..., L n of these omponents are disjoint. In order to guarantee this, for any omponent p i in P we prefix its ation names with the name of the omponent (e.g. p i : α!, p i : β?). This way, all the messages exhanged will pass through the adaptor, whih an be seen as a oordinator or omponent-in-the-middle for the omponents being adapted. Example. Let us onsider two omponents, C 1 and C 2. A vetor v = C 1 : on!, C 2 : ativate? denotes that the ation on! performed by omponent C 1 orresponds to ation ativate? performed by omponent C 2. C1 Adaptor C2 on! on? on! on? ativate! ativate? ativate! ativate? Figure 1: Components C 1 and C 2 onneted through an adaptor. The adaptor synhronizes with omponents using the same name of ations but the reversed diretions, e.g., in Fig. 1 we may observe the ommuniation between on! in C 1 and on? in the adaptor. Furthermore, when a vetor inludes more than one ation, the adaptor always starts the set of interations formalized in the vetor with the reeptions (whih orrespond to emissions on omponent interfaes), and next handles the emissions. 6

7 3. Running Example This setion presents the running example used in the following setions. It onsists of a lient/server system in whih the server may be substituted by an alternative server omponent. This an be needed in ase of server failure, or simply for a hange in the lient s ontext or network onnetion that made unreahable the original server. We assume that none of the omponents have been designed with reonfiguration apabilities. The lient wants to buy books and magazines as shown in its behavioral interfae in Fig. 2(a). The two servers A and B have behavioral interfaes depited in Figs. 2() and 3(b) respetively. Server A an sell only one book; on the other hand, server B an sell any number of books and magazines, eventually disonneting. Initially, the lient is onneted to server A; we shall all this onfiguration A. The orrespondene between ations on the lient and the server is given by an adaptation ontrat AC C,A (see Fig. 2(b)). Under onfiguration A the lient is able to buy at most one book, but it is not allowed to buy magazines beause this is not supported by server A. The latter is impliitly defined in the adaptation ontrat (Fig. 2(b)) as there is no vetor allowing the lient to perform the ation buymagazine!. Finally, server A does not send the aknowledgement ak? (see v 4 in Fig. 2(b)) expeted by the lient; this must also be worked out by the adaptor. In an alternative onfiguration B the lient is onneted to server B whose protool is depited in Fig. 3(b). Similarly, the orrespondene between ations is given by AC C,B (see Fig. 3(a)). Under onfiguration B, the lient an buy a number of books and magazines. In Fig. 3(a), we see that vetor v 5 allows the lient to buy magazines. Moreover, server B sends a different aknowledgment for eah produt (see v 4 and v 6 in Fig. 3(a)). We shall study reonfiguration from A to B whih substitutes A by B. It is worth noting that A and B do not have the same behavioral interfaes. Not only B provides additional funtionality wrt. A, but also B does not have the same names for the ations (and potentially the ordering of ations may be different as well). For instane, v 1 of AC C,A (see Fig. 2(b)) says that the login! ation of the lient relates to user? of server A. On the other hand, this login! ation must be related to onnet? of server B (see v 1 of AC C,B in Fig. 3(a)). Following the methodology for behavioral adaptation presented in [11], adaptors LTS an be automatially generated for onfigurations A and B (see adaptors A C,A and A C,B in Fig. 4). This is done by the Compositor tool [16]. Based on the adaptation ontrats, Compositor automatially generates an adaptor for eah onfiguration. Eah adaptor is guaranteed by onstrution to orhestrate deadlok-free interations between the lient and the orresponding server, and also to fulfill the orrespondenes of ations desribed in the adaptation ontrat of eah onfiguration. 7

8 0 LOGIN! 1 PASSWD! 2 LOGOUT! BUYBOOK! BUYMAGAZINE! ACK? v 1 = C : login!, A : user? v 2 = C : passwd!, A : passwd? v 3 = C : buybook!, A : buy? v 4 = C : ak?, A : ɛ v 5 = C : logout!, A : disonnet? 4 3 (a) LTS of Client C (b) Adaptation Contrat AC C,A 0 USER? 1 PASSWD? 2 BUY? DISCONNECT? 3 DISCONNECT? 4 () LTS of Server A Figure 2: Configuration A. 4. Formal Model This setion provides the formal model that enables both reonfiguration and behavioral adaptation. We first define a onfiguration as a set of omponents interating by means of an adaptor, and then reonfiguration ontrats are introdued in order to determine how a system may evolve in terms of strutural hanges Configurations A system arhiteture onsists of a finite number of omponents. The arhiteture may present different onfigurations. Eah onfiguration onsists of a subset of these omponents onneted together by means of an adaptor. Definition 7. [Configuration]. A onfiguration of an arhiteture is a tuple P, AC, A P, where P = {p 1,..., p n } is a subset of the omponents of the arhiteture. Eah omponent p i P is represented by an LTS S i, s 0i, L i, i. AC 8

9 v 1 = C : login!, B : onnet? v 2 = C : passwd!, B : pwd? v 3 = C : buybook!, B : buybook? v 4 = C : ak?, B : bookok! v 5 = C : buymagazine!, B : buymagazine? v 6 = C : ak?, B : magazineok! v 7 = C : logout!, B : disonnet? (a) Adaptation Contrat AC C,B 0 CONNECT? 1 PWD? 2 DISCONNECT? BUYBOOK? BOOKOK! BUYMAGAZINE? MAGAZINEOK! (b) LTS of Server B Figure 3: Configuration B. is an adaptation ontrat for the omponents in P, A P = S A, s 0A, L A, A is an adaptor, generated from AC and P by means of Algorithms 1 or 3 in [11]. A onfiguration P, AC, A P is haraterized by an LTS = S, s 0, L, obtained by omputing the synhronous produt of all the omponents p i P and the adaptor A P, i.e., = A P p 1... p n. Let us now fous on the traes of suh a onfiguration. From Definition 4, the ations of are of the form (α AP, α 1,..., α n ), where α AP is an ation from the adaptor A P, and eah α i (i = 1,..., n) is an ation from L i { }. However, as the adaptor orhestrates the interation between the omponents in a onfiguration, and any ommuniation passes through it (we may reall that all the ation sets L i of the omponents are disjoint), eah ation of the onfiguration will onsist on a synhronization between the adaptor A P and exatly one of the omponents in P, i.e.,!α i (i = 1,..., n) suh that α i { } and α i = α AP. Hene, we will only pay attention to the (omplemented) ations of the adaptor for representing the traes of a onfiguration. Definition 8. [Traes of a onfiguration]. Let P, AC, A P be a onfiguration. Let = S, s 0, L, be the LTS haraterizing it. We define its traes Σ = {ɛ} {σ σ = α σ s.t. (s 0, (ᾱ,..., α,...), s ) and σ Σ }, where α stands for the omplementary ation of α (i.e., α? for α! and vie versa), and = S, s, L,. Given a onfiguration P, AC, A P, the LTS haraterizing it, and a trae 9

10 0 C:LOGIN? 1 A:USER! 2 C:PASSWD? 3 A:PASSWD! 4 C:BUYBOOK? 5 A:BUY! 6 C:LOGOUT? C:ACK! 7 C:LOGOUT? 8 A:DISCONNECT! f 0 C:LOGIN? 1 B:CONNECT! 2 6 B:BUYMAGAZINE! 9 C:PASSWD? B:MAGAZINEOK? C:BUYMAGAZINE? 3 10 B:PWD! C:ACK! 4 C:BUYBOOK? C:LOGOUT? 5 7 B:BUYBOOK! C:ACK! B:DISCONNECT! 8 12 B:BOOKOK? 11 (a) Adaptor A C,A (b) Adaptor A C,B Figure 4: Adaptors for onfigurations A and B. σ Σ, we an derive the ations performed in σ by eah of the omponents p P in the onfiguration. For that we have to projet σ over the ations of p. Definition 9. [Projetion]. Let σ be a trae of a ertain onfiguration. Let p = S, s 0, L, be a omponent in that onfiguration. The projetion of σ over p (denoted σ p ) is defined as: ɛ p = ɛ { α σ (α σ ) p = p if α L σ p if α L The definition of projetion an be extended to a set of traes {σ i } I. We write {σ i } I p for {σ i p } I. We will also need an operator over traes that hides the ations performed by a given omponent, leaving intat the rest of the ations in the trae. Definition 10. [Hiding]. Let σ be a trae of a ertain onfiguration. Let p = S, s 0, L, be a omponent in that onfiguration. The hiding of p in σ (denoted σ\ p ) is defined as: 10

11 ɛ\ p = ɛ { α σ (α σ )\ p = \ p if α L σ \ p if α L From the definitions of projetion and hiding above, some properties an be trivially inferred. In partiular, we will use the following in the sequel: (σ σ ) p = σ p σ p, (σ σ )\ p = σ\ p σ \ p, and if p p (and thus L p L p = ) then (σ\ p ) p = σ p. Finally, we will also make use of an operator for trae interleaving: Definition 11. [Trae Interleaving]. Let σ and σ be two traes. Their interleaving is defined as follows: {σ} if σ = ɛ σ σ {σ } if σ = ɛ = { σ 1 σ 1 = α (σ tail σ ) } { σ 2 σ 2 = α (σ σ tail ) } with σ = α σ tail and σ = α σ tail, otherwise Interleaving an be generalized to a set of traes {σ i } I. In that ase we write {σ i } I. Lemma 12. Let {p i = S i, s 0i, L i, i } P p i P be a set of LTS whose ations are disjoint (i.e., p i, p j P (p i p j ), L i L j = ). Let {σ pi } P p i P a set of traes suh that eah σ pi Σ pi. Then for any trae σ {σ pi } P p i P, we have that p i P, σ pi = σ pi. Proof. Sine p i, p j P (p i p j ), L i L j =, it an be easily derived from Definitions 9 and Reonfiguration ontrats Replaing a onfiguration by another one is what we all a reonfiguration. Reonfigurations are speified in a reonfiguration ontrat whih separates reonfiguration onerns from the business logi. Eah onfiguration an be thought of as a stati view of the arhiteture, while its dynami view is speified by a reonfiguration ontrat. Definition 13. [Reonfiguration Contrat]. Let C be the set of onfigurations of an arhiteture. Let { S i, s 0i, L i, i } C, i C be the set of LTS haraterizing the onfigurations in C. Let S = C S i. A reonfiguration ontrat R is a tuple C, 0, R where 0 C is the initial onfiguration, and R C S C S is a set of reonfiguration operations, where i :s i j :s j R implies i, j C, s i S i, and s j S j the states of the LTS haraterizing i and j respetively. A reonfiguration operation i :s i j :s j indiates that the arhiteture an be reonfigured from state s i in i whih is alled the soure reonfiguration state to state s j in j whih is alled the target reonfiguration state. 11

12 Reonfiguration an take plae in the middle of the exeution of a onfiguration, and the new onfiguration may use a different adaptation ontrat. This allows the replaement of a omponent by another one that implements a different behavioral interfae. The soure reonfiguration state s i defines when a onfiguration i an be reonfigured. On the other hand, the target reonfiguration state s j indiates the starting state in the target onfiguration j to resume the exeution. We will assume for the time being, that soure and target reonfiguration states are known. In Setion 5, we show how they an be obtained. Example. In our running example, there are two onfigurations, A and B, where A = {C, A}, AC C,A, A C,A and B = {C, B}, AC C,B, A C,B. The reonfiguration ontrat R = { A, B }, A, R must indiate the reonfiguration states in whih reonfiguration an be performed. However, as the servers A and B have different behavioral interfaes, it is not straight-forward to determine how reonfiguration an take plae after the interation between the lient C and the server A has started. Therefore, the simplest reonfiguration senario from A to B is defined at the initial states of the lient and the server A. This is speified as a unique reonfiguration operation (A C,A : s 0, C : s 0, A : s 0 ) (A C,B : s 0, C : s 0, B : s 0 ). In Setion 5 we will study how other pairs of reonfiguration states apart from the initial state here an be obtained. 5. Contrat-Aware Reonfiguration In the preeding setion, we have shown that systems an be reonfigured at the initial stage of their exeution. Nevertheless, there are more interesting senarios in whih reonfiguration an take plae. In this Setion, we will introdue several notions of reonfiguration ompliane, and prove some of their properties of interest. We will also show how to determine the reonfiguration states, and the ations that must be performed for ahieving reonfiguration. To that purpose, Setion 5.1 defines a notion of ompliane that determines whether it is possible to reonfigure an arhiteture at an arbitrary stage paying attention to the interations that took plae in the system prior to reonfiguration. Setion 5.2 explores how to define a reonfiguration ompliane that is aware of future ations in the soure onfiguration. Setion 5.3 presents the less restritive notion of property-ompliant reonfiguration, whih allows fine-grained ontrol over the speifiation of the behavior that the arhiteture must preserve after reonfiguration, speified using temporal logi. Setion 5.4 ombines both history and future-aware reonfiguration, resulting in a definition of the onditions for one-way reonfigurability, from the soure to the target onfiguration. Finally, Setion 5.5 studies how to design a fully reonfigurable system arhiteture in whih reonfiguration an take plae bak and forth between different onfigurations. 12

13 5.1. History-Aware Reonfiguration First, we define the onditions for performing reonfiguration being aware of the previous history of the arhiteture. We all it history-aware reonfiguration. Let = P, AC, A and = P, AC, A be two onfigurations of a given arhiteture. Suppose that and differ in that a ertain omponent p i P is replaed by a omponent p j P (and thus the adaptor A generated from AC for onfiguration is replaed by A generated from AC for ). Assume that the arhiteture is urrently under onfiguration and that the trae performed so far is σ. Let us onsider a omponent p suh that p P P, i.e., p p i, p p j. This omponent p is not diretly affeted by the reonfiguration from to, sine it remains in. Thus, p should not be obliged to abort nor to rollbak its urrent exeution, represented by σ p, so it an keep on running unaware of the reonfiguration. Therefore, for history-aware reonfiguration we have to ensure that for eah omponent p in both the soure and the target onfigurations, the exeution trae σ p already performed by p under onfiguration is also ontained in the traes of. Let us formalize this notion of history-aware reonfiguration with the following definition. Definition 14. [History Compliane]. Let σ Σ be a trae exeuted under a ertain onfiguration = P, AC, A. Let = P, AC, A be a onfiguration suh that p i P p j P, p i p j and P \{p i } = P \{p j }, in whih a omponent p i in has been replaed by another omponent p j in. Configuration is history-ompliant to onfiguration given σ (written σ ) iff there exists σ Σ suh that p P P we have that σ p = σ p. Based on Definition 14, we will define history-aware reonfiguration operations in the reonfiguration ontrat of the arhiteture as follows. For eah σ Σ suh that σ, assume that σ Σ is the trae whose existene Definition 14 refers to. Let s be the state of onfiguration after performing σ, and s the state of onfiguration after performing σ. Then, we add :s :s to the reonfiguration ontrat of the arhiteture, allowing it to reonfigure from the state s in the onfiguration to s in. The following theorem proves that after performing a history-aware reonfiguration operation from to all omponents p present in both onfigurations remain in the same state. Hene, they need not to abort nor to rollbak their urrent traes σ p, and they do not require initialization in. Instead, they are able to go on working unaware of the reonfiguration, and their previous ations are ontained in the new exeution trae σ. Theorem 15. Let and be two onfigurations of a given arhiteture, and let σ Σ suh that σ. Let σ Σ be a trae under the onditions of Definition 14. Let s = (s A, s 1,..., s i,..., s n ) and s = (s A, s 1,..., s j,..., s n) be the states of the LTS haraterizing and after performing σ and σ respetively. Then, k s.t. p k P P, we have s k = s k. 13

14 Proof. It is trivial, sine Definition 14 requires that p k P P σ pk = σ pk. As a result of Theorem 15, for performing the reonfiguration, we only need to initialize the new omponent p j and the adaptor A in, in order to make them arrive to states s A and s j, respetively. For initializing the adaptor A, as the traes of a onfiguration are the omplement of those of its adaptor (see Definition 8), we only need to feed A with σ. On the other hand, as the ations of the omponents of a onfiguration are disjoint, σ pj gives us the trae for initializing p j. Definition 14 above establishes the onditions for a new onfiguration being aware of the previous history of the arhiteture. However, it does not give us the trae σ that must be used for initializing the new onfiguration. Finding that trae is the purpose of the following theorem: Theorem 16. Let and be two onfigurations of a given arhiteture as desribed in Definition 14. Let σ Σ, and let σ be a trae suh that: ˆ p P P, σ p and σ are disjoint, and ˆ ( p P P {σ p } {σ} ) Σ then σ and σ Σ pj. Proof. From the seond ondition of the theorem, let us onsider a trae σ suh that σ Σ and σ ( p P P {σ p } {σ} ). Sine all the omponents in P have disjoint ation sets, and also σ and all the σ p are disjoint (by the first ondition), then for all p P P from Lemma 12 we have that σ p = σ p. Hene, σ. Finally, as σ Σ and p j is the only omponent in P whih is not in P P, again from Lemma 12 we have that σ pj = σ and σ Σ pj. Theorem 16 gives us a way to ompute the trae σ that fulfills the onditions of Definition 14 and the trae σ required for initializing the omponent p j. Algorithm 1 below builds the initialization traes pair (σ, σ ) for the omponent p j and the adaptor A inrementally. At eah step, the algorithm tries to make the system advane with elements from the traes in Σ (initially {σ p } p P P ). If this is not possible, it heks if an ation in L pj an make the system advane. If there is only a single ation meeting the ondition, the algorithm extends the initialization traes with it and goes to the next iteration. If more than one ation meet the ondition, the algorithm tries to build reursively the potential remaining parts of the initialization traes, (σ, σ ), starting from the urrent state of the adaptor (urrent), and the traes urrently in Σ. If no initialization traes are found, the algorithm returns (ɛ, ɛ). The Algorithm stops when all traes in Σ are empty (suess), or the system annot further advane with elements of Σ or L pj. Initial all to the algorithm is made as h traes(p j, A, {σ p } p P P, s 0A ). It is worth mentioning that 14

15 the initialization traes pair (σ, σ ) may be not unique. In that ase, the stop ondition of the algorithm guarantees that one of them will be returned. Algorithm 1 h traes Computes initialization traes σ and σ for p j P and A, respetively. inputs Component p j = S pj, s 0pj, L pj, pj, Adaptor A = S, s A 0, L A A, A, Traes Σ, urrent state for adaptor urrent output Traes σ, σ 1: (σ, σ ) := (ɛ, ɛ) 2: while σ k Σ : σ k ɛ do 3: if σ l = {p l : α 0 p l : α 1... p l : α n } Σ : (urrent, α 0, s ) A then 4: σ := σ {p l : α 0 } 5: urrent := s 6: σ l := {p l : α 1... p l : α n } 7: else 8: L = {α L pj (urrent, α, s ) } A 9: if L = 1 then 10: σ := σ {p j : α} 11: σ := σ {p j : α} 12: urrent := s 13: else if ( L > 1) ( (σ, σ ) = h traes(p j, A, Σ, urrent) : (σ, σ ) (ɛ, ɛ)) then 14: return (σ σ, σ σ ) 15: else 16: return (ɛ, ɛ) 17: end if 18: end if 19: end while 20: return (σ, σ ) One we have found σ and σ, for performing the reonfiguration from to, we will initialize A and p j with σ and σ respetively, while the rest of the omponents p P P in the onfiguration remain in their urrent states (i.e., eah of them having performed the trae σ p under onfiguration ). This way we have reonfigured the arhiteture from to being aware of its previous history. Example. In the running example, it is easy to find out situations for whih onfiguration B is history-ompliant to 1 A. For instane, let us suppose a senario where a lient onnets to server A, logs in, and before disonneting, A needs to be substituted by B. Unfortunately, A and B do not provide suh reonfiguration apabilities and it is not possible to diretly replae one by another without adaptation beause they have different behavioral interfaes. Let us suppose that the trae performed so far under onfiguration A is: σ A = < :login! a:user? :passwd! a:passwd? > Hene, the trae performed by the lient C is: σ A C = < :login! :passwd! > 1 In fat, it an be found that B σ A for any trae σ of onfiguration A. 15

16 In order to keep the lient unaware of the reonfiguration, it must not abort its ongoing exeution. Only if the trae σ A C is valid in the new onfiguration B, C ould ontinue its exeution as if it has been interating with B from the very beginning. Using Algorithm 1, from B, σ A C and the adaptor A C,B we an obtain a trae σ B that makes B σa A : σ B = < :login! b:onnet? :passwd! > Hene, onfiguration B is history-ompliant to onfiguration A given the trae σ A. This allows us to define a history-aware reonfiguration operation from the state s A = (A C,A : s 4, C : s 2, A : s 2 ) in A to the state s B = (A C,B : s 3, C :s 2, B :s 1 ) in B, where state numbers refer to Figs. 2, 3, and 4. The trae σ B indiates the initialization required for the adaptor A C,B in the target onfiguration B. With respet to the server B, it must be initialized using the trae σ B B : σ B B = < b:onnet! > After these initializations all the omponents in the target onfiguration B are ready to resume working as if reonfiguration had never taken plae. While the lient was kept logged in, the original server A has been substituted at runtime by another omponent B with a different behavioral interfae. This example shows how the lient may initially log to server A, and after a reonfiguration to B it is logged to server B, where differently from onfiguration A it would be able to buy several books and magazines. On the ontrary, A is not history-ompliant to B given an arbitrary trae σ B. Consider the ase that the lient has bought a magazine (it will be the same for several books) under onfiguration B, as for instane: σ B C = < :login! :passwd! :buymagazine! > this trae annot be performed under onfiguration A beause A only does not allow exeution traes in whih magazines are sold. In this ase, Algorithm 1 would provide no results. Still, A is history-ompliant to B for traes that do not inlude buying magazines nor more than one book, suh as for instane: σ B = < :login! b:onnet? :passwd! b:pwd? :buybook! > as its projetion over the lient C : σ B C = < :login! :passwd! :buybook! > is a trae that an be performed by the lient under onfiguration A. We shall explore this senario of reonfiguration bak from B to A in Setion 5.5. History ompliane requires that the history of the arhiteture remains unhanged. In suh a way, the omponents not diretly involved in a reonfiguration are able to ontinue working on from their urrent states, even if the reonfiguration was aused by a failure in the omponent being replaed. However, history ompliane says nothing about future ations. Therefore, it may be possible to provide more (or less) funtionality in the target onfiguration. The next setion deals with the future behavior of an arhiteture after reonfiguration. 16

17 5.2. Future-aware reonfiguration In the preeding setion, we have studied reonfigurations whih are aware of past ations in the arhiteture. Now, we will explore how to define a notion of ompliane that takes into aount future ations in the soure onfiguration. We all this future-aware reonfiguration. Suppose that = P, AP, A and = P, AP, A are two onfigurations of a given arhiteture. Suppose that the differene between and is that omponent p i P is replaed by omponent p j P. Assume that the trae performed so far under onfiguration is σ. Let us onsider again a omponent p P P (i.e., any of the omponents whih are not diretly affeted by the reonfiguration). Differently from historyaware onfiguration above, we shall fous now on the future ations of these omponents that an be performed in both onfigurations. In order to determine if is future-ompliant with we shall hek if any possible trae of that ontinues σ is also possible under onfiguration (onveniently hiding the ations performed by the omponents p i and p j, whih are not in both onfigurations). This requirement would ensure that any omponent p P P mentioned above ould go on interating under onfiguration as it would have done under onfiguration. Let us formalize this notion of future-aware reonfiguration by the definition of future-ompliane below. Definition 17. [Future Compliane]. Let σ Σ be a trae exeuted under a ertain onfiguration = P, AP, A. Let = P, AP, A be a onfiguration suh that p i P p j P, p i p j and P \{p i } = P \{p j }, in whih a omponent p i in has been replaed by another omponent p j in. Configuration is future-ompliant to onfiguration given σ (written σ ) iff there exists σ Σ suh that σ. σ σ Σ, σ. σ σ Σ and σ\ pi = σ \ p j. Based on Definition 17, we will define future-aware reonfiguration operations in the reonfiguration ontrat of the arhiteture as follows. For eah σ Σ suh that σ, assume that σ Σ is the trae whose existene Definition 17 refers to. Let s be the state of onfiguration after performing σ, and s the state of onfiguration after performing σ. Then, we add :s :s to the reonfiguration ontrat of the arhiteture, allowing it to reonfigure from the state s in the onfiguration to s in. Future ompliane ensures ertain interesting properties in the arhiteture. In partiular, that after the point of reonfiguration, the behavior in the onfiguration of the omponents p P P not diretly affeted by the reonfiguration an be simulated by the new onfiguration, as shown by the following theorem: Theorem 18. Let and be two onfigurations of a given arhiteture, and let σ Σ suh that σ. Let σ Σ be a trae under the onditions of Definition 17. Then, p P P and σ s.t. σ σ Σ we have that (σ σ ) p Σ p. 17

18 Proof. From Definition 17 we have that σ s.t. σ σ Σ σ s.t. σ σ Σ. In partiular, if we projet the trae σ σ over any omponent p P P, and attending to Definition 9, we have that (σ σ ) p= σ p σ p Σ p ( ). On the other hand, from Definition 17, we also have that for σ and σ, σ \ pi = σ \ p j. Projeting again over all p P P, we have that (σ\ pi ) p = (σ \ p j ) p, and as p p j and p p i, from Definitions 9 and 10, we have that σ p = σ p. Hene, realling (*) we have that σ p σ p Σ p, and thus (σ σ) p Σ p. From Theorem 18, all the omponents p P P will not require to rollbak nor to ompensate the interations performed so far under onfiguration, and in fat they an ontinue working on as if they still were under onfiguration, although the arhiteture has been reonfigured and the adaptation ontrat has hanged from AC to AC. Similarly as we have done in Setion 5.1, for the new omponents in the target onfiguration, the adaptor A P must be initialized using the trae σ, while p j must be initialized using σ pj. Future ompliane defines the onditions for performing a reonfiguration ensuring that the future behavior of the omponents remaining in the target onfiguration is not affeted by the reonfiguration: they an ontinue working as if reonfiguration had never taken plae. However, the past ations in (represented by the trae σ ) may be ompletely different from those in (represented by σ ), and in fat it may happen that some of the past ations in the soure onfiguration are not available in the target, whih prevents us from finding a straightforward algorithm for omputing the required trae σ as we have done in Algorithm 1 for history-aware reonfiguration. Instead, we should explore all the states in onfiguration in order to find out if any of them satisfies the onditions of Definition 17. However, this limitation of future ompliane will be overome in Setion 5.4, where we introdue one-way reonfiguration. Example. Coming bak to our running example, it is again easy to find out situations in whih reonfiguration is future-ompliant. For instane, let us suppose a senario where a lient is initially onneted to server A, where it has aomplished the login phase. We will assume that the trae exeuted so far under onfiguration A is: σ A = < :login! a:user? :passwd! a:passwd? > Hene, hiding in σ A the server A being replaed, we have: σ A \ A = σ A C = < :login! :passwd! > Suppose that at this point, we need to hange from onfiguration A to onfiguration B and that we would like to ensure future ompliane in the reonfiguration. In order to do that, we need to find a trae σ B of the target onfiguration suh that the onditions of Definition 17 onerning possible future traes under onfiguration A are fulfilled. Sine the behavior of server A is rather restritive, these traes are basially: σ 1 A = < :buybook! a:buy? :ak? :logout! a:disonnet? > and 18

19 σ 2 A = < :logout! a:disonnet? > representing the senarios in whih the lient buys a book then disonnets (σ 1 A ), or diretly disonnets (σ 2 A ). In both traes we hide the server A, obtaining the behavior of the lient C, whih is the only omponent in ommon in both onfigurations. and σ 1 A \ A = σ 1 A C = < :buybook! :ak? :logout! > σ 2 A \ A = σ 2 A C = < :logout! > Now we have to find a trae σ B that makes onfiguration B arrive to a point in whih both σ 1 A \ A and σ 2 A \ A are possible under this reonfiguration. It is not diffiult to find out that for instane: σ B = < :login! b:onnet? :passwd! > may be suh a trae. Hene, onfiguration B is future-ompliant to onfiguration A given σ A ( B σa A ). This allows us to define a future-aware reonfiguration operation from the state s A = (A C,A : s 4, C : s 2, A : s 2 ) in A to s B = (A C,B : s 3, C : s 2, B : s 1 ) in B, where state numbers refer to Figs. 2, 3, and 4. Thus, the adaptor A C,B in the target onfiguration B has to be initialized with the trae: σ B = < :login? b:onnet! :passwd? > and the new server B in the target is initialized with: σ B B = σ A \ A = < b:onnet? > Notie that one both omponents are initialized as indiated, the following ation in B will be b:pwd?, representing that the password is sent from the adaptor A C,B to the server B. Then, the lient C will go on interating with the server B (through the adaptor A C,B ) by any of the traes σ 1 A B or σ 2 A B, as it still was under onfiguration A. Hene, the reonfiguration from A to B an be done keeping the lient C unaware of it. Future ompliane defines the basi requirements for omponent replaement without affeting the future behavior of the rest of the omponents in a onfiguration. The omponents remaining in the target onfiguration will not be aware of the replaement as the new omponent provides at least the same behavior that the one being replaed. However, it may be diffiult to find a replaement omponent that ensures future ompliane. For this reason, the next setion will explore more relaxed notions of ompliane, suitable for senarios in whih it is only required that ertain properties hold after reonfiguration Property-aware Reonfiguration The notion of future-ompliane introdued in the preeding setion may be too restritive in some situations, espeially in senarios where a omponent is substituted by another one with a more restrited funtionality. In these ases, preserving part of the soure onfiguration behavior (represented by a ertain property φ) may suffie for the operation of the system. To deal with these situations we present in this setion the notion of property-aware reonfiguration, whih allows a finer-grained ontrol over the speifiation of the behavior 19

20 that the arhiteture must preserve after reonfiguration. Namely, we introdue two different notions of property-aware reonfiguration: (i) existential property ompliane, whih requires the existene of traes under the target onfiguration preserving a ertain property; and (ii) universal property ompliane, in whih a global property must be satisfied by every possible trae one reonfiguration takes plae. Properties are expressed as next-free LTL formulas over ations in exeution traes, i.e., atomi propositions orrespond to ations and therefore we assume that the exeution of an ation α! is synonymous to the atomi proposition α! in a temporal logi formula. Hene, given a finite set of atomi propositions P, formulas are onstruted indutively as: (i) Every φ P is a formula; (ii) given the formulas φ and ψ: φ ψ, φ ψ, φ ψ, and φ are also formulas; and (iii) given the formulas φ and ψ: φu ψ is also a formula. The following abbreviations are used: Eventually ( φ = TRUE U φ) and Always ( φ = φ). An interpretation of an LTL formula is an infinite word w = x 0 x 1... x n over 2 P, where at some time point i N a proposition φ is true iff φ x i. We express as w i the suffix of w starting at i. The semantis of next-free LTL is defined as: Propositions For φ P, w = φ iff φ x 0. Boolean operators Given the formulas φ and ψ: ˆ w = φ iff not w = φ ˆ w = φ ψ iff w = φ and w = ψ ˆ w = φ ψ iff w = φ or w = ψ ˆ w = φ ψ iff not (w = φ and not w = ψ) Temporal operators w = φu ψ iff there exists i N suh that w i = ψ and for all 0 j < i, w j = φ. We now define existential property ompliane as follows: Definition 19. [Existential Property Compliane]. Let σ Σ be a trae exeuted under a ertain onfiguration = P, AP, A. Let = P, AP, A be a onfiguration suh that p i P p j P, p i p j and P\{p i } = P \{p j }, in whih a omponent p i in has been replaed by another omponent p j in. Let φ be a next-free LTL formula built on ations of omponents from P P. Configuration is existentially-property-ompliant with respet to onfiguration given σ, and φ (written σ,φ ) iff: 1. σ s.t. σ σ Σ and σ σ = φ 2. σ, σ s.t. σ σ Σ and σ σ = φ Existential property ompliane requires first that φ holds at least for a maximal trae (prefixed by σ ) under the soure onfiguration, and then that there exists at least one maximal trae in the target onfiguration suh that 20

21 φ holds for the ombined trae performed before and after the reonfiguration (σ σ ). Note that the stated property φ refers only to ations of the omponents in ommon. In fat, if φ depended on ations from p i or p j, in general it may not hold either before or after reonfiguration, sine p i and p j are not present in both the soure and the target onfigurations. As we have mentioned, existential property ompliane relaxes the onditions of future ompliane, sine it only requires that a ertain property is satisfied after reonfiguration (instead or requiring that any possible ontinuation trae is also possible in the target onfiguration). The following theorem formalizes this intuition. Theorem 20. Let and be two onfigurations of a given arhiteture, and let σ Σ. If σ s.t. σ σ Σ and σ σ = φ, then σ = σ,φ. Proof. We have that σ s.t. σ σ Σ and σ σ = φ. As as φ is not built on ations from p i, we have that σ σ\ pi = φ. On the other hand, from σ we have that σ Σ suh that σ s.t. σ σ Σ σ s.t. σ σ Σ and σ \ pi = σ \ p j. Thus, σ σ \ p j = φ. Finally, as φ is not built on ations from p j, σ σ = φ. Hene, σ.,φ Let us now onsider a universally quantified version of property ompliane. It is defined as follows: Definition 21. [Universal Property Compliane]. Let σ Σ be a trae exeuted under a ertain onfiguration = P, AP, A. Let = P, AP, A be a onfiguration suh that p i P p j P, p i p j and P\{p i } = P \{p j }, in whih a omponent p i in has been replaed by another omponent p j in. Let φ be a next-free LTL formula built on ations of omponents from P P. Configuration is universally-property-ompliant with respet to onfiguration given σ, and φ (written σ,φ ) iff: 1. σ s.t. σ σ Σ, we have that σ σ = φ 2. σ Σ suh that σ s.t. σ σ Σ, we have that σ σ = φ Universal property ompliane firstly requires that φ holds for all maximal traes whih ontinue from the urrent state of exeution in the soure onfiguration. Seondly, it also requires that there exists a trae σ under onfiguration suh that φ holds for all traes that ombine the exeution trae σ already performed under onfiguration with any possible maximal ontinuation trae σ under onfiguration. Based on Definition 19 and 21, and given a ertain property φ we want a trae or all the traes in the arhiteture to satisfy, we will define property-aware reonfiguration operations in the reonfiguration ontrat of the arhiteture as follows. For eah σ Σ suh that σ, or,φ σ,φ, assume that σ Σ is the trae whose existene Definitions 19 or 21 refer to. Let s be the state of onfiguration after performing σ, and s the state of onfiguration 21