Le travail que nous avons réalisé dans cette thèse se présente principalement en deux parties : conception et réalisation de solutions de reconfiguration pour des modèles de composants spécifiques, puis l'extension des résultats obtenus pour définir une solution plus générale.
8.2.1 Solutions spécifiques
Au lieu de définir un nouveau modèle de composants et de le doter de capacités de reconfiguration dynamique, nous sommes plutôt partis de modèles existants.
Nous avons dans un premier temps étudié le modèle JavaBeans, et nous avons analysé la BeanBox qui est un outil de composition graphique d'applications en JavaBeans. Nous avons proposé et implémenté ensuite une extension de la BeanBox pour supporter la reconfiguration dynamique des applications composées. Les différentes opérations de reconfiguration mises en œuvre concernent principalement l'architecture des applications. Parmi ces opérations, nous pouvons citer la connexion, la déconnexion, la reconnexion et le remplacement dynamique des composants. Toute opération de reconfiguration doit nécessairement garantir la cohérence de l'application reconfigurée. Dans la solution que nous avons développée, nous avons travaillé en particulier sur la gestion de la communication entre les composants lors de la reconfiguration, pour éviter de perdre des messages ou des données échangés. Nous avons également développé des outils pour aider au transfert de l'état lors du remplacement des composants. Les mécanismes nécessaires pour maîtriser la cohérence des applications reconfigurées sont primordiales dans un système de reconfiguration. La mise en œuvre de ces mécanismes représente une partie considérable de l'effort de développement d'un tel système.
Nous avons ensuite réalisé une solution de reconfiguration similaire pour le modèle OSGi. Ce deuxième travail sur un autre modèle nous a aidés à approfondir et à valider les idées acquises lors de la première expérimentation sur le modèle JavaBeans. La solution développée se présente sous la forme d'un composant OSGi spécifique qui incarne le système de reconfiguration. Elle est donc indépendante de toute implémentation du modèle OSGi, ce qui n'était pas le cas dans la première expérimentation qui est liée à l'environnement BeanBox.
Le troisième travail que nous avons mené dans cette thèse traite le problème d'incompatibilité des interfaces. En effet, les composants formant une même application peuvent être réalisés indépendamment par des développeurs différents. Des composants équivalents peuvent ainsi avoir des interfaces différentes, ce qui complique leur substituabilité. Nous avons réalisé dans le contexte du modèle OSGi une solution pour résoudre le problème d'incompatibilité d'interfaces. Cette solution permet, en particulier, de remplacer un composant par un autre composant sémantiquement équivalent, même s'il a une interface différente.
8.2.2 Solution générale
Notre objectif principal dans cette thèse était la spécification et la réalisation d'une solution de reconfiguration générale. Un tel objectif constitue un vrai défi du fait que chaque modèle de composants possède ses propres concepts et sa propre plate-forme d'exécution. Cette différence entre les modèles nous a amenés à définir une solution de reconfiguration partielle mais extensible pour pouvoir considérer les spécificités de chaque modèle. Le système de reconfiguration que nous avons mis en œuvre est fondé sur un modèle de composants abstrait. Il est cependant important de souligner que nous n'avons pas introduit le modèle abstrait dans l'esprit de concevoir un nouveau modèle de composants, et nous ne prétendons pas définir un modèle de composants générique pour remplacer les autres modèles. L'intérêt du modèle abstrait est d'augmenter l'indépendance (idéalement totale) de notre système de reconfiguration vis-à-vis des modèles de composants ciblés. La solution que nous avons développée présente plusieurs avantages qui peuvent être résumés dans les points suivants :
La logique de reconfiguration qui est en général commune à différents modèles de composants est incarnée au sein d'un même système réutilisable. Ceci évite de réimplanter la même chose à chaque fois qu'on souhaite développer un système de reconfiguration pour un nouveau modèle de composants.
Le modèle abstrait permet d'ajouter de la sémantique aux composants et aux connexions qui les relient grâce aux annotations qui peuvent y être attachées. Ces annotations permettent aussi d'augmenter les capacités d'auto-reconfiguration de notre système comme expliqué dans le point suivant.
Reconfigurer dynamiquement une application nécessite un cycle d'observation, d'analyse et de décision. Ces différentes étapes constituent une lourde tâche surtout si la reconfiguration doit être réalisée d'une façon répétitive. Pour assister l'utilisateur de notre système, nous avons doté ce dernier d'un moteur de raisonnement qui permet de reconfigurer automatiquement les applications. Ce moteur reçoit des notifications, et
prend des décisions en fonction d'un ensemble de règles spécifiées à l'avance. Ces règles matérialisent la logique de reconfiguration
La prise en compte de la responsabilité de reconfiguration par un système dédié, permet au développeur de se concentrer sur la logique métier de ses applications. Cette séparation facilite la maintenance et l'évolution aussi bien des applications que du système de reconfiguration.
8.2.3 Synthèse générale
Lors du travail que nous avons réalisé sur les deux modèles JavaBeans et OSGi, nous avons rencontré plusieurs difficultés. Ces difficultés étaient en général techniques et résolvables avec plus ou moins d'efforts de développement. Les problèmes auxquels nous avons dû faire face concernent le transfert d'état, la gestion des communications et la question de cohérence au moment de la reconfiguration. Ces différents points seront abordés plus en détails dans la section présentant les perspectives.
Nous avons eu un vrai défi dans cette thèse lors de la conception et de la réalisation de notre système général. Les différents modèles de composants sont naturellement basés sur des concepts différents et possèdent des plate-formes d'exécution différentes. Il n'existe pas un modèle pivot autour duquel on aurait pu définir un système générique. Il était même difficile d'identifier une notion commune de ce qu'est un composant ou de ce qu'est une application à base de composants dans le sens général et indépendamment d'une technologie particulière. Ces différences vont à l'encontre d'une solution de reconfiguration générique. Nous sommes arrivés ainsi à la conclusion qu'il faut concevoir une solution en deux parties, l'une générique et indépendante des modèles ciblés, et l'autre complémentaire et spécifique à un modèle particulier. La question clé à ce niveau, et qui nous a demandé un effort considérable, était de décider qu'est-ce qui est commun, applicable à tous les modèles et ainsi intégrable dans la partie générique, et qu'est-ce qui est spécifique à chaque modèle.
Au vu de nos objectifs, nous avons identifié une architecture de référence d'un système de reconfiguration. Nous avons également instancié cette architecture pour le modèle OSGi. L'architecture conceptuelle et le noyau de reconfiguration ont été complètement repris. Nous nous sommes donc concentrés, dans l'instanciation, uniquement sur les spécificités du modèle OSGi (interfaces spécifiques, plugins de projection,…). Le travail d'instanciation continue et a besoin d'être consolidé sur d'autres modèles (Fractal, EJB,…) pour en tirer une évaluation complète.
9
9 PP
EERRSSPPEECCTTIIVVEESSDDEELLAATTHHEESSEELe travail que nous avons réalisé dans cette thèse a permis, d'un coté, d'explorer quelques approches de reconfiguration dynamique, et d'un autre coté, de réaliser quelques expérimentations et de développer une solution de reconfiguration. Même si cette solution a été réalisée dans un esprit de réutilisabilité, et qu'elle favorise l'automatisation, beaucoup de
travail reste à faire et le chemin vers un système de reconfiguration complet et satisfaisant demeure très long. Plusieurs facettes constituent les perspectives de notre travail de thèse :
• Formalisation du problème de transfert d’état, • Cohérence de la reconfiguration,
• Auto-reconfiguration, • Approche par raffinement.