Quelques plateformes adaptatives à base de composants

De nombreuses plateformes d’exécution adaptatives à base de composants existent et permettent de réaliser des adaptations compositionnelles. B. Morin dans sa thèse [96], montre que la plupart de ces plateformes d’exécution fournissent des API pour l’introspection et la reconfiguration. Ces deux techniques sont les principes de base de la réflexivité. La réflexivité est la capacité d’un système à observer et altérer son comportement [148]. Elle ne s’applique pas uniquement à la programmation orientée objet mais, avec le développement des machines virtuelles, son utilisation s’est désormais largement répandue. Elle repose sur deux mécanismes : (1) l’intercession, qui est la capacité d’un système à modifier son comportement et (2) l’introspection qui est la capacité d’un système à s’ob- server. Pour ce faire, la réflexion repose sur deux niveaux. L’introspection consiste en particulier en la réification des entités logicielles composant l’application à un niveau méta. L’intercession, quant à elle, est le mécanisme qui permet de modifier ces entités réifiées. Le niveau méta, qui englobe les réifications et le code pour modifier ces entités est en connexion causale avec le niveau de base (l’ap- plication s’exécutant). Les modifications au niveau méta sont directement reportées au niveau de base de manière implicite, c’est le mécanisme d’absorption. Le niveau méta peut être vu comme un modèle de l’application s’exécutant [125]. De la même manière, dans les plateformes d’exécution que nous allons présenter, les modifications sont directement reportées au niveau de base. Hormis le modèle à

composant Fractal, les modèles OSGi, SLCA et SCA mélangent des concepts tirés à la fois des ap- proches orientées composants et services. A chaque modèle nous associerons une implémentation de référence qui offre des mécanismes d’adaptations compositionnelle.

Fractal est un modèle à composant [61] dont une implémentation de référence est Julia2. Dans ce modèle, l’entité de base d’une application est un composant. Il peut être primitif ou composite. Un composant primitif est une entité atomique dépendant d’une implémentation du modèle. Un com- posant composite se compose de plusieurs composants, il englobe un assemblage de composants. Le modèle de composant Fractal est donc hiérarchique ; des composants peuvent englober d’autres composants de manière récursive. De plus, les composants peuvent être partagés, c’est-à-dire pré- sents dans l’assemblage de plusieurs composites. Un composant Fractal se divise en deux parties : un contenu et une membrane. La membrane d’un composant peut contenir des intercepteurs ainsi que des contrôleurs. Les intercepteurs ont pour objectif d’intercepter les appels à certaines méthodes et les redirigent vers des contrôleurs. Les contrôleurs ont pour objectif de définir de quelle manière contrô- ler le contenu d’un composant. Les contrôleurs permettent alors par exemple de gérer l’assemblage interne d’un composite. Fractal fournit une API réflexive permettant de créer, introspecter et gérer composants, interfaces ou encore liaisons.

SCA pour Service Component Architecture est un standard avancé par l’OSOA3 qui propose d’agréger des concepts tirés des approches orientées composants et services [56]. Parmi les implé- mentations de référence, nous trouvons FraSCAti [111], une implémentation du standard au-dessus de Fractal. Il s’agit de réaliser des compositions de services par assemblage de composants. La réa- lisation d’un assemblage de composants permet de créer un service composite. L’élément de base d’une composition est le composant. Un type de composant peut avoir plusieurs implémentations à partir du moment où elles respectent sa description. Une description contient les références aux ser- vices utilisés par le composant ainsi qu’une description des services et des propriétés qu’il propose. Les fonctionnalités exposées par un composant prennent la forme de service. Le standard ne fait au- cune proposition quant à l’adaptation dynamique d’assemblages. Cependant, FraSCAti propose de tels mécanismes grâce à la mise en œuvre du standard au dessus de Fractal.

OSGi est un consortium composé de nombreux grands acteurs industriels4_{. OSGi propose un mo-}

