version pdf

Intergiciel et Construction d’Applications R´eparties
c
2006 P. D´echamboux, Y. Bersihand, S. Chassande-Barrioz (version du 4 janvier 2007 - 14:58)
Licence Creative Commons (http://creativecommons.org/licenses/by-nc-nd/2.0/fr/deed.fr)
Annexe F
Speedo : un syst`eme de gestion de
la persistance
F.1 Introduction
Cette annexe d´ecrit le fonctionnement et l’utilisation de Speedo, un syst`eme de ges-
tion de la persistance d’objets Java. Cette description s’appuie sur le mod`ele de persis-
tance propos´e dans le cadre des sp´ecifications JDO (Java Data Objects) [JSR-000012 2004,
JSR-000243 2006], mises en œuvre par Speedo.
Le sujet de la persistance est au cœur des applications informatiques pratiquement
depuis l’origine de la discipline. P´er´enniser les informations manipul´ees par une applica-
tion par del`a son ex´ecution ou les probl`emes de pannes aff´erents `a son environnement
d’ex´ecution mat´eriel et logiciel est une propri´et´e essentielle. Les disques durs repr´esentent
le support le plus courant pour g´erer les informations p´erennes, avec des abstractions lo-
gicielles de plus ou moins haut niveau pour les manipuler, que ce soit des syst`emes de
fichiers ou des syst`emes de gestion de bases de donn´ees.
Il se trouve que les formats des donn´ees manipul´ees dans les langages de programma-
tion et leur repr´esentation dans le support p´erenne sont dans tous les cas diff´erents. Le
couplage entre l’espace m´emoire li´e `a l’environnement d’ex´ecution d’un langage et l’espace
m´emoire p´erenne est central dans le probl`eme de la persistance. Dans le seul contexte du
langage Java, plusieurs propositions ont ´et´e faites pour proposer des solutions le plus trans-
parente possible du point de vue du programmeur, que ce soit au travers de sp´ecifications
standard [Sun JSR-000153 2003, JSR-000220 2006, JSR-000012 2004, JSR-000243 2006]
ou de produits sp´ecifiques [Oracle 1994, Hibernate 2002, Enhydra 2002, Castor 1999]. Le
produit Speedo [Chassande-Barrioz 2003] propos´e dans le cadre du consortium Objectweb
[ObjectWeb 1999] se situe dans cette mouvance.
F.1.1 Qu’est-ce que Speedo ?
Speedo est un canevas de gestion de la persistance dans le contexte du langage Java.
Il est utilis´e pour implanter les deux standards pr´epond´erants sur le sujet dans le cadre

2ANNEXE F. SPEEDO : UN SYST ` EME DE GESTION DE LA PERSISTANCE
de Java : JDO2 [JSR-000243 2006] et EJB3 [JSR-000220 2006]. Ces standards ont eu des
´evolutions diff´erentes :
– JDO : l’objectif de JDO est de fournir un standard de persistance ind´ependant
des supports de stockage (c’est `a dire non li´e aux seules bases de donn´ees rela-
tionnelles), et qui s’applique aussi bien dans le cadre de Java de base [J2SE 2005]
que de Java pour l’entreprise [J2EE 2005]. Deux versions 1 [JSR-000012 2004] et 2
[JSR-000243 2006] de la sp´ecification se sont succ´ed´ees, sachant que les ´evolutions
concernent soit des ajouts fonctionnels, soit des diff´erences dans la sp´ecification des
informations de projection vers les bases de donn´ees relationnelles. Le mod`ele de
programmation n’est notamment pas remis en cause entre ces deux versions.
– EJB : les sp´ecifications EJB font partie de l’environnement Java pour l’entreprise
[J2EE 2005]. Elles incluent un support de la persistance `a travers les entity beans.
Ces sp´ecifications ont eu trois ´evolutions majeures, sachant qu’`a chaque changement
de version, le mod`ele de programmation a ´et´e compl`etement chang´e. Par ailleurs, la
derni`ere mouture de ces sp´ecifications propose un cadre de gestion de la persistance
Java valide aussi bien pour Java de base [J2SE 2005] que pour Java pour l’entreprise
[J2EE 2005]. Ce standard reste fortement li´e aux bases de donn´ees relationnelles.
Fonctionnellement, Speedo s’apparente aux clients lourds des bases de donn´ees `a objets
puisqu’il met en œuvre des techniques de gestion de cache ´evolu´ees ou encore de gestion
de concurrence. Il s’appuie sur un certain nombre d’autres canevas comme le montre la
figure F.1, au nombre desquels on retrouve :
– Perseus [Chassande-Barrioz and Dechamboux 2003] : c’est un canevas qui identi-
fie diff´erents composants concourants `a la mise en œuvre de syst`emes d’´echange
de donn´ees entre un support de stockage et une m´emoire d’ex´ecution d’applica-
tion, prenant en compte des comportements transactionnels ou encore des contextes
d’ex´ecution concurrents. Il d´efinit aussi les liens qui r´egissent les interactions entre
ces diff´erents composants. Parmi ces composants, nous pouvons citer le gestionnaire
de concurrence, le syst`eme de journalisation ou encore le gestionnaire d’E/S.
– MEDOR [Team 2000] : c’est un canevas qui permet de manipuler des requˆetes en-
semblistes `a travers des arbres combinant des op´erations alg´ebriques. Il permet de
s’adapter `a diff´erents moteurs d’ex´ecution de requˆetes, comme par exemple un mo-
teur SQL.
– JORM [Team 1998] : ce canevas offre un moyen de projeter des objets vers diff´erentes
structures de stockage. Il permet notamment de supporter les r´ef´erences entre objets
et la navigation `a travers ces r´ef´erences pour ce qui concerne le d´eclenchement d’E/S.
Par ailleurs, l’architecture de Speedo et d’autres canevas de l’´ecosyst`eme technique
s’appuie sur Fractal [Team 2003] ce qui permet d’expliciter l’architecture logicielle de l’en-
semble. L’int´erˆet est qu’il est alors possible d’adapter l’environnement Speedo pour chan-
ger certains comportement, et notamment amener de nouvelles politiques de gestion de la
concurrence, de gestion de remplacement des objets dans le cache, etc.
F.1.2 Principales fonctions de Speedo
Au niveau des mod`eles programmatiques, Speedo a fait le choix d’implanter des stan-
dards car ils sont garants de p´erennit´e pour l’utilisateur et par l`a de stabilit´e pour les so-
lutions fournies. Outre le support des standard JDO2 et EJB3, Speedo offre des sp´ecifit´es

