Spécification modulaire

montre la structure de la spécification modulaire.

7.2.1.2 Décomposition

La compilation du modèle décrit à la figure 7.4 produit une hiérarchie de contrôleurs :Ctrlr_M1,Ctrlr_M2etCtrlr_M3. A l’exécution centralisée, le contrôleur principalCtrlr_M3instancie les contrôleursCtrlr_M2. Chaque contrôleurCtrlr_M2

instancie un contrôleurCtrlr_M1.

Repair

Apache

Repair Sizing

Tomcat repl. tier

Repair

Proxy

Repair Sizing

MySQL repl. tier

Ctrlr_M1 CtrlrM2 Ctrlr_M1 CtrlrM2 Ctrlr_M3 (o₁,na₁,u₁, ...,f L₂,f₂,o₂,na₂)

(repL₁,rep₁,add₁,rem₁) (repL₂,rep₂,add₂,rem₂) s

(c, ...)

s⁰ (c⁰, ...)

7.2. EXEMPLE: GESTION D’UNE APPLICATION MULTI-TIERS

Ici, nous décomposons le code en trois parties à exécuter sur des machines différentes comme le montre la figure 7.5. Les contrôleursCtrlr_M1sont locaux aux contrôleurs Ctrlr_M2. Sur cet exemple, l’exécution distribuée obtenue est totalement synchronisée. En effet toutes les entrées sont reçues par le contrôleur

Ctrlr_M3. Ce dernier, distribue les entrées reçues aux autres contrôleurs avec

ses restrictions pour respecter son contrat. Une fois qu’il a calculé les valeurs de contrôle, il appelle la méthode step des contrôleurs Ctrlr_M2 distants. Ces derniers vont, eux aussi, appliquer des restrictions pour atteindre leurs objectifs. L’appel des méthodesstepest bloquant et totalement synchronisé.

7.2.2 Exécution distribuée partiellement synchronisée

Pour obtenir une exécution distribuée partiellement synchronisée, il faut dis-tinguer les entrées nécessaires au contrôleur principalCtrlr_M3pour réaliser son contrôle. Cela permet de ne transmettre à ce dernier que les entrées dont il a be-soin. Les autres entrées seront directement transmises aux contrôleursCtrlr_M2. De manière générale, il faut distinguer pour chaque entrée, le contrôleur de haut niveau qui doit la traiter en premier.

7.2.2.1 Modélisation

Pour une exécution partiellement synchronisée, les entrées qui ne sont pas nécessaires au contrôleur de haut niveau, par exempleCtrlr_M3, sont directe-ment transmises aux contrôleurs qui les traitent, par exempleCtrlr_M2. Toutefois les contrats associés aux contrôleurs ne changent pas. Le code obtenu de la spécification décrite à la figure 7.4 peut être adapté pour une exécution dis-tribuée partiellement synchronisée. Une approche est d’affecter une valeur par défaut aux entrées que le contrôle principal ne traitent pas lors de l’appel de sa méthode step. Les vraies valeurs de ces entrées seront transmises aux contrôleursCtrlr_M2qui les traitent.

Une autre approche est de modifier la spécification des contrôleurs pour n’avoir que les entrées de contrôle comme arguments de leur méthode step. Les autres entrées sont récupérées dans la méthode step via des appels de fonctions externes. Le langageHeptagon/BZR, tout comme les autres langages synchrones, permet d’appeler des fonctions externes dans la définition d’un

automate. Pour utiliser les fonctions externes, nous définissons un module qui fournit les signatures de ces dernières. Dans la suite, nous utilisons le terme

«System» comme nom du module.

Tier dupliqué.

(. . .) =coord_repl_tier(cr⁰, ca⁰, crm⁰) enforce(not(repairingandadd))

and LongActions(cr⁰,rep,repairing) and LongActions(ca⁰,add,adding) and(crm⁰or notrem)

withcr, ca, crm fail= System.failure(); nr =System.repaired(); o =System.overload(); na =System.added(); u =System.underload();

(rep, repairing) =self_repair(cr, fail, nr);

(add, rem, adding) =self_sizing (ca, crm, o, u, na);

FIGURE7.6– Tier dupliqué

La figure 7.6 correspond au modèle de coordination d’un gestionnaire self-sizing et un gestionnaire self-repair pour un tier dupliqué. Ici les événements en entrée sont récupérées via les fonctions externes «System.*». Ces dernières sont implémentées en dehors du modèle. Chaque fonction externe retourne

unbooléenqui correspond à la valeur courante de l’événement qu’elle traite.

Par exempleSystem.overloadretournevrailorsqu’une sur-charge est détectée, sinon elle retournefaux. Cependant ce modèle expose les entrées de contrôle qui permettent sa réutilisation et d’inhiber les actions des gestionnaires.

Tier dupliqué avec aiguilleur de charge en frontal.

La figure 7.7 correspond au modèle de coordination de deux gestionnaires self-repair et un gestionnaire self-sizing pour un tier dupliqué avec un aiguilleur en frontal. Le modèle dans la figure 7.6 est réutilisé pour la construction de la hiérarchie. Toutefois, ici toutes les entrées ne sont pas transmises au modèle dans la figure 7.7.

