Architecture de référence proposée

!$ !" !# !$

FI G U R E 4.8 – Changement du classement de services

4.3.6 Adaptation autonomique globale

Comme indiqué précédemment, nous avons également décidé d’ajouter une boucle de contrôle globale pour gérer une application dans sa globalité. Il s’agit à ce niveau de gérer les paramètres de configuration et les différents éléments de l’application ainsi que sa topologie. Ce dernier point peut se traduire par exemple par l’ajout, le retrait ou le remplacement d’un composant mais également la reconfiguration des liaisons entre les composants. Une telle boucle de contrôle doit être capable de surveiller l’état global de l’application en cours d’exécution, de prendre des décisions d’adaptation si nécessaire, et de mettre en œuvre ces adaptations.

Introspection

Le gestionnaire autonomique global doit posséder une vue du système de haut-niveau lui permettant de décider des reconfigurations à effectuer. Cette vue contient non seulement l’ensemble des composants utilisés par le système et les liaisons entre eux mais également des données métier collectées soit par des composants spécifiques, soit récupérées à partir d’une source de données. Par exemple, dans le contexte de l’informatique ubiquitaire, le gestionnaire global a accès au contexte physique

(température, luminosité, etc.).

Pour l’ensemble des données remontées, il est important pour le gestionnaire de pouvoir avoir une capture de l’état mais également un ensemble de notifications permettant de suivre l’évolution. Le gestionnaire compose sa propre vue et les notifi-cations importantes en fonction de son but.

Adaptation

Le gestionnaire global a accès à un vaste panel d’adaptations possibles. Pour cela, il interagit avec un modèle de représentation de la machine d’exécution. Ce modèle fournit également un ensemble d’opérations d’adaptations de haut niveau.

Le modèle présenté est synchronisé, c’est-à-dire que les changements d’état de la plateforme d’exécution sont répercutés sur l’état du modèle, et vice et versa. Les actions de reconfiguration du gestionnaire global reposent sur les gestionnaires de composants et de liaisons présents.

4.3.7 Architecture de référence proposée

Dans le cadre de cette thèse, nous proposons de fournir les parties génériques permettant le développement et l’exécution d’applications autonomiques spécifiques.

!"##$%& %'(%)#%&

!"#$%&'#&'(&)(*+&,-.-/",'#0'+1+-$2&

FI G U R E 4.9 – Positionnement du modèle de représentation

Notre canevas propose donc un modèle de développement pour les applications au-tonomiques. L’architecture de référence des applications ubiquitaires autonomiques développées au-dessus de ce canevas repose sur les axiomes suivants :

1. Séparation des préoccupations : les aspects fonctionnels (métiers) des applica-tions et leurs aspects autonomiques sont clairement séparés.

2. Architecture à composants orientés services : la partie métier des

applica-tions est construite sous forme d’un assemblage de composants fonctionnels (C).

Chaque composant peut utiliser les services (S) disponibles sur la plateforme

d’exécution et fournir de nouveaux services.

3. Dynamisme de l’architecture : les services sont dynamiques et peuvent appa-raître, dispaappa-raître, changer à tout moment. L’assemblage de composants métiers, liés entre eux par des services, forment donc une architecture dynamique.

4. Dynamisme des composants : chaque composant métier pris indépendamment

peut nécessiter une inspection de son état et une reconfiguration de cet état. Un composant doit donc être conçu en envisageant sa manipulation par un gestionnaire externe.

5. Représentation du système : le système doit fournir une représentation de

lui-même (R). Cette représentation est un fondement de sa gestion par un

ges-tionnaire autonomique. Un administrateur humain peut aussi avoir à inspecter cette représentation du système afin d’identifier des problèmes et adapter les politiques de haut-niveau.

6. Gestionnaire autonomique d’application : l’application est gérée par un

ges-tionnaire autonomique MAPE-K global (AM_global). Ce gestionnaire offre une

inter-face permettant à un administrateur de configurer les objectifs de haut niveau de l’application. Le gestionnaire global repose sa base de connaissance sur le

modèle représentatif (R) de l’application.

7. Gestionnaires autonomiques de composants, de liaisons : Afin de décomposer les buts de haut-niveau en tâches plus spécifiques et techniques, le gestionnaire

global (AM_global) s’appuie sur un ensemble de gestionnaires autonomiques

