Laboratoire LSR Équipe ADELE Université Joseph Fourier – Grenoble

Présentation au sujet: "Laboratoire LSR Équipe ADELE Université Joseph Fourier – Grenoble"— Transcription de la présentation:

1 Laboratoire LSR Équipe ADELE Université Joseph Fourier – Grenoble Une Approche Générique pour la Reconfiguration Dynamique des Applications à base de Composants Logiciels Abdelmadjid KETFI le 10 décembre 2004 Bonjour, J’ai le plaisir de vous présenter aujourd’hui mon travail de thèse, intitulé … , réalisé au sein de l’équipe Adèle du laboratoire LSR sous la direction de NB et de PYC

2 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

3 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

4 Motivation Analyse Conception Développement Déploiement Internet
Composants Mobilité Le développement d’un logiciel se déroule suivant un cycle constitué de +sieurs phases. La première étant l’analyse… Récemment une nouvelle phase a été mise en évidence dans ce cycle de vie. Cette phase s’appelle le déploiement. Elle prend le relais après la phase de développement et accompagne le logiciel dans le reste des étapes de son cycle de vie. En effet, le déploiement, auparavant caché dans les autres phases du cycle de vie, a été rendu explicite et possible grâce aux avancées technologiques dans le domaine des réseaux, et spécialement l’Internet, les modèles de composants et les besoins des applications mobiles ont aussi fortement participé à la mise en évidence du déploiement. Mon travail de thèse se situe dans cette phase abordée dans l’équipe depuis plusieurs années. Le déploiement ne se limite pas à l’installation comme il est souvent considéré. De récents travaux ont montré que c’est plutôt tout un cycle complexe qui commence par la configuration du logiciel, puis son installation et son activation. Le logiciel peut être désactivé, mis à jour ou désinstallé. Dans le cycle de vie du déploiement, une activité a pris de l’importance ces dernières années. c’est la reconfiguration dynamique, cad une reconfiguration réalisée à l’exéuction et sans l’arrêt complet de l’application. Mon travail de thèse est justement centré autour de cette activité.

5 Modifier une application à l’exécution, sans l’arrêter
Motivation Analyse Conception Développement Déploiement Configuration Fin de support Installation Désinstallation Mise à jour Reconfiguration Activation Désactivation Plusieurs domaines d’applications font appel à la reconfiguration dynamique. Dans la suite, je vais illustrer qq uns de ces domaines avec des exemples de systèmes pour montrer l’utilité de la RD. Reconfiguration Modifier une application à l’exécution, sans l’arrêter

6 Motivation Scénarios d’applications : Hautement disponibles WWW
D’abord les applications qui doivent s’exécuter pour longtemps, et qui doivent rester tout le temps disponibles. Prenons l’exemple du système de réservation de la SNCF ou même l’exemple du portail de commerce électronique d’Amazon qui reçoit un nombre énorme de requêtes par jour. Arrêter ce portail pour faire sa reconfiguration d’une façon statique peut avoir des effets négatifs sur les clients qui risquent de perdre leur données et leur temps. Aussi du coté des exploitants du portail, Le temps signifie l’argent, et des arrêtes fréquents sont synonyme de mauvaise qualité de service et perte des clients. Pour toutes ces raisons, l’adaptation du portail doit impérativement se réaliser dynamiquement.

7 Motivation Scénarios d’applications : Hautement disponibles
Distribuées, large échelle Les applications distribuées et de grandes taille nécessitent beaucoup d’effort pour être arrêtées et correctement redémarrées, pour cette raison il est intéressant dans la mesure du possible de les adapter dynamiquement.

8 Motivation Scénarios d’applications : Hautement disponibles
Distribuées, large échelle Clients hétérogènes WWW Dans le même sens, un serveur doit être capable de s’adapter dynamiquement pour répondre à des requêtes de postes clients hétérogènes, et prendre en compte leur propriétés par rapport à la bande passante, aux capacités de calcul, de mémoire, d’affichage, etc.

9 Motivation Scénarios d’applications : Hautement disponibles
Distribuées, large échelle Clients hétérogènes Embarquées Le dernier type d’application que je vais citer concerne les applications embarquées. Les mise à jour dynamiques lancées à distances sur des terminaux de TV par satellite TPS, et sur des véhicules récents en font le meilleur exemple. Jusque là, j’ai expliqué pk on s’intéresse à la RD, je vais présenter mnt l’objectif de la thèse.