dèle de composant orienté services, c’est-à-dire que des services sont implémentés à l’aide de com- posants [93] dont Felix5 est une implémentation de référence. Les services sont déployés dans des « bundles » (composants). Un bundle peut être un demandeur ou un fournisseur de services. Physi- quement, un bundle correspond à un fichier JAR contenant du code et des ressources. Les bundles OSGi gèrent eux-mêmes leurs dépendances. De cette manière, un bundle peut chercher lui-même des services requis satisfaisant ses dépendances. Un bundle peut également s’abonner à un mécanisme de notification l’informant quand un service est disponible. Le framework OSGi, qui est l’environnement d’exécution des bundles, fournit un ensemble de mécanismes pour gérer leur cycle de vie. L’adminis- tration, locale ou distante d’un framework permet l’installation, le démarrage, l’arrêt ou encore la mise à jour des bundles. Cependant, la gestion des dépendances interne aux bundles reste complexe.

2. http://fractal.ow2.org/

3. http://www.osoa.org/display/Main/Home 4. http://www.osgi.org/Main/HomePage 5. http://felix.apache.org

SLCA pour Service Lightweight Component Architecture est un modèle multi-paradigmes utili- sant : services, composants légers et événements [87]. WComp6en est l’implémentation de référence. Comme SCA, ce modèle permet de réaliser des compositions de services par assemblage de compo- sants. Pour ce faire, des composants proxy vers des services Web ou des services pour dispositifs peuvent être générés dynamiquement et intégrés dans un assemblage. Un assemblage de composant se trouve dans un conteneur qui peut lui-même être exporté comme un service composite. Le mo- dèle est donc hiérarchique puisque ce service pourra être utilisé dans un autre service composite. Les communications entre les composants sont événementielles. Un service composite exporte deux in- terfaces : (1) l’interface structurelle, qui permet de gérer le contenu du composite (ajouter/retirer des composants/liaisons ou encore modifier des propriétés) et (2) l’interface fonctionnelle qui permet de communiquer avec les composants internes du composite.

2.3.1.1 Discussion

Ces plateformes permettent de réaliser à l’exécution des adaptations compositionnelles. Comme nous l’avons vu, dans le cadre de l’informatique ambiante, le système sera appelé à être adapté de nombreuses fois. Dans ces plateformes, lorsqu’une modification est réalisée elle est directement reportée dans l’application, et ce, de manière implicite. Ce qui signifie que la moindre modification atomique est directement transposée de manière à ce que le niveau méta soit toujours l’exact reflet du niveau de base. Il n’y a pas de séparation claire entre les entités méta manipulées et les entités de l’application s’exécutant. Ainsi, comme cela est mis en avant dans [96] : « Modifying the model implies modifying the reality : there is no mean to preview the effect of a reconfiguration before actually executing it, or to execute what-if scenarios to evaluate different possible configurations, etc.» . Puisque nous souhaitons mettre en œuvre diverses adaptations que nous ne connaissons pas nécessairement à l’avance, ce type d’approche consisterait à réaliser les adaptations les unes après les autres puis à analyser le résultat déjà porté sur l’application s’exécutant afin de résoudre de potentiels conflits. Reporter les modifications directement dans l’application peut s’avérer risqué [54] et ne permet ni de juger de l’impact de ces modifications sur le système ni de vérifier leur cohérence. Par exemple, si l’ordre dans lequel les modifications sont portées n’est pas soigneusement étudié, peuvent alors apparaître dans l’assemblage des liaisons ouvertes ou encore des cycles qui ne pourront être identifiés qu’une fois l’adaptation réalisée. Il est également possible qu’une modification annule l’effet d’une autre modification. De plus, ce type d’approche peut mener au blocage successif de l’application lors de chaque modification apportée à l’application comme décrit en FIGURE2.6.

Comme nous l’avons vu dans la section 2.1, nous souhaitons stopper l’application le moins pos- sible durant une adaptation afin de la rendre la plus utilisable possible. Il serait alors intéressant de reporter ces modifications lors d’une unique opération atomique d’adaptation, n’interrompant ainsi l’application qu’une fois. Cela passe, entre autre, par le fait de ne porter dans l’application que les modifications dont la cohérence est vérifiée. L’utilisation unique des plateformes d’exécution adapta- tive n’est donc pas suffisante. Elles doivent être combinées à un mécanisme permettant de porter « à blanc » les modifications sur une image de l’application puis à déclencher explicitement la mise en œuvre des modifications afin de porter les modifications de manière atomique.

FIGURE2.6 – Dans les plateformes d’exécutions adaptatives classiques, les modifications portées au niveau méta sont directement transposées dans le niveau de base plutôt que d’être portée une fois que tout le calcul d’adaptation est réalisé.

2.3.2 Appliquer les adaptations sur des représentations abstraites des plateformes