Adaptation d applications à base de services

Transcription

1 Adaptation d applications à base de services Erwan Daubert 29 janvier 2009 Introduction Le développement des usages mobiles de l Internet et des puces à radiofréquence (RFID) devrait bientôt permettre la création d un Internet des objets dont les services accompagneront les utilisateurs dans chacune de leurs activités. Ces services de l Internet du Futur s étendront à des domaines aussi divers que la santé, l éducation, les services de proximité, le maintien à domicile, ou encore la maîtrise de l énergie. Dans ce contexte à la fois futuriste mais aussi tellement proche, le besoin de pouvoir faire évoluer les applications par l ajout, la modification ou la suppression de services est de plus en plus pressant afin de faire face à l apparition, et la disparition d équipement mais aussi pour faire face à l émergence continu de nouveaux services sur cet internet du futur. Traditionnellement, le cycle de vie d une telle application suit les phases successives de conception, développement, assemblage, configuration, déploiement et exécution. La maintenance de l application comporte généralement des opérations de reparamétrage d un composant (module logiciel), de reconfiguration d un assemblage de composants et ou de remplacement d un composant par un autre qui peut éventuellement fournir et requérir des contrats différents du composant initial. Ces trois types de modifications souvent englobés sous le terme d adaptation requiert généralement l arrêt de l application et oblige à reprendre le cycle de vie à partir de la phase d assemblage. Une adaptation peut être réalisée pour corriger le mauvais comportement d un composant, pour répondre aux changements affectant l environnement d exécution, pour étendre l application avec de nouvelles fonctionnalités ou pour améliorer ses performances. L adaptation est un événement de plus en plus fréquent dans le cycle de vie d une application. L adaptation dynamique consiste à introduire des modifications dans l application au cours de son exécution contrairement à l approche traditionnelle qui nécessite l arrêt total de l application. Ainsi par exemple, la modification du contexte, qui correspond à l ensemble des ressources disponibles (bande passante, CPUs,...) ainsi qu aux préférences des utilisateurs voire même aux propriétés de l environnement (météo, date,...) peut entraîner une adaptation dynamique de l application afin de respecter des contraintes (charge du réseau, charge mémoire,...). Les travaux autour des architectures orientées services (SOA Services Oriented Architecture) [18] vise justement à proposer un cadre pour la construction d applications ou de nouveaux services définis par assemblage de services pré-existant en cours d exécution. La plupart des plate-formes fournissent des mécanismes de base pour gérer la dynamique de telles applications mais sans pour autant fournir de réponse à la problématique de construction d application dynamiquement adaptable. Les approches par composants logiciels [29, 9] sont dans ce sens très complémentaires aux approches de constuction d applications par services. Si les premières permettent de structurer convenablement l application et facilite la réutilisation d entité logiciel existante, les suivantes offre un pouvoir d intégration très intéressant permettant de créer 1

2 dynamiquement de nouvelles applications à partir d un ensemble de services préexistants, distribué et hétérogène au niveau de leur protocole de communication. L objectif de ce document est de présenter les différentes plate-formes à composants et services existantes ainsi que les travaux simplifiant le développement d applications dynamiquement adaptables majoritairement menés dans le monde des composants logiciels. Cette étude vise à mettre en lumière les challenges encore à résoudre pour la conception d applications adaptables à base de services. La suite de ce document est structurée de la manière suivante. Il présente tout d abord en section 1 les principes des modèles à base de composants ou de services ainsi que quelques implémentations de plate-formes existantes. Ensuite, la section 2 définit ce à quoi correspond l adaptation dynamique et présente quelques modèles existants. Enfin la section 3 présentera l adaptation dynamique dans le cadre des plate-formes orientées services. 1 Services et composants logiciels Les plate-formes orientées services permettent de voir une application comme un ensemble d élements (services) interagissant entre eux. Dans cette partie, nous allons présenter la programmation par composant et son utilisation au sein des plate-formes orientées services. Ensuite, nous définirons des critères de comparaison concernant la dynamicité dans ce genre de plate-forme et enfin nous analyserons, par rapport à ces critères, des plate-formes existantes. 1.1 Composants et services À l instar de la programmation orientée objet [29], la programmation par composant définit le composant comme étant l élément de base d une application. Celui-ci peut être vu comme une entité indépendante encapsulant un ensemble de classes lui permettant de s exécuter. Dans une plate-forme orientée services [18], un composant offre un ensemble de services qui correspondent aux tâches qu il peut effectuer pour les autres composants. De plus, il peut requérir des services provenant d autres composants. Fig. 1 Représentation d un composant dans une plate-forme orientée services Une plate-forme orientée services peut donc être constituée d un ensemble de composants qui interagissent entre eux par l intermédiaire des services qu ils proposent et requièrent. Ces services peuvent être implémentés dans diverses technologies pouvant interagir entre elle de manière aisée et sans l intervention des développeurs mais simplement grâce aux plate-formes. L intérêt de ces services est aussi leur dynamicité. 2

