L’un des facteurs cl´es de performance de l’entreprise moderne r´eside dans l’agilit´e de son syst`eme d’informations (S.I). C’est `a dire, la capacit´e de ce syst`eme `a refl´eter, `
a tout moment, la r´ealit´e de l’organisation. En effet, le S.I doit, imp´erativement, g´erer les changements qui surviennent dans l’environnement de l’entreprise. En se sens, la capacit´e des organisations modernes `a s’adapter aux changements est un besoin strat´egique r´eel qui leur garantit la survie dans des syst`emes ´economiques, fortement, caract´eris´es par la concurrence rude et les coalitions conjoncturelles.
Les besoins d’adaptation passent, fondamentalement, par la gestion des change- ments des processus m´etiers. Dans le contexte des services web, ces changements se traduisent par des modifications qui peuvent affecter les interfaces de services et/ou les param`etres de qualit´e de service, aussi bien que la description des protocoles de ser- vices. La mise en œuvre des changements qui surgissent induit des impacts directs sur les instances du service. Ces derni`eres auront, incontournablement, besoin de migrer pour s’adapter aux nouvelles exigences impos´ees par le nouveau protocole.
Dans notre approche nous nous int´eressons `a l’´evolution des protocoles des services web, et nous visons les objectifs suivants :
CHAPITRE 5. UN LANGAGE D´ECLARATIF DE MIGRATION D’INSTANCES
− capturer les diff´erences et les similitudes entre l’ancienne et la nouvelle version du protocole de service web,
− prendre en compte l’´etat d’ex´ecution de chaque instance active en consid´erant sa trace d’ex´ecution r´eelle (chemin d’ex´ecution emprunt´e),
− analyser l’impact de l’´evolution des protocoles de services sur les instances en cours, et d´ecider de la mani`ere dont les changements seront propag´es.
Abstraction faite aux raisons qui ont produit les changements, r´epondre `a de telles pr´eoccupations est une tˆache complexe qui d´epend de plusieurs param`etres, dont les plus pertinents sont :
1. le mod`ele de description des protocoles de services ; 2. la nature du processus d’´evolution ;
3. la nature des op´erations de changement op´er´ees ;
4. les strat´egies de migration d´eploy´ees pour g´erer les changements.
La combinaison de ces consid´eration avec les objectifs vis´es exige une approche globale qui permettra de sp´ecifier diverses strat´egies de migration capables d’op´erer une analyse de l’impact des changements sur les instances en cours d’ex´ecution.
En se basant sur le mod`ele de description des protocoles de service d´ecrit pr´ec´e- dentes (c.f. 5.2 et 5.3), dans cette section nous analysons ces param`etres (2, 3 et 4 ), et nous mettons en ´evidence les choix retenus dans le cadre de notre approche. Ces choix sont des crit`eres d´eterminants pour la mod´elisation du probl`eme de l’analyse de l’impact des ´evolutions des protocoles des services web.
5.4.1
La nature du processus d’´evolution des protocoles
G´en´eralement, deux types d’´evolution sont distingu´es pour les diff´erents domaines concern´es par les changements (g´enie-logiciel, bases de donn´ees, Workflows, services web, . . . ), `a savoir : les ´evolutions statiques et les ´evolutions dynamiques.
Dans le contexte particulier des services web, les ´evolutions statiques sont carac- t´eris´ees par l’absence d’instances actives au moment pr´ecis du changement. Dans ce cas, la gestion de l’´evolution du protocole de service se limite, tout simplement, au d´e- ploiement de la nouvelle version du protocole. Les nouvelles instances pourront, par la suite, d´emarrer leurs ex´ecutions conform´ement aux nouvelles sp´ecifications et aucune difficult´e n’est rencontr´ee.
Cependant, dans le cadre des ´evolutions dynamiques, certaines instances sont en- core en cours d’ex´ecution au moment du changement du protocole. Ces instances dites actives ont engag´e leurs conversations avec le fournisseur du service web sur la base d’un protocole qui a subi des modifications de sa description, alors que des instances sont en cours d’ex´ecution.
Pour g´erer la progression des instances actives dans le contexte des ´evolutions dynamiques des services web, deux solutions sont possibles.
− laisser toutes les instances actives poursuivre leur ex´ecution selon l’ancien pro- tocole de service ;
− annuler toutes les instances actives et les red´emarrer conform´ement `a la nouvelle sp´ecification du protocole.
CHAPITRE 5. UN LANGAGE D´ECLARATIF DE MIGRATION D’INSTANCES
Cependant, ces deux solutions extrˆemes sont rarement possibles en pratique pour des raisons de pr´eservation de l’historique des ex´ecutions et pour des besoins de mise en conformit´e imm´ediate avec les nouvelles r`egles m´etier qui doivent entrer en vigueur le plus tˆot possible. Dans notre approche, on s’int´eressera `a l’´evolution dynamique des protocoles, et nous proposons une approche qui permettra la continuit´e de l’ex´ecution des instances actives dans le protocole ´evolu´e.
5.4.2
Le type d’op´erations de changement consid´er´ees
Nous nous appuyons sur le mod`ele de protocole de service introduit dans la sec- tion 5.2, et nous consid´erons les ´evolutions des services qui se traduisent par des modifications de la description de leur protocole. Les op´erations d’actualisation qui sont permises constituent une dimension importante du probl`eme. G´en´eralement, deux classes de changements sont distingu´ees :
− La modification de la description d’un ´el´ement contenu dans la sp´ecification du protocole. Par exemple, la modification du nom d’une activit´e ou d’un ´etat. − La modification de la structure du protocole elle mˆeme, comme par exemple,
l’ajout ou la suppression d’une activit´e.
Ces deux types d’op´erations de base peuvent ˆetre compos´es, de mani`ere `a exprimer des changements plus complexes. Par exemple, la fusion des ´etats, le d´eplacement des activit´es (r´eorganisation) ou l’ajout d’un sous-protocole en entier (c.f 3.3.1).
Si la premi`ere cat´egorie des changements est consid´er´ee comme assez facile `a g´erer, la seconde classe de changements est plus complexe, en particulier, dans le contexte des changements dynamiques. En effet, dans ce dernier cas, une analyse de l’impact des changements sur les instances actives doit ˆetre conduite afin d’identifier les actions n´ecessaires `a d´eclencher pour rendre ces instances conformes aux nouvelles exigences impos´ees par le nouveau sch´ema du protocole de service.
5.4.3
Les strat´egies de migration pour g´erer les changements
Dans notre contexte, une strat´egie de migration exprime un ensemble de propri´et´es utiles qu’il faut pr´eserver lors du processus de migration des instances actives. Autre- ment dit, elle sp´ecifie des conditions pr´ecises que les instances actives doivent satisfaire pour qu’elles puissent continuer leurs ex´ecutions dans le nouveau protocole, tout en d´ecrivant leurs configurations correspondantes dans le contexte de ce dernier. En r´ea- lit´e, les conditions `a satisfaire expriment, des choix de gestion et des besoins m´etier du fournisseur de service. Dans cette optique, les strat´egies de migration `a d´efinir doivent ˆ
etre explicit´ees d’une mani`ere formelle et pr´ecise.
Dans [24], trois types de strat´egies de migration ont ´et´es explor´ees : la continuit´e de l’ex´ecution conform´ement `a l’ancien protocole, la migration vers des protocoles ad-hoc et la migration vers le nouveau protocole. Dans notre approche, nous nous focalisons sur la derni`ere cat´egorie de strat´egies de migration compte tenu, `a la fois, de son importance du point de vue pratique et de la difficult´e de sa mise en œuvre.
D’une mani`ere g´en´erale, d´efinir une strat´egie de migration est une tˆache complexe qui d´epend ´etroitement de nombreuses d´ecisions d’entreprise [135]. Nous estimons qu’une strat´egie de migration efficace doit ˆetre s´elective et `a granularit´e fine, dans
CHAPITRE 5. UN LANGAGE D´ECLARATIF DE MIGRATION D’INSTANCES
le sens o`u elle doit ˆetre capable de distinguer entre les diff´erentes instances actives en s’appuyant sur des crit`eres de s´election tr`es pr´ecis.
Nous avons identifi´e deux axes d’analyse pertinents pour la d´efinition des strat´egies de migration des instances actives.
− Les ex´ecutions historiques vs. futures : la strat´egie de migration peut se concentrer sur les propri´et´es li´ees `a des ex´ecutions pass´ees et/ou certaines pro- pri´et´es des activit´es potentielles qui peuvent ˆetre effectu´ees dans le futur. − Les contraintes d’obligation vs. d’interdiction : la strat´egie de migration
peut viser l’instauration de certaines actions obligatoires, comme par exemple l’ex´ecution obligatoire d’une activit´e importante, ou elle peut cibler l’interdic- tion de certaines situations (par exemple, interdiction d’une activit´e future). Nous exposons, ci-apr`es, quelques exemples de strat´egies de migration qui peuvent ˆ
etre d´eploy´ees pour g´erer la migration des instances actives, et nous illustrons leur utilit´e et leurs objectifs.
a. Strat´egie maximisant la pr´eservation de l’historique
Dans certains protocoles sp´ecifiques, les activit´es ex´ecut´ees par les instances du- rant leur historique, peuvent ˆetre importantes et couteuses. Alors, le gestionnaire de protocole vise `a pr´eserver les historiques des ex´ecutions lors de la migration. En ex- ploitant cette strat´egie, l’objectif est d’´eviter la perte de travail, tout en pr´eservant au maximum les activit´es d´ej`a effectu´ees dans le pass´e.
La strat´egie de migration bas´ee sur la pr´eservation de l’historique des ex´ecutions est recommand´ee lorsque les activit´es du protocole sont de longue dur´ee et consommatrices de ressources (r´eseau, temps machine, temps d’utilisation du service . . . ).
b. Strat´egie maximisant le nombre d’instances migrables
Cette strat´egie projette d’assurer la migration du nombre maximum d’instances actives. Elle est utile lorsque le nombre d’instances est consistant, alors que les chan- gements sont significatifs. Par cons´equent, le gestionnaire de protocole vise `a imposer imm´ediatement ces changements. C’est le cas, par exemple, lors de l’application des exigences de s´ecurit´e (nouveau protocole d’authentification, par exemple), ou lors de la mise en place d’une nouvelle r´eglementation (une nouvelle proc´edure qui doit entrer en vigueur le plus tˆot possible).
c. Strat´egie de migration bas´ee sur l’analyse des traces d’ex´ecution
Du fait que le nombre d’instances actives peut ˆetre tr`es ´elev´e, l’analyse de leur traces d’ex´ecution peut orienter les gestionnaires dans le choix de la meilleure strat´egie de migration `a adopter. En fait, les informations relatives aux activit´es ex´ecut´ees, aux sous-chemins parcourus et aux ´etats atteints par les instances, sont des indicateurs potentiels qu’il faut prendre en consid´eration lors de la sp´ecification d’une strat´egie de migration.
A titre d’exemple, le gestionnaire de protocole peut stipuler que les instances n’ayant pas encore atteint un ´etat sp´ecifique (affect´e par les changements), ou celles n’ayant pas ex´ecut´e un sous-protocole particulier, ou encore les instances qui ne sont
CHAPITRE 5. UN LANGAGE D´ECLARATIF DE MIGRATION D’INSTANCES
pas en train d’ex´ecuter un sous-chemin donn´e, sont les seules instances qui peuvent migrer vers le nouveau protocole.
d. Strat´egie de migration bas´ee sur les ex´ecutions futures
Dans cette strat´egie, l’accent est mis, particuli`erement, sur les ex´ecutions futures des instances actives. En effet, les gestionnaires veulent faire migrer les instances ac- tives, tout en minimisant le nombre d’activit´es `a ex´ecuter durant les interactions fu- tures (pour atteindre un ´etat final ).
Cette derni`ere strat´egie est int´eressante lorsque les contraintes de temps sont im- portantes, et si la terminaison des ex´ecutions pour les instances en cours est la pr´e- occupation majeure. Cette option de migration peut ˆetre adopt´ee dans les cas de changement de la nature de l’activit´e de l’entreprise, sa liquidation ´economique ou encore lors des rachats d’entreprises par d’autres, . . . .
A signaler que la liste pr´ec´edente des strat´egies de migration n’est pas exhaustive. En fait, d’autres strat´egies peuvent ˆetre propos´ees afin de r´epondre `a des besoins sp´ecifiques et diversifi´es des utilisateurs. N´eanmoins, ces strat´egies demeurent fig´ees, car elles sont sp´ecifi´ees d’une mani`ere pr´ed´efinie. Or, l’un des soucis permanent des gestionnaires de protocoles est de disposer d’outils efficaces leur permettant de sp´ecifier d’une mani`ere flexible des strat´egies de migration personnalis´ees.
Pour r´epondre `a cette pr´eoccupation, nous proposons une approche d´eclarative bas´ee sur un langage de migration d’instances qui permet aux fournisseurs de services de sp´ecifier leurs propres strat´egies de migration lors de l’´evolution dynamique des protocoles des services web. Chaque strat´egie `a d´efinir permettra de mettre l’accent sur une ou plusieurs propri´et´es `a respecter lors de la migration des instances actives vers la nouvelle version du protocole de service.