340 likes | 494 Views
Soutenance de thèse pour obtenir le grade de Docteur de l’Université de Paris VI Container Virtual Machine Une plate-forme générique pour l’adaptation dynamique des services système dans les intergiciels orientés composants. Assia HACHICHI Thème Regal/LIP6 Directeur : Bertil FOLLIOT
E N D
Soutenance de thèse pour obtenir le grade de Docteur de l’Université de Paris VIContainer Virtual MachineUne plate-forme générique pour l’adaptation dynamique des services système dans les intergiciels orientés composants Assia HACHICHI Thème Regal/LIP6 Directeur : Bertil FOLLIOT Rapporteurs : Daniel HAGIMONT Lionel SEINTURIER Examinateurs : Didier DONSEZ Christine MORIN Pierre SENS
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
Contexte • Intergiciels orientés composants : • Masquer l’hétérogénéité et la répartition • Séparation des préoccupations • Code métier : composant entité logicielle invocable à distance • Service système : code non-fonctionnel géré par l’intergiciel • e.g. service de nommage, réplication • Besoins d’évolution des logiciels • Ajout de nouvelles fonctionnalités : e.g. équilibrage de charge • Mise à jour : nouvelle version, correction de bug (e.g. faille de sécurité) • Besoin d’adapter les services systèmes dans les intergiciels I. Introduction
Type d’adaptation • Adaptation statique • Interruption logiciel coûteusefinancièrement • (e.g. services commerciaux) • Perte de l’état d’exécution • Adaptation dynamique • Mise à jour durant l’exécution • Pas de perte d’état due à la mise à jour • Interruption de l’ordre de quelques secondes versus quelques heures • Adaptation dynamique des services système I. Introduction
Problèmes de l’adaptation dynamique répartie • Nombreuses études sur l’adaptation centralisée • Adaptation dynamique de plateforme d’exécution [exo-noyaux, JnJVM,…] • Adaptation dynamique de services système [AOKell, JOD, JonasALaCarte,…] • Peu d’études sur l’adaptation répartie • Nœuds construits avec des Machine/OS/Langage différents • Complexité de l’adaptation répartie augmente avec l’hétérogénéité • Gestion complexe de la synchronisation • Absence d’unification de l’adaptation répartie I. Contexte et problématique
Notre solution • Adaptation dynamique répartie • Masquer l’hétérogénéité de l’adaptation répartie • Séparer la logique d’adaptation de son implémentation • Base pour résoudre la synchronisation • Adaptation ciblée • Service système d’information : liés aux traitements des requêtes • Transparent par rapport au code métier • Porté générale • Unifier l’adaptation des intergiciels rigides et adaptables • Augmenter la réutilisation de l’existant I. Introduction
État de l’art • Adaptation dynamique des services système • Nouveaux intergiciels : • Différents concepts • Simplifie l’adaptation • Hétérogénéité des applications réparties • Assemblages de composants hétérogènes • Unification de la construction (e.g. PolyOrb) • Absence d’unification de l’adaptation répartie • Diminue la réutilisation de l’existant I. Contexte et problématique
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
Console administration Composant Composant Adapter Intergiciel Y Adapter Intergiciel X Concept de la CVM Intergiciel X • Adaptation dynamique répartie • Spécifique à un intergiciel • Hétérogénéité • Cohérence et synchronisation • Objectif : • Séparer la logique d’adaptation de son implémentation Intergiciel Y Adaptation unifiée & synchronisation Adaptation Spécifique II. Notre proposition : la CVM
PIP PIP PDP PDP adapter adapter Composant Composant Architecture de la CVM • La CVM est une plate-forme générique • N’offre pas un nouvel intergiciel • S’insère comme un service d’adaptation • Ré-exploite les mécanismes existants • Les entités de la CVM • SA : Instanciation d’un service d’adaptation • PIP : Partie Indépendante de la Plate-forme • PDP : Partie Dépendante de la Plate-forme • Console distante d’administration Console Intergiciel X Intergiciel Y II. Notre proposition : la CVM
Partie Indépendante de la Plate-forme • DSL : Langage dédié à l’adaptation • Sépare la logique d’adaptation de son implémentation • Fournit un haut-niveau d’abstraction • Simple pour l’administrateur • Adaptation élémentaire • Ajouter un service : addService • Supprimer un service :rmService • Adapter un service :adaptService II. Notre proposition : la CVM
Objet d’interposition Service 1 Service 2 Objet d’interposition Service 3 Partie Dépendante de la Plate-forme • PDP : Partie spécifique à l’intergiciel • Interception des messages • Absence d’une architecture commune aux intergiciels • Ajouter un objet d’interposition • méthode addservice(OI, service) • méthode rmService(OI, service) • méthode adaptService(OI, service) • Associer ces méthodes aux instructions du DSL II. Notre proposition : la CVM
PIP PDP OI PIP PDP adapter msg msg OI msg msg S1 S2 Synthèse adapter Intergiciel X adapter msg msg Composant Console d’administration msg msg S1 S2 Intergiciel Y adapter Composant II. Notre proposition : la CVM
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
AST sérialisé PIP Composant VM Implémentation de la CVM • PIP de la CVM réalisée au dessus de la VM • VM implémentation de la MVV • VM permet de définir de nouveaux langages (DSL). • VM sépare la construction du langage de sa compilation • PDP : VM peut être spécialisable pour un intergiciel Délégation de la compilation PDP Console d’administration adapter Intergiciel Y III. Réalisation pour OpenCCM et JOnAS
Implémentation d’une PDP • PDP – CVM réalisée pour OpenCCM et JOnAS • Pas de possibilité d’adaptation dynamique • Valider le DSL • Processus d’implémentation d’une PDP • Etude de l’architecture de l’intergiciel et de leur MV • Déterminer les objets d’interposition • Établir les méthodes qui permettent de les manipuler • Associer ces méthodes aux instructions du DSL • Réalisation de la PDP complexe, mais effectuée une seule fois pour un intergiciel donné III. Réalisation pour OpenCCM et JOnAS
PDP - OpenCCM • OpenCCM : implémentation de CCM en Java • Étude de l’architecture d’OpenCCM et de JVM • Les objets d’interposition • les intercepteurs portables (IP) proposés par la spécification de CORBA • les Composants Orientés Système (COS) défini dans la thèse • Méthodes d’adaptation en OpenCCM • Association des méthodes d’adaptation au DSL COS Intercepteur portable III. Réalisation pour OpenCCM et JOnAS
PDP - JOnAS • JOnAS : implémentation des EJB en Java • Étude de l’architecture de JOnAS et de la JVM • Ne propose pas nativement des objets d’interposition. • Les objets d’interposition • Les objets proxy Java • Agent JVMTI (Java Virtual Machine Tool Interface). • Méthodes d’adaptation en JOnAS • Association des méthodes d’adaptation au DSL Proxy JVMTI III. Réalisation pour OpenCCM et JOnAS
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
Validation • Prototype • PIP réutilisable • 2 PDP OpenCCM et JOnAS • Adaptation dynamique des services dans OpenCCM et JOnAS IV. Validation
Service de monitoring flexible • Gestion d’applications complexes. • Le service de monitoring • Intégration dynamique du service de monitoring flexible • Application « Dîner des philosophes » d’OpenCCM • Insérer le service dans les crochets du PI • La CVM unifie et adapte dynamiquement OpenCCM (.push ‘(addService 21 "MonitorCI" C1) SocketA) (.push ‘(addService 21 "MonitorCI" C2) SocketB) IV. Validation
Service de debug • Service de debug dans JOnAS • Collecte et journalise les appels aux méthodes et leurs arguments d’appel • Basé sur l’agent JVMTI (tissage mixte) • La CVM unifie et adapte dynamiquement JOnAS (.push ‘(addService 31 serviceDebugpoincut) SocketA) (.push ‘(addService 32 serviceDebug pointcut) SocketA) (.push ‘(rmService 31 serviceDebug poincut) SocketA) (.push ‘(rmService 32 serviceDebugpointcut) SocketA) IV. Validation
Service de cryptage • Crypter les messages entre émetteur et récepteur • Intégrer le service de cryptage • Adapter l’algorithme de cryptage • Application répartie • Composant A qui envoie des messages au composant B • Synchronisation de l’adaptation répartie • Implémentation • OpenCCM • JOnAS IV. Validation
Service de cryptage OpenCCM (.push ‘(deactivate) socketA) (.push ‘(deactivate) socketB) (.push ‘(addService 22 cryptCA) SocketA) (.push ‘(addService 22 cryptCB) SocketB) JOnAS (.push ‘(sb1 ejbPassivate) socketA) (.push ‘(sb2 ejbPassivate) socketB) (.push ‘(addService 33 cryptJOnASOpRemote) SocketA) (.push ‘(addService 33 cryptJOnASOpRemote_Stub) SocketB) IV. Validation
Mise en œuvre des applications • Unification de l’adaptation • Facilite la description de l’adaptation répartie • Offre une base pour résoudre les problèmes de la répartition • Construction de langage d’adaptation difficile • Etendre le DSL pour uniformiser • Synchronisation • Mécanismes de répartition IV. Validation
Performances • Durée moyenne d’adaptation en milliseconde • Comparaison avec l’adaptation statique • Interruption du service • Coût très limité par rapport à l’adaptation statique IV. Validation
Container Virtual Machine I. Contexte et Problématique II. Notre proposition : la CVM III. Réalisation pour OpenCCM et JOnAS IV. Validation V. Conclusion et Perspectives
Conclusion • Masque l’hétérogénéité de l’adaptation répartie • DSL : sépare la logique d’adaptation de son implémentation • Facilite l’administration de l’adaptation répartie • Adaptation dynamique des services système • Adapte les intergiciels • Adapte de manière transparente pour l’application V. Conclusion et Perspectives
Conclusion • Validation de la CVM • Implémentation de la PIP sur la VM • Implémentation de la PDP pour OpenCCM et JOnAS • Adaptation de services : monitoring, debug, cryptage • CVM générique • Unification de l’adaptation des intergiciels à composants • Réalisation pour d’autres intergiciels à composants. V. Conclusion et Perspectives
Perspectives - Court terme • Étendre le DSL • Séparer la logique de la synchronisation de son implémentation • Cohérence • Autres mécanismes de synchronisation • Gestion de reprise sur erreur • Sécurité • Module de sécurité dans la CVM • Retour à un ancien état • Implémentation d’un mécanisme « Undo » • Retour vers un ancien état de façon atomique V. Conclusion et Perspectives
Perspectives - Long terme • Validation • Validation des propriétés en se basant sur le DSL de la CVM • Séparation entre la logique d’adaptation et son implémentation • Auto-adaptation • Faciliter l’administration de systèmes de grande taille • Coupler la CVM avec les notions d’intelligence artificielle • Outils permettant l’aide à la décision et l’auto-adaptation V. Conclusion et Perspectives
MERCI QUESTIONS ?