3 En effet, c est lors de la demande d utilisation d un service, que celui-ci est connecté au demandeur et non pas directement au lancement de l application comme dans les plate-formes à composants. 1.2 Critère de dynamicité Dans une plate-forme orientée services, on peut définir deux critères de dynamicité. Le premier concernant l ajout, la suppression ou la mise à jour de services et de composants durant l exécution de l application. L autre concernant la composition dynamique des services, c est-à-dire l utilisation de services découverts au cours de l exécution de l application et non pas simplement des services définis au lancement de celle-ci. ajout, suppression et mise à jour Ajouter, modifier ou supprimer des composants ou services dans une plate-forme permet de faire évoluer celle-ci durant son exécution afin de prendre en compte les besoins des utilisateurs ou les contraintes imposées au système. Ainsi on peut adapter de manière dynamique le comportement de la plate-forme. composition dynamique de services Composer les services de manière dynamique permet de prendre en compte la présence ou non de ces services. Ainsi dans un contexte ou les services peuvent disparaître, il est possible de faire fonctionner l application même si toutes ses fonctionnalités ne sont plus présentes. 1.3 État de l art Nous allons ici développer les caractéristiques de quelques plate-formes existantes et les évaluer par rapport aux critères définis précédemment. Tout d abord nous présenterons Fractal (1.3.1) car c est la plate-forme sur laquelle sont basés les travaux que nous allons présenté dans la partie 2. Ensuite nous parlerons de OSGi (1.3.2) qui est aujourd hui l une des principales plate-formes orientées services dont une implémentation connue est Equinox, le coeur de l IDE Eclipse. Enfin nous parlerons de SCA (1.3.3) et ESB (1.3.4) qui présentent d autres approches possibles des plate-formes orientées services Fractal En 2000, dans le cadre du projet Jonathan [14], France Telecom R&D et l IN- RIA débute la conception d un modèle de composant. En 2002, sort la première spécification de Fractal [17, 2, 24] ainsi que la première implémentation (Julia). En plus de cette spécification, est défini un langage de description d architecture (ADL) permettant de décrire l architecture d un composant Fractal et basé sur le langage XML. Actuellement, Fractal en est à la version et date de février Fractal n est pas une plate-forme orientée services mais une plate-forme orientée composant. Un composant Fractal (figure 2) est un composant comme défini dans la programmation du même nom. Il dispose de deux types d interfaces visible pour les autres composants. Ce sont les interfaces dîtes serveurs qui regroupent les opérations que peut fournir le composant et les interfaces dîtes clientes qui correspondent aux interfaces requises par le composant pour qu il puisse fournir ces propres opérations. 3

4 Bien qu il n y ait pas la notion de service, elle peut être simulée par les liaisons entre les composants. Une application peut être vue comme un composant composite (figure 3) c est-à-dire composé de plusieurs sous-composants connectés les uns avec les autres. Ces connexions peuvent être prédéfinies dans un fichier Fractal ADL qui représente l architecture du composant. Ainsi c est au lancement de l application que sont établies les liaisons. Il est cependant possible de modifier ces liaisons si le composant offre une interface de type BindingController. Cette interface offre la possibilité de connecter et déconnecter les interfaces clientes du composant. L une des particularités de Fractal est aussi d offrir la possibilité de concevoir des composants partagés. Ainsi un même composant sera un sous-composant de plusieurs autres composants. Fig. 2 Représentation d un composant Fractal Fig. 3 Représentation d un composant Fractal composite OSGi L OSGi Alliance [25], organisation fondée en mars 1999, a publié un ensemble de spécifications définissant une plate-forme orientée services. Comme toute plate-forme orientée services, la plate-forme OSGi définie des composants exportant et requérant des services [5]. Ces composants peuvent aussi exporter et importer des packages. Ainsi il est possible de définir des composants ne contenant qu une API utilisée par les autres composants. La configuration d un composant dans la plate-forme se fait par l intermédiaire d un fichier que l on appelle le Manifest. Ce fichier de type texte contient des directives (méta-données) décrivant les caractéristiques du composant. Là où Fractal définissait statiquement les liaisons entre les composants, OSGi offre une liaison dynamique au niveau des services. En effet, un service est tout 4

