N OTRE APPROCHE

Dans cette thèse, nous proposons un système de déploiement dirigé par les modèles. Ce système, nommé DMSA pour Deployment Manager for Services Applications, se base sur des modèles d'application à services, sur le modèle global associé à chaque environnement d'exécution ciblé et sur des modèles implémentations de service (c'est-à-dire d'unité de déploiement) pour réaliser/exécuter des activités de déploiement.

Notre objectif est d'identifier et d'isoler les informations relatives au déploiement d'applications à services et aux propriétés de déploiement attendues afin d'offrir un système, dirigé par les modèles issus des méta-modèles définis, qui automatise le déploiement (c'est-à-dire qui joue le rôle de déployeur). Pour ce faire, nous avons défini un méta-modèle pour les applications à services (il permet de spécifier une vue "déploiement" des applications à services), un méta-modèle pour les environnements et un méta-modèle pour les implémentations de services (c'est-à-dire pour les unités de déploiement).

Nous utilisons l'approche dirigée par les modèles afin de bénéficier de son haut niveau d'abstraction et du découplage technologique qu'elle permet d'atteindre (c'est-à-dire un découplage entre le niveau modèle et le niveau "réalité"). En effet, dans le cadre du déploiement nous ne souhaitions plus manipuler des unités de déploiement constituées d'un descripteur et de l'implémentation décrite, mais uniquement les descripteurs (c'est-à-dire des modèles de services). Notre idée est de nous abstraire des implémentations afin de pouvoir tirer parti de la propriété de substituabilité des services. En guise de rappel, cette propriété permet de substituer une implémentation de service utilisée pour réaliser un contrat de service par une autre implémentation de service de contrat équivalent. En conséquence, les modèles d'application spécifiés et passés en paramètre au DMSA n'ont aucun lien avec une quelconque implémentation de service, le découplage entre les niveaux modèle et "réalité" est total. L'objectif final est d'appréhender au mieux le fait que les environnements d'exécutions ciblés relèvent du domaine de l'embarqué/réactif et le fait qu'ils sont hétérogènes et/ou qu'ils contiennent des implémentations de services hétérogènes.

Figure 32. Schéma de notre approche (DMSA's Deployment Agents).

L'élément central du DMSA est le modèle global qu'il construit et maintient pour chaque environnement d'exécution géré. Chaque déploiement est tout d'abord appréhendé par rapport aux modèles d'application ciblés et aux modèles globaux des environnements ciblés, avant d'être traduit en instructions de déploiement aux niveaux implémentations de services et instances, puis exécuté dans chaque environnement ciblé, pour être enfin répercuté au niveau du modèle global de chaque environnement.

Plus simplement, chaque déploiement passé en paramètre au DMSA est appréhendé comme une instruction visant à modifier le modèle global de l'environnement cible. Ainsi, si l'instruction est sensée par rapport au modèle global de l'environnement ciblé, alors un plan de déploiement correspondant à cette instruction est généré et exécuté dans l'environnement et le modèle global de l'environnement est mis à jour en conséquence, sinon une erreur est retournée et le modèle global reste inchangé. Si l'exécution du plan de déploiement échoue, le modèle global de l'environnement reste inchangé et le DMSA tente un retour en arrière sur les éléments du plan de déploiement qui ont été exécutés, afin d'assurer la cohérence entre le modèle global associé à l'environnement et l'état "réel" de l'environnement.

Concrètement, le DMSA prend en entrée :

• des identifiants de modèles d'application à services précédemment enregistrés dans le dépôt de modèles d'application du DMSA,

• le dépôt de modèles d'implémentations de services du DMSA ainsi que les dépôts d'implémentations de services correspondants,

• des identifiants d'environnements d'exécution à services précédemment enregistrés auprès du gestionnaire des modèles globaux des environnements du DMSA

• et un ensemble d'activités de déploiement.

Lors de chaque déploiement, le DMSA reçoit des instructions de l'administrateur qui gère les environnements d'exécutions cibles. Il vérifie si le déploiement a un sens par rapport au modèle de chaque environnement ciblé (c'est-à-dire si le modèle global de chaque environnement peut être modifié par le déploiement donné) et, le cas échéant, il génère le plan de déploiement correspondant (afin de modifier la "réalité" de l'environnement).

Chaque plan de déploiement est ensuite envoyé aux dits environnements pour être exécuté. Le résultat de chaque exécution est ensuite retourné à la partie centrale du DMSA qui modifie le modèle global associé à chaque environnement ciblé et qui informe l'administrateur du résultat de l'exécution de chaque déploiement.

Ensuite, il est important de noter que notre choix d'une approche dirigée par les modèles est la suite logique de la montée en abstraction qu'il est possible d'observer en génie logiciel. Ainsi, comme

nous l'avons présenté dans notre état de l'art, les paradigmes de développement conçus et mis en avant au fil des ans ont toujours cherché à gagner en abstraction par rapport à leurs prédécesseurs, preuve en est, l'introduction des objets pour faire suite aux modules, puis des composants, des services et à l'heure actuelle des modèles. De son côté, le déploiement logiciel n'échappe pas à ce mouvement global du génie logiciel, ainsi, les déployeurs qui déployaient initialement des implémentations monolithiques (tels les archives JAVA .jar [JAR] ou les packages [ACR08]), ont cherché ensuite à déployer des logiciels décrits à l'aide de descripteurs de déploiement [SUN03b] [BCS03], puis à déployer des logiciels en ne se basant que sur leur seul identifiant [CLM05] [.Net06] [MAV08] et enfin, à déployer des modèles qui permettent un découplage envers les implémentations et une bonne abstraction puisque seules les informations nécessaires au processus de déploiement entrent en jeu et sont manipulées, c'est par exemple le cas pour [OMG06] (où un ensemble d'implémentations est mis à disposition pour un modèle de composant donné) et dans notre approche (où les modèles manipulés sont dissociés du niveau implémentation et où le choix, la sélection des implémentations revient au déploiement).

