Soutenance de thse pour obtenir le grade de

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/LIP 6 Directeur : Bertil FOLLIOT Rapporteurs : Daniel HAGIMONT Lionel SEINTURIER Examinateurs : Didier DONSEZ Christine MORIN Pierre SENS

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 2

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 3

Contexte n Intergiciels orientés composants : n n 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 n n Besoins d’évolution des logiciels n n n e. g. service de nommage, réplication 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 4

Type d’adaptation n Adaptation statique n Interruption logiciel coûteuse financièrement n n n (e. g. services commerciaux) Perte de l’état d’exécution Adaptation dynamique n n n 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 5

Problèmes de l’adaptation dynamique répartie n Nombreuses études sur l’adaptation centralisée n Adaptation dynamique de plateforme d’exécution [exo-noyaux, Jn. JVM, …] n Adaptation dynamique de services système [AOKell, JOD, Jonas. ALa. Carte, …] n Peu d’études sur l’adaptation répartie n 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 6

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

État de l’art n Dynamic. TAO X Open. ORB X Open. CORBA X Flexi. Net X UIC X ZEN X Jonas. ALa. Carte X FROGi X JOn. AS On Demand X AOKell I. Contexte et problématique Composant n Adaptation dynamique des services système Nouveaux intergiciels : n Différents concepts n Simplifie l’adaptation Hétérogénéité des applications réparties n Assemblages de composants hétérogènes n Unification de la construction (e. g. Poly. Orb) n Absence d’unification de l’adaptation répartie n Diminue la réutilisation de l’existant Aspect n Concepts Réflexion Intergiciels adaptables X X 8

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 9

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

Architecture de la CVM n La CVM est une plate-forme générique n N’offre pas un nouvel intergiciel n S’insère comme un service d’adaptation adapter PIP Composant Console Intergiciel X Ä Ré-exploite les mécanismes existants n Les entités de la CVM n PDP adapter PIP PDP SA : Instanciation d’un service d’adaptation n PIP : Partie Indépendante de la Plate-forme n PDP : Partie Dépendante de la Plate-forme n Console distante d’administration II. Notre proposition : la CVM Composant Intergiciel Y 11

Partie Indépendante de la Plate-forme n DSL : Langage dédié à l’adaptation n n Sépare la logique d’adaptation de son implémentation Fournit un haut-niveau d’abstraction Simple pour l’administrateur Adaptation élémentaire n n n Ajouter un service : add. Service Supprimer un service : rm. Service Adapter un service : adapt. Service II. Notre proposition : la CVM 12

Partie Dépendante de la Plate-forme n n PDP : Partie spécifique à l’intergiciel Interception des messages n Objet d’interposition Service 1 Objet d’interposition Service 2 n Ajouter un objet d’interposition n Service 3 n n n II. Notre proposition : la CVM Absence d’une architecture commune aux intergiciels méthode addservice(OI, service) méthode rm. Service(OI, service) méthode adapt. Service(OI, service) Associer ces méthodes aux instructions du DSL 13

Synthèse adapter PIP Intergiciel X PDP adapter msg OI msg Console d’administration PIP msg S 1 S 2 Intergiciel Y PDP adapter msg II. Notre proposition : la CVM Composant OI adapter msg msg S 1 S 2 Composant 14

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 15

Implémentation de la CVM n PIP de la CVM réalisée au dessus de la VM n VM implémentation de la MVV n VM permet de définir de nouveaux langages (DSL). n VM sépare la construction du langage de sa compilation VM n PDP : VM peut être spécialisable pour un intergiciel Console d’administration PIP adapter VM Délégation de la compilation AST sérialisé PDP Composant Intergiciel Y III. Réalisation pour Open. CCM et JOn. AS 16

Implémentation d’une PDP n n PDP – CVM réalisée pour Open. CCM et JOn. AS n Pas de possibilité d’adaptation dynamique n Valider le DSL Processus d’implémentation d’une PDP 1. Etude de l’architecture de l’intergiciel et de leur MV 2. Déterminer les objets d’interposition 3. Établir les méthodes qui permettent de les manipuler 4. Associer ces méthodes aux instructions du DSL n Réalisation de la PDP complexe, mais effectuée une seule fois pour un intergiciel donné III. Réalisation pour Open. CCM et JOn. AS 17

PDP - Open. CCM n Open. CCM : implémentation de CCM en Java n Étude de l’architecture d’Open. CCM et de JVM n Les objets d’interposition n n COS 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 n Méthodes d’adaptation en Open. CCM n Association des méthodes d’adaptation au DSL III. Réalisation pour Open. CCM et JOn. AS Intercepteur portable 18

