Assia HACHICHI Thème Regal/LIP6 Directeur : Bertil FOLLIOT

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

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

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

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

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

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 ?

Assia HACHICHI Thème Regal/LIP6 Directeur : Bertil FOLLIOT