10 Objectif Code de l’application Code non-fonctionnel Avec Séparation de préoccupations Sans Séparation Traiter la reconfiguration dynamique comme un concept non-fonctionnel Séparation des préoccupations Code de la reconfiguration Conception et développement d’un système de reconfiguration dynamique « générique » pour les applications à base de composants Indépendant des applications à reconfigurer Indépendant des modèles de composants sous-jacents Facile à utiliser Automatisé le plus possible Pour favoriser la productivité, le programmeur ne doit se préoccuper que de la logique métier de son application. Les autres services, souvent qualifiées de non-fonctionnels, et nécessaires pour l'exécution de l'application, doivent être réalisés séparément par des spécialistes qualifiés dans des domaines spécifiques comme les transactions, la sécurité et la persistance. Notre objectif dans cette thèse est de traiter la reconfiguration dynamique comme une propriété non-fonctionnelle, dans un esprit de séparation de préoccupation. Concrètement, nous voulons mettre au point un…. Nous voulons que ce système soit générique et indépendant le plus possible à la fois des applications à reconfigurer et de leurs modèles de composants. Cela signifie que dans notre système, on ne doit pas avoir des informations spécifiques aux applications à reconfigurer pour pouvoir appliquer la solution à différentes applications, et l’autre objectif, c’est de ne pas avoir des informations spécifiques aux modèles ciblés, pour pouvoir appliquer la solution à différents modèles. Nous visons également une solution facile à utiliser et automatisée le plus possible pour faciliter le rôle des administrateurs. J’ai mentionné que nous nous intéressons aux AABC, regardons les caract importantes de ce type d’appli [En effet, de nombreux travaux existants ont traité la problématique de reconfiguration dynamique autour d'un modèle de composants particulier. Les solutions proposées sont par conséquent spécifiques au modèle traité. En passant d'un modèle à un autre, et même d'une plate-forme d'exécution à une autre, il est nécessaire de développer une nouvelle solution spécifique, même si la logique de reconfiguration est similaire. Ceci pose un sérieux problème de réutilisation.]

11 Aucun modèle de composants ne supporte toutes ces caractéristiques
Cadre de travail Application à base de composants Réutilisation Architecture explicite – assemblage Séparation aspects fonctionnels/non fonctionnels Capable de s’auto-décrire Dépendances Fonctionnalités offertes Déploiement dynamique Évolution D’abord, les AABC sont des app modulaires. elles visent à assurer la réutilisation et faciliter l’évolution. Une AABC a une architecture explicite, qui n’est pas enfouies dans le code de ses composants. Pour construire une AABC, On doit définir ses briques de base (les composants) sans parler de l’architecture dans laquelle on va les mettre. Ensuite on assemble explicitement ces briques pour obtenir l’application. Malheureusement, dans les modèles de composants existants, cette propriété n’est pas tjs vérifiée. Séparation aspects F/NF ce qui permet de développer des applications propres faciles à faire évoluer; qq modèles issus de l’industrie utilisent en général les conteneurs (EJB, Avalon), d’autres modèles académiques (DCUP/Fractal) utilise, au sein même du composant, une séparation entre une partie fonctionnelle et une partie de contrôle qui correspond aux aspects NF. Un composant doit être capable de s’auto-décrire :  Il doit explicitement exprimer les services dont il a besoin pour fonctionner Il doit explicitement exprimer les fonctionnalités qu’il offre aux autres composants ou à d’autres clients On peut aussi remarquer que le déploiement a pris de l’importance avec l’apparition des modèles de composants. Et on considère en général qu’un composant doit pouvoir être déployé indépendamment des autres composants, ceci permet de faciliter l’évolution dynamique des applications. Et c’est pour cette raison qu’on s’est intéressé à ce type d’applis. Aucun modèle de composants ne supporte toutes ces caractéristiques

