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 Rapporteurs : Daniel HAGIMONT Lionel SEINTURIER Examinateurs : Didier DONSEZ Christine MORIN
33
Embed
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.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Soutenance de thèse pour obtenir le grade de Docteur de l’Université de Paris VI
pour l’adaptation dynamique des services système dans les intergiciels orientés composants
Assia HACHICHIThème Regal/LIP6
Directeur : Bertil FOLLIOTRapporteurs : Daniel HAGIMONT
Lionel SEINTURIERExaminateurs : 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 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
(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
6
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
7
Notre solution
I. Introduction
1. 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
2. Adaptation ciblée 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
8
État de l’art
I. Contexte et problématique
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
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
11
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
adapter
Intergiciel X
Composant
Intergiciel Y
Composant
PIP PDP
PIP PDP
adapter
II. Notre proposition : la CVM
12
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
13
Partie Dépendante de la Plate-forme
Objet d’interposition
Objet d’interposition
Service 1
Service 3
Service 2
PDP : Partie spécifique à l’intergiciel Interception des messages
Absence d’une architecture commune aux intergiciels
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). VMVM 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 com
pilation
Intergiciel Y
Composant
PDP
adapter
AST sérialisé
Console d’administration
17
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 PDP1. 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
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 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
Intercepteur portable
COS
III. Réalisation pour OpenCCM et JOnAS
19
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
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 d’interposition OpenCCM JOnAS
Service de Monitoring
(service non-intrusif)
Intercepteur Portable
Service de debug
(service non-intrusif)
JVMTI
Service de cryptage
(service intrusif)
COS Proxy
IV. Validation
22
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
23
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
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
27
Performances
Intergiciel
Temps (ms)
Intégration Modification Suppression
PIII
664 Mhz
PIV
3,2Ghz
PIII
664 Mhz
PIV
3,2Ghz
PIII
664 Mhz
PIV
3,2Ghz
Service de cryptage OpenCCM 2054 369,2 94 69,2
JOnAS 153 79
Service de monitoring OpenCCM 8539 518 162 79,7
Service de debug JOnAS 109 48 94 45,2
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
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 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
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 l’adaptation des intergiciels à composants
Réalisation pour d’autres 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 d’un 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 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