D ÉFINITION DU DÉPLOIEMENT

Dans cette section, nous allons détailler le résultat de l'adaptation de la définition du déploiement de l'université du Colorado [HHC+98], ainsi que sa signification au niveau des services et des applications à services introduites précédemment. Pour remarque, l'état de l'art "déploiement" de ce document de thèse présente en détail la définition du déploiement de l'université du Colorado, ainsi que nos conclusions et critiques.

Nous avons choisi d'adapter la définition du déploiement de l'université du Colorado puisque, parmi les trois définitions majeures présentées, elle est la seule à offrir un processus non linéaire et non séquentiel, elle est la plus complète (car elle couvre l'insertion, l'exécution, une partie de la maintenance et la suppression d'un système logiciel sur un site) et elle est aussi la plus cohérente (car elle définit à la fois l'insertion d'un système logiciel sur un site et sa suppression, ainsi qu'à la fois le lancement et l'arrêt de l'exécution du système logiciel).

3.1 Définition

Notre proposition concernant la phase de déploiement est un processus non linéaire et non séquentiel qui est constitué par cinq activités de déploiement, à savoir, l'installation, l'activation, la maintenance, la désactivation et la désinstallation. En détail :

• L'installation d'un logiciel sur un site signifie l'insertion de son ou de ses unités de déploiement sur le site.

• L'activation d'un logiciel signifie le lancement de l'exécution de la ou des implémentations contenues dans la ou les unités de déploiement relatives au logiciel.

• En ce qui concerne l'activité de maintenance, nous la considérons du point de vue du déploiement, c'est-à-dire qu'il n'est pas question ici d'incorporer la détection et la correction de "bug" (le développement de "patch") dans la phase de déploiement. Ainsi, dans le cadre du déploiement, la maintenance d'un logiciel englobe sa mise à jour et la modification de son architecture. L'activité de maintenance n'est pas une activité de déploiement en elle-même, c'est un terme qui regroupe quatre sous activités de déploiement, à savoir :

o la mise à jour statique d'un logiciel qui désigne le remplacement d'une ou plusieurs implémentations (contenues dans une ou plusieurs unités de déploiement réalisant le logiciel) par une ou plusieurs autres implémentations (contenues dans une ou plusieurs unités de déploiement) lorsque le logiciel n'est pas activé (c'est-à-dire lorsqu'il n'est pas en train de s'exécuter). Attention, l'architecture du logiciel doit être conservée ; de même, les architectures des implémentations remplacées et des implémentations remplaçantes doivent être similaires.

o la mise à jour dynamique qui est en tout point similaire à la mise à jour statique à ceci près qu'elle cible un logiciel activé.

o l'évolution d'un logiciel qui désigne la modification de l'architecture du logiciel lorsque ce dernier n'est pas activé.

o la dernière sous-activité est le dynamisme. Il désigne la modification de l'architecture d'un logiciel lorsque ce dernier est activé.

• La désactivation d'un logiciel est la fonction inverse de l'activité d'activation, c'est-à-dire qu'elle vise à arrêter l'exécution du logiciel.

• La désinstallation d'un logiciel est elle aussi une fonction inverse mais, cette fois, de l'activité d'installation, c'est-à-dire qu'elle vise à supprimer un logiciel inséré sur un site.

Les activités d'installation, d'activation, de désactivation et de désinstallation sont quatre activités qui aboutissent à un état de déploiement stable (respectivement installé, activé, désactivé, désinstallé). Par exemple, une fois l'activité d'activation réalisée, le logiciel est dans l'état actif. L'activité maintenance est quant à elle une activité transitoire. Par exemple, si un logiciel est actif et qu'une des activités de maintenance est exécutée alors si l'exécution se déroule bien, le logiciel se retrouvera dans

l'état actif (sinon, soit l'erreur d'exécution de la maintenance est rattrapée et le logiciel se retrouvera dans l'état actif, soit il pourra se retrouver au mieux dans l'état installé, au pire dans un état "corrompu").

Il est intéressant de noter que les états de déploiement installé et désactivé sont relativement similaires, au point qu'il est possible de les factoriser. Cependant, l'état désactivé n'est accessible que depuis l'état activé, ainsi il informe le déployeur sur le fait qu'un logiciel désactivé a déjà pu être activé (au moins une fois). C'est pourquoi nous avons conservé la distinction entre les états installé et désactivé.