La spécification D&C de l'OMG a été la première spécification à introduire ce type d'approche dans le cadre du déploiement [OMG06]. Son objectif était la création d'un modèle générique pour le déploiement et la configuration de logiciels (distribués). Malheureusement, cette volonté de généricité a rendu l'approche de l'OMG particulièrement complexe et difficile à utiliser et à mettre en place. De plus, les bénéfices apportés par l'utilisation de cette spécification sont discutables puisque, par exemple, le processus de déploiement ne couvre pas les activités de désinstallation et de mises à jour et puisque le modèle générique de l'OMG est particulièrement difficile à appréhender et à manipuler.

Afin d'éviter les écueils rencontrés par l'OMG, nous nous sommes concentrés sur l'identification, la conception et la mise en place d'un ensemble minimal de modèles répondant à notre problématique et à ses contraintes, c'est-à-dire permettant le déploiement d'applications à services centralisées dans des environnements d'exécution à services.

Pour mettre en œuvre notre approche, il nous a été nécessaire de :

• Définir un méta modèle pour les applications à services dans notre contexte de "déploiement au plus près" (c'est-à-dire à définir une vue déploiement pour les applications à services satisfaisant notre contexte et les propriétés de déploiement que nous ciblons),

• Utiliser ce méta-modèle pour modéliser les applications, les implémentations de services (c'est-à-dire les unités de déploiement) et les environnements d'exécution.

• Définir le déploiement pour les applications à services dans notre contexte. Il nous a aussi été nécessaire :

• D'appréhender ce déploiement, c'est-à-dire permettre l'installation, l'activation, la désactivation, la mise à jour statique et la désinstallation de modèles d'application sur un environnement d'exécution à services en agissant sur ces dits modèles et sur le modèle global de l'environnement.

• De gérer le partage d'implémentations de services et d'instances, ainsi que l'isolation entre les modèles d'application déployés.

• D'appréhender le contexte embarqué/réactif des environnements d'exécution à services que nous ciblons, c'est-à-dire maximiser le partage des implémentations de services et des instances d'implémentations de services dès que cela est possible.

• De permettre le déploiement sur plusieurs environnements, ainsi que l'exécution de listes d'activités de déploiement.

Enfin, l'utilisation d'une approche dirigée par les modèles dans le cadre de cette thèse nous fait manipuler quatre niveaux distincts, à savoir, le niveau modèle d'application, le niveau modèle de service, le niveau implémentation de service (c'est-à-dire le niveau unité de déploiement dans notre objectif de déploiement "au plus près") et le niveau instance d'implémentation de service. La figure ci-dessous schématise ces quatre niveaux.

Figure 33. Schéma des quatre niveaux manipulés.

Pour rappel, chaque modèle d'application est identifié de manière unique par le DMSA et chaque modèle de service est identifié de manière unique au sein de son application. Cela explique la cardinalité "1..1" associée à la classe "Modèle d'application à services" pour l'association entre les classes "Modèle d'application à services" et "Modèle de service". Dans une application à service, chaque contrat de service fait partie d'un modèle de service. Si plusieurs modèles de services ont des contrats de services similaires, alors ces modèles de services peuvent être réalisés par la même implémentation de service ; cela explique la cardinalité "1..*" sur la classe "Modèle de service" pour l'association entre les classes "Modèle de service" et "Implémentation de service". Exprimé autrement, si l'attribut "ServiceIdInTheServicesApplication est enlevé d'un modèle de service apparaissant dans un modèle d'application, alors le modèle de service "tronqué" (qui se trouve être le contrat de service) peut tout à fait apparaitre dans plusieurs applications, voir même plusieurs fois dans la même application.

Dans la suite de ce chapitre, nous présentons notre méta-modèle pour les applications à services, la définition du déploiement, ainsi que l'architecture de notre système de déploiement ; nos propositions autour du déploiement d'un modèle d'application sur un environnement et autour du déploiement de modèles d'application, puis notre appréhension du contexte embarqué des environnements et nos propositions autour de l'exécution (de listes) d'activités de déploiement sur des environnements. Enfin, la dernière section synthétise le contenu de notre proposition.