4.4. SYNTHÈSE ! "#_$%&'(% ! " # "#)&*+&,(-. $ "#)&*+&,(-. "# %/(/,&-% & % ' "++%/)(./&-( )

FI G U R E 4.10 – Architecture d’une application autonomique selon le canevas proposé respectivement, d’adapter les composants et les liaisons auxquels ils sont dédiés. Les gestionnaires de liaisons peuvent éventuellement à leur tour être décomposés en gestionnaires de fournisseur de services et en gestionnaires de dépendance de services.

La figure 4.10 illustre l’architecture d’une application conçue selon les principes énoncés ci-dessus. Les parties en gris sont les mécanismes existants, fournis par la couche d’exécution (points 1 à 4). Les parties en vert sont les extensions de cette couche d’exécution, qui permettent la mise en œuvre d’applications autonomiques. Ces mécanismes fournissent les parties génériques qui vont permettre le branchement des différents gestionnaires autonomiques sur l’application (points 5 à 7). Enfin, les parties en bleu représentent les parties applicatives spécifiques : elles comprennent le code métier des composants applicatifs, ainsi que l’implantation des différents gestion-naires autonomiques. Bien que la représentation du système soit considérée comme générique, elle contient de nombreuses données spécifiques issues des différents gestionnaires autonomiques. La couche d’exécution fournit un modèle de base repré-sentant l’exécution de la plateforme ; ce modèle est ensuite étendu par les données provenant des bases de connaissance spécifiques des gestionnaires autonomiques.

4.4 Synthèse

La proposition de cette thèse vise à fournir les mécanismes permettant de simplifier grandement la mise en œuvre d’une application autonomique. Au développement, le code métier est découpé en composants liés par des interfaces de services. La gestion autonomique est séparée de la logique métier. La conception de la partie de gestion autonomique de l’application est centrée autour d’une représentation uniforme du système. Au sommet, le gestionnaire global traduit les buts de haut niveau de l’administrateur en tâches spécifiques, exécutées par les gestionnaires autonomiques de composants et de liaisons. À l’exécution, le système est en permanence représenté par le modèle central. Ce dernier est scruté et augmenté par tous les gestionnaires autonomiques de l’application.

Le chapitre suivant va s’attacher à préciser les parties spécifiques de la gestion au-tonomique en montrant quelles sont les données qu’elles remontent aux gestionnaires et les actions qu’elles permettent d’exécuter. Les caractéristiques du modèle central de représentation du système et ses interactions avec les différents gestionnaires autonomiques seront aussi expliquées.

Chapitre 5

Extension de la machine

d’exécution iPOJO

Le chapitre précédent a décrit les principes permettant une conception facilitée d’applications autonomiques. La machine d’exécution doit pouvoir offrir des méca-nismes élémentaires d’adaptation des composants pendant leur fonctionnement. En offrant un modèle d’exécution adaptable, les gestionnaires autonomiques gagnent en simplicité d’expression, et peuvent ainsi remonter des informations plus pertinentes et exécuter des actions de plus haut-niveau, sans devoir se soucier du fonctionnement de la couche d’exécution. Le modèle à composants à services iPOJO fournit un certain nombre de points d’adaptation pour les composants, et constitue donc un candidat idéal pour l’ajout des principes Autonomic-Ready susmentionnés.

Ce chapitre va maintenant détailler la mise en œuvre de ces mécanismes au sein du framework iPOJO. Les modifications proposées vont donc permettre de rendre la couche d’exécution suffisamment adaptable pour l’intégration naturelle de boucles de contrôle autonomiques.

Sommaire

5.1 Rappels . . . 113 5.2 Extensions requises et contraintes . . . 114 5.3 Introspection par l’API . . . 116

5.3.1 Interception au niveau du conteneur . . . 117 5.3.2 Interception au niveau des dépendances de service . . . . 125 5.3.3 Interception des liaisons de service . . . . 133 5.3.4 Bilan des intercepteurs de dépendances de services . . . . 133 5.3.5 Interception au niveau des fournitures de service . . . 134 5.3.6 Impacts sur l’architecture . . . . 136

5.4 Représentation de la connaissance . . . 138

5.4.1 Principes du style d’architectureREST . . . . 140 5.4.2 Représentation uniforme du contexte proposée . . . . 140

5.1. RAPPELS

5.1 Rappels

