Gestion du dynamisme dans les instances de composants composites

Afin de montrer les bénéfices du modèle de composition proposée, cette section présente une application simple conçue avec de modèle de composition. Cette application est un éditeur de texte. Celui-ci est une composition contenant un sous-service central (éditeur) ainsi que d’un ensemble de plugin. La spécification de service de l’éditeur définit les fonctionnalités basiques de l’édition de texte ainsi que des fonctionnalités de manipulation de fichier (sauvegarde, restauration). Cette spécification définit également des points d’extension afin que les plug-ins puissent rajouter des icones, des menus ou manipuler le texte ou la gouttière.

Cette spécification définit deux dépendances de service. La première cible des plug-ins est agrégée. La deuxième dépendance est une dépendance optionnelle, simple sur service d’impression. Dans la composition, la dépendance de service sur les plug-ins est réalisée via l’utilisation d’un sous service (Figure 90). Ainsi, pour chaque implémentation de plug-ins, une instance sera créée à l’intérieur du composite. Dès qu’une nouvelle implémentation devient disponible, une instance sera créée. Si une implémentation disparaît, l’instance créée avec cette implémentation sera détruite. L’absence d’implémentation invalidera la composition. La dépendance sur le service d’impression est réalisée par un import de service. Ce service sera donc importé du contexte de service parent. Dès que celui-ci est disponible, le service d’impression sera publié dans le contexte de service de la composition. Si ce service disparaît, alors la composition en cherchera un autre. Lorsqu’ aucun service d’impression est disponible, le composite restera valide mais ne pourra pas utiliser les fonctionnalités d’impression.

Figure 90. Editeur de texte simple

Malgré la simplicité de cette éditeur, celui illustre parfaitement comment une application à plug-in peut être conçue avec le langage de composition proposé et comment le dynamisme est géré. Il est également

131 possible d’aller plus loin et de filtrer les plug-ins afin d’instancier seulement les plug-ins utiles. Dans cette première version, tous les plug-ins disponibles étaient instanciés sans regarder leur utilité par rapport à l’édition en cours. Si l’on modifie l’éditeur afin d’également proposé un service de contexte (une source de contexte), il peut alors annoncer le type de fichier (par exemple le type MIME³¹ du fichier) actuellement édité et notifié lorsque celui-ci change. Grâce à cette information, il est possible de filtrer dynamiquement les plug-ins utilisés. Ceci évite alors de surcharger l’éditeur avec des plug-plug-ins inutiles (Figure 91).

Figure 91. Editeur de texte avec une dépendance contextuelle

Figure 92. Editeur de texte réagissant au contexte

Dans cette seconde version, le sous -service représentant l’éditeur participe à la composition afin que celle-ci supporte les changements contextuels. En effet, grâce à la publication du type de fichier courant, seuls les plug-ins compatibles seront instanciés. Lorsque ce type change, l’ensemble des plug-ins à utiliser est

31

Clement Escoffier 132 réévalué. Ceci ne nuit pas au support du dynamisme : l’arrivée et le départ d’implémentation de plug-ins restent également gérés. Cependant, une implémentation apparaissant est utilisée seulement si elle est compatible avec le type de fichier actuellement édité. Cette séparation du support du contexte permet aux développeurs du service d’édition de se concentrer seulement sur le code métier de ce service. Il n’a donc pas à gérer ces changements de contexte.

Il est également possible d’aller encore plus loin si nous attachons un filtre contextuel à l’importation du service d’impression (Figure 92). Par exemple, la composition pourrait importer un service d’impression seulement si celui-ci est dans la même pièce que l’utilisateur. Ce filtre dynamique utilisera alors une source de contexte indiquant la position courante de l’utilisateur. Ainsi, les fonctionnalités d’impression seront activées et désactivées en fonction de la localisation de l’utilisateur et des services d’impression disponibles. En comparaison de la seconde approche ou la composition elle-même participer à la mise à jour du contexte, cette réaction à la localisation est totalement externalisée et transparente.

6. Synthèse

Ce chapitre a présenté les deux catégories de types de composant supportées dans iPOJO et plus exactement :

 Le modèle de développement des composants atomiques  Le modèle de composition supportant le dynamisme

Ce chapitre a donc décrit comment les composants atomiques pouvaient être implémentés et quelles étaient les propriétés importantes que devait supporter le modèle de développement utilisé pour cette implémentation. Ainsi, ce modèle de développement doit être à la fois simple et flexible. La simplicité doit tendre vers un modèle de développement POJO ne contenant que la logique-métier du composant mais également à un descripteur de type de composant concis et simple. Ainsi le dynamisme, les problèmes de gestion d’état, de synchronisation et les primitives de l’approche à service ne doivent pas apparaître dans le code du développeur. Le descripteur contient toutes les informations nécessaires afin de gérer le dynamisme. Cependant, cette simplicité ne doit pas limiter les possibilités.

Afin de proposer ce modèle, les types de composants atomiques décrivent les services fournis et requis mais également les méthodes d’activation et de désactivation, les variables d’état … Grâce à cette description, iPOJO peut gérer tous les types de dynamisme lors de l’exécution sans que l’implémentation du composant n’ait à le traiter. Ce chapitre a également montré comment ce modèle peut être projeté sur Java et le modèle de développement résultant. Celui-ci remplit les contraintes énoncées précédemment. En effet, le code du développeur peut ne contenir que la logique-métier. L’intégralité du dynamisme est gérée de manière transparente. Le descripteur est rendu très simple en supprimant toutes informations superflues et redondantes.

De plus, ce chapitre a présenté le modèle de composition proposé par iPOJO. Ce modèle de composition utilise la notion de service comme entité de premier ordre. Ainsi une telle composition peut ne pas avoir de lien avec des implémentations spécifiques ce qui permet alors la substitution d’une implémentation par une autre. Ce langage de composition reste tout de même proche des langages de description d’architecture afin d’être intuitif. Les compositions proposent également une notion d’isolation similaire à la composition verticale de l’approche par composant. Il a également montré comment une composition pouvait importer des services provenant du contexte de service supérieur.

Afin de supporter le dynamisme provenant de changement contextuel, la notion de filtre contextuel reconfigurant les dépendances de service a été présentée dans ce chapitre. Ainsi une application conçue avec

133 ce langage de composition devient automatiquement dynamique. Elle supporte toutes les sources de dynamisme, tels que l’évolution, le dynamisme d’environnement et les changements contextuels.

Bien que ces fonctionnalités décrites dans ce chapitre permettent de créer et d’exécuter des applications dynamiques, elles ne sont pas suffisantes. En effet, un SOA étendu dynamique doit également proposer des fonctionnalités d’introspection et de reconfiguration. De plus, l’ajout de nouvelles préoccupations non fonctionnelles est également un besoin important. Le chapitre suivant présentera les capacités d’introspection et de reconfiguration proposées par iPOJO. De plus, le mécanisme d’extensibilité mis en place sera également présenté afin de montrer comment des nouveaux besoins non-fonctionnels peuvent être gérés tout en garantissant le dynamisme.