Analyse de la migration conform´ ement aux patterns

Nous analysons ci-apr`es l’impact de l’application des diff´erentes strat´egies de mi- gration du tableau 6.2 sur les instances actives du protocole.

• Nous illustrons tout d’abord une utilisation simple du pattern PM4 dont la sp´ecification g´en´erique est rappel´ee ci-dessous :

(δe, qs)

Reduc ((δ,qs),(β,q0t),α)

CHAPITRE 6. FORMALISATION DES PATTERNS DE MIGRATION

La strat´egie 1 (i.e., ligne Num Strat´egie=1 du tableau 6.2) permet d’instancier ce pattern avec les valeurs des param`etres donn´ees dans la colonne 2 du mˆeme tableau. Cette strat´egie a pour effet de transf´erer toutes les instances qui ont atteint l’´etat Car- ri`ere Reconstitu´ee de l’ancien protocole, en suivant le chemin d’ex´ecution δ=ID.VI.CC jusqu’`a l’´etat Carri`ere Reconstitu´ee. Le chemin d’ex´ecution t´emoin dans le nouveau protocole est donn´e par : β=ID.VI (i.e., suppression de l’activit´e initiale CC, activit´e qui n’existe plus dans le nouveau protocole). Cependant, on peut observer que la stra- t´egie 1 ne permet pas de transf´erer toutes les instances qui se trouvent `a l’´etat Carri`ere Reconstitu´ee de l’ancien protocole. En effet, les instances qui sont dans cet ´etat et qui ont ex´ecut´e une ou plusieurs fois l’activit´e CIC ne seront pas pr´e-s´electionn´ees par la pr´e-condition de la strat´egie 1.

• La strat´egie 2 (ligne Num Strat´egie=2 du tableau 6.2) est plus g´en´erique que la strat´egie 1, dans la mesure ou elle exploite l’op´erateur de Kleene ”∗” pour d´eplacer toutes les instances qui se trouvent `a l’´etat Carri`ere Reconstitu´ee de l’ancien protocole vers l’´etat de mˆeme nom dans le nouveau protocole. Le transfert est op´er´e, tout en supprimant des anciens chemins d’ex´ecution respectifs l’activit´e CC. Par exemple, un historique d’ex´ecution ID.VI.CC.CIC.CIC de l’ancien protocole aura comme chemin d’ex´ecution t´emoin ID.VI.CIC.CIC dans le nouveau protocole.

• La strat´egie 3 (ligne Num Strat´egie=3 du tableau 6.2), dont la sp´ecification est donn´ee ci-dessous, combine les patterns PM4 et PM5 `a l’aide de l’op´erateur de disjonction.

(δe, qs)

Reduc ((δ,qs),(β,q0t),α) ∨ Extend ((δ,qs),(β,qt0),α0)

−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (βe, q0t)

L’instanciation des param`etres de la strat´egie 3 est donn´ee dans le tableau 6.2. Cette strat´egie permet de faire migrer toutes les instances qui se trouvent `a l’´etat Rejet de l’ancien protocole vers l’´etat de mˆeme nom du nouveau protocole. Deux types de chemins d’ex´ecutions t´emoins sont g´en´er´es en fonction des chemins suivis par les ins- tances pour atteindre l’´etat Rejet de l’ancien protocole. En effet, les instances ayant pass´e par l’´etat Carri`ere Reconstitu´ee se verront appliqu´e le pattern PM4 (i.e., sup- pression de l’activit´e CC de leurs historiques respectifs). Ainsi une instance qui a pour historique ID.VI.CC.VE.NR aura comme historique t´emoin dans le nouveau protocole ID.VI.VE.NR. Par contre, les instances ayant transit´e directement de l’´etat V´erification Termin´ee vers l’´etat Rejet dans l’ancien protocole, et qui ont donc comme historique d’ex´ecution ID.VI.NR, se verront appliqu´e le pattern PM5 (i.e., extension de leur che- min d’ex´ecution avec l’activit´e VE ) et auront comme historique d’ex´ecution t´emoin ID.VI.VE.NR.

• La strat´egie 4 (ligne Num Strat´egie=4 du tableau 6.2) illustre la combinaison des trois patterns PM1, PM4 et PF3, `a l’aide des connecteurs de conjonction et de disjonction. Elle permet de transf´erer une grande partie des instances actives en une seule fois, montrant ainsi la puissance d’expression des patterns propos´es. Les valeurs des param`etres de cette strat´egie sont donn´ees dans le tableau 6.2 et sa sp´ecification est la suivante :

(δe, qs)

[Strict ((δ,qs),(β,qt0),−)∨Reduc ((δ,qs),(β,q0t),α)] ∧ Sous-protocol ((δ,qs),(β,q0t),(P1:P2))

−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (βe, qt0)

- Le pr´edicat Strict ((∗, qs), (β, q0t), −) permet de transf´erer toute instance qui a atteint

CHAPITRE 6. FORMALISATION DES PATTERNS DE MIGRATION

l’´etat q_t0 du nouveau protocole qui est atteignable par le chemin d’ex´ecution t´emoin β = δ.

- Le pr´edicat Reduc ((∗, qs), (β, qt0), Contrˆole carri`ere) permet de transf´erer toute ins-