Pour remarque, dans le cadre de la mise à jour dynamique et du dynamisme, deux propriétés sont à distinguer. La première porte sur le gel, la propagation et le dégel de l'état (interne) des implémentations ciblées. La seconde porte sur le gel et le dégel des communications vers et partant des implémentations ciblées. Typiquement, la technologie OSGi permet les mises à jour dynamiques, néanmoins, les deux propriétés ci-dessus ne sont pas offertes.

Figure 45. Proposition de phase de déploiement contenant les états et activités de déploiement. Dans le cadre de l'approche dirigée par les modèles que nous suivons, le point d'entrée de la phase de déploiement est non pas un logiciel, mais un modèle d'application à services. Ce dernier contient des modèles de services et d'interactions et est totalement découplé d'un quelconque niveau "implémentation". Ensuite, dans le cadre du déploiement "au plus près" nous avons choisi que les implémentations de services et les unités de déploiement que nous manipulons soient de même grain, ce qui signifie que toute unité de déploiement contient une unique implémentation de service et inversement que toute implémentation soit packagée seule dans son unité de déploiement.

3.2 Définition du déploiement de services

Ci-dessous, nous précisons la signification de la phase de déploiement pour les services. Ainsi : • l'installation d'un service sur un site signifie l'insertion du service (en réalité de son unité de

déploiement) sur le site.

• l'activation d'un logiciel signifie le lancement de l'exécution du service (en réalité de l'exécution de l'implémentation de service contenue dans l'unité de déploiement correspondant au service). Dans le cas général, l'activation d'un service peut échouer si ses dépendances ne sont pas satisfaites.

• dans le cadre du déploiement, la maintenance d'un service englobe sa mise à jour et la modification de son architecture. L'activité de maintenance regroupe quatre sous activités de déploiement, à savoir :

o la mise à jour statique d'un service qui désigne le remplacement de l'implémentation actuelle/courante du service (contenue dans l'unité de déploiement correspondante) par une autre implémentation de service (elle-même contenue dans une autre unité de déploiement) lorsque le service n'est pas activé. Attention, l'architecture du service (et donc son contrat de service) doit être conservée.

o la mise à jour dynamique qui est en tout point similaire à la mise à jour statique à ceci près qu'elle cible un service activé.

o l'évolution d'un service qui désigne la modification de l'architecture du service lorsque ce dernier n'est pas activé. Une modification peut, par exemple, être l'ajout d'un demandeur au contrat d'un service.

o le dynamisme d'un service désigne la modification de l'architecture du service lorsque ce dernier est activé.

• la désactivation d'un service vise à arrêter son exécution.

• la désinstallation d'un service vise à supprimer/enlever un service inséré sur un site.

3.3 Définition du déploiement d'application à services

Nous allons maintenant présenter la signification de la phase de déploiement pour les applications à services. La seule différence majeure entre le déploiement d’un service et le déploiement d’une application à services réside dans le fait que déployer un service met en jeu une unité de déploiement alors que déployer une application en met en jeu une ou plusieurs. Ainsi :

• l'installation d'une application à services sur un site signifie l'insertion, sur le site, du ou des unités de déploiement réalisant le ou les services qui appartiennent à l'application.

• l'activation d'une application à services signifie le lancement de l'exécution de l'application et donc le lancement de l'exécution de la ou des implémentations de service contenues dans la ou les unités de déploiement correspondant aux services de l'application).

• dans le cadre du déploiement, la maintenance d'une application à services englobe sa mise à jour et la modification de son architecture. L'activité de maintenance regroupe quatre sous-activités de déploiement, à savoir :

o la mise à jour statique d'une application à services qui désigne le remplacement d'une ou plusieurs implémentations de services actuelles/courantes (appartenant à l'application) par une ou d'autres implémentations de service lorsque l'application n'est pas activé. Attention, l'architecture de l'application doit être conservée, de même que les architectures des services ciblés par la mise à jour.

o la mise à jour dynamique qui est en tout point similaire à la mise à jour statique à ceci près qu'elle cible une application à services activée.

o l'évolution d'une application à services qui désigne la modification de l'architecture d'une application à services lorsque cette dernière n'est pas activée.

o le dynamisme d'une application à service désigne la modification de l'architecture de l'application lorsque cette dernière est activée.

• la désactivation d'une application à services vise à arrêter l'exécution de l'application.

• la désinstallation d'une application à services vise à supprimer/enlever une application à services insérée sur un site.

Enfin, la figure ci-dessous présente quelles sont les activités de déploiement possibles en fonction de l'état de déploiement de l'application ciblée.