Soutenance de thèse pour obtenir le grade de Docteur de l’Université de Paris VI

Container Virtual MachineUne plate-forme générique

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

I. Introduction

5

Type d’adaptation

Adaptation statique Interruption logiciel coûteuse financiè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

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

répartie Diminue la réutilisation de l’existant

Intergiciels adaptables

Concepts

Réflexio

n

Aspect

Com

posant

DynamicTAO X

OpenORB X

OpenCORBA X

FlexiNet X

UIC X

ZEN X

JonasALaCarte X

FROGi X

JOnAS On Demand X

AOKell X X

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

Consoleadministration

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 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

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

14

Synthèse

PIP PDP

Composant

S1 S2

msg

msgmsg

msgadapter

Intergiciel X

PIP PDP

Composant

Intergiciel Y

Console d’administration

adapter

adapter

OI

OI

S1 S2

msg

msgmsg

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). 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

(.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 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

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 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

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

V. Conclusion et Perspectives

33

MERCI

QUESTIONS ?