tance qui a atteint un ´etat qs de l’ancien protocole en suivant un chemin d’ex´ecution

quelconque δ vers l’´etat q_t0 du nouveau protocole qui est atteignable par le chemin d’ex´ecution t´emoin β, obtenue en supprimant l’activit´e Contrˆole carri`ere du chemin δ. - La combinaison de ces deux premiers pr´edicats avec une disjonction permet, donc, de transf´erer les instances de l’ancien protocole vers les ´etats atteignables par le mˆeme chemin (pr´eservation stricte des ex´ecutions), ou bien par les chemins obtenus en sup- primant l’activit´e Contrˆole Carri`ere du chemin d’ex´ecution consid´er´e. Par exemple, les instances qui sont `a l’´etat V´erification Termin´ee de l’ancien protocole, et qui ont un chemin d’ex´ecution ID.VI seront transf´er´ees vers l’´etat Carri`ere Reconstitu´ee du nou- veau protocole, car cet ´etat est atteignable par le mˆeme chemin d’ex´ecution dans le nouveau protocole, suite `a la suppression de l’´etat V´erification Termin´ee.

- Le pr´edicat Sous-protocol ((δ, qs), (β, q0t), (P1 : P2)), avec P1 = CSP(Retraite, qs) et

P2 = CSP(CRetraite, qt0), rajoute une contrainte suppl´ementaire sur la migration en

imposant que l’´etat qs soit simul´e par l’´etat cible qt0. Cette nouvelle contrainte impose

que le comportement possible `a partir de n’importe quel ´etat qs peut ˆetre reproduit

par l’´etat q_t0.

- La conjonction de ce dernier pr´edicat avec la premi`ere condition, permet `a la stra- t´egie 4 de faire migrer les instances de tous les ´etats de l’ancien protocole sauf les trois ´etats : D´ebut, Demandeur Identifi´e et V´erification Termin´ee. Cette restriction vient du fait que l’´etat V´erification Termin´ee de l’ancien protocole, qui est atteignable par le chemin d’ex´ecution ID.VI, n’est pas simul´e par l’´etat Carri`ere Reconstitu´ee qui est atteignable par le mˆeme chemin dans le nouveau protocole. En effet, l’activit´e NR est possible `a partir de l’´etat V´erification Termin´ee de l’ancien protocole, mais elle n’est pas possible `a partir de l’´etat Carri`ere Reconstitu´ee du nouveau protocole.

A noter que les patterns d’interdiction d’activit´es pass´ees (PI1) et futures (PI2) peuvent ˆetre utilis´es `a leur tour lors de la sp´ecification des strat´egies par combinaison de patterns. Dans cette perspective, la technique de composition de patterns permet de doter les gestionnaires de protocole d’un outil souple et efficace pour satisfaire leurs besoins sp´ecifiques relatifs `a la gestion de la migration d’instances.

6.7

Conclusion