12 Cadre de travail (suite)
Définition  Configuration Reconfiguration Reconfiguration dynamique Propriétés d’un système de reconfiguration Cohérence Performance Automatisation Facilité d’utilisation Je vais mnt expliquer ce que nous entendons par RD ds le cadre de cet exposé. Nous considérons qu’une conf… Un système de R doit avoir un ensemble de propriétés :  D’abord il doit assurer cohérence :  La reconfiguration doit être réalisée à des moments bien précis dans lesquels l’application est dans un état stable. Cad un état à partir duquel elle peut recommencer normalement son exécution. Il ne faut pas aussi que le SR cause un blocage ou des trous de sécurité dans l’application reconfigurée. Généralement, on distingue 2 types de cohérences :  Locale : concerne un composant particulier Globale concerne l’application dans sa globalité Le SR doit être performant pour ne pas affecter la qualité de service de l’application reconfigurée. Le SR doit être automatisé le + possible, cad il doit avoir la capacité de raisonner sur certaines situations et prendre des décisions de R adéquate avec le minimum de participation humaine. Un SR doit être facile à utiliser. Donc il faut disposer d’un ensemble d’outils intuitifs qui facilitent l’utilisation du S.

13 Cadre de travail (suite)
Taxonomie des modifications Implémentation Serveur1 calculer() Client1 calculer() Lors de la RD on peut appliquer +sieurs types de modifs. D’abord la modif de l’arch en ajout…

14 Cadre de travail (suite)
Taxonomie des modifications Implémentation Interface Serveur1 calculer() Client1 ? Lors de la RD on peut appliquer +sieurs types de modifs. D’abord la modif de l’arch en ajout… Serveur2 traiter()

15 Cadre de travail (suite)
Taxonomie des modifications Implémentation Interface Architecture Serveur calculer() Client Lors de la RD on peut appliquer +sieurs types de modifs. D’abord la modif de l’arch en ajout… Filtre calculer()

16 Cadre de travail (suite)
Taxonomie des modifications Architecture Implémentation Interface Localisation Client calculer() Serveur stocker() Machine1 Lors de la RD on peut appliquer +sieurs types de modifs. D’abord la modif de l’arch en ajout… stocker() DB

17 Cadre de travail (suite)
Taxonomie des modifications Architecture Implémentation Interface Localisation Client calculer() Serveur stocker() Machine1 DB stocker() Machine2 Lors de la RD on peut appliquer +sieurs types de modifs. D’abord la modif de l’arch en ajout…

18 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

19 État de l’art Dimensions : Ouverture Granularité Support
Quand on regarde les approches existantes, il est difficile de trouver un critère déterminant qui permet de les classifier et de les comparer. Pour cette raison, je vais discuter ces approches selon trois axes qui représentent l’ouverture de la solution, la granularité adressée et le support utilisé pour supporter la reconfiguration. D’abord par rapport à la propriété d’ouverture, on peut classer les solutions en trois catégories : fermées, … Support Granularité

20 État de l’art Dimension 1 : Support
Remplacer une entité logicielle par une autre Remplacer une entité matérielle par une autre ACARS (ARINC, Inc) Système de messagerie aérienne SCP (Bellcore) Système de télécommunication

21 État de l’art Dimension 2 : Solutions fermées vs. ouvertes Fermées
Logique de reconfiguration intégrée dans l’application Il faut tout envisager à l’avance Partiellement ouvertes « Points » de reconfiguration bien définis « plug-ins » Modifications non spécifiées à l’avance Eclipse, Netscape, OpenVL Ouvertes Tous les éléments du système sont sujets à la manipulation Iguana/J Par rapport aux capacités d’adaptation, les systèmes ouverts sont les plus intéressants. Je vais alors donner plus de détail sur la notion de réflexion qui peut être utilisée comme support pour mettre au point des solutions ouvertes.