PDP - JOn. AS n n n JOn. AS : implémentation des EJB en Java Étude de l’architecture de JOn. AS et de la JVM n Ne propose pas nativement des objets d’interposition. Proxy Les objets d’interposition n Les objets proxy Java n Agent JVMTI (Java Virtual Machine Tool Interface). Méthodes d’adaptation en JOn. AS Association des méthodes d’adaptation au DSL III. Réalisation pour Open. CCM et JOn. AS JVMTI 19

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 20

Validation n n Prototype n PIP réutilisable n 2 PDP Open. CCM et JOn. AS Adaptation dynamique des services dans Open. CCM et JOn. AS Objets d’interposition Open. CCM JOn. AS Service de Monitoring Intercepteur Portable (service non-intrusif) Service de debug (service non-intrusif) Service de cryptage (service intrusif) IV. Validation JVMTI COS Proxy 21

Service de monitoring flexible n Gestion d’applications complexes. n n Intégration dynamique du service de monitoring flexible n n n Le service de monitoring Application « Dîner des philosophes » d’Open. CCM Insérer le service dans les crochets du PI La CVM unifie et adapte dynamiquement Open. CCM (. push ‘(add. Service 21 "Monitor. CI" C 1) Socket. A) (. push ‘(add. Service 21 "Monitor. CI" C 2) Socket. B) IV. Validation 22

Service de debug n Service de debug dans JOn. AS n n n 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 JOn. AS (. push ‘(add. Service 31 service. Debug poincut) Socket. A) (. push ‘(add. Service 32 service. Debug pointcut) Socket. A) (. push ‘(rm. Service 31 service. Debug poincut) Socket. A) (. push ‘(rm. Service 32 service. Debug pointcut) Socket. A) IV. Validation 23

Service de cryptage n Crypter les messages entre émetteur et récepteur n n n Application répartie n n n Intégrer le service de cryptage Adapter l’algorithme de cryptage Composant A qui envoie des messages au composant B Synchronisation de l’adaptation répartie Implémentation n n IV. Validation Open. CCM JOn. AS 24

Service de cryptage Open. CCM (. push ‘(deactivate) socket. A) (. push ‘(deactivate) socket. B) (. push ‘(add. Service 22 crypt CA) Socket. A) (. push ‘(add. Service 22 crypt CB) Socket. B) JOn. AS (. push ‘(sb 1 ejb. Passivate) socket. A) (. push ‘(sb 2 ejb. Passivate) socket. B) (. push ‘(add. Service 33 crypt JOn. ASOp. Remote) Socket. A) (. push ‘(add. Service 33 crypt JOn. ASOp. Remote_Stub) Socket. B) IV. Validation 25

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

Performances n n 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 Temps (ms) Intergiciel Intégration Modification PIII 664 Mhz PIV 3, 2 Ghz Open. CCM 2054 369, 2 94 69, 2 JOn. AS 153 79 Service de monitoring Open. CCM 8539 Service de debug JOn. AS 109 Service de cryptage IV. Validation Suppression PIII 664 Mhz PIV 3, 2 Ghz 518 162 79, 7 48 94 45, 2 27

Container Virtual Machine I. II. IV. Contexte et Problématique Notre proposition : la CVM Réalisation pour Open. CCM et JOn. AS Validation Conclusion et Perspectives 28

Conclusion n n Masque l’hétérogénéité de l’adaptation répartie n DSL : sépare la logique d’adaptation de son implémentation n Facilite l’administration de l’adaptation répartie Adaptation dynamique des services système n Adapte les intergiciels n Adapte de manière transparente pour l’application V. Conclusion et Perspectives 29

Conclusion n n Validation de la CVM n Implémentation de la PIP sur la VM n Implémentation de la PDP pour Open. CCM et JOn. AS n Adaptation de services : monitoring, debug, cryptage CVM générique n Unification de l’adaptation des intergiciels à composants n Réalisation pour d’autres intergiciels à composants. V. Conclusion et Perspectives 30

Perspectives - Court terme n Étendre le DSL n n n Cohérence n Autres mécanismes de synchronisation n Gestion de reprise sur erreur Sécurité n n Séparer la logique de la synchronisation de son implémentation Module de sécurité dans la CVM Retour à un ancien état n n Implémentation d’un mécanisme « Undo » Retour vers un ancien état de façon atomique V. Conclusion et Perspectives 31

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

MERCI QUESTIONS ? 33