Plugins de projection

Nous avons expliqué que les fonctions du gestionnaire de reconfiguration opèrent sur la représentation abstraite de l'application. Il est évidemment nécessaire de projeter les modifications établies au niveau abstrait sur l'application concrète. Dans un esprit réflexif, ceci correspond à la mise en œuvre de la connexion causale dans le sens descendant.

Dans le cas de l'interface de notification et de celle de reconfiguration, les opérations définies travaillent sur les éléments du modèle abstrait. Ces opérations sont ainsi indépendantes d'un modèle particulier, ce qui nous a permis de les définir définitivement.

La projection des modifications, d'un autre coté, dépend du modèle ciblé et de l'application concrète. Partant du principe que notre objectif est d'adresser des modèles différents, les opérations qui projettent les modifications sur les applications concrètes ne peuvent pas être définies définitivement, et pour tous les modèles. Considérons par exemple l'opération de déconnexion. Lorsque cette dernière est réalisée au méta-niveau, elle doit être matérialisée sur l'application. Si on prend une application en JavaBeans, la déconnexion se fait en dés-enregistrant l'instance cible de la liste des auditeurs de l'instance source. Si on prend une application (instrumentée) en OSGi, la déconnexion se fait en appelant une méthode spécifique de l'instance source. Enfin, si on prend une application basée sur le modèle Fractal [FRACTAL], la déconnexion se fait en appelant la méthode du contrôleur de binding associé à l'instance source.

Pour garder notre système de reconfiguration suffisamment générique, nous l'avons conçu d'une manière à ce que les opérations de projection puissent être intégrées sous forme de plugins. Ceci permet d'adapter les fonctions de projection en fonction du modèle adressé. La liste des plugins requis pour exploiter DYVA pour un modèle particulier est présentée dans la section 7.

6

6 PP

''

Le transfert d'état est l'un des problèmes les plus délicats auquel il faut faire face pendant la reconfiguration dynamique. La difficulté réside dans le fait que l'état est spécifique et interne à chaque instance, et qu'il est par conséquent difficile de trouver une solution générale sans la participation de cette dernière.

Dans le contexte de cette thèse, nous avons développé une solution basée sur la représentation abstraite de l'état. Chaque instance de composant au niveau abstrait contient l'état de l'instance concrète. La Figure 59 présente le modèle abstrait de l'état.

Figure 59. Modèle abstrait de l'état

Si une instance est à état, elle doit fournir deux opérations pour consulter et modifier son état. L'état en lui-même est vu simplement comme une liste d'enregistrements. Chacun représente un attribut, et, est décrit par un nom, un type, une description et une valeur. Pour la synchronisation de l'état de l'instance avec sa représentation abstraite, nous avions le choix entre deux solutions :

Synchronisation immédiate : chaque fois qu'un élément faisant partie de l'état change au niveau de l'application, l'information est remontée au niveau abstrait. Cette solution assure une représentation fidèle de l'état à tout moment. Elle peut causer en contre partie une surcharge de l'application et peut dégrader considérablement ses performances.

Synchronisation différée : il est possible de considérer qu'au niveau abstrait, on a besoin de l'état uniquement au moment de la reconfiguration. Dans ce cas, la synchronisation est établie uniquement à ce moment-là. C'est cette deuxième approche que nous avons adoptée dans DYVA.

Nous sommes partis du principe que l'état est sémantique, et que sa spécification dépend de l'application, du contexte d'utilisation et même du développeur des composants. Nous avons décidé de déléguer la responsabilité de spécification de l'état au développeur lui-même. Nous avons mis au point un outil pour l'assister et l'aider à réaliser cette spécification.

L'outil est spécifique aux composants développés en Java. Son rôle est d'introspecter la classe d'implémentation du composant, et d'afficher la liste des attributs qui font

potentiellement partie de l'état. Le développeur peut sélectionner ensuite les attributs qui constituent effectivement l'état. L'outil se charge finalement de générer et d'intégrer automatiquement les deux opérations getState() et setState() dans la classe d'implémentation du composant.

7

7 PP

''

Nous expliquons brièvement dans cette section comment personnaliser et utiliser DYVA pour supporter la reconfiguration dynamique dans le contexte d'un modèle de composants particulier. Cette personnalisation doit être faite par un spécialiste de ce modèle.

Comme le montre la

Figure 60, la personnalisation consiste à définir des interfaces spécifiques au dessus des interfaces fournies par DYVA. Elle consiste aussi à implanter les plugins de projection associés au modèle.

DYVA

Figure 60. Personnalisation de DYVA

Interface de notification spécifique : définit des opérations qui permettent aux applications d'envoyer des événements au système de reconfiguration. Ces opérations peuvent être basées sur les opérations définies dans l'interface de notification de DYVA. Les nouvelles opérations peuvent être un simple renommage des opérations de notification de DYVA. Elles peuvent être aussi plus complexe qu'un simple renommage. Par exemple, on décide de réaliser un filtrage sur les notifications envoyés par l'application ou par son environnement.