22 Systèmes réflexifs Tours réflexives (B. Smith) Notions Introspection
Méta-méta-méta… . Tours réflexives (B. Smith) Méta-méta-niveau Méta-niveau Niveau de base Notions Introspection Lire les informations du méta-niveau Intercession Modifier les informations du méta-niveau Réification Construire le méta-niveau à partir du niveau de base Introspection Méta-niveau Un S réf est un système capable de raisonner sur lui même… et capable d’utiliser sa propre représentation pour étendre et adapter son comportement… donc on peut dire que la réflexion est l’une des méthodes qu’on peut utiliser pour construire des systèmes adaptables et c’est ça qui justifie notre intérêt à la réflexion. A l’origine, le concept de réflexion a été introduit par Brayan Smith dans ses travaux de thèse. Il a introduit le principe des tours réflexives, en considérant qu’un système réflexif peut être structuré en un nombre infini de tours, où chacune d’elles représente un niveau logique du système, donc chaque tour est une vue abstraite de la tour juste au dessous. Là on a une vision simplifiée avec simplement 2 tours ou deux niveaux : un niveau de base et un méta-niveau. Un système réflexif est basé sur 2 notions fondamentales :  La réification :  c’est l’opération par laquelle quelque chose d’implicite, de non exprimé, est formulé explicitement, et, est rendu disponible à la manipulation. L’introspection  : c’est l’opération de consultation des informations décrivant le système, résultant de la phase de réification. L’intercession qui signifie la modification des structures contenant la représentation abstraite d’un système réflexif. Intercession Niveau de base Réification

23 État de l’art Dimension 3 : Granularité Procédurales Modulaires
DYMOS (Insup Lee, USA, 1983) Modulaires Polylith (Maryland, 1985-) Orientées-objet Dynamic Java/C++ classes Orientées-composant K-Components (Trinity College of Dublin) SOFA/DCUP (Charles University, Prague)

24 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

25 Démarche Approche ascendante Personnalisation
Système de reconfiguration Générique Généralisation Personnalisation Systèmes de reconfiguration dédiés à des modèles particuliers Généralisation Système de reconfiguration JavaBeans Système de reconfiguration OSGi Personnalisation Pour réaliser notre objectif, qui est la réalisation d’un système de reconf général, nous avons opté pour une approche ascendante. D’abord pour acquérir de la matière, nous avons commencé par mettre en œuvre un système de reconfiguration pour un modèle de composants existant appelé JavaBeans. Nous avons ensuite réalisé une expérimentation similaire visant à développer un système de reconfiguration pour un autre modèle de composants appelé OSGi. Après ces deux expérimentations, nous avons fait l’effort de factorisation et d’abstraction des concepts utilisés lors des deux expérimentations préliminaires dans l’objectif de concevoir et de mettre en œuvre notre solution générique. Dans la suite je vais me contenter de présenter la 1ere exper. Avant de passer à notre syst de reconf générique.

26 Système de reconfiguration pour le modèle JavaBeans
BeanBox DBeanBox  Intercepteurs : générés, compilés et chargés à la volée Communication limitée aux événements L’objectif de l’ex est la mise en oeuvre d’un SR pour le m JB, pour cela, nous avions le choix entre, développer notre propre env d’assemblage de composants JB, et de le doter d’un SR. en entre la réutilisation d’un environnement existant. Nous avons choisi cette 2eme approche et nous avons repris un envi libre qui s’appelle la BB, à base de cet environ, nous avons batis la DBB.

27 Système de reconfiguration pour le modèle JavaBeans
Intercepteurs Principe :  notify receive Sonde Intercepteur Moniteur IReconfiguration Rôle :  setTargetObject(...) setTargetMethod(...) passivate() activate() IReconfiguration Gestion des connexions Gestion des messages Ceci montre que toutes les communications transitent par les intercepteurs. Ces intercepteurs jouent un rôle central dans la reconfiguration

28 Système de reconfiguration pour le modèle JavaBeans
Ik I1 Bean2 3 1 4 5 2 Gestion des messages Éviter la perte des messages Files d’attente Ik I1 I1 Ik Bean3 Gestion du transfert d’état Solution ad-hoc Lire les valeurs des propriétés du Bean à remplacer et les écrire dans les propriétés du nouveau Bean Problème de correspondance … Après cette expérimentation sur le modèle JB, nous avons voulu réaliser une exp similaire sur un autre modèle pour valider les idées mise en oeuvre ds la 1ere exp, et pour mettre en clair les différence potentielle. Dans la suite, je ne vais pas présenter en détail cette exp mais je vais me limiter à une problématique particulière sur laquelle nous avons mis l’accent. Cette probl. Concerne l’adaptabilité des interfaces…

29 Synthèse des expérimentations
La conclu

30 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

