Chapitre 7 Gestion du dynamisme dans les composants atomiques et composites
4. Principes et concepts des types de composants composites pour supporter le dynamisme
Bien que créer des composants atomiques soit nécessaire pour développer des applications dynamiques, il est devenu également crucial de proposer un modèle de composition permettant d’assembler des applications tout en masquant le dynamisme. Ce modèle de composition doit se rapprocher de la composition proposée par les langages de description d’architecture. Des caractéristiques telles que le support de la hiérarchie sont également importantes.
iPOJO propose donc un nouveau style de composition appelé composition de service structurelle permettant de concevoir des applications dynamiques. La principale différence par rapport aux langages de compositions traditionnels est que ce modèle utilise la notion de service comme une entité de premier ordre en plus de posséder la notion d’instance traditionnelle. De plus, chaque composition possède son propre contexte de service. Ainsi les services exposés dans le composite sont isolés. Une application créée à l’aide de ce modèle pourra être géré de manière dynamique lors de l’exécution. Une telle composition (Figure 82) est décrite en fonction de trois différentes entités :
Des sous-services (dépendance de service) qui sont des services disponibles à l’intérieur de la composition (et donc publiés dans le contexte de service attachés à la composition)
Les services fournis qui seront des services exportés dans le contexte de service parent (ce sont alors des services fournis)
Des instances qui sont instanciées directement tel que le propose les langages de description d’architecture traditionnelle
125 Les types de composant composite sont des types de composants. Une instance d’une composition peut suivre les mêmes règles qu’une instance d’un composant atomique. Cette section décrira plus en détails ces différents éléments d’une composition et comment ils réagissent face au dynamisme lors de l’exécution.
4.1. Sous-services
La notion de sous-service est l’implantation des dépendances de service pour les composites. Un composite peut ainsi utiliser des services. Cependant, deux types d’action sont envisageables afin de consommer ce service (Figure 83):
Instancier le service au sein du composite
Importer ce service depuis le contexte de service supérieur
Lors d’une instanciation, le composite recherche une implémentation de service. Si une implémentation compatible est disponible, une instance est créée. Cette instance vit au sein du composite. L’instance ainsi créée n’est disponible que dans le composite lui-même. Le dynamisme est supporté via le remplacement de l’instance si l’implémentation utilisée disparaît. En effet, cette dépendance étant une dépendance de service elle ne cible pas d’implémentation particulière. Ceci permet donc de substituer l’instance par une instance provenant d’une autre implémentation disponible. L’état peut être sauvegardé et réinjecté si la spécification de service définit son modèle d’état. Lorsque cette dépendance est agrégée, une instance par implémentation disponible est créée.
Figure 83. Exemple de sous-service et d'import de service
Un import de service publie un service disponible dans le contexte de service supérieur dans le contexte de service de la composition composite. Ce style de dépendance réagit de manière similaire aux dépendances de service des composants atomiques. Ainsi, dès lors qu’un fournisseur est disponible dans le contexte du parent, celui-ci est publié dans le contexte de service du composite. Ceci est très différent des services instanciés. En effet, le fournisseur importé n’est pas isolé dans le composite et donc peut éventuellement être utilisé par d’autres consommateurs vivant dans le contexte de service supérieur.
Clement Escoffier 126 Ces deux dépendances suivent le modèle de dépendance de service d’iPOJO. Ainsi elles peuvent spécifier une politique de liaison, un comparateur, être agrégées, optionnelles ou filtrées. Les dépendances instanciées peuvent également fournir une configuration aux services instanciés.
4.2. Instances internes
La notion d’instances internes provient des langages de description d’architecture traditionnels. Grâce à ces instances, une composition peut demander la création d’une instance d’un type de composant particulier avec une configuration particulière. Cependant, le dynamisme lors de la gestion de ces instances est limité. En effet, vu qu’elle cible une implémentation particulière, ces instances ne peuvent être créées que lorsque la fabrique associée à cette implémentation est disponible.
Figure 84. Exemple de composition contenant une instance interne
Une instance créée ainsi vit dans le contexte de service de la composition et donc n’a accès qu’au service publié dans ce contexte de service (Figure 84). Ces instances peuvent être utilisées lorsqu’une instance ne fournissant pas de service est nécessaire comme par exemple pour une interface graphique. Elles peuvent être également utilisées comme glue code afin de personnaliser une implémentation de service tel que cela sera défini dans la prochaine section. Dans ce cas, cette notion d’instance se rapproche de la notion de module présente dans Koala [107].
4.3. Fourniture de service et export de service
Une composition peut également fournir des services. Deux mécanismes sont disponibles pour cela : L’exportation de service
L’implémentation de service
Dans les deux cas, le composite est alors considéré comme une implémentation du service et ainsi être instancié au sein d’une autre composition. Le modèle obtenu est donc un modèle hiérarchique identique au modèle de composition hiérarchique des modèles à composant. De plus, en tant qu’implémentation de service, la composition doit respecter les contraintes imposées lorsque les spécifications implémentées possèdent des dépendances de service.
127 Lorsqu’un service est exporté, le composite publie un service existant, c'est-à-dire publié dans son contexte de service, dans le contexte de service parent. Cette méthode requiert que le composite possède au moins un fournisseur de ce service. Cette exportation est très proche des liens promotes proposé par SCA.
Figure 85. Exemple de composition exportant un service
La deuxième méthode pour fournir un service est de l’implémenter. Cependant, ce service est implémenté par délégation. Ainsi chaque méthode est alors déléguée sur une entité vivante dans le composite possédant la même méthode (même nom et même argument).
Cette délégation peut être spécialisée pour chaque méthode pour indiquer le service à employer ainsi que la politique de délégation. Lorsque cette délégation n’est pas indiquée, iPOJO recherche automatiquement le schéma de délégation. iPOJO vérifie en permanence le schéma de délégation. Si un service ne peut plus être fourni (c'est-à-dire qu’une méthode ne peut plus être déléguée), l’instance devient invalide.
Deux politiques de délégation sont disponibles. La politique de délégation « One » délègue la méthode sur un seul fournisseur du service. La politique de délégation « All » délègue la méthode sur l’ensemble des candidats disponibles. Cette deuxième politique n’a de sens que pour les méthodes ne retournant pas de résultat.
Clement Escoffier 128 Lorsqu’une méthode est déléguée sur un sous-service optionnel, celui-ci est potentiellement absent. Dans ce cas, la méthode lance une UnsupportedOperationException30 pour indiquer l’impossibilité d’exécuter cette opération actuellement. Les instances internes sont également utilisées lors de la délégation. Ainsi une instance peut contenir un schéma de délégation pour une ou plusieurs méthodes d’un service fourni. Si une instance interne possède des méthodes d’un service fourni, elle sera systématiquement choisie pour exécuter ces méthodes (Figure 86). Il est ainsi possible de créer des composites fournissant des services à partir de sous- service tout rajoutant de la logique de composition au sein de ces instances internes.
4.4. Cohérence des compositions
La composition structurelle telle qu’illustrée dans cette section repose particulièrement sur les dépendances de niveau service introduits dans les spécifications de service. Grâce à ces dépendances, un assembleur peut décrire sa composition et vérifier que celle-ci est cohérente. En effet, une composition est cohérente si tous les services requis par les services et les instances internes introduits dans la composition seront disponibles lors de l’exécution.
Figure 87. Une composition cohérente (en haut) et une composition incohérente en bas
Ainsi, iPOJO vérifie la cohérence de la composition lors de son déploiement. En plus de vérifier que le graphe de dépendances de service est cohérent, iPOJO vérifie également que toutes les méthodes des services fournis par implémentation peuvent être déléguées.
Il est important de comprendre que cette vérification ne concerne que les dépendances de service de niveau spécification. Ainsi lorsqu’une implémentation possède des dépendances de service d’implémentation celles-ci sont résolues différemment tel qu’expliqué page 111. La disponibilité de tel service ne peut être vérifiée à l’avance.
30
129
4.5. Source de contexte et gestion du dynamisme contextuel
Bien que les concepts introduits dans la composition permettent de gérer le dynamisme provenant de l’évolution de l’application (via la substitution d’instance) ainsi que le dynamisme d’environnement (via les importations de service), le dynamisme provenant d’un changement de contexte n’est pas géré ainsi. En effet, il est parfois nécessaire de réagir pro-activement au dynamisme lors d’un changement de contexte [188].
Afin de supporter ce type de dynamisme, les sous-services peuvent déclarer des filtres contextuels. Ces filtres seront alors reconfigurés en fonction des sources de contexte disponibles. Une source de contexte est simplement un moyen pour obtenir des informations sur le contexte et être notifié de changement tel que défini dans [189]. Les sources de contextes (accessible sous la forme d’un service) peuvent être choisies ou non, locales au composite, globales ou importés du parent.
Figure 88. Reconfiguration des dépendances de service en fonction du contexte
Clement Escoffier 130 Le gestionnaire de contexte s’enregistre aux différentes sources de contexte (Figure 88). En fonction des informations disponibles, ce gestionnaire reconfigure les dépendances de service (à la fois les services instanciés et importés). Cette reconfiguration porte sur l’injection de valeur dans les filtres contextuels (Figure 89).
Grâce à ce filtrage contextuel, il est possible de créer des compositions réagissant au contexte. Le contexte peut donc influencer à la fois les services importés mais également les implémentations de service choisies rendant le modèle de composition très flexible.