5 Fig. 4 Représentation d un composant OSGi d abord enregistré, par le composant qui l exporte, au niveau de la plate-forme et plus précisément au niveau d un Service Provider qui par la suite va distribuer les services disponibles aux demandeurs. Un service peut être enregistré à tout moment car c est directement dans le code du composant que se situe cet enregistrement par l intermédiaire de la fonction registerservice() de la classe BundleContext. L inconvénient est que ce code peut se situer n importe où dans le code du composant. Il est donc difficile de connaître les services offerts par un composant particulier sans parcourir son code. La possibilité pour pallier cette difficulté est de spécifier, dans le Manifest du composant, les services disponibles au cours de l exécution de celui-ci. Bien que cette information ne soit pas traitée par la plate-forme lors de l enregistrement du composant, elle permet au développeur de connaître les particularités du composant sans devoir connaître son code. De la même façon, les services requis ne peuvent être connu que dans le code du composant. Là encore, il est possible d ajouter une directive dans le Manifest pour spécifier les services requis par le composant. D autres solutions concernant la liaison des services existent. SCR (Service Component Runtime), qui fait partie de la spécification OSGi R4 permet de définir, au moyen d un langage ADL en XML, la composition des services. Ainsi on peut spécifier de manière stricte la définition du service à utiliser de la même manière que dans Fractal avec Fractal ADL. La différence se fait sur le moment de la liaison entre les services. En effet, cette liaison est effectuée au moment où le service est nécessaire durant l exécution du composant. Il existe ausi un framework intitulé Spring Dynamic Module[28] ou encore IPOJO [16] qui propose des choses similaires. Ces derniers ne sont pas inclus dans les spécifications OSGi. Il est donc nécessaire d ajouter, sur la plate-forme, les composants qui permettent la prise en compte de ces frameworks. De plus, OSGi offre une dynamicité au niveau des composants. Ainsi il est possible de démarrer, arrêter ou mettre à jour un composant durant l exécution de la plateforme. L arrêt ou la mise à jour d un composant supprime les services enregistrés par le composant sur la plate-forme empêchant ainsi une possible incohérence entre la nouvelle version du service et la précédente. Dans le cas de la mise à jour du composant, le composant est tout d abord dupliqué, puis une des instances est enlevée du système. Pendant ce temps, si les applications s exécutant sur la plate-forme utilisent des services offerts par le composant que l on tente de mettre à jour, elles utilisent la seconde instance. Cette seconde instance restera présente sur la plate-forme tant que les services ou le composant lui-même seront utilisés. La nouvelle version est mise en place et toute nouvelle demande pour l utilisation de ce composant se fera sur cette nouvelle version. Ainsi on s assure que l ancienne version sera bien supprimée au bout 5

6 d un temps fini Service Component Architecture (SCA) SCA est une spécification pour une plate-forme orientée services [26, 11] proposée par plusieurs grands groupes du monde informatique tel que IBM ou Oracle. L intérêt de cette spécification est d offrir un standard pour la construction d applications à base de services. Un avantage de SCA consiste à ne pas fixer la technique de communication. En effet, SCA permet aussi l utilisation d autres techniques de communication telle que les Web-Services [30] ou CORBA [10]. L utilisation de ces différents moyens de communication restant totalement transparente pour le développeur d applications. De la même manière que Fractal avec Fractal ADL ou OSGi avec le fichier Manifest, SCA propose un fichier au format XML permettant la définition d un module. Ce dernier est un ensemble de composants représentant une partie du code métier de l application. Les composants de ce module peuvent offrir des services aux composants du même module ou aux autres modules par l intermédiaire de EntryPoint. De la même manière, un composant peut requérir des services d autres modules. On appelle ces services des References. Concernant la composition dynamique des services, celle-ci existe du fait de l utilisation de protocole de communication tel que les Web-Services. Ces Web-Services peuvent être composés et ainsi formé des services plus important voire même des applications. Étant donné la composition dynamique des services, il est donc possible de faire évoluer une application au cours de son exécution Entreprise Service Bus (ESB) ESB [6, 22] est une spécification de plate-forme orientée services utilisant un BUS pour les communications entre les services. Chaque service se connecte à ce BUS par l intermédiaire de Web-Service. Contrairement à OSGi où il est nécessaire de faire une demande de service à un ServiceProvider, ici, l utilisation des Web-Services masque cette opération. Il est nécessaire tout de même de spécifier les services que l on offre. Pour cela, ESB définit trois possibilités pour enregistrer des services au niveau de la plate-forme. Tout d abord, les services peuvent être enregistrés lors de l initialisation du composant qui offre ces services. Ils peuvent aussi être enregistrés par le composant lui-même au cours de son exécution. La troisième possibilité offerte par ESB correspond à la découverte par lui-même de services déjà déployés. Il faut noter que les composants qui offrent et requièrent des services ne sont pas eux-mêmes contenus dans la plate-forme ESB contrairement à OSGi. Du fait de l utilisation de Web-Service, la composition des services est dynamique et effectuée par le système ESB. De plus toujours grâce aux Web-Services, il est possible comme pour OSGi et SCA de modifier une application de manière dynamique Récapitulatif Nous avons pu voir que les plate-formes orientées services offraient, en plus de ce qu offrent les plate-formes à composants, la possibilité de gérer dynamiquement l application du point de vue de son architecture. Cependant, les techniques utilisées peuvent varier selon les plate-formes. Ainsi dans OSGi il n y a pas d appel direct 6