31 DYVA : principe de conception
Dynamic Virtual Adaptation machine Noyau générique pour la reconfiguration dynamique Une approche réflexive Système de Reconfiguration Méta-niveau Abstraction Connexion Causale Application Environnement Niveau de base Services supportés :  Personnalisation Installation Exécution

32 DYVA : architecture interne
Gestionnaire du modèle abstrait Gestionnaire du modèle abstrait des applications à reconfigurer Gestionnaire de reconfiguration Modification Gestionnaire de reconfiguration : opérations de reconfiguration de base Superviseur Notification Superviseur : responsable de l’auto-reconfiguration Politiques de reconfiguration Politiques de reconfiguration : règles interprétées par le superviseur Base de composants Bases de composants : organisation des composants, propriétés…

33 DYVA : modèle abstrait d’application
Blalala… je vais présenter ce modèle en 2 étapes  :  Dans les expérimentations que nous avons menées, les op de R opèrent sur des elmnts d’un modèle particulier. Pour assurer la généricité de notre noyau, nous l’avons basé sur un modèle abstrait, qui est considéré comme un modèle représentatifs des modèles concrets que nous voulons cibler. Il est important aussi de préciser que ce modèle est abstrait pour la R, cad qu’il regroupe uniquement les éléments nécessaires pour faire la R. L’explication des éléments de ce modèle est donnée en détail dans le doc de la thèse. Je tiens juste à préciser qu’à l’exécution, une instance de ce modèle va contenir une rep abst de l’app à reconf, qu’on calcule à partir de l’appli. Et c’est justement sur cette rep que le noyau de recon va opérer.

34 DYVA : opérations de reconfiguration
Exemple du remplacement d’instances :  IM1 X IJ IM1 Moniteur1 Moniteur1 IJ Sonde Journal IJ IM2 Moniteur2 Je vais mnt illustrer l’une des op de reconf. À travers un exemple. Et je vais m’intéresser à l’op de remplacement…

35 DYVA : auto-reconfiguration
Décision Automatisation Observation Action Application Environnement Règles ECA :  ON <événement> IF <condition> THEN <action> L’automatisation est l’une des propriétés les + importantes considérées dans notre noyau. Elle reflète la capacité du SR de raisonner et de prendre des décision de R cohérentes. Ceci permet de faciliter le travail de l’admin surtout si la R doit se faire d’une façon fréquente. Le schéma suivant montre le principe général d’auto R. dans ce cycle on trouve les 3 concepts de base Obs/Déc/Act Lorsque la reconfiguration est lancée manuellement, l'utilisateur emploie un ensemble de connaissances implicites (pourquoi reconfigurer, qu'est-ce qu'il faut reconfigurer, sous quelles conditions, etc ?). Pour automatiser la reconfiguration, il est nécessaire de trouver un moyen pour exprimer ces connaissances et les rendre explicites. Dans notre noyau, nous avons utilisé le concept de règles de reconfiguration pour ces fins. La règle est composé&e de 3 parties :  évnt, cond action Pour interpréter des règles, nous avons mis en œuvre un moteur (superviseur) qui reçoit les notifs et qui interprète les règles. Exemple :  [RULE] ON: OVERLOAD_EVENT IF: LOAD > 80 AND Moniteur = Moniteur1 THEN: replace Moniteur1 Moniteur2

36 DYVA : vue externe Interface de notification
Interface de Reconfiguration Interface de reconfiguration Disconnect, remove, replace… (en exécution) DYVA Plugins de Projection Plugins de projection Plugins spécifiques Interface de Notification Interface de notification Application (instanciation, connexion…) Environnement (bande passante, disque, charge…)

37 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

38 DYVA : Implémentation Architecture interne
Implémentation du modèle abstrait Génération des classes Java en utilisant XML Castor Organisation du méta-niveau D’abord, pour impl notre MA, nous avons… Nous avons ensuite les classes principales qui constitue la structure physique du noyau, on peut remarquer que cette structure est symétrique à l’architecture conceptuelle que j’avais présenté tt à l’heure. Autour de cette structure physique, nous avons développé un ens d’outils qui permettent de faciliter l’utilisation de notre noyau.