7.2. EXEMPLE: GESTION D’UNE APPLICATION MULTI-TIERS (. . .) =coord_lb_repl_tier(cL⁰, c⁰, ca⁰, crm⁰)

enforce(not(repairingLand_rem))

and LongActions(cL⁰,repL,repairingL) and LongActions(c⁰,rep,repairing) and LongActions(ca⁰,add,adding) and(crm⁰ or not_rem)

withcL, c, ca, crm

failL= System.failureLb();

nrL= System.repairedLb();

(repL, repairingL) =self_repair(cL, failL, nrL);

FIGURE7.7– Tier dupliqué avec aiguilleur en frontal

Multi-tiers.

(. . .) =coord_multitier(cL⁰₁, c₁⁰, ca⁰₁, crm₁⁰, cL₂⁰, c⁰₂, ca⁰₂, crm⁰₂)

enforce(not((repairingL₁ orrepairing₁)andrem₂))

and LongActions(cL⁰_i,repL_i,repairingL_i)

and LongActions(c⁰_i,rep_i,repairing_i)

and LongActions(ca⁰_i,add_i,adding_i)

and(crm⁰_ior notrem_i)

i=1, 2

withcL₁, c₁, ca₁, crm₁, cL₂, c₂, ca₂, crm₂

(repL₁, repairingL₁, rep₁, repairing₁, add₁, rem₁, adding₁) =coord_lb_repl_tier(cL₁, c₁, ca₁, crm₁);

(repL₂, repairingL₂, rep₂, repairing₂, add₂, rem₂, adding₂) =coord_lb_repl_tier(cL₂, c₂, ca₂, crm₂);

FIGURE7.8– Multi-tiers

La figure 7.8 correspond au modèle de coordination de l’application multi-tiers. Ce dernier modèle ne reçoit aucun événement. Ses objectifs de contrôle sont définis sur les sorties des contrôleurs sous-jacents.

Dans cet exemple, seules les entrées de contrôle et les sorties sont utilisées pour exprimer les objectifs. De ce fait, toutes les autres entrées peuvent être récupérées via des appels de fonctions dans les méthodes step. Cependant, lorsque ces dernières sont utiles dans la déclaration des objectifs, il est nécessaire qu’elles soient reçues comme entrées de la méthodesteppour pouvoir appliquer

la synthèse de contrôleur.

Dans tous les cas, il faut distinguer les entrées qui nécessitent l’appel de la méthode step, ici, du contrôleur Ctrlr_M3. Dans cet exemple, ces entrées sont : failL₁ (panne Apache),nrL₁ (Apache réparé), failL₁ (panne Tomcat),

nr₁(Tomcatréparé),u₂(sous-chargeMysql).

7.2.2.2 Décomposition

La compilation donne la même hiérarchie de contrôleurs que celle obtenue avec la coordination totalement synchronisée. Chacun des contrôleurs assure le respect des mêmes objectifs que son vis-à-vis dans la coordination totalement synchronisée.

Repair

Apache

Repair Sizing

Tomcat repl. tier

Repair

Proxy

Repair Sizing

MySQL repl. tier

Ctrlr_M1 Ctrlr_M2 Ctrlr_M1 Ctrlr_M2 Ctrlr_M3 (f L1,nrL1,f1,nr1,u2)

(o₁,na₁,u₁) (repL₁,rep₁,add₁,rem₁) (f L2,nrL2,f2,nr2,o2,na2) (repL2,rep2,add2,rem2) s

(c, ...)

s⁰ (c⁰,u₂)

FIGURE7.9– Exécution distribuée partiellement synchronisée

Cependant, comme le montre la figure 7.9, le contrôleur principalCtrlr_M3et les deuxCtrlr_M2reçoivent, chacun, une partie des entrées. De ce fait, lesstep sont partiellement synchronisés. Le contrôleurCtrlr_M3n’initie la synchronisa-tion que pour le respect de l’objectif global. Les entrées qui ne concernent pas le contrat du contrôleurCtrlr_M3sont transmises directement aux contrôleurs

Ctrlr_M2 qui les traitent. Chaque contrôleur Ctrlr_M2 évolue à son propre

7.2. EXEMPLE: GESTION D’UNE APPLICATION MULTI-TIERS

contrôleurCtrlr_M3. Ces entrées (failL₁,nrL₁,fail₁,nr₁,u₂) sont transmises au contrôleurCtrlr_M3 qui calcule ses valeurs de contrôle. Ensuite, il appelle les méthodesstep des contrôleurs Ctrlr_M2, avec ses valeurs de contrôle. Ces derniers conservent les valeurs de contrôle reçues du contrôleur principal jusqu’à la prochaine synchronisation.

7.2.3 Exécution distribuée désynchronisée

Pour l’exécution distribuée désynchronisée, le contrat qui est défini dans le modèle global est assuré par les contrôleursCtrlr_M2. Dans la coordination modulaire synchronisée, ce contrat est assuré par le contrôleurCtrlr_M3.

7.2.3.1 Modélisation

Repair

Apache

Repair Sizing

Tomcat repl. tier Ctrlr_M1 Ctrlr_M2

Repair

Proxy

Repair Sizing

MySQL repl. tier Ctrlr_M1 Ctrlr_M2

Communication

Veri f ication(model−checking)