Soutenance de thèse pour obtenir le grade de Docteur de lUniversité de Paris VI Container Virtual Machine Une plate-forme générique pour ladaptation 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

2 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

3 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

4 Contexte Intergiciels orientés composants : Masquer lhé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 lintergiciel 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 dadapter les services systèmes dans les intergiciels I. Introduction

5 Type dadaptation Adaptation statique Interruption logiciel coûteuse financièrement (e.g. services commerciaux) Perte de létat dexécution Adaptation dynamique Mise à jour durant lexécution Pas de perte détat due à la mise à jour Interruption de lordre de quelques secondes versus quelques heures Adaptation dynamique des services système I. Introduction

6 Problèmes de ladaptation dynamique répartie Nombreuses études sur ladaptation centralisée Adaptation dynamique de plateforme dexécution [exo-noyaux, JnJVM,…] Adaptation dynamique de services système [AOKell, JOD, JonasALaCarte,…] Peu détudes sur ladaptation répartie Nœuds construits avec des Machine/OS/Langage différents Complexité de ladaptation répartie augmente avec lhétérogénéité Gestion complexe de la synchronisation Absence dunification de ladaptation répartie I. Contexte et problématique

7 Notre solution I. Introduction 1. Adaptation dynamique répartie Masquer lhétérogénéité de ladaptation répartie Séparer la logique dadaptation de son implémentation Base pour résoudre la synchronisation 2. Adaptation ciblée Service système dinformation : liés aux traitements des requêtes Transparent par rapport au code métier 3. Porté générale Unifier ladaptation des intergiciels rigides et adaptables Augmenter la réutilisation de lexistant

8 É tat de lart I. Contexte et problématique Adaptation dynamique des services système Nouveaux intergiciels : Différents concepts Simplifie ladaptation Hétérogénéité des applications réparties Assemblages de composants hétérogènes Unification de la construction (e.g. PolyOrb) Absence dunification de ladaptation répartie Diminue la réutilisation de lexistant Intergiciels adaptables Concepts Réflexion Aspect Composant DynamicTAOX OpenORBX OpenCORBAX FlexiNetX UICX ZENX JonasALaCarteX FROGiX JOnAS On DemandX AOKellXX

9 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

10 Concept de la CVM Composant Console administration Intergiciel Y Intergiciel X Composant Adaptation unifiée & synchronisation Adaptation Spécifique II. Notre proposition : la CVM Adapter Intergiciel Y Adapter Intergiciel X Adaptation dynamique répartie Spécifique à un intergiciel Hétérogénéité Cohérence et synchronisation Objectif : Séparer la logique dadaptation de son implémentation

11 Architecture de la CVM La CVM est une plate-forme générique Noffre pas un nouvel intergiciel Sinsère comme un service dadaptation Ré-exploite les mécanismes existants Les entités de la CVM SA : Instanciation dun service dadaptation PIP : Partie Indépendante de la Plate-forme PDP : Partie Dépendante de la Plate-forme Console distante dadministration Console adapter Intergiciel X Composant Intergiciel Y Composant PIPPDPPIPPDP adapter II. Notre proposition : la CVM

12 Partie Indépendante de la Plate-forme DSL : Langage dédié à ladaptation Sépare la logique dadaptation de son implémentation Fournit un haut-niveau dabstraction Simple pour ladministrateur Adaptation élémentaire Ajouter un service : addService Supprimer un service : rmService Adapter un service : adaptService II. Notre proposition : la CVM

13 Partie Dépendante de la Plate-forme Objet dinterposition Service 1 Service 3 Service 2 PDP : Partie spécifique à lintergiciel Interception des messages Absence dune architecture commune aux intergiciels Ajouter un objet dinterposition 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

14 Synthèse PIPPDP Composant S1S2 msg adapter Intergiciel X PIPPDP Composant Intergiciel Y Console dadministration adapter OI S1S2 msg adapter II. Notre proposition : la CVM

15 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

16 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 VM sépare la construction du langage de sa compilation PDP : VM peut être spécialisable pour un intergiciel III. Réalisation pour OpenCCM et JOnAS VM PIP Délégation de la compilation Intergiciel Y Composant PDP adapter AST sérialisé Console dadministration

17 Implémentation dune PDP PDP – CVM réalisée pour OpenCCM et JOnAS Pas de possibilité dadaptation dynamique Valider le DSL Processus dimplémentation dune PDP 1.Etude de larchitecture de lintergiciel et de leur MV 2.Déterminer les objets dinterposition 3.Établir les méthodes qui permettent de les manipuler 4.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