39 DYVA : Implémentation Transfert d’état
Outil d’assistance au transfert d’état  Introspection Spécification XML Classe Java Ci Instrumentation Outil Le prem outil concerne Le transf E qui est l’un des pbs les + délicats auxquels il faut faire face lorsqu’on implémente un SR. L’état est en général sémantique, et spécifique à chaque appli. Donc seul le concepteur d’une appli est capable d’exprimer l’état de ses composants, et il est par conséquent difficile de développer une sol générale pour ce pb. Dans notre approche, nous considérons alors que chaque compo est responsable d’implémenter deux métodes qui permettent respectivement de consulter et de modifier l’état de ses instances. Pour facilier la mise en place de ces méthodes, nous avons développé un outil spécifique à Java, qui permet d’introspecter une c j, puis demander à l’util de sélectionner les att qui constituent l’état, Il

40 DYVA : Implémentation Interface d’administration
Affichage du graphe de l'architecture : Grappa Mode « Local » Mode « Distant » (RMI)

41 DYVA : Implémentation Effort de programmation
Taille du code (calculée en utilisant JavaNCSS) Système de reconfiguration JavaBeans 2000 BeanBox = 5400 Système de reconfiguration OSGi 3600 OSGi = 7200 Noyau 3200 Personnalisation OSGi 1600 On réutilise la conception Le travail que nous avons présenté ds cette thèse traite du domaine de la RD des applications… la complexité du domaine est liée à l'absence de mécanismes de haut niveau, permettant d'intervenir dynamiquement sur une application. Il existe cependant +sieurs travaux autour des syst de R, ces travaux sont en général spécifiques et difficilement exploitable en dehors de leur contexte. Comme contribution, nous avons proposé une approche de RD qui vise les AABC. L’originalité de cette approche réside surtout ds sa géréricité. Pour atteindre notre objectif, nous avons d’abord commencé à travailler sur des MC spécifiques, nous avons ensuite généralisé nos résultats pour définir notre solution générique. Cette solution se présente sous forme d’un noyau commun qu’on peut personnaliser pour différents modèles de composants. Comme résultats pratiques, nous avons implémenté un système de R dynamique pour le modèle JB. Et un système similaire pour le modèle OSGi, nous avons également implanté une solution pour le problème d’incompatibilité d’interfaces pour le modèle OSGi. Nous avons aussi réalisé en Java une implémentation du noyau générique et nous l’avons personnalisé pour OSGi. L’effort que nous avons fournis pour adapter le noyau au modèle OSGi est nettement plus faible comparant à l’effort nécessaire pour développer une solution en partant de rien. Ceci est naturel vu qu’en reprenant notre noyau, on a pas à réfléchir et à implanter l’architecture du système, et sa logique interne. Exemple comparatif : plug-in de binding Plug-in de binding pour OSGi 400 Plug-in de binding pour Fractal 30

42 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives Mon exposé sera organisé comme suit :  Je vais d’abord commencer par les motivations et présenter l’objectif et le cadre de travail de la thèse. Je présente ensuite quelques travaux ayant adressé la problématique de RD. Les 2 points suivants présente notre contribution à savoir deux expé. Et notre approche générale de reconfiguration. Je conclue à la fin et je présente les perspectives de ce travail.

43 DYVA : Personnalisation pour OSGi
JVM OSGi Framework http Service log Service Permission MyProbe MyHandler … OSGiAdaptor Le modèle OSGi Chargement/déchargement dynamiques Gestion limitée aux unités de déploiement Objet Service Services Classe Java Interfaces Instanciation Composants OSGi OSGi est un modèle qui vise en particulier les environnements qui ont des contraintes de ressources comme les passerelles résidentielles et véhiculaires. Il est basé sur Java. Sa spec définit l’archi d’un framework qui s’exécute au dessus d’une mvj. Et définit un ens de services de base. OSGI a une archi orientée service…. OSGi introduit le concept de bundle, Il est important de noter qu’un bundle représente l’unité de déploiement associée au modèle OSGi, et sert à conditionner les composants. Et qu’il ne correspond pas à la notion de compo telle que nous l’avons définie dans cet exposé. Pour simplifier, un compo OSGi peut être vu comme une classe Java qui impl un ens d’interf. Lorsque cette classe est instanciée, on obtient un objet service qui exporte alors un ens d’interfaces de services. À l’exécution, c l’objet service qui va correspondre à la notion d’intance de composant.