Dans le cadre de cette thèse, nous avons choisi comme fondation l’approche à

composants orientés service en nous appuyant sur le framework iPOJO. Ce dernier

favorise la modularité des applications et le couplage faible entre composants ; au-tant de qualités qui facilitent l’adaptation des applications et leur gestion par un gestionnaire autonomique. La version d’iPOJO de base n’offre cependant pas toutes les caractéristiques permettant la conception et le support à l’exécution d’applications autonomiques.

Comme nous l’avons vu précédemment, la clé de l’adaptation d’un système repose sur la capacité de sa machine d’exécution à exposer un modèle satisfaisant aux dif-férents gestionnaires autonomiques. Ce modèle se doit de remplir certain critères fondamentaux, afin de permettre la surveillance et la modification du système par le gestionnaire, ainsi que de faciliter sa conception et son évolution :

– le modèle doit être réflexif. Il doit permettre l’introspection de l’état de la

pla-teforme : non seulement il doit être possible de récupérer, à tout moment, un instantané de l’état actuel, mais il est nécessaire de pouvoir être notifié lorsque certains changements d’états, significatifs pour le gestionnaire autonomique, surviennent. Le modèle doit aussi permettre l’intercession, c’est-à-dire la modifi-cation du comportement de la plateforme, pour mettre en œuvre les adaptations commandées par le gestionnaire autonomique.

– le modèle doit fournir un niveau d’abstraction satisfaisant : les données

re-montées au gestionnaire autonomique ainsi que les structures qu’il manipule doivent écarter les considérations techniques de bas niveau, spécifiques à la plateforme. La simplicité du modèle est un gage de facilité de son utilisation. Il doit cependant offrir un accès complet à tous les éléments s’exécutant sur la plateforme.

La plateforme d’exécution Apache Felix iPOJO a été conçue dans le but de faciliter la conception des applications dynamiques à base de composants à service. Elle favorise la gestion de la modularité et du dynamisme des applications tout en masquant sa complexité derrière un modèle de développement simple, focalisé sur le code métier. La gestion des aspects techniques, le dynamisme notamment, est une tâche complexe

et source de nombreuses erreurs (deadlocks,race conditions,etc.). iPOJO encapsule le

code fonctionnel à l’intérieur d’un conteneur, et permet aux applications de s’exécuter naturellement dans des environnements hétérogènes et dynamiques.

Comme indiqué dans le chapitre précédent, nous avons décidé d’étendre iPOJO pour permettre le développement aisé de boucles de contrôle multiples. Ces boucles de contrôle doivent être en mesure de récupérer de manière simple les informations sur les éléments qu’elles gèrent : composant, liaison ou application. De plus, les composants et les liaisons doivent pouvoir être adaptés par ces mêmes gestionnaires. Les gestionnaires récupèrent donc des informations de contexte depuis les éléments gérés (entre autres) et adaptent ces éléments en fonction de ce contexte. La principale manifestation de cette difficulté d’adaptation concerne l’adaptation de l’architecture des applications. Les dépendances de service sont exprimées sous forme d’interface et de filtres de sélection. iPOJO permet au développeur d’un composant de spécifier ce filtre de sélection, et au gestionnaire autonomique de le modifier à la volée. Cependant,

le niveau d’expression de ce filtre, et sa syntaxe rébarbative (basée sur LDAP) font

qu’il est, en pratique, peu utilisé par les concepteurs de composants, qui préfèrent effectuer la sélection de manière programmatique. De plus, l’écriture de gestionnaire

!"#$%&'" (" %"')$*"% !"&'+$& !"*,"'*," -.')"$//+0*" !"#$%&$'#()" 1$+$%2033433!.5&.'" 62752%+0& 82.'0$%%".' ("3%"')$*"% 9.:/$*+&$20 62752%+0& *20%277+&".' ("3%"')$*"%

FI G U R E5.1 – Interception des appels au registre de services

autonomique s’en trouve grandement complexifiée : ces filtres ne permettent pas d’inclure des variables de contexte, et le gestionnaire doit donc le rafraîchir à chaque fois qu’un changement contexte est susceptible de modifier la sélection de services couramment utilisée. Ceci fait que les filtres de sélection calculés par le gestionnaire autonomique sont souvent de très grande taille, ce qui amène des problèmes de performances pour la plateforme, et de lisibilité pour l’administrateur.