dans les composants. De plus, nous avons défini des entités dédiées pour permettre de raisonner à l’exé- cution sur les décompositions structurelles des propriétés compositionnelles des composites, compte tenu des composants de leur hiérarchie. Les patrons d’intégration et le support compositionnel sont effective- ment exploités pour propager les processus de négociation dans le cadre de la politique par effort, mais ils restent potentiellement réutilisables dans d’autres contextes. Les propositions ont ainsi été effectuées en s’attachant à les abstraire des technologies à composants, néanmoins, la mise en œuvre effective, dans la plate-formeFractal , des patrons d’intégration et du support de raisonnement compositionnel est décrite. Celle-ci est réalisée en réutilisant directement des éléments de base des composants de la plate- forme, et en définissant une nouvelle interface de contrôle qui permet de gérer les diverses propriétés compositionnelles des composants composites paramétrés. Les différents éléments du modèle proposé sont illustrés et discutés au travers de plusieurs exemples de contrats et de scénarii de négociation extraits du cas d’étude présenté dans l’annexeA. Cette annexe présente le cas d’étude de façon plus complète et fournit des exemples de négociation complémentaires.
Intégration, évaluation et expérimentations
Ces contributions s’intègrent dans la plate-forme de composants Fractal . Une implémentation du modèle de négociation est réalisée en se basant sur la première version du systèmeConFract et sur la der- nière version 2.5 de l’implémentation de référenceJulia de la plate-forme Fractal . Le chapitre8fournit une vision complète de l’architecture du système de négociation et des interactions entre les principaux éléments, implémentés eux-mêmes sur la base de composantsFractal contenus dans les membranes des composants métiers concernés. En particulier, l’implémentation du système de négociation présente les caractéristiques suivantes. Elle respecte les règles de visibilité des composants, réutilise avantageusement la notion de partage de composants et exploite une caractéristique majeure, proposée dans la version 2.5 deJulia, d’architecturer les membranes de composants par des composants. Différents composants sont définis dans ce sens, ils sont créés à l’exécution lors des déclenchements des processus de négociation et sont associés aux composants métiers concernés par les négociations, par reconfiguration dynamique de leur membrane. Enfin, le chapitre9fournit des éléments d’évaluation qualitative à la fois du modèle et des processus de négociation. Il présente des éléments méthodologiques pour l’utilisation du modèle de négociation, et analyse les premières évaluations de performances, en termes de temps d’exécution et de consommation mémoire, réalisées dans le cadre d’une application très simple.
10.2 Perspectives
S
Ur la base du travail réalisé durant cette thèse, nous identifions les perspectives de recherche suivantes.Les perspectives directes à court et moyen terme sont d’abord présentées avant de discuter les axes de recherche qui sont liés à des travaux à plus long terme.
Perspectives à court terme
Stabilité et cohérence du système de négociation Comme nous l’avons évoqué dans le chapitre9, une des principales limites des processus de négociation concerne le contrôle général des négocia- tions (réalisation d’actions d’adaptations incontrôlées, propagations en cascade, cycle de violations et re-négociations de contrats dépendants, etc.). Il est possible d’appliquer des solutions locales pour trai- ter individuellement chacune de ses limites (désactivation des contrats violés en boucle, définition d’un nombre maximal de niveaux de propagation, définition d’une durée maximale de négociation,...). Tou- tefois, dans une approche plus complète, une piste intéressante de recherche consisterait plutôt à étu- dier dans quelle mesure il est possible d’exprimer ou d’inférer les relations et dépendances qui peuvent
Chapitre 10. Conclusion et perspectives
exister entre les éléments des négociations atomiques (clauses dépendantes, propriétés liées, etc.). Cela pourrait se faire, par exemple, par observation du système, des contrats et des négociations à l’exécution, par analyse statique des clauses des contrats, ou encore par analyse des dépendances entre propriétés extrafonctionnelles contractualisées. Ainsi, comme ces limites découlent surtout des relations d’interdé- pendances qui peuvent exister, la meilleure compréhension de ces dépendances permettrait de les gérer d’une façon plus globale.
Modélisation d’autres propriétés extrafonctionnelles Lors de l’intégration des propriétés extrafonc- tionnelles dans les composants, notre étude était restreinte aux propriétés quantitative, de bas-niveau et orthogonales aux composants. Il serait bien évidemment intéressant de prolonger cette étude en considé- rant d’autres propriétés extrafonctionnelles, notamment des propriétés temporelles. Cette étude pourrait ainsi s’appuyer sur des systèmes d’interception et de surveillance à l’exécution, des approches basées sur des scénarii de simulation [Bondarev et al. 2004] ou encore des canevas d’analyse statique [Defour et al.2004a]. De plus, comme nous l’avons souligné, une dimension de plus en plus importante réside dans les possibilités de pouvoir raisonner compositionnellement sur des propriétés extrafonctionnelles d’un système, compte tenu des entités d’architectures qui la structurent, tout cela dans le but final de faciliter l’évaluation des qualités du système global. Un autre prolongement de ce travail pourrait ainsi consister à étudier d’autres formes de composabilité des propriétés extrafonctionnelles, qui prendrait par exemple en compte d’autres types d’opérateurs ou de modèles de composition (automates, modèles mar- koviens...) [Reussner et al. 2003], ou des éléments ou des propriétés qui ne découlent pas uniquement de composants [Crnkovic et al. 2004] (profils d’utilisation, influences de l’environnement...).
Expérimentations et évaluation de performances complémentaires Les premières évaluations quan- titatives se placent dans le cadre d’une application très simple et mesurent le coût des négociations en termes de temps d’exécution et de consommation mémoire. Les surcoûts mesurés découlent directement du choix d’implémenter le système de négociation sous la forme de composants. Par ailleurs, celle-ci est aussi réalisée sans optimisation, ni surJulia, ni sur le système lui-même (instanciation des composants, chargement des stratégies, etc.). Une perspective directe consisterait donc à travailler sur l’optimisation de certains éléments de l’implémentation, et nous pensons que l’architecture à composants du système de négociation peut à l’inverse être utilisée pour déjà identifier et isoler certains points d’optimisation (définition de composants singletons pour les fabriques ou les builders, réutilisation de composants de stratégies, etc.). De plus, selon les contraintes des applications cibles, il sera toujours possible d’effectuer des optimisations similaires au niveau de l’implémentationJulia (fusion des objets d’interception et de contrôle des composants), et un retour à une version tout objet reste envisageable si les contraintes sont fortes. De nouvelles expérimentations sur le JDK 1.6 sont aussi à effectuer. Du point de vue de l’efficacité de l’adaptation, puisqu’aucune mesure relative à cela n’est effectuée à ce stade, nous comptons mettre en place une évaluation plus complète des mécanismes de négociation sur des applications de taille et de complexité significatives, à commencer par celle qui fait l’objet de notre étude de cas. Cette évaluation devra notamment définir les métriques de réussite de l’adaptation (nombre d’appels réussis, minimisation des montées en charge des ressources...) ainsi que l’environnement de simulation (injections de charges diverses).
Application du modèle à d’autres plates-formes Le modèle de négociation proposé est actuellement validé sur la plate-forme de composants logiciels Fractal . Dans l’optique de généraliser le modèle de négociation, il serait pertinent d’étudier l’application du modèle à d’autres types d’architectures et de plates-formes. En particulier, les architectures orientées service [Erl 2005] et les plates-formes de web services [Weerawarana et al. 2005] constituent un domaine d’étude fort intéressant, car elles aussi in-
10.2. Perspectives
tègrent et proposent de plus en plus des formes de contrats et de négociation. Ainsi, des travaux de re- cherche à court terme consisteraient i) à étudier l’utilisation des mécanismes de négociation en tant que tels pour l’établissement de contrats/accords qui vont régir les interactions fonctionnelles fournisseurs et consommateurs de services, ii) à exploiter les mécanismes de négociation en tant que moyens d’adap- tation pour rétablir des contraintes extrafonctionnelles non satisfaites au niveau des interactions métiers (Service Level Objectives en anglais), et iii) à exploiter les mécanismes de négociation pour concevoir des applications orientées services auto-adaptatives dès lors qu’ils sont implémentées sous la forme de composants. Il est à noter que compte tenu de la généralité du modèleFractal , une première étape de ces travaux serait de virtualiser une interaction orientée service – consommateur/fournisseur – par des com- posantsFractal et de travailler directement sur ces derniers. Dans cette démarche, une première boîte à outils a déjà été réalisée pour établir plus facilement des ponts entre composants logiciels et web services [Collet et al. 2007a]. Ces derniers automatisent l’exposition d’interfaces de composants sous la forme de web services, ainsi que l’intégration d’un web service externe dans un assemblage de composants. La représentation architecturale, par des composants, d’orchestrations de web services est aussi à l’étude. Enfin, une perspective à beaucoup long terme est de proposer une virtualisation de systèmes logiciels dans le but d’intégrer et de réaliser, de façon homogène, diverses fonctionnalités d’administration et de maintenance. Compte tenu des qualités du modèleFractal , une telle virtualisation pourrait être implé- mentée sur ce modèle et celle-ci offrirait alors une abstraction et une vision hiérarchique des systèmes dans laquelle i) les composants implémentent des fonctionnalités propres ou interfaçent des systèmes patrimoniaux existants, et ii) les différentes opérations d’administration et de maintenance sont réalisées en prenant appui sur les fonctionnalités de contrôle (réalisation d’interceptions, intégration de divers services de contrôle,...).
Axes de recherches
Suivi des évolutions du système, des contrats et des adaptations Les contrats du système ConFract, sur lequel s’appuie principalement nos propositions, suivent le cycle de vie des composants et sont mis à jour lors de leurs reconfigurations dynamiques. Toutefois, il n’y a pas réellement de maintien des évolutions successives des contrats. Pour augmenter les possibilités d’analyse de ces éléments (compo- sants, contrats, adaptations) et de leurs relations mutuelles, il serait intéressant de capturer et de main- tenir à l’exécution, d’une part les évolutions successives des contrats déjà réifiés, mais aussi celles qui concernent l’architecture des composants et les actions d’adaptations effectuées par la négociation. Par exemple, cela pourrait se faire par une architecture à couches dans laquelle : i) le niveau de base représen- terait les instances des composants applicatifs courants, ii) un second niveau maintiendrait les évolutions de l’architecture des composants, initialisée avec l’architecture initiale et mis à jour selon les reconfigu- rations dynamiques des composants, iii) un troisième niveau maintiendrait les évolutions des contrats, initialisé par les contrats issus des spécifications initiales et mis à jour selon les reconfigurations des com- posants, et iv) le quatrième niveau maintiendrait les actions d’adaptations résultantes de la négociation, effectuées tant sur le niveau des contrats que sur le niveau des composants. Ainsi, il serait possible de conserver les historiques des évolutions de chacun de ces éléments mais aussi d’envisager des retours à des configurations ’composants-contrats-adaptations’ stables.
Pilotage global de l’auto-adaptation Les mécanismes d’auto-adaptation reposent sur les négocia- tions atomiques. Celles-ci sont définies dans un contexte (portée spatiale, composants impliqués, clause concernée) bien précis, et les négociations atomiques peuvent donc se dérouler de façon indépendante les unes des autres. Dans une telle approche décentralisée, il n’est actuellement pas possible d’avoir une vue globale des différentes négociations atomiques qui se déroulent et cela empêche donc définir des stratégies globales de contrôle de ces différentes négociations atomiques. Dans cette optique, une
Chapitre 10. Conclusion et perspectives
autre piste intéressante de recherche consisterait à étudier dans quelle mesure il est possible de spé- cifier un système de négociation, ou plus généralement d’auto-adaptation, de façon à ce qu’il puisse piloter et optimiser l’adaptation du système global à partir d’objectifs de haut-niveau et en agissant sur les mécanismes d’adaptation sous-jacents – les négociations atomiques dans notre cadre. Cela pourrait, par exemple, consister à configurer les mécanismes d’auto-adaptation, à gérer des conflits entre actions d’adaptations locales, ou encore à piloter de négociations dépendantes. Toutefois, pour mettre en œuvre cela, des études plus approfondies sont bien évidemment requises.
Méthodologie pour l’adaptation Dans ce travail de thèse, comme dans la plupart des techniques d’adaptation, les mécanismes mis en œuvre sont automatisés à condition que les logiques d’adapta- tion soient fournies. En conséquence, le point crucial est à ce niveau et compte tenu de l’importance croissante de l’auto-adaptation et de l’émergence de très nombreux mécanismes pour supporter cela, il devient maintenant pertinent de s’attacher à développer une certaine méthodologie de l’adaptation. En particulier, cette méthodologie pourra adresser les questions suivantes : i) étant donné un système logi- ciel donné qui fonctionne dans un environnement d’exécution, comment identifier les événements sur lesquels réagir, puis les bonnes actions d’adaptations à mettre en œuvre en réponse à ces erreurs ?, ii) comme un des buts de l’auto-adaptation est de rétablir un certain niveau de fonctionnement acceptable des systèmes, dans quelle mesure est-il possible d’évaluer quantitativement, peut-être par la définition de critères d’optimalité ou de sous-optimalité sur des propriétés globales du système, que les adaptations marchent effectivement ? iii) pour des systèmes qui fonctionnent sur des durées réellement longues, dans quelle mesure est-il possible de ré-évaluer l’adéquation des logiques d’adaptation initiales et de les faire évoluer au cours du temps ?