18 PDP - OpenCCM OpenCCM : implémentation de CCM en Java Étude de larchitecture dOpenCCM et de JVM Les objets dinterposition 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 dadaptation en OpenCCM Association des méthodes dadaptation au DSL Intercepteur portable COS III. Réalisation pour OpenCCM et JOnAS

19 PDP - JOnAS JOnAS : implémentation des EJB en Java Étude de larchitecture de JOnAS et de la JVM Ne propose pas nativement des objets dinterposition. Les objets dinterposition Les objets proxy Java Agent JVMTI (Java Virtual Machine Tool Interface). Méthodes dadaptation en JOnAS Association des méthodes dadaptation au DSL JVMTI Proxy III. Réalisation pour OpenCCM et JOnAS

20 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

21 Validation Prototype PIP réutilisable 2 PDP OpenCCM et JOnAS Adaptation dynamique des services dans OpenCCM et JOnAS Objets dinterpositionOpenCCMJOnAS Service de Monitoring (service non-intrusif) Intercepteur Portable Service de debug (service non-intrusif) JVMTI Service de cryptage (service intrusif) COSProxy IV. Validation

22 Service de monitoring flexible Gestion dapplications complexes. Le service de monitoring Intégration dynamique du service de monitoring flexible Application « Dîner des philosophes » dOpenCCM 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

23 Service de debug Service de debug dans JOnAS Collecte et journalise les appels aux méthodes et leurs arguments dappel Basé sur lagent JVMTI (tissage mixte) La CVM unifie et adapte dynamiquement JOnAS (.push (addService 31 serviceDebug poincut) SocketA) (.push (addService 32 serviceDebug pointcut) SocketA) (.push (rmService 31 serviceDebug poincut) SocketA) (.push (rmService 32 serviceDebug pointcut) SocketA) IV. Validation

24 Service de cryptage Crypter les messages entre émetteur et récepteur Intégrer le service de cryptage Adapter lalgorithme de cryptage Application répartie Composant A qui envoie des messages au composant B Synchronisation de ladaptation répartie Implémentation OpenCCM JOnAS IV. Validation

25 Service de cryptage (.push (deactivate) socketA) (.push (deactivate) socketB) (.push (addService 22 crypt CA) SocketA) (.push (addService 22 crypt CB) SocketB) OpenCCM JOnAS (.push (sb1 ejbPassivate) socketA) (.push (sb2 ejbPassivate) socketB) (.push (addService 33 crypt JOnASOpRemote) SocketA) (.push (addService 33 crypt JOnASOpRemote_Stub) SocketB) IV. Validation

26 Mise en œuvre des applications Unification de ladaptation Facilite la description de ladaptation répartie Offre une base pour résoudre les problèmes de la répartition Construction de langage dadaptation difficile Etendre le DSL pour uniformiser Synchronisation Mécanismes de répartition IV. Validation

27 Performances Intergiciel Temps (ms) IntégrationModificationSuppression PIII 664 Mhz PIV 3,2Ghz PIII 664 Mhz PIV 3,2Ghz PIII 664 Mhz PIV 3,2Ghz Service de cryptageOpenCCM ,29469,2 JOnAS15379 Service de monitoringOpenCCM ,7 Service de debugJOnAS ,2 Durée moyenne dadaptation en milliseconde Comparaison avec ladaptation statique Interruption du service Coût très limité par rapport à ladaptation statique IV. Validation

28 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

29 Conclusion Masque lhétérogénéité de ladaptation répartie DSL : sépare la logique dadaptation de son implémentation Facilite ladministration de ladaptation répartie Adaptation dynamique des services système Adapte les intergiciels Adapte de manière transparente pour lapplication V. Conclusion et Perspectives

30 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 ladaptation des intergiciels à composants Réalisation pour dautres intergiciels à composants. V. Conclusion et Perspectives

31 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 dun mécanisme « Undo » Retour vers un ancien état de façon atomique V. Conclusion et Perspectives

32 Perspectives - Long terme Validation Validation des propriétés en se basant sur le DSL de la CVM Séparation entre la logique dadaptation et son implémentation Auto-adaptation Faciliter ladministration de systèmes de grande taille Coupler la CVM avec les notions dintelligence artificielle Outils permettant laide à la décision et lauto-adaptation V. Conclusion et Perspectives

33 MERCI QUESTIONS ?