Persistance d'objets répartis

1. Persistance d'objets répartis Alexandre Lefebvre (DTL/ASR) 24 mars 2000

2. Plan • Présentation de DTL/ASR • Problèmes qui nous préoccupent • Supports de persistance répartis • Noah : gestion de la persistance • SRS : gestion de la répartition • Conclusion

3. Positionnement du département ASR • France Telecom R&D • Centre de R&D de France Télécom ; environ 3800 personnes • Rattaché à la Branche Développement • Direction des Techniques Logicielles (DTL) • Environ 180 personnes en R&D • Quatre départements dans les domaines suivants : • Maquettage, Spécification et Validation • Développement Logiciel, Intelligence artificielle et connexionnisme • Sécurité des Services et des Réseaux • Architecture des Systèmes Répartis (ASR)

4. Profil du département ASR • Centre de compétence “systèmes répartis et systèmes logiciels de base” • Plates-formes d’exécution réparties (ORB) • Moniteurs transactionnels et bases de données répartis • Systèmes (d’exploitation) sous contraintes (QoS, embarqués) • Missions • Recherche & Développement avancé • Veille technologique • Assistance technique (conseil interne) • Effectif = ~ 55 personnes (~ 40 ingénieurs, 10 thésards, post-doc, chercheurs invités)

5. ASR participe à l'initiative ObjectWeb • Initiative « middleware open source » Java • « ObjectWeb Group » initialisé par Bull, FT-R&D et l’INRIA • Base logicielle • Jonathan = ORB ouvert (support de Corba et de RMI) • JOnAS = plate-forme EJB • Coopération avec Enhydra Þ plate-forme J2EE • Informations • http://www.objectweb.org • http://www.enhydra.org

6. BD réparties : quelques sujets en panne • Support de persistance réparti • BD relationnelles • liaisons entre données : calculées par jointures • répartition : modèles de partitionnement (placement) • horizontal (Þ union) • vertical (Þ jointure) • pas d'objets = mauvais candidat pour BD réparties • BD à objets • liaisons entre données : liaisons système • bon candidat mais peu de travail sur la répartition (Versant, Thor)

7. Notre contexte de recherche • BD réparties • contexte intranet plutôt qu’Internet (connaissance exhaustive du monde) • objectif = faire inter-opérer des bases d’objets hétérogènes • Deux catégories de problèmes • gestion des chaînes de liaison entre objets • références persistantes réparties • chaînes d’activation • gestion de l’interrogation (SQL++) • modèle de placement • optimisation Û BD parallèles

8. Quelques principes directeurs • Séparation claire des rôles métier / technique • Architecture multi-tiers Þ BD gère les données (pas de code applicatif) • BD extensible OK pour interrogation (indexes spécialisés) • LPBD (Pjama) KO (modèle de programmation trop différent) • orthogonalité / persistance mais pas de contrôle possible • Serveurs applicatifs : besoin d'une couche intermédiaire • cache d’objets persistants • problème : le serveur de données impose • modèle d’échange (format, politique de pré-chargement,...) • synchronisation (CBL, verrouillage optimiste, etc) • approche composants (EJB, Corba Components, COM+?) • Besoin d'une couche intermédiaire

9. Nos axes de travail actuels • Les chaînes de liaisons entre objets • Références entre objets persistants • Gestion des caches d’objets • Gestion des noms répartis • Synchronisation entre les différentes mémoires • Définition d’invariants architecturaux • Standardisation des interfaces Objets applicatifs répartis : ORB (Corba, RMI) Serveurs applicatifs (EJB) gestion des caches (BDO) Serveurs de données (BDRO, BDO) objets persistants répartis

10. Vision architecturale pour le support de persistance • Objectif = ouvrir le support d’échanges entre les parties “client” et “serveur” d’un SGBD à objets • Support d’échanges entre serveur applicatif et serveur de données • “vision BD” = schéma externe • interface d’accès à objet : SDL (State Definition Language) • interface de synchronisation • interface pour support de transactions client applicatif http (html, xml), IIOP serveur applicatif schéma externe serveur de données schéma logique schéma physique support de persistance disque

11. Persistance : quels besoins ? • Transparence langage (orthogonalité) • Support de l’objet (Noah) • gestion implicite des références • gestion de l’héritage et du polymorphisme • Indépendance vis-à-vis du support de stockage • modèle objet de base (définition d’état) • portabilité binaire de l'accès réparti (SRS) • accès réparti (standard réseau) • Services • de persistance - Noah • de réplication d’objet (état) entre mémoires réparties hétérogènes - SRS

12. Transparence à la conteneur EJB

13. Etendre la persistance des EJB (1) • Contexte : EJB avec persistance container-managed • Limitations de la specification EJB 1.1 • pas d'héritage entre beans • références entre beans gérées par le programmeurs, ou spécifiques aux conteneurs • But : augmenter la transparence pour le programmeur du bean pour : • les références entre objets • l'héritage entre beans • les attributs multi-valués • en bref, retrouver l'abstraction de l'ODMG, mais dans une autre architecture

