Persistance d'objets répartis

AFNOR Java Serveurs - D1 - 24/03/2000France Télécom R&D

Le présent document contient des informations qui sont la propriété de France Télécom. L'acceptation de ce document par son destinataire implique, de la part de ce dernier, la reconnaissance du caractère confidentiel de son contenu et l'engagement de n'en faire aucune reproduction, aucune transmission à des tiers, aucune divulgation et aucune utilisation commerciale sans l'accord préalable écrit de France Télécom R&D

Persistance d'objets répartis

Alexandre Lefebvre (DTL/ASR)

24 mars 2000

La communication de ce document est soumise à autorisation de France Télécom R&D

Alexandre Lefebvre - AFNOR Java Serveurs - D2 - 24/03/2000

France Télécom R&D

Plan

Présentation de DTL/ASRProblèmes qui nous préoccupentSupports de persistance répartis

Noah : gestion de la persistanceSRS : gestion de la répartition

Conclusion




Positionnement du département ASR France Telecom R&D

Centre de R&D de France Télécom ; environ 3800 personnesRattaché à la Branche Développement

Direction des Techniques Logicielles (DTL)Environ 180 personnes en R&DQuatre départements dans les domaines suivants :

Maquettage, Spécification et ValidationDéveloppement Logiciel, Intelligence artificielle et

connexionnismeSécurité des Services et des Réseaux

Architecture des Systèmes Répartis (ASR)




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épartisSystèmes (d’exploitation) sous contraintes (QoS, embarqués)

MissionsRecherche & Développement avancéVeille technologiqueAssistance technique (conseil interne)

Effectif = ~ 55 personnes (~ 40 ingénieurs, 10 thésards, post-doc, chercheurs invités)




ASR participe à l'initiative ObjectWeb

Initiative « middleware open source » Java« ObjectWeb Group » initialisé par Bull, FT-R&D et

l’INRIABase logicielle

Jonathan = ORB ouvert (support de Corba et de RMI)JOnAS = plate-forme EJBCoopération avec Enhydra

plate-forme J2EE

Informationshttp://www.objectweb.orghttp://www.enhydra.org




BD réparties : quelques sujets en panne

Support de persistance répartiBD relationnelles

liaisons entre données : calculées par jointuresrépartition : modèles de partitionnement (placement)

horizontal ( union)vertical ( jointure)

pas d'objets = mauvais candidat pour BD réparties

BD à objetsliaisons entre données : liaisons systèmebon candidat mais peu de travail sur la répartition

(Versant, Thor)




Notre contexte de recherche

BD répartiescontexte 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èmesgestion des chaînes de liaison entre objets

références persistantes répartieschaînes d’activation

gestion de l’interrogation (SQL++)modèle de placementoptimisation BD parallèles




Quelques principes directeursSéparation claire des rôles métier / techniqueArchitecture 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édiairecache d’objets persistantsproblè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




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

Serveursapplicatifs

(EJB)

Serveursde

données(BDRO, BDO)

gestion descaches (BDO)

Objets applicatifs répartis :ORB (Corba, RMI)

objets persistants répartis




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 externeinterface d’accès à objet :

SDL (State Definition Language)

interface de synchronisationinterface pour support de

transactions

clientapplicatif

serveurapplicatif

serveurde données

disque

schéma externe

schéma logique

schéma physique

http (html, xml), IIOP




Persistance : quels besoins ?

Transparence langage (orthogonalité) Support de l’objet (Noah)

gestion implicite des référencesgestion de l’héritage et du polymorphisme

Indépendance vis-à-vis du support de stockagemodèle objet de base (définition d’état)portabilité binaire de l'accès réparti (SRS) accès réparti (standard réseau)

Servicesde persistance - Noahde réplication d’objet (état) entre mémoires réparties

hétérogènes - SRS




Transparence à la conteneur EJB

Environnementd’exécution fermé

nom d’objetlocal

objetd’interception

(proxy)

objetréel

(langage)

objetréel

(persistant)

chaîne de liaison gérée parle support de persistance

Contrôle de la chaîne deliaison « persistante »

Environnementd’exécution réflexif

MEMOIRED’EXECUTION




Contexte : EJB avec persistance container-managed Limitations de la specification EJB 1.1

