Un mcanisme pour ladaptation

1
Un mécanisme pour ladaptation

• Journée ARCAD - 29 novembre 2000
• Eric Bruneton

2
Plan

• Introduction
• Architecture
• Implémentation
• Evaluation
• Conclusion

3
Introduction

• Objectifs trouver une architecture de
  plate-forme middleware permettant
• dassocier des propriétés non fonctionnelles
  (persistance, mobilité, protection) aux
  applications, de façon  orthogonale 
• de programmer séparément chaque propriété
• de composer plusieurs propriétés
• dajouter de nouvelles propriétés (composables
  avec lexistant) au fur et à mesure plate-forme
  extensible

4
Plan

• Introduction
• Architecture
• Modèle applicatif
• Architecture de la plate-forme
• Besoins pour ladaptation ? Modèle de composition
• Résumé
• Implémentation
• Evaluation
• Conclusion

5
Modèle applicatif
Composant
S
Connecteur
Interface
C2
6
Architecture de la plate-forme
Talon
Conteneur
Squelette
Serveur
7
Besoins pour ladaptation

• Exemple dimplémentation dun talon RPC
• méthodes de linterface applicative
• invoke(method,args)
• marshall, unmarshall, ...
• Scénarios dadaptation
• monitoring ? surcharger invoke
• cryptographie ? surcharger marshall et unmarshall
• ...
• Lhéritage de classes nest pas une solution

8
Modèle de composition
Composite
Extension (monitoring)
invoke
Extension (cryptographie)
marshall
invoke
Extension (RPC)
marshall
invoke
Objet extensible (stub générique)
invoke
marshall
9
Résumé de larchitecture
10
Plan

• Introduction
• Architecture
• Implémentation
• Le langage ejava caractéristiques
• Le langage ejava un exemple
• La plate-forme JavaPod
• Evaluation
• Conclusion

11
Le langage ejava caractéristiques

• sur-ensemble de Java
• nouveaux mots-clefs extensible, extension
• permet dassocier dynamiquement des extensions à
  des objets extensibles
• EJava.setExtensions(o,exts)
• compilé en bytecode Java
• compilateur basé sur KOPI (open source)
• URL http//sirac.inrialpes.fr/Logiciel

12
Le langage ejava un exemple
extensible interface Stub Object invoke
(String m, Object args) public extensible
class StubImpl implements Stub public
extensible Object invoke (String m, Object
args) throw new Exception("Not
implemented") public extension class
RPCStub dextends Stub public extensible
Object invoke (String m, Object args) //
... dsuper.invoke(m,args) public
extensible void marshall (...) Stub s
new StubImpl() Ejava.setExtensions(s,new
Object new RPCStub()) s.invoke("print",null)
s.RPCStubmarshall(...)
13
La plate-forme JavaPod

• Prototype pour évaluer larchitecture
• Organisation
• noyau ( 1500 lignes)
• définit les objets extensibles Server, Container,
  Stub et Skeleton
• extensions ( 11000 lignes)
• management configuration, déploiement
• protocoles envoi de messages basique,
  mobilité, cryptographie
• connecteurs client-serveur, flots de données
• propriétés non fonctionnelles persistance,
  protection (hsc, acl), duplication (cache,
  abcast), mode déconnecté

14
Plan

• Introduction
• Architecture
• Implémentation
• Evaluation
• lapplication Baghera
• Baghera propriétés non-fonctionnelles
• implémentation avec JavaPod
• résultats
• Conclusion

15
Lapplication Baghera (1/3)
Ecole
Boites aux lettres
Interface élèves
Interface professeurs
Base dexercices
Cartables
Interface administrateurs
16
Lapplication Baghera (2/3)
interface Mailbox extends JavaPodInterface
Vector getMails () void addMail (Mail mail)
void removeMail (int index) void removeMails
() void addListener (MailListener listener)
interface ElectronicCase extends Mailbox
Vector getExerciseList () void addExercise
(String exercise) void removeExercise (String
exercise) Solution getSolution (String
exercise) void proposeSolution (String
exercise, AnnotatedFigure solution) void
confirmSolution (String exercise) void
proposeCorrection (String exercise,
AnnotatedFigure correction) void
confirmCorrection (String exercise)
17
Lapplication Baghera (3/3)
interface VirtualSchool extends JavaPodInterface
Vector getStudents () void addStudent
(String name, String professor) void
removeStudent (String name) String
getProfessor (String student) ElectronicCase
getElectronicCase (String student) Vector
getProfessors () void addProfessor (String
name) void removeProfessor (String name)
Vector getStudents (String professor) Mailbox
getMailbox (String professor) void
transferStudent (String student, String
professor) ExerciseRepository
getExerciseRepository ()
18
Propriétés non-fonctionnelles

• Persistance
• pour les cartables, les boîtes aux lettres...
• Protection
• un élève ne doit pas avoir accès aux cartables
  des autres élèves, aux solutions des exercices...
• Mode déconnecté
• travail sur une copie partielle des composants
  persistants, puis réconciliation

19
Implémentation persistance
20
Implémentation protection
21
Résultats (1/2)

• associer des propriétés non fonctionnelles aux
  applications, de façon  orthogonale 
• persistance ok (sérialisation après chaque
  appel en écriture)
• protection ok (contrôle daccès avant chaque
  appel)
• mode déconnecté séparation incomplète (certains
  aspects dépendent du code fonctionnel ce quil
  faut copier, et comment réconcilier les copies)
• programmer séparément chaque propriété
• ok, mais il reste quand même des dépendances
  implicites (ex les adresses pour le RPC doivent
  être  permanentes  pour que la persistance
  fonctionne correctement)

22
Résultats (2/2)

• composer plusieurs propriétés
• ok on peut composer persistance, protection et
  mode déconnecté
• mais pas toujours immédiat, ex protection et
  mode déconnecté (il ne faut pas recopier les mots
  de passe, les clefs privées implique en plus de
  changer de protocoles au moment de la
  déconnexion)
• plate-forme extensible
• ajout du service de persistance, de protection,
  sans remettre en cause lexistant (mais petites
  retouches parfois nécessaires)
• on peut ajouter des extensions spécifiques à
  lapplication (ex protection spécialisée, cache
  local pour le RPC)
• mais il y a des limites (ex ajouter un GC
  serait difficile)

23
Conclusion

• Larchitecture proposée permet, dans lensemble,
  de répondre aux objectifs
• Les performances sont acceptables
• Le modèle de composition est plus pratique que
  dautres (composants, méta-objets)
• Les limitations mises en évidence semblent plus
  intrinsèques que liées à larchitecture

24
Perspectives

• Généralisation à une plate-forme moins
   prototype , comme Jonathan
• Composants composites ?
• Choix et ordonnancement automatique des
  extensions, en fonction dune description de haut
  niveau (descripteur de déploiement)
• Optimisations pour le cas  statique 

25
Comparaison ejava / méta-objets
redéfinit marshall
invoke
handle
redéfinit invoke
méta-méta-niveau
marshall
handle
handle
invoke
marshall
marshall
méta-niveau
invoke
invoke
26
Comparaison ejava / composants
Correspond au invoke appelé par dsuper
invoke
invoke
invoke
marshall
marshall
Correspond au marshall appelé par invoke
interface fournie
interface requise