14. Etendre la persistance des EJB (2) • Exemple: class ProductBean { class OfferBean { float price; Collection products; //set of products public float getPrice(){ public Collection getProducts() { return price; } return products; }} } class PurchaseOfferBean{ Offer offer ; public float totalPrice() throws RemoteException { int theTotal = 0 ;//get the set of product objects Collection products = offer.getProducts(); Iterator productsI = products.iterator(); //for each such product, add the product price to the total while (productsI.hasNext()){ theTotal += ((Product)productsI.next()).getPrice(); } //finally, return the total return theTotal ; }}

15. Noah (persisteNt Object mApping tecHnology)Liaisons pour objets persistants • Modèle de données structurel objet • Descriptions XML : • de la structure des classes persistantes • du mapping vers le support de persistance • Gère la liaison entre les objets dans la base de données et les objets en mémoire • Notion de PId (persistent object identifier) • étend la notion de primary key • introduit le contexte de nommage

16. Noah : modèle de données • Classes et interfaces (pour héritage multiple) • Types de base : integer, loats, strings, etc • Tout ce qui n'est pas d'un type de base est un objet • Ensemble extensible de classes génériques • set, array interface person { class invoice { string(30) LastName; customer Customer; array<string(15)> FirstNames; set<purchase> Purchases; } } interface customer {class purchase { set<invoice> Invoices; product Product; } integer Quantity; interface product { float Total; float Price; } } serialized Picture; class client } implements person, customer { }

17. Noah : utilisation • Dans la hiérarchie des classes EJB pour fournir la persistance container-managed • au niveau de la couche d'interception du container • Autres approches • PSS CORBA • ...

18. Noah : vision logique

19. Noah dans le context EJB

20. persistent class structure persistent class mapping information persistent class structure persistent class mapping information persistent class structure persistent class mapping information PMC XML parser NOAH 1) creation of meta-objects 2) call of meta-object initialization meta-objects java files for persistent class java files for persistent class java files for persistent class reflexive information Utilisation de Noah : Compilation

21. void PID Bean instance 4-setPID 3-init PFactory_XXX PObject_XXX EJBObject_XXX Home_XXX 2-new 5-new, EJBCreate 1-create Utilisation de Noah : creation d'objets (1)

22. 3-setPID 1-export PFactory_XXX PObject_XXX EJBObject_XXX Home_XXX 2-new PID Utilisation de Noah : creation d'objets (2)

23. 6-create 8-read Bean instance PObject_XXX 2-find 10-setattr PFactory_XXX EJBObject_XXX 5-bind Home_XXX 4-bind PID PID PID PID 11-EJBLoad + business method 1-find 3 9-data from data store 7-business method Utilisation de Noah pour trouver et utiliser des objets data store

24. Quelques propriétés de Noah • Réflexivité • les méta objets décrivant les classes persistantes sont eux-même persistants • Les méta-objets sont auto-suffisants : • regénération du fichier de description XML • regénération du code Java

25. Noah : état des travaux • Première version en cours de développement • mapping objet-relationnel implicite • identifiants d'objets • mapping horizontal • attributs multi-valués transformés en collections d'objets mappés dans une table séparée • héritage multiple • Limitations : • pas de support de bases de données legacy • mapping non customisable dans cette version

26. Plan de travail pour Noah • février 00: spécifications • avril 00: premier prototype • été 00: • integration avec JOnAS • plus tard : évolution pour support de persistance sur : • bases de données objet • mapping explicite vers les BD relationnelles legacy • LDAP ?

27. Service de réplication (SRS) • Objectifs • gérer des liaisons entre réplicas • réplicas  mémoires réparties hétérogènes • échanges d’états entre réplicas (gestion de la cohérence) • Modèle de programmation à la ORB • échange d'états au lieu d'appels de procédures à distance • Ce que le SRS ne fait pas, mais permet de programmer • politique de cohérence • politique de synchronisation • mécanisme de transparence langage

28. Exemple d’utilisation du SRS

29. SRS : état des travaux • Spécifications du SRS en cours • Implantation • Personnalité de l’ORB Java Jonathan • Utilisation de GIOP bidirectionnel • Application à l’implantation d’un cache d’objets applicatif • Serveur EJB JOnAS • Choix du serveur d’objets ? • Application à l’implantation de réplication d’objets entre BD • Serveur EJB Jonas • Serveurs de données hétérogènes

30. Autres travaux • Relation avec • les specifications EJB 2.0 • Java Data Objects ? • Autres travaux sur la persistance : PSS • approche très différente • par d'orthogonalité / persistance

31. Conclusion • Objectif : concevoir et construire un middleware d'accès à des mémoires d'objets • répartis • répliqués • persistants • Principes architecturaux : • d'ouverture • d'adaptabilité • Trouver les bons invariants architecturaux • En déduire les bonnes interfaces