iPOJO : un modèle à composant à service

Cette thèse propose un modèle à composant à service ayant pour but de proposer une infrastructure permettant le développement d’applications dynamiques en suivant les principes des SOA dynamiques étendus. Plus particulièrement, cette thèse combine des concepts d’architecture logicielle [69], de la programmation par composant [102] et de l’approche à service [137] afin de définir un modèle à composant permettant de concevoir, d’implémenter et d’exécuter des applications dynamiques telles que défini précédemment.

97 Figure 52. Principes des SOA dynamiques étendus

Ce modèle à composant doit fournir les fonctionnalités définis dans les architectures dynamiques étendues (rappelées dans la figure ci-dessus). Cette section décrit les exigences que doit remplir ce modèle à composant à service afin de fournir une infrastructure permettant la conception, l’implémentation, l’exécution et l’administration de systèmes dynamiques. En effet, tel que nous l’avons vu dans le chapitre précédent, il n’existe pas aujourd’hui d’infrastructure fournissant l’ensemble de ces fonctionnalités.

2.1. Un modèle et une machine d’exécution

La première exigence lors du développement d’iPOJO fut de concevoir à la fois un modèle et une machine d’exécution fortement liés. Ainsi, tous les éléments du modèle existeront lors de l’exécution. Ceci est primordial pour comprendre lors de l’exécution la structure de l’application. Ainsi, celle-ci sera décrite avec les concepts introduits dans le modèle.

Ce besoin a beaucoup contraint à la fois le modèle et la machine. En effet, les exigences étaient issues des deux parties : le modèle devait être simple tout en permettant l’expression du dynamisme, la machine d’exécution devait être capable d’exécution des applications utilisant le modèle défini et de gérer le dynamisme lors de ces exécutions.

2.2. Une architecture à service dynamique et isolation

Un modèle à composant à service repose nécessairement sur un SOA dynamique. En effet, les primitives liées à l'approche à service dynamique sont requises afin de gérer correctement le dynamisme. La machine d’exécution proposée repose sur OSGi™. En effet, la plate-forme de service OSGi™ propose toutes les primitives de l’approche à service dynamique nécessaire à la création d’application dynamique.

Cependant, dans les architectures à service traditionnelles, les services sont publiés de manière globale. Ainsi tous les consommateurs peuvent accéder à l’ensemble des services. Cette structure plate ne permet pas d’isoler certains services privés à application. Or, cette isolation est nécessaire afin de composer des applications telles que le proposent les mécanismes de composition des modèles à composant. L’architecture à

Clement Escoffier 98 service dynamique sous-jacente doit donc permettre d’isoler certains services dans un annuaire de service attachée à une application. Bien qu’iPOJO repose sur OSGi™, il permet d’isoler certains services dans des

architectures à service privées à une application. iPOJO reste néanmoins entièrement compatible avec OSGi™.

2.3. Un modèle de développement simple

Ensuite, le modèle à composant proposé fournit un modèle de développement simple. En effet, tout comme l’ont fait les précédents modèles à composant à service, il est nécessaire de masquer la complexité du SOA dynamique sous-jacent. iPOJO vise à proposer le modèle de développement le plus simple possible (basé sur l’idée de POJO [182]).

Celui-ci masque le dynamisme mais également les problèmes inhérents au dynamisme (gestion d’état, gestion des erreurs, synchronisation). Pour cela, la machine d’exécution d’iPOJO fournit une machine d’injection et de d’introspection permettant une gestion transparente de ces préoccupations pour le développeur d’application (Figure 53).

Figure 53. Utilisation d'une machine d'injection afin de gérer le dynamisme et les propriétés non-fonctionnelles liées

2.4. Un langage de composition structurelle

Tel que défini dans la pyramide du SOA dynamique étendu, iPOJO fournit un langage de composition structurelle. Afin de concevoir des applications dynamiques, iPOJO propose de composer les services structurellement. La principale différence par rapport aux langages de composition traditionnels vient du fait que la composition ne cible pas d’implémentation particulièrement, mais est exprimée en termes de spécifications de service. Ceci a l’avantage de découpler la composition des implémentations. A l’exécution l’infrastructure d’exécution choisira une implémentation disponible.