7 aux services ni de protocole de communication spécifique contrairement à SCA ou ESB. C est l utilisation d une entité tiers (BundleContext) qui se charge d effectuer la liaison entre deux services. Il en va de même dans ESB mais la communication avec l entité tiers se fait par l intermédiaire de Web-Service. Quant à SCA, le protocole de communication n est pas quelque chose de fixé. Ainsi il est possible d utiliser diverses méthodes (Web-Service, CORBA,...) pour la communication entre services. SCA se charge de rendre l utilisation de ces méthodes transparentes afin de faciliter leurs utilisations. 2 Adaptation dynamique L adaptation dynamique permet de prendre en compte la dynamicité d un système. Cette dynamicité peut s exprimer par l évolution des ressources disponibles sur le système ainsi que des préférences des utilisateurs. Dans ce cas, l adaptation dynamique se révèle être appropriée pour gérer ces situations. Dans cette partie, nous allons présenter le principe de l adaptation dynamique. Ensuite, nous poserons quelques critères intéressants pour de l adaptation dynamique et nous les utiliserons pour analyser des frameworks existants. 2.1 Principes Adapter signifie ajuster une chose à une autre. Dans le contexte informatique, on ajuste une application par rapport à des contraintes qui lui sont imposées en fonction de son contexte d exécution. Dans un système informatique, l adaptation se fait sur le comportement, la structure ou les paramètres de l application. Les contraintes quant à elles peuvent être diverses telle que la performance de l application, l utilisation des ressources, etc. Lors de l adpatation d une application, il est nécessaire que celle-ci reste dans un état cohérent. C est pourquoi, il est nécessaire de s assurer de la valider des stratégies d adaptation exécutée afin de conserver un système stable. Plusieurs travaux ont été effectués dans ce sens tel que l utilisation de la modélisation orientée aspect (AOM) et l ingénérie dirigée par les modèles (MDE) [19] afin de valider, grâce à une représentation de haut niveau, une stratégie d adaptation avant son exécution [23]. D autres travaux ont été effectués concernant la mise en place de langage de haut niveau permettant l expression des stratégies d adaptation [7]. On peut distinguer 3 phases dans le processus d adaptation comme schématiser dans la figure 5. La première phase correspond à la phase d observation. Elle consiste à surveiller le contexte de l application afin de détecter les changements qui nécessiteraient une adaptation. Ce contexte peut aller des ressources disponibles (bande passante, CPUs,...) pour le système jusqu aux préférences des utilisateurs en passant par les propriétés de son environnement (météo, date,...). La seconde phase est la phase de décision. Cette phase est chargée de décider, comme son nom l indique, de la stratégie à appliquer pour adapter l application. Cette phase peut elle-même être découpée en deux sous-phases que sont l analyse et la pla- 7

8 Fig. 5 Représentation de la boucle de contrôle proposée par IBM [20] nification. L analyse correspond au traitement des informations obtenues et la planification se charge de sélectionner les actions à effectuer pour prendre en compte les changements au niveau du contexte de l application. Enfin la dernière phase représente l exécution de la décision c est-à-dire l application concrète sur le système des actions qui ont été planifiées. On peut distinguer l adaptation dynamique et l adaptation statique qui adapte l application à l installation ou au démarrage de celle-ci. Cette dernière est donc tributaire du moment où elle a lieu. En effet, si cette adaptation est effectuée alors que le système est fortement sur-chargé (ou d autres contraintes lui sont imposées : surcharge du réseau,...), l application va s adapter à une situation qui n est peut-être pas pérenne tout au long de l exécution. Dans le cas inverse, si l adaptation est effectuée sur un système complètement libre, l application va supposer disponible des ressources qui ne le seront peut-être pas constamment et là encore elle va perdre en efficacité. On peut aussi distinguer différents types d adaptation dynamique qui peuvent être vu comme différents niveaux d adaptation. Le premier correspond à l adaptation paramétrique, celui-ci ne s occupe que des paramètres d une application. Par exemple, la durée d un timeout peut être représentée par un paramètre. Et selon les performances du réseau, il est possible de modifier ce paramètre pour assurer le bon fonctionnement de notre application. Ensuite vient l adaptation structurelle qui modifie la connexion entre les différents éléments de l application. Dans une plate-forme orientée services, ces éléments sont les composants et les services. Enfin l adaptation fonctionnelle modifie le comportement d un élément en modifiant le code applicatif qui le compose. 8

