Dans cette section, nous analysons la capacit´e des patterns de migration propos´es `
a capturer les principales strat´egies de migration existantes et `a prendre en charge les crit`eres de conformit´e propos´es dans la litt´erature.
7.5.1
Capture des strat´egies de migration existantes
Comme il a ´et´e discut´e dans la section 4.3, dans le domaine des services web, les notions de compatibilit´e historique et de compatibilit´e future [24, 25, 21, 136, 97] ont ´
et´e utilis´ees comme base principale pour d´efinir diverses strat´egies de migration des instances actives. Dans notre approche, la compatibilit´e historique peut ˆetre accomplie en employant le pattern de migration Strict (PM1), comme suit :
(δe = v, qs)
Strict ((δ,qs),(β,q0t))
−−−−−−−−−−−→ (βe= v0, qt0).
Ce pattern permet de convertir une instance active i de l’ancien protocole, avec un chemin d’ex´ecution δ en une instance du nouveau protocole, s’il existe un ´etat q0t qui peut ˆetre atteint dans le nouveau protocole en utilisant le chemin d’ex´ecution δ. Par cons´equent, ce mod`ele assure la compatibilit´e historique des instances migr´ees.
Pour la compatibilit´e future, le pattern de migration pour la substitution de sous- protocole Sous-P (PF3) peut ˆetre exploit´e comme suit :
(δe, qs)
Sous-P((δ,qs),(β,q0t),(SP:SP 0))
−−−−−−−−−−−−−−−−−→ (βe, q0t)
Comme discut´e pr´ec´edemment (cf., section 6.3.2), ce pattern assure qu’une instance i de l’ancien protocole est migrable vers le nouveau protocole, si et seulement si, il
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
existe un ´etat correspondant dans le nouveau protocole qui peut reproduire tous les comportements qui ont ´et´e offerts `a i `a partir de son ´etat actuel dans l’ancien protocole. A signaler que la conjonction des deux patterns pr´ec´edents conduit `a une strat´egie de migration qui assure `a la fois la compatibilit´e historique et la compatibilit´e future des instances migr´ees. Donc, de r´ealiser une compatibilit´e compl`ete.
D’autres classes de compatibilit´e, bas´ees sur les protocoles clients et qui sont utiles quand les informations sur les protocoles clients sont disponibles, ont ´et´e ´etudi´ees dans [24, 135]. Les patterns propos´es peuvent ˆetre ´etendus sans difficult´es majeures pour r´epondre `a ces classes suppl´ementaires de compatibilit´e.
Nous tenons `a signaler le fait que la sp´ecification des strat´egies de migration qui assurent les cas de compatibilit´e historique et/ou future est plus ais´ee en utilisant nos patterns de migration. Cela est dˆu au fait que les patterns que nous avons propos´e sont d´eclaratifs, dans le sens o`u ils pr´ecisent uniquement quelles sont les propri´et´es `
a pr´eserver lors de la migration des instances. Par contre, les approches bas´ees sur les mod`eles de migration discut´es dans le chapitre4(section4.3) incorporent et int`egrent, en mˆeme temps, dans la d´efinition de la strat´egie de migration `a appliquer quelles sont les propri´et´es `a pr´eserver et comment proc´eder pour les pr´eserver.
7.5.2
Prise en charge des crit`eres de conformit´e
Dans le domaine des syst`emes workflows et les syst`emes de gestion de processus m´etier (BPM), certains crit`eres de conformit´e manipul´es par ces syst`emes sont simi- laires `a ceux utilis´es dans le domaine des services web, mais ils se manifestent dans un contexte technique diff´erent. Par exemple, la notion de conformit´e par rapport `a l’h´eritage (conformit´e under inheritance) [23] est tr`es proche de la notion de compa- tibilit´e compl`ete, dans le sens o`u elle est bas´ee sur une relation globale de raffinement entre ancien et nouveau protocoles (i.e., la relation d’h´eritage) qui assure la compati- bilit´e historique et la compatibilit´e future de toutes les instances de l’ancien processus m´etiers avec le nouveau. D’autres approches sont bas´ees sur la pr´eservation de l’his- torique (pr´efixe de sch´ema, ´etats sˆurs, la conformit´e restrictive, crit`eres complets de conformit´e [23] ). En mˆeme temps, une grande partie de ces approches consid`ere les ex´ecutions futures (s´equence de d´eclenchement de pr´e-changement : pre-change firing sequence), [23]). La majorit´e de ces crit`eres peut ˆetre captur´ee par nos patterns de migration, tel que discut´e pr´ec´edemment.
Deux crit`eres de conformit´e suppl´ementaires abord´es dans [23] permettent d’´etendre la compatibilit´e historique `a deux types particuliers de compatibilit´e : la compatibilit´e insensible au r´e-ordonnancement des activit´es et la compatibilit´e tol´erante aux boucles. Comme pr´esent´e dans la section 6.3.1, notre pattern de migration Reord (PM2) per- met la migration des instances actives d’un ancien protocole, si les changements qui les ont affect´es concernent leurs historiques d’ex´ecution et touchent uniquement la modification de l’ordre de certaines activit´es. (cf., exemple6.3).
La tol´erance aux boucles permet d’´eviter d’exclure les instances `a migrer du fait que les changements respectifs concernent les boucles [22, 23]. La compatibilit´e historique est alors ´etendue `a une instance de l’ancien protocole, si sa trace d’ex´ecution ignore toutes les it´erations de la boucle, sauf la derni`ere, pour qu’elle soit compatible avec le nouveau protocole. Un tel crit`ere peut ˆetre captur´e dans notre approche en utilisant
CHAPITRE 7. IMPL´EMENTATION ET EXP ´ERIMENTATION
le pattern de migration de substitution de sous-chemins Subst (PM3), comme suit : (δe= v1vv∗v2, qs)
Subst ((δ,qs),(β,q0t),(αe:α0e))
−−−−−−−−−−−−−−−−→ (βe = v1vv2, qt0)
o`u v, v1, v2 sont des variables de chemins.
Ce pattern capture la s´emantique de la compatibilit´e historique avec tol´erance aux boucles, dans le sens o`u les changements dans une boucle n’excluent pas les instances de migrer vers la nouvelle version du protocole. Par exemple, si la boucle CIC est supprim´ee de l’´etat Carri`ere Reconstitu´ee du protocole Retraite de la figure 5.1 et si cette boucle est remplac´ee par une transition unique CIC, alors ce pattern permet de migrer une instance i ayant un chemin d’ex´ecution ID.VI.CC.CIC.CIC.CIC.VE vers le nouveau protocole, avec comme chemin d’ex´ecution t´emoin ID.VI.CC.CIC.VE.
Dans cette section, nous avons discut´e l’expressivit´e de notre langage d´eclaratif de transformation d’instances. Nous avons montr´e que les patterns de migration propos´es peuvent ˆetre utilis´es pour capturer, de mani`ere d´eclarative, la plupart des crit`eres de conformit´e utilis´es, `a la fois dans le cadre de protocoles m´etiers des services Web et dans les mod`eles de workflows. Pour rendre l’image plus compl`ete, il convient de mentionner le fait que notre langage de migration est assez puissant pour permettre d’exprimer des strat´egies de migration `a granularit´e fine des instances actives, qui ne sont pas pris en charge par les approches existantes dans l’´etat de l’art. Par exemple, nous ne sommes pas au courant de l’existence de types d’approches de migration qui utilisent des contraintes d’interdiction, ni des approches qui sont en mesure de d´efinir des crit`eres sp´ecifiques de conformit´e dans l’esprit de notre pattern de migration pour la substitution de sous-chemins (PM3). En effet, ce dernier pattern peut ˆetre vu comme une g´en´eralisation des notions de compatibilit´e historique et future, dans le sens o`u il permet `a un utilisateur de d´efinir quand deux instances sont ou ne sont pas compatibles, en fonction du contexte sp´ecifique de son application.
7.6
Conclusion
Dans ce chapitre, nous avons expos´e un prototype impl´ementant notre approche d´e- clarative de migration d’instances actives. L’outil logiciel r´ealis´e r´epond d’une mani`ere cons´equente aux objectifs fix´es, `a savoir : (i) sp´ecification des protocoles de service par des automates d’´etat finis d´eterministes, (ii) simulation des ex´ecutions des services et g´en´eration des traces d’ex´ecution, (iii) application des changements sur les proto- coles et sp´ecification des patterns de migration gouvernant l’´evolution, (iv) analyse de l’impact et migration des instances g´en´er´ees conform´ement aux patterns propos´es.
Il est important de noter que vue les difficult´es rencontr´ees pour l’obtention de donn´ees r´eelles (journaux logs), nous ´etions contraints de proc´eder aux exp´erimenta- tions par des simulations de jeux de test g´en´er´es par notre prototype. Les premiers r´esultats obtenus sont tr`es satisfaisants en termes de performances.
Pour ´evaluer l’expressivit´e et la compl´etude de notre approche, nous avons montr´e que les patterns de migration propos´es ont la capacit´e suffisante pour pouvoir prendre en charge, d’une mani`ere plus efficace, les approches de migrations les plus connues dans le domaine des services web et qu’ils v´erifient les crit`eres de conformit´e les plus utilis´es dans la litt´erature relative au domaine.
Chapitre 8
Conclusion G´en´erale
“Rien n’est permanent, sauf le changement”1. Effectivement, le changement est une v´erit´e intrins`eque de notre monde physique, o`u tout ph´enom`ene est mouvant et assujetti aux facteurs de son environnement. Cette loi de la ”non-permanence” ou du changement perp´etuel affecte tous les syst`emes.
Dans le contexte socio-´economique, les changements et les ´evolutions caract´erisent les processus m´etiers des entreprises qui vivent dans des ´ecosyst`emes de plus en plus versatiles. Ces changements exigent, entre autre, qu’un processus m´etier doit ˆetre continuellement actualis´e et am´elior´e. Par cons´equent, les organisations doivent s’as- surer, `a tout moment, que c’est le bon protocole m´etier qui est op´erationnel. Cette exigence strat´egique et tactique influe sur les instances en cours d’ex´ecution et pose, alors, le probl`eme de leur migration vers la nouvelle version du processus m´etier.
D’autre part, la technologie des services web constitue aujourd’hui une technolo- gie de choix pour l’impl´ementation des processus m´etiers trans-organisationnels. Par cons´equent, la gestion de l’´evolution des protocoles de ces services dans leur phase op´erationnelle (o`u certains instances sont en cours) est un probl`eme complexe qui affecte plusieurs dimensions de la sph`ere de l’organisation.
Dans cette th`ese, nous avons apport´e une contribution au probl`eme de l’analyse de l’impact des changements. L’approche de migration propos´ee pour la gestion de l’´evolution dynamique des protocoles des services web est d´eclarative et elle est fond´ee sur la transformation des instances actives.
8.1
Synth`ese des contributions
Nous avons abord´e le probl`eme de la migration des instances actives des processus m´etiers impl´ement´es en tant que services web, suite `a l’´evolution dynamique des sp´e- cifications de ces services. Un cadre formel pour l’analyse de l’impact des changements des protocoles des services web a ´et´e formalis´e, illustr´e, impl´ement´e et exp´eriment´e.
Les contributions majeures de la th`ese sont les suivantes :
1. Formalisation d’un langage de migration des instances actives bas´e sur les ex- pressions de chemins et sur les r`egles de migration.
2. Les patterns les plus fr´equents ont ´et´e identifi´es, formalis´es et illustr´es par des sc´enarios r´eels. Ces patterns ´etendent le langage propos´e et permettent la sp´eci- fication de diff´erentes strat´egies de migration s´electives.
3. Dans l’approche propos´ee, nous avons trait´e le probl`eme de la compatibilit´e stricte des protocoles apr`es l’application des changements. En plus, nous avons propos´e de nouvelles classes de compatibilit´e plus flexibles.
1. H´eraclite d’Eph`ese. Philosophe pr´e-socratique, consid´er´e par Hegel comme le p`ere de la pens´ee dialectique.
CHAPITRE 8. CONCLUSION G´EN´ERALE
4. Au del`a de l’examen classique de la gestion des traces historiques, les interactions futures et les sc´enarios interdits ont ´et´e trait´es et formalis´es.
5. La description formelle des patterns de migration constitue un cadre formel solide qui permet d’effectuer des raisonnements sur les connaissances repr´esentant aussi bien, les sp´ecifications du protocole que les traces des ex´ecutions. Par cons´equent, nous avons ´elabor´e une technique de composition des patterns de base qui permet la sp´ecification de strat´egies de migration plus complexes et qui r´epondent `a des besoins particuliers de gestion.
6. L’approche propos´ee a ´et´e mise en œuvre par un prototype logiciel. L’outil d´eve- lopp´e offre diverses fonctionnalit´es tr`es utiles aux gestionnaires de protocole. Le noyau du syst`eme g`ere l’analyse de l’impact du changement sur les instances en cours et fournit les informations de migration ad´equates qui sont associ´ees aux patterns de migration pr´ed´efinis.
7. L’approche a ´et´e exp´eriment´ee sur des donn´ees synth´etiques. Les r´esultats ob- tenus montrent que le syst`eme passe `a l’´echelle et que ses performances sont encourageantes.
8. En termes d’´evaluation formelle, le cadre propos´e permet de capturer d’une mani`ere plus efficace, les diff´erentes classes de compatibilit´es existantes et de prendre en charge les crit`eres de conformit´e utilis´es dans la litt´erature du do- maine (Workflows, processus m´etiers et services web)