pas d'héritage entre beansré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 objetsl'héritage entre beansles attributs multi-valuésen bref, retrouver l'abstraction de l'ODMG, mais dans une

autre architecture

Etendre la persistance des EJB (1)




Exemple:class ProductBean { class OfferBean { float price; Collection products; //set of products public float getPrice(){ public Collection getProducts() { return price; } return products; }} }

Etendre la persistance des EJB (2)

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




Noah (persisteNt Object mApping tecHnology)

Liaisons pour objets persistants

Modèle de données structurel objetDescriptions XML :

de la structure des classes persistantesdu 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 keyintroduit le contexte de nommage




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




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 approchesPSS CORBA...




Noah : vision logique

Interfaces

StoredObject

State Mngt Class Factory Class

Control Object Class Control Factory Class

get_attr, set_attr read, write

creation, deletion, retrieval

init, export, unexport, find, bind

setPID

new

NOAH Runtime : Code for Persistence Control

method

create

Persistence Storage System

MemoryObject

Code for controlling memory copies of objects




Noah dans le context EJB

abstract class class interfaceextends

implements

PFactory

PFactory_XXX

XXX home class

PFinder

PObject

PObject_XXX

XXX interface classEJB containercode

Generated code forpersistent class XXX

NOAH code

EJBHomeEJBObject




Utilisation de Noah : Compilation

persistent class mapping information

persistent class structure





2) call of meta-object initialization

reflexive information

java files for persistent class



PMCXML parser

1) creation of meta-objects

meta-objects

NOAH




Utilisation de Noah : creation d'objets (1)

Home_XXX

PFactory_XXX

1-create

EJBObject_XXX

PObject_XXX

2-new

3-init

void PID

4-setPID

Bean instance

5-new, EJBCreate




Utilisation de Noah : creation d'objets (2)

Home_XXX

PFactory_XXX

EJBObject_XXX

PObject_XXX1-export

3-setPID

PID

2-new




Utilisation de Noah pour trouver et utiliser des objets

Home_XXX

PFactory_XXX2-find

1-finddata store

PIDPID

PIDPID

3

4-bind

5-bind EJBObject_XXX

PObject_XXX

6-create

7-business method

8-read

Bean instance

9-data fromdata store

10-setattr

11-EJBLoad + business method




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 XMLregénération du code Java




Noah : état des travaux

Première version en cours de développementmapping objet-relationnel impliciteidentifiants d'objetsmapping horizontalattributs multi-valués transformés en collections d'objets

mappés dans une table séparéehéritage multiple

Limitations :pas de support de bases de données legacymapping non customisable dans cette version




Plan de travail pour Noah

février 00: spécificationsavril 00: premier prototypeété 00:

integration avec JOnAS

plus tard : évolution pour support de persistance sur :bases de données objetmapping explicite vers les BD relationnelles legacyLDAP ?




Service de réplication (SRS)

Objectifsgérer des liaisons

entre réplicasré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 programmerpolitique de cohérencepolitique de synchronisationmécanisme de transparence langage

Original Copy Replica Copy

SRSRequests




Exemple d’utilisation du SRS

MC1

MP1 MP2 MP3

MC2 MC3 MC4 MC5Memoires« Cache »

MemoiresPersistantes

Domaines de réplication persistants

Domaines de réplication de « Cache »




SRS : état des travaux

Spécifications du SRS en cours Implantation

Personnalité de l’ORB Java JonathanUtilisation de GIOP bidirectionnel

Application à l’implantation d’un cache d’objets applicatif Serveur EJB JOnASChoix du serveur d’objets ?

Application à l’implantation de réplication d’objets entre BDServeur EJB JonasServeurs de données hétérogènes




Autres travaux

Relation avec les specifications EJB 2.0 Java Data Objects ?

Autres travaux sur la persistance : PSSapproche très différentepar d'orthogonalité / persistance




Conclusion

Objectif : concevoir et construire un middleware d'accès à des mémoires d'objets

répartisrépliquéspersistants

Principes architecturaux :d'ouvertured'adaptabilité

Trouver les bons invariants architecturauxEn déduire les bonnes interfaces

Documents

Persistance d'objets répartis