Les applications conçues ainsi sont gérées de manière dynamique. En effet, l’infrastructure d’exécution gère la disponibilité des implémentations de services, ainsi que les services importés et exportés dans et par la composition (Figure 54).

99 En plus de fournir une machine d’exécution capable d’exécuter ces compositions, il est nécessaire que cette machine vérifie en permanence la conformité de la structure de la composition par rapport à la description faite dans l’architecture de cette composition. Cette vérification doit porter sur les services et instances internes à la composition, mais également sur les services importés et fournis. En effet, avec le dynamisme, les instances et services internes peuvent être remplacés « à la volée », les services importés peuvent évoluer en fonction de la disponibilité des fournisseurs et enfin, les services fournis ne doivent être publiés que si la composition est capable de fournir réellement le service.

2.5. Des fonctionnalités d’introspection et reconfiguration dynamique

iPOJO doit également proposer des mécanismes afin d’introspecter l’état du système et de le reconfigurer. En effet, dans le contexte des applications dynamiques il est crucial de pouvoir remonter l’architecture du système actuelle afin de comprendre les connexions, les services requis manquants… De plus, il est souvent nécessaire de reconfigurer une application ou une instance de composant.

La découverte et la visualisation de l’état du système permet de connaitre précisément les interconnexions et la structure des applications exécutées. Ainsi un administrateur peut à tout moment vérifier l’intégrité de son système, traquer les services requis manquant, etc.

iPOJO supporte également la reconfiguration dynamique. Chaque composition et composant atomique peuvent être reconfigurés. Cependant, celle-ci n’est pas exprimée de manière traditionnelle [61] mais introduit le concept de service dans ces reconfigurations. Ainsi, un administrateur ne manipulera pas directement les connexions ou les instances mais spécifiera les contraintes à appliquer sur ces dépendances de service. iPOJO modifiera alors les services utilisés afin d’être compatible avec les nouvelles contraintes.

Tout comme pour les modèles à composant supportant la reconfiguration dynamique, ces reconfigurations peuvent être effectuées par un administrateur humain ou par un gestionnaire d’adaptation externe. Dans ce cas, le gestionnaire ne modifie que les dépendances de services ce qui évite de manipuler directement l’architecture de l’application.

2.6. Des mécanismes d’extension

Le SOA dynamique étendu veut également gérer des propriétés non fonctionnelles autres que celles liées au dynamisme et à la configuration. Cependant, chaque domaine d’application a son propre ensemble de propriétés non-fonctionnelles. Afin de prendre en compte ces préoccupations, iPOJO propose des mécanismes permettant d’étendre le modèle de base. En effet, il permet d’introduire de nouveaux handlers¹⁹ spécifiques à un besoin non-fonctionnel. Ce mécanisme d’extensibilité est disponible à la fois pour les composants atomiques et pour le langage de composition. Fournir un modèle à composant extensible n’est pas nouveau, cependant ces nouveaux traitants peuvent profiter des propriétés non-fonctionnelles déjà traitées et donc supporter le dynamisme. En effet, chaque nouveau traitant est un composant iPOJO et peut donc dépendre ou fournir des services. Le dynamisme de ces services sera géré par l’infrastructure d’exécution.

Ainsi le modèle à composant proposé peut être étendu avec de nouvelles propriétés non-fonctionnelles telles que la persistance, la sécurité, l’ordonnancement ou la qualité de service… Les traitants associés à ces préoccupations peuvent utiliser des services dynamiques gérés par iPOJO également²⁰.

19

Dans cette thèse, nous nous permettons d’utiliser le vocable anglais généralement admis.

20 En fait, toutes les propriétés non-fonctionnelles gérées par iPOJO suivent ce modèle, y compris la gestion du dynamisme.

Clement Escoffier 100