44 DYVA : Personnalisation pour OSGi
Principe de personnalisation Interface de reconfiguration OSGi Interface de notification OSGi Plug-ins de projection OSGi NOYAU Concept de “Bundle”  Opération “libérer bundle” Bundle={composants} Un composant a plusieurs instances “libérer bundle”  déconnecter toutes les instances de tous les composants contenus dans le bundle libérer interface de service libérer objet service connecter interface de service libérer bundle remplacer objet service enregistrement de service dé-enregistrement de service connexion déconnexion événement binding transfert d’état instanciation

45 Démo : Application Portail en OSGi
MySQL

46 Démo : scénario de reconfiguration
Superviseur Événement Gestionnaire de Reconfiguration Règles Gestionnaire du méta-niveau Application 600 400 Version haute qualité Version basse qualité

47 Plan Motivation, objectif et cadre de travail État de l’art
Expérimentations Noyau générique pour la reconfiguration dynamique : DYVA Conception et implémentation Personnalisation Conclusion et perspectives

48 Conclusion Problématique Solution Méthodologie Implémentation
Reconfiguration dynamique des applications à base de composants La plupart des solutions existantes : spécifiques Solution Proposition d’une approche générique de reconfiguration pour les applications à base de composants Méthodologie    Spécifique vers généralisation puis personnalisation Implémentation  Extension de la BeanBox puis OSGi Noyau DYVA :  prototype Personnalisation pour OSGI Le travail que nous avons présenté ds cette thèse traite du domaine de la RD des applications… la complexité du domaine est liée à l'absence de mécanismes de haut niveau, permettant d'intervenir dynamiquement sur une application. Il existe cependant +sieurs travaux autour des syst de R, ces travaux sont en général spécifiques et difficilement exploitable en dehors de leur contexte. Comme contribution, nous avons proposé une approche de RD qui vise les AABC. L’originalité de cette approche réside surtout ds sa géréricité. Pour atteindre notre objectif, nous avons d’abord commencé à travailler sur des MC spécifiques, nous avons ensuite généralisé nos résultats pour définir notre solution générique. Cette solution se présente sous forme d’un noyau commun qu’on peut personnaliser pour différents modèles de composants. Comme résultats pratiques, nous avons implémenté un système de R dynamique pour le modèle JB. Et un système similaire pour le modèle OSGi, nous avons également implanté une solution pour le problème d’incompatibilité d’interfaces pour le modèle OSGi. Nous avons aussi réalisé en Java une implémentation du noyau générique et nous l’avons personnalisé pour OSGi. L’effort que nous avons fournis pour adapter le noyau au modèle OSGi est nettement plus faible comparant à l’effort nécessaire pour développer une solution en partant de rien. Ceci est naturel vu qu’en reprenant notre noyau, on a pas à réfléchir et à implanter l’architecture du système, et sa logique interne.

49 Perspectives (1/2) Stabilisation du prototype DYVA Expérimentations
Large diffusion : logiciel libre (consortium ObjectWeb) Expérimentations Valider la personnalisation OSGi (Projet OSMOSE, PISE…) Autres personnalisations : Fractal, EJB… Les perspectives de ce travail se déclinent en deux aspects :  d’un coté la stabilisation du prototype que nous avons réalisé en vue de le diffuser… nous visons en particulier la diffusion dans le consor OW, où plusieurs membres ont manifesté leur intérêt pour le prototype. L’application de portail Web que nous avons mise en œuvre pour valider la personnalisation OSGi, malgré qu’elle nous a permis de tester divers scénarios, reste une application expérimentale, développée sur mesure. Nous visons à court terme d’exploiter nos résultats dans le cadre de deux projets de l’équipe ce qui va permettre de valider notre approche à une échelle réelle. Il est aussi important de personnaliser le noyau pour d’autres modèles de composants pour consolider l’approche. Par rapport à ça, nous avons déjà commencé à faire des tests pour le modèle Fractal…

50 Perspectives (2/2) Recherche
Formalisation du problème de transfert d’état Solution conceptuelle Automatisation du transfert d’état Migration Gestion de la cohérence de la reconfiguration Détection et résolution des anomalies lors de la reconfiguration États stables Sensibilité au contexte : auto-reconfiguration Paradigmes : ECA, agents…

51 Questions?