F.1. INTRODUCTION 3
Figure F.1 – D´ecomposition fonctionnelle de Speedo
qui ne mettent pas en cause la portabilit´e des applications et qui sont autant d’atouts
vis-`a-vis d’autres solutions ou produits de persistance ´equivalents.
Gestion des caches
Speedo propose deux niveaux de gestion de cache. Il g`ere dans un premier temps
l’ensemble des objets actifs dans le contexte d’ex´ecution d’une transaction. Lorsqu’un
nouvel objet doit ˆetre attach´e `a un tel contexte, on v´erifie qu’il n’y est pas d´ej`a. S’il n’y
est pas, un deuxi`eme niveau de cache est mis en œuvre. C’est un cache global qui contient
les objets Java persistants pr´esents en m´emoire. Le fait de recycler les objets d’un contexte
`a un autre permet d’all´eger la charge d’ex´ecution li´ee `a la cr´eation/destruction d’objets
(all´egement de la charge du ramasse-miettes).
Pour la gestion de l’encombrement m´emoire par le cache global, Speedo supporte
diff´erentes politiques de remplacement telles que LRU (Least Recently Used). Par ailleurs,
il est possible d’implanter de nouvelles politiques si n´ecessaire.
Gestion de la concurrence
Les solutioons de persistance actuelles d´el`eguent la gestion de la concurrence d’acc`es
au syst`eme de gestion de base de donn´ees sous-jacent. Cela a l’avantage de permettre `a
d’autres applications n’utilisant pas Speedo d’acc´eder `a la base de donn´ees en coh´erence
avec les applications Speedo.
Si cette contrainte est lev´ee, Speedo supporte la gestion de la concurrence directement
en m´emoire au niveau des objets Java, ce qui permet d’´eviter nombre d’acc`es inutiles `a
la base de donn´ees pour effectuer des prises de verrou. L`a aussi diff´erentes politiques sont
propos´ees comme des politiques pessimiste ou optimiste, avec gestion des situations de
dead locks.
Chargement d’objet anticip´e
Dans bien des cas, il peut ˆetre int´eressant de ramener les objets qui vont ˆetre instanci´es
en m´emoire, notamment lorsqu’il s’agit de collection d’objets. En, effet, traverser une
collection d’objets implique de ramener en m´emoire des objets r´epr´esentant une collection

4ANNEXE F. SPEEDO : UN SYST ` EME DE GESTION DE LA PERSISTANCE
(cas de relations multi-valu´ees), ou la collection r´esultant d’une requˆete ensembliste, puis
d’instancier chaque objet de cette collection. Cela n´ecessite n + 1 requˆetes vers la base.
Speedo permet de remonter les objets de la collection en mˆeme temps, ce qui ne n´ecessite
plus qu’une requˆete vers la base au lieu des n + 1. L’impact de cette approche sur les
performances est donc majeur.
F.1.3 Restrictions actuelles
F.1.4 Organisation du cours Speedo
Ce cours d´ecrit la mise en œuvre de Speedo `a travers sa personnalit´e JDO. Dans le
mˆeme temps, il couvre aussi une description du standard JDO lui-mˆeme.
F.2 Gestion d’objets persistants avec JDO : les principes
En 1999, un groupe d’experts travaillant sur la probl´ematique de persistance des ob-
jets Java a d´ecid´e d’apporter l’ensemble de ses travaux `a SUN, dans le cadre du JSR 12
([JSR-000012 2004]) : sp´ecifications dites Java Data Objects (JDO). Ambitieux, l’objectif
de cette sp´ecification est write once, persist anywhere (coder une fois, persister n’im-
porte o`u). Ce standard con¸cu `a l’origine par des ´editeurs de bases de donn´ees `a objets
se transforme en une solution de persistance universelle pour Java. En effet, n’importe
quel support de stockage, un SGBDR, un SGBDO, de simples fichiers, peut recevoir une
interface JDO. R´eciproquement, une application d´evelopp´ee dans un cadre JDO peut per-
sister sans aucune modification sur tout support de persistance dot´e d’une interface JDO.
Plusieurs solutions commerciales ou open source sont apparues tr`es rapidement. Face aux
retours des utilisateurs et aux ´evolutions de la sp´ecification EJB (2.x puis la prochaine
3.0), le mˆeme groupe d’experts, dans le cadre du JSR 243, a travaill´e sur l’´evolution de la
sp´ecification JDO. Cette nouvelle version 2.0 apporte son lot de nouvelles fonctions et de
standardisation, en particulier la projection objet/relationnel (O/R dans la suite).
Figure F.2 – Position de JDO dans l’architecture d’application
JDO est une sp´ecification qui d´efinit un mod`ele de programmation transparent pour la
persistance d’objets Java vers un syst`eme de stockage potentiellement transactionnel. Les
produits JDO sont donc des outils intergiciels de projection d’objets langage vers diverses
structures de stockage. Les avantages de JDO sont les suivants :

F.2. GESTION D’OBJETS PERSISTANTS AVEC JDO : LES PRINCIPES 5
– Mod´elisation objet sans contraintes : supporte de l’h´eritage, des collections, des
interfaces, etc.
– Persistance transparente : permet d’avoir des objets m´etiers compl`etement
ind´ependants de la structure de stockage (par exemple, pas de d´ependance vers
les APIs JDBC).
– R´eduction des temps de d´eveloppement : en effet tout le code d´edi´e `a la gestion de
la structure de stockage, qui repr´esente un effort non n´egligeable (´evalu´ee `a 40% de
l’effort de d´eveloppement par certaines ´etudes), est prise en charge par JDO.
– Persistance universelle : JDBC est limit´ee au SGBDR, JDO est capable, au
d´eploiement, d’assurer la persistance aussi bien dans un SGBDR que dans un
SGBDO, un syst`eme de type CICS, des fichiers plats ou au format XML.
– JDO est disponible sur toutes versions de Java : J2SE, J2ME et J2EE, en architecture
client/serveur ou multi ´etages.
Comme le montre la figure F.2, une solution JDO est un canevas logiciel qui prend en
charge la persistance des objets applicatifs n´ecessitant cette propri´et´e.
F.2.1 Classes et objets persistants
Les objets persistants sont des objets Java comme les autres. Simplement, le program-
meur doit indiquer les classes de son application qui peuvent produire des objets persis-
tants : nous les appelons classes persistantes. En effet, le principe de JDO est d’ajouter
le code n´ecessaire au support de la persistance dans la classe en question (cette phase
est aussi appel´ee phase d’enhancement en anglais). Pratiquement toutes les classes java
peuvent ˆetre trait´ees afin que leurs instances puissent persister.
L’unit´e de persistance est donc l’objet d’une classe persistante. N´eanmoins, la persis-
tance d’un tel objet n’est pas li´e `a sa classe. C’est le programmeur qui d´ecide du moment o`u
un objet devient persistant. Il le fait soit explicitement grˆace `a la fonction makePersistent
de l’API JDO, soit implicitement par rattachement `a un objet d´ej`a persistant.
Une instance persistante est toujours identifi´ee de mani`ere unique par un identifiant
permettant de d´esigner l’objet dans la structure de stockage. Cet identifiant permet donc
de faire le lien entre l’objet Java pr´esent en m´emoire sa projection dans la structure de
stockage sous-jacente. L’identifiant peut ˆetre bas´e sur des champs de la classe ou calcul´e
par ailleurs (par la solution JDO, par le support de stockage, etc).
Rendre un objet persistant signifie que l’ensemble des variables ou des champs d´esign´es
comme persistants, composant ainsi l’´etat de cet objet persistant, est enregistr´e sur le
support de stockage. D`es lors qu’une de ces variables est modifi´ee en m´emoire, cette mo-
dification est propag´ee vers le support de stockage. L’instant de synchronisation d´epend
du contexte d’ex´ecution : par exemple, les modifications effectu´ees dans un contexte tran-
sactionnel sont g´en´eralement propag´ees `a la validation de la transaction.
JDO d´efinit les types de champs qui peuvent ˆetre persistants. Nous pouvons les re-
grouper suivant diff´erentes cat´egories :
– Types primitifs : il s’agit de boolean,byte,char,short,int,long,float,double,byte[]
et char[].
– Types ”objet” simples : il s’agit des classes Java java.lang.Boolean,java.lang.Byte,
java.lang.Character,java.lang.Short,java.lang.Integer,java.lang.Long,java.lang.Float,
java.lang.Double,java.lang.String,java.lang.Number,java.math.BigDecimal,