Dans ce chapitre, nous avons pr´esent´e le deuxi`eme aspect de notre approche d´e- clarative de gestion de l’´evolution des protocoles de services web. Il consiste en un enrichissement du langage de migration d’instances par l’identification et la formali- sation d’un ensemble de patterns de migration.

Les patterns identifi´es permettent la sp´ecification de diff´erentes strat´egies de mi- gration. Ils ont ´et´e expos´es et illustr´es par diff´erents sc´enarios d’´evolution. N´eanmoins, les patterns identifi´es ne sont pas exhaustifs. En effet, ils repr´esentent ceux qui sont les plus fr´equemment rencontr´es lors des ´evolutions des protocoles de services. Pour d´e- passer cette restriction, nous avons propos´e une technique de composition des patterns de base, afin de permettre aux gestionnaires de protocoles de sp´ecifier des strat´egies de migration plus ´elabor´ees.

CHAPITRE 6. FORMALISATION DES PATTERNS DE MIGRATION

Une ´etude de cas compl`ete qui illustre l’application des diff´erentes strat´egies de migration a ´et´e pr´esent´ee, et l’analyse de l’impact de l’´evolution, suite `a l’´evolution du protocole Retraite, a ´et´e r´ealis´ee en exploitant les patterns propos´es.

Il est `a rappeler que les approches existantes pour la migration d’instances se focalisent, uniquement, sur la stricte mise en conformit´e des instances actives avec la nouvelle version du protocole (pattern Strict (PM1)). Dans notre approche, nous avons propos´e une technique de migration plus flexible et qui est param´etrable.

Il convient de noter que, lors de la migration, le souci est de faire migrer le maximum d’instance actives. En ce sens, l’approche propos´ee apporte une plus value dans le domaine de la gestion des ´evolutions dynamiques des protocoles des services web. En effet, consolid´ee par un cadre formel solide, elle favorise la composition des patterns de base pour r´epondre aux besoins sp´ecifiques lors de la gestion de la migration des instances actives.

Pour montrer la faisabilit´e de notre approche d´eclarative, nous abordons dans le prochain chapitre l’aspect impl´ementation et exp´erimentation.

Chapitre 7

Impl´ementation et exp´erimentation

7.1

Introduction

Afin de valider les contributions propos´ees tout au long de ce manuscrit, nous avons mis en œuvre un prototype logiciel qui int`egre diff´erents composants impl´ementant chacun des aspects ´evoqu´es dans notre approche, puis nous avons exp´eriment´e les performances de l’outil d´evelopp´e.

Dans ce chapitre, nous pr´esentons et nous d´ecrivons de mani`ere succincte le pro- totype exp´erimental, nomm´e Protocol Change Impact Analyser (PCIA) qui, impl´e- mente notre approche d´eclarative de migration d’instances. Diff´erents exp´erimenta- tions ont ´et´e r´ealis´ees sur des donn´ees synth´etiques, pour ´evaluer le passage `a l’´echelle et les performances du prototype r´ealis´e. En fin, nous avons ´evaluer la capacit´e des patterns de migration propos´es `a capturer les principales strat´egies de migration exis- tantes dans la litt´erature et nous avons examin´e leur aptitude `a prendre en charge les diff´erents crit`eres de conformit´e r´epandus dans le domaine de la gestion des ´evolutions. Ce chapitre est organis´e comme suit : la section 7.2 pr´esente la conception, l’ar- chitecture g´en´erale et les fonctionnalit´es du prototype PCIA ainsi que la description de chacun des modules qui le compose. La section 7.3 d´ecrit en d´etails diff´erents sc´e- narios d’utilisation du prototype r´ealis´e pour g´erer les tˆaches inh´erentes `a l’´evolution. Quelques r´esultats exp´erimentaux sur des donn´ees synth´etiques sont pr´esent´es et dis- cut´es en section 7.4. En fin, une ´evaluation de l’expressivit´e et de la compl´etude de l’approche propos´ee est discut´ee en section7.5. La section7.6r´ecapitule le chapitre et discute bri`evement les futures perspectives de d´eveloppement de notre prototype.