Interface de reconfiguration spécifique : définit les opérations de reconfiguration associées au modèle adressé. Ces opérations spécialisent celles définies dans l'interface de reconfiguration de DYVA. L'interface de reconfiguration spécifique définit aussi de nouvelles opérations pour traiter les concepts particuliers du

modèle adressé. Par exemple, supposons que dans un modèle donné, on a le concept de sous-application, définie comme un ensemble d'instances interconnectées. On souhaite ainsi définir une opération, associée à ce concept, et permettant à titre d'exemple de supprimer une sous-application. Cette opération se charge de mettre à l'état passif les instances d'une sous-application, de les déconnecter, plus de demander leur suppression effective.

Plugins de projection : constituent la partie la plus complexe et la plus importante du processus de personnalisation. Ils permettent de projeter les modifications introduites au modèle abstrait sur l'application concrète. L'ensemble de plugins à concevoir, qui reflètent chacun une opération de projection, peut être résumé par les points suivants :

Plugin de binding : permet d'établir et de supprimer les connexions entre deux ports de deux instances.

Plugin d'instanciation : responsable de la création et de la suppression d'instances de composants.

Plugin de déploiement : responsable de déployer de nouveau composants, et de supprimer de l'application les composants inutiles.

Plugin de gestion d'état : responsable de retourner l'état d'exécution d'une instance donnée. Il est aussi responsable d'initialiser l'état d'une instance de composant.

Plugin de gestion de communication : responsable de la passivation et de l'activation des instances de composants. Il assure la sauvegarde des messages envoyés pendant la reconfiguration, et le traitement de ces messages dans le bon ordre après la reconfiguration.

Le chapitre 7 est consacré à discuter un cas réel de personnalisation de DYVA pour le modèle OSGi. Il présente en détail la spécification de l'interface de notification, de celle de reconfiguration et explique le fonctionnement des plugins de projection associés à OSGi.

8

8 CC

Nous avons présenté dans ce chapitre DYVA, notre système de reconfiguration dynamique. Nous avons surtout insisté sur son architecture interne, sur sa capacité d'auto-reconfiguration et sur sa vue externe.

Pour assurer l'ouverture et la réutilisabilité de notre système, nous l'avons basé sur un modèle de composants abstrait. Ce modèle incarne l'image de l'application à reconfigurer et permet de traiter d'une manière homogène, des applications issues de modèles de composants différents.

Nous avons favorisé dans notre approche l'automatisation. Cette automatisation a deux facettes :

Instrumentation des applications : cela consiste à introduire des modifications dans une application déjà développée pour qu'elle puisse répondre aux besoins du système de reconfiguration. Ceci concerne l'introduction du code qui permet de réaliser les notifications, et celui qui est responsable du transfert d'état.

Auto-reconfiguration : nous avons mis en place un moteur de raisonnement qui

permet de reconfigurer automatiquement les applications. Ce moteur reçoit des notifications, et prend des décisions en fonction de stratégies exprimées sous forme de règles spécifiées à l'avance.

Ce chapitre a expliqué aussi la solution que nous avons développée pour le problème de transfert d'état. Cette solution est basée sur un modèle abstrait de l'état. Elle permet, grâce à ce modèle, d'avoir une vision commune de la notion d'état.

La dernière partie de ce chapitre a brièvement expliqué le processus de personnalisation de notre système de reconfiguration pour un modèle de composants particulier. Cette personnalisation se fait par la définition d'une interface de notification, d'une interface de reconfiguration et d'un ensemble de plugins de projection spécifiques au modèle ciblé.

Le chapitre suivant est consacré à décrire l'implémentation de notre système de reconfiguration. Il explique les interfaces, les structures de données et les outils qui ont été mis en œuvre.

145

C

CHAHAPPIITTRREE 66

Chapitre 6 :

DDYYVAVA :: IMI

MPPLLEEMMEENNTTAATTIIOONN

PRÉAMBULE.

Ce chapitre décrit l'implémentation de notre système de reconfiguration. Il explique d'abord les détails d'implémentation de la base de composants. Puis il illustre l'implémentation des différents éléments de l'architecture. Nous présentons également, dans ce chapitre, les différents outils que nous avons développés comme support à notre approche.

1

1 II

Les chapitres précédents ont expliqué le principe de notre approche. Nous avons réalisé, dans cette thèse, une implémentation en Java pour démontrer la faisabilité et la validité de cette approche. Ce chapitre présente les éléments les plus importants de cette implémentation.

Nous nous concentrons principalement, dans la suite, sur les interfaces, les structures et les outils que nous avons développés comme support à notre approche. Nous commençons par une description détaillée de la base de composants, sur laquelle DYVA est basé. Puis nous décrivons les différents éléments de l'architecture, comme le modèle abstrait, les interfaces et les classes principales formant l'architecture. Pour simplifier la spécification de l'état, et la génération des opérations qui permettent de consulter et de modifier l'état d'une instance, nous avons implémenté un outil qui sera présenté après l'illustration de l'architecture. Avant de conclure ce chapitre, nous décrivons brièvement l'interface graphique que nous avons implémentée, pour simplifier le contrôle et la reconfiguration dynamique des applications.

146