9 2.2 Critère d adaptation Dans un framework d adaptation dynamique, on peut distinguer 3 critères pour un bon framework. Tout d abord, l impact que celui-ci peut avoir sur la conception de la structure de l application. Ensuite, les types d adaptation qu il offre. Et enfin sa généricité qui permettrait de faire évoluer les algorithmes correspondant à chaque phase. Impact sur la structure de l application Du fait d applications déjà existantes, il peut être intéressant de connaître l impact d un framework sur l architecture d une application. En effet, un framework est plus intéressant si il permet d adapter une application déjà existante sans devoir redévelopper l application elle-même. Type d adaptation Comme il a été expliqué ci-dessus, il existe plusieurs types d adaptation (statique, dynamique et fonctionnelle, paramétrique, structurelle). Le fait de pouvoir supporter plusieurs types d adaptation peut être un avantage car chaque type d adaptation offre des possibilités qui lui sont propres. En effet, dans le cas d une adaptation dynamique fonctionnelle, il est possible d optimiser un morceau de code critique de l application alors que cela n est pas possible avec de l adaptation dynamique paramétrique. Évolution des algorithmes Il est intéressant que le framework est une séparation bien distincte des phases. Ainsi il peut être aisé d adapter dynamiquement ces phases afin d utiliser de nouveaux algorithmes qui pourraient répondre plus précisement à nos besoins d adaptation de l application. 2.3 État de l art Ici nous allons présenter deux frameworks d adaptation développé sur Fractal. Le premier Dynaco (2.3.1) est un framework d adaptation conçu initialement pour applications sur grille. Ensuite SAFRAN (2.3.2) dont une partie (wildcat) a été porté sur OSGi. Ces deux frameworks ont les particularités d isoler les phases d adaptation. Ils permettent, de plus, d effectuer plusieurs types d adaptation dynamique. Et surtout ils sont génériques car ils permettent l implémentation personnaliser des algorithmes des différentes phases. Il en existe d autres tel que Jade [1] basé lui aussi sur Fractal. Cependant, il ne concerne que la tolérance aux fautes pour le redémarrage d une application dans un état cohérent et cela de manière automatique Dynaco Dynaco [3] a été conçu initialement dans le cadre de grilles de calcul afin d aider au design et à l implémentation d applications dynamiquement adaptables. Basé sur Fractal, il définit un composant dynamiquement adaptable comme le montre le schéma de la figure 6. Dans ce composant, en plus des interfaces clientes et serveur définies dans le modèle Fractal, il y a aussi les monitors. Ces moniteurs permettent de se connecter à la partie adaptative (adaptation manager) du composant. Ces moniteurs sont utilisés par le système ou le contexte de l application pour envoyer des informations concernant des modifications nécessitant peut-être une adaptation du composant. La partie d adaptation contient la phase de décision, et d exécution de la 9

10 boucle de contrôle. Ici le sous-composant decider représente la phase d analyse des informations obtenues par l intermédiaire des moniteurs. Une fois l analyse effectuée et une stratégie d adaptation choisie, le planner élabore et planifie la mise en oeuvre de cette stratégie, celle-ci est ensuite exécutée par l executor. Il est à noter que les boîtes mc correspondent à des contrôleurs permettant de modifier les éléments qui leur sont reliés. Ainsi il est possible d adapter les différents composants de la partie d adaptation. Étant donné les caractéristiques de Fractal qui permet de partager des composants, il est possible de concevoir un seul composant chargé de l adaptation et de l inclure dans tous les composants d une application. Fig. 6 Représentation d un composant sous Dynaco En plus de la partie adaptative de Dynaco, il a été développé un autre framework (AFPAC [4, 15]) permettant de gérer la cohérence de l exécution de l adaptation d une application composée de plusieurs processus parallèles sur grille de calcul. Le framework Dynaco ne propose pas un support de l observation mais simplement un ensemble d interface permettant la connexion avec un système d observation. La phase de décision (analyse et planification) est une phase abstraite dans le framework. Ainsi il est possible d implémenter de diverses manières cette phase. Par exemple, un système expert peut être utilisé. La troisième phase (exécution) quant à elle est très liée au composant sur laquelle elle doit agir. Un exemple en est AFPAC qui permet le composant en un point cohérent de l exécution de l application. C est le même principe que les points de sauvegarde dans un réseau mais la particularité est la recherche d un point d adaptation dans le futur et non pas dans le passé de l application. Comme il est décrit sur le schéma (figure 6), la structure des composants de l application utilisant Dynaco est fortement dépendante du framework. En effet, il faut concevoir dans chaque composant une partie qui gère l adaptation. Concernant les types d adaptation supportés, le fait de gérer l adaptation à l intérieur du composant nous empêche de faire de l adaptation au niveau de l ensemble d une application formée de plusieurs composants. Cette particularité peut entrainer une incohérence entre les composants et ainsi perturber l exécution de l application. En effet, si l on choisit de modifier le comportement d un composant (changement du format de données envoyées sur le réseau) alors que celui-ci est nécessaire à un autre composant (enregistrement des données envoyées), il est nécessaire d adapter 10

11 aussi ce composant afin de garder cohérent l exécution de l application. Des travaux ont été effectuées pour pallier ce problème d une manière centralisée [8] ou distribuée hiérarchiquement [27]. De plus, si le composant n offre pas d interface BindingControlller, le fait d utiliser Fractal rend les liaisons entre les composants statiques ce qui ne permet donc pas de les modifier. Ainsi il n est pas possible de faire de l adaptation structurelle au niveau de l application. Concernant l adaptation paramétrique, rien dans la structure de Dynaco n empêche de modifier des paramètres d un composant. Enfin l adaptation fonctionnelle, qui consiste à changer le comportement d une fonction, est possible. Pour cela, il est possible d utiliser la réflexivité au niveau du code des méthodes. Une autre solution correspond à coder directement les différentes possibilités d algorithmes et par l intermédiaire d attributs et d adaptation paramétrique de sélectionner tel ou tel algorithme. Ces deux solutions impliquent que le code des algorithmes soit connu et contenu dans le composant. Dans une plate-forme orientée services, la possibilité de remplacer un service par un autre ne surchargeant que la méthode que l on souhaite modifier permet de remplacer l algorithme. Ici ce n est pas possible toujours du fait des liaisons statiques entre les composants. Le fait de concevoir un sous-composant chargé de gérer l adaptation dans le composant et de définir des sous-composants pour chaque étape du processus d adaptation permet de pouvoir modifier les algorithmes utilisés pour chaque étape. Ainsi il est possible de modifier le fonctionnement de la phase de planification (planner) sans influencer la phase de décision. Cependant, il est nécessaire que ces phases implémentent l interface BindingController sinon les liaisons statiques entre composants interdissent le changement d un composant (adaptation structurelle). Une autre solution consiste à effectuer la modification au niveau du code du composant et principalement la fonction correspondant à l algorithme que l on souhaite remplacer (adaptation fonctionnelle) SAFRAN SAFRAN [12] a été conçu afin de permettre la conception d application dynamiquement adaptables. La particularité de ce framework, est de proposer la conception de ces adaptations sous forme d aspects [21]. Basé sur Fractal, les auteurs ont défini deux extensions au modèle standard de celui-ci. La première nommée contraintes métier permet de spécifier des contraintes propres à l application et ne pouvant être simplement spécifier par le langage Fractal ADL comme par exemple le fait qu un composant composite donné doit contenir deux sous-composants et que ceux-ci sont connectés d une certaine manière. Pour ce faire, un langage dédié a été mis au point. FPath, un langage inspiré de XPath [31]. Il permet de parcourir une architecture Fractal afin de sélectionner des composants et de spécifier des contraintes sur ceux-ci. Ces contraintes permettent de valider des architectures Fractal, là où Fractal ADL ne pouvait suffire. En effet, Fractal ADL spécifie les liaisons entre composants de manière statique. La possibilité de reconfiguration dynamique proposée par les interfaces BindingController peuvent rendre ces liaisons invalides voire incohérentes pour l application. Cependant dans l implémentation SA- FRAN proposée dans [12], ces contraintes n ont que valeurs d informations, car d après l auteur il serait trop couteux d effectuer la validation des contraintes lors de modification des liaisons. C est aux clients (composants utilisant une des interfaces clientes 11

12 du composant) intéressés par la validité de ces contraintes de les vérifier. La seconde extension, intitulée méta-composants permet la mise en place d un reflexion comportementale. Un méta-composant est un composant chargé de modifier le comportement d un composant dit de base. Étant donné que dans Fractal, la communication entre composant se fait par message, les méta-composants n ont donc besoin que de surveiller la réception de messages du composant. Ensuite, ils doivent choisir si oui ou non, ils transmettent ceux-ci au composant afin qu ils soient traités. En plus des deux extensions sur Fractal, SAFRAN propose 3 éléments qui représentent la boucle de contrôle (figure 5). Tout d abord wildcat [13] qui est un framework permettant l observation sous forme de notification par évènement. Ce framework définit des sensors, sorte de capteurs qui dans une plate-forme peuvent représenter de réels capteurs (capteur de température, de présence,...) présents dans le système ou encore une simulation de capteur permettant de contrôler des informations tel que les préférences des utilisateurs. Ces capteurs permettent de notifier, sous la forme d évènements, le système d adaptation lorsque les modifications du sytème peuvent impliquer une adaptation de l application. Il faut noter qu il est nécessaire de concevoir ces capteurs dans l application. Dans SAFRAN, c est la partie Adaptation Controller qui est chargée d analyser les informations obtenues par l intermédiaire de wildcat et de décider si oui ou non, une adaptation est nécessaire. Ici, il est possible d utiliser le langage dédié intitulé SAFRAN ou de développer soi-même sa partie Adaptation Controller en tenant compte de l interface AdaptationController spécifiée par SAFRAN. Il est aussi possible d utiliser d autres systèmes logiciels. Après l analyse et le choix d une stratégie à appliquer, il est nécessaire d appliquer cette stratégie. C est FScript qui en a la charge. FScript est un langage de scripts permettant de spécifier les stratégies sous forme d actions à effectuer. Son implémentation, sous la forme d interpréteur dans Fractal, assure la cohérence de l application après exécution d une action FScript. Ainsi, si l action n est pas valide (affectation d un attribut à un objet qui ne possède pas le bon type), l implémentation s assure que le système revient à son état antérieur. C est le principe d atomicité de l action. L implémentation assure aussi la consistance de l état après adaptation pour le cas où une action ne respecterait pas des contraintes métiers. L utilisation du framework d adaptation SAFRAN impose la définition d une interface AdaptationController au niveau des composants. Cependant, il est possible de définir un composant composite qui contient les composants à adapter et ainsi utiliser la spécificité de SAFRAN qui est de concevoir l adaptation comme un préoccupation transverse dans la conception d une application en utilisant les aspects. La possibilité d utiliser des composants composites pour regrouper les composants à adapter permet aussi de gérer l impact de l adaptation d un composant sur l ensemble de l application et ainsi d adapter d autres composants afin d assurer la cohérence de l application. Pour effectuer de l adaptation paramétrique, il suffit de modifier les paramètres d un composant par l intermédiaire du langage FScript et de la fonction set-value(). Concernant l adaptation structurelle, FScript offre là encore la possibilité de modifier les liaisons entre composants par l intermédiaire des fonctions bind() et unbind(). Ici, 12

13 Fig. 7 Représentation du système SAFRAN il n est pas nécessaire que le composant définisse l interface BindingController comme définit dans Fractal. Ceci permet ainsi une reconfiguration plus aisée des applications. Il est aussi possible d ajouter des sous-composants à un composite par l intermédiare des fonctions add() et remove(). De la même manière que Dynaco, l adaptation fonctionnelle peut s effectuer de deux façons. Par l utilisation d adaptation paramétrique en codant les différents algorithmes directement dans le code de la fonction ou en utilisant la reflexivité offerte par le langage de programmation. Là encore, il est nécessaire que les algorithmes soient définis dès le départ dans le composant alors que dans une plate-forme orientée services, il est possible que ces algorithmes apparaissent au cours de l exécution de l application. Concernant l évolution algorithmique des différentes phases d adaptation, la phase d exécution qui correspond à FScript utilise un interpréteur qu il est tout à fait possible de remplacer par un plus performant selon les besoins. Pour la phase d observation, il est difficile de pouvoir changer le fonctionnement par évènement car cela implique de modifier aussi la phase de décision. Mais il est possible de définir de plusieurs manières les sensors utilisés et ainsi les adapter. Enfin la phase de décision peut utiliser le langage SAFRAN définit dans le framework mais peut aussi utiliser d autres systèmes de décision tel qu un système expert. Cependant toute ces modifications imposent la présence dès le démarrage de l application des différents éléments. En effet, il n y a pas de découverte dynamique de composants ou de services durant l exécution d une application Fractal Récapitulatif On peut voir que les deux frameworks présentés offrent deux approches différentes de l adaptation dynamique. L un impliquant une définition des composants afin d intégrer les phases d adaptation et un autre qui veut offrir, aux applications, une indépendance vis à vis de lui-même grâce aux méta-composants. On peut voir aussi que les limites dans les différents types d adaptation offerts par ces frameworks sont dûes en grande partie aux restrictions imposées par la plate-forme (liaisons statiques entre composants). 13

14 3 Adaptation de plate-forme orientée services Nous avons, dans les sections précédentes, présenté les plate-formes à base de composant logiciels ou de services ainsi que l adaptation dynamique. Les frameworks que nous avons présenté étant basés sur les composants logiciels, ils ne prennent pas totalement en compte le dynamisme et l hétérogénéité des services. C est pourquoi il serait intéressant de concevoir un framework d adaptation dans le cadre de ces plate-formes. Étant donné la variété importante des plate-formes orientées services, il serait intéressant de proposer un framework de suffisamment haut niveau afin de faciliter son implémentation sur diverses plate-formes et non pas limiter son utilisation à une seule. Tout comme les frameworks présentés, celui-ci se devrait de proposer une séparation distincte des 3 phases de l adaptation afin de faciliter l évolution de ces phases, c est-àdire l adaptation de celle-ci durant l exécution de l application. Cette séparation peut être envisagée comme la conception de trois frameworks distincts coopérant entre eux à l aide de service. Ainsi il serait aisé de changer l implémentation de l un des frameworks par un autre dans le cadre de l adaptation de celui-ci. De plus, la dynamicité de la connexion des services peut permettre l utilisation d adaptation structurelle qui était difficilement envisageable dans le cas des composants logiciels dûe à la limitation et à la complexité des modifications architecturales des applications à base de composants. Enfin un autre point important serait la phase d exécution et le déploiement et redéploiement des services du fait de la dynamicité et de l hétérogénéité des protocoles de communications utilisables. En effet, dans les plate-formes telle que SCA, une adaptation envisageable serait le choix du protocole de communication entre services permettant ainsi de prendre en compte les caractéristique diverses de ces protocoles en fonction des contraintes imposées à l application (sécurité, charge du réseau,...). Dans ce dernier paragraphe concernant le déploiement, je vois l hétérogénéité des protocoles de communications mais je vois aussi l hétérogénéité de la plate-forme dans le cas d une plate-forme distribuée. Étant donné que je n en parle quasiment jamais excepté pour ESB, je ne sais pas si je dois en parler ici. References [1] Sara Bouchenak, Fabienne Boyer, Sacha Krakowiak, Daniel Hagimont, Adrian Mos, Stefani Jean- Bernard, Noel de Palma, and Vivien Quema. Architecture-based autonomous repair management : An application to j2ee clusters. Reliable Distributed Systems, IEEE Symposium on, 0 :13 24, [2] Eric Bruneton, Thierry Coupaye, Matthieu Leclercq, Vivien Quéma, and Jean-Bernard Stefani. The fractal component model and its support in java : Experiences with auto-adaptive and reconfigurable systems. Softw. Pract. Exper., 36(11-12) : , [3] Jérémy Buisson. Adaptation dynamique de programmes et composants parallèles. PhD thesis, INSA de Rennes, [4] Jérémy Buisson, Françoise André, and Jean-Louis Pazat. Afpac : Enforcing consistency during the adaptation of a parallel component. Scalable Computing : Practice and Experience, 7(3) :83 95, September electronic journal (http :// extended version of cite2005 :BuiAnd- Paz :ISPDC. [5] Humberto Cervantes and Richard S. Hall. Autonomous adaptation to dynamic availability using a service-oriented component model. In ICSE 04 : Proceedings of the 26th International Conference on Software Engineering, pages , Washington, DC, USA, IEEE Computer Society. [6] David A. Chappell. Enterprise Service Bus. O Reilly, [7] Franck Chauvel, Olivier Barais, Isabelle Borne, and Jean-Marc Jézéquel. Composition of qualitative adaptation policies. In ASE, pages IEEE, [8] Djalel Chefrour. Plate-forme de composants logiciels pour la coordination des adaptations multiples en environnement dynamique. PhD thesis, Université de Rennes I, [9] Jan Bosch Clemens Szyperski and Wolfgang Weck. Component-Oriented Programming, volume 1743 of Lecture Notes in Computer Science. Springer Berlin,

15 [10] Corba omg. http :// [11] Francisco Curbera, Donald F. Ferguson, Martin Nally, and Marcia L. Stockton. Toward a programming model for service-oriented computing. In ICSOC, pages 33 47, [12] Pierre-Charles DAVID. Développement de composants Fractal adaptatifs : un langage dédié à l aspect d adaptation. PhD thesis, Université de Nantes UFR Sciences et Technique, [13] Pierre-Charles David and Thomas Ledoux. Wildcat : a generic framework for context-aware applications. In MPAC 05 : Proceedings of the 3rd international workshop on Middleware for pervasive and ad-hoc computing, pages 1 7, New York, NY, USA, ACM. [14] B. Dumant, F. Horn, F. Dang Tran, and J.-B. Stefani. Jonathan : an open distributed processing environment in Java. Distributed Systems Engineering, 6 :3 12, March [15] Afpac framework. http ://afpac.gforge.inria.fr. [16] C. Escoffier, R.S. Hall, and P. Lalanda. ipojo : an extensible service-oriented component framework. Services Computing, SCC IEEE International Conference on, pages , July [17] Fractal project. http ://fractal.objectweb.org/. [18] F. Jammes and H. Smit. Service-oriented paradigms in industrial automation. IEEE Trans. Industrial Informatics, 1(1) :62 70, [19] Jean Marc Jézéquel. Model driven design and aspect weaving. Software and Systems Modeling, 7(2) : , May [20] Jeffrey O. Kephart and David M. Chess. The vision of autonomic computing. Computer, 36(1) :41 50, [21] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, Cristina Lopes, Jean M. Loingtier, and John Irwin. Aspect-oriented programming. In Proceedings European Conference on Object- Oriented Programming, volume 1241, pages Springer-Verlag, Berlin, Heidelberg, and New York, [22] P. Lambros M.-T. Schmidt, B. Hutchison and R. Phippen. The enterprise service bus : Making serviceoriented architecture real. [23] Brice Morin, Olivier Barais, Grégory Nain, and Jean-Marc Jézéquel. Taming Dynamically Adaptive Systems with Models and Aspects. In 31st International Conference on Software Engineering (ICSE 09), Vancouver, Canada, May [24] Seventh International Workshop on Component-Oriented Programming (WCOP02). Recursive and dynamic software composition with sharing. In Seventh International Workshop on Component- Oriented Programming (WCOP02). [25] Osgi alliance. http :// [26] Sca specification. http ://www-128.ibm.com/developerworks/library/specification/ws-sca/. [27] M.T Segarra and F. André. A distributed dynamic adaptation model for component-based applications. In The 23rd IEEE International Conference on Advanced Information Networking and Application AINA 2009, May [28] Spring dynamic modules for osgi. http :// [29] Clemens Szyperski. Component Software : Beyond Object-Oriented Programming. Addison-Wesley Professional, December [30] Web-service w3c. http :// [31] Xpath w3c. http :// 15