1209_Inf7115_JDO.pps

JDO
Université du Québec à Montréal
INF7115: Bases de Données
Professeur:
Robert Godin
Étudiants:
Naby D. Soumah
Abdeltif Harrouchi
Ovidiu Nacu
Lundi 9 décembre 2002
PLAN
•Introduction
•Architecture
•Persistance des objets métiers
•Support de la modélisation par objet métier
•Interfaces primaires et classes
•Transactions
•JDOQL
•Cycle de vie des instances
Présentation (1)
 JDO (Java Data Object) – nouvelle technologie
de SUN, proposée en Juillet 2000
 JDO offre une approche orientée objet et
standardisée pour la persistance des objets Java
 Au contraire de JDBC, orienté base de données
relationnelle, JDO cache les difficultés liées aux
différences entre le monde objet et le monde
relationnel
Présentation (2)
 Le support des données peut être un SGBD
relationnel, objet ou XML, ou utiliser toute
autre forme d’enregistrement des données
 Objectif:
– offrir une API standard permettant d'utiliser un
gestionnaire de persistance d'objets métier
– offrir une unification des techniques d'accès aux
données, masquant les particularités des
gestionnaires de ressources derrière le paradigme
de persistance des objets métiers
Présentation (3)
 JDO repose sur deux grandes fonctionnalités:
– La persistance des objets :gère automatiquement la
synchronisation entre les données représentées par la
couche d'objets métier et les gestionnaires de
ressources sous-jacents.
– Le support des transactions : gère le graphe d'objet
de manière transactionnelle (commit et rollback sur
le graphe d'objet) tout en bénéficiant d'une gestion
automatique des transactions à effectuer sur les
gestionnaires de ressource.
Présentation (4)
 Les modifications à apporter au code sont
minimes pour rendre des objets persistants
 Les « classes du domaine » (celles qui
correspondent aux entités qui seront
persistantes) peuvent être écrites exactement
comme si elles n’étaient pas persistantes
 La persistance des applications est le plus
souvent transparente (aucune ligne de code ne
l’indique)
Architecture JDO (1)
Architecture JDO (2)
 Une « base de données » dans laquelle sont
enregistrés les objets persistants
 2 types d’objets :
– persistants (correspondent à des données de
la base)
– éphémères (transients), non persistants
 Un gestionnaire de persistance gère la
persistance des objets persistants
 Des méta-données, enregistrées dans un fichier
XML, décrivent les classes des objets
persistants
Persistance des objets métiers (1)
 Une application d’entreprise en Java requiert
souvent l’accès aux données persistantes, stockées
en base de données.
 Aujourd’hui, la méthode la plus répandue est
d’utiliser, à l’intérieur du code application, une
API JDBC qui envoie de requêtes SQL à une base
de données.
 Si les données se trouvent dans une base
hiérarchique, un mainframe ou encore un ERP, on
utilise en général une API spécifique au
gestionnaire de ressource en question.
Persistance des objets métiers (2)
 Les données sont remontées
vers l'application sous forme
de chaînes de caractères
et/ou de types simples (Date,
int, etc.) et traitées sous cette
forme (fig. 1)
Persistance des objets métiers (3)
 L'approche par objet métier -
définir une représentation objet
des données du système.
 En pratique, elle requiert la
programmation de classes Java
destinées à représenter les
diverses données se trouvant
dans les gestionnaires de
ressources, au niveau de
l'application. Lors de l'exécution
de l'application, les données
apparaissent en mémoire sous
forme d'objets Java complexes,
exposant des comportements de
haut niveau (fig. 2).
Persistance des objets métiers (4)
 La persistance des objets métiers permet de
profiter, au niveau de la modélisation des entités,
des divers apports de la technologie objet :
modularité, extensibilité, encapsulation, etc.
 Elle requiert la présence d'un gestionnaire de
persistance objet dont le rôle est d'établir une
correspondance entre les objets métiers en
mémoire et le moteur de persistance (le
gestionnaire de ressource).
Persistance des objets métiers (5)
 La présence du gestionnaire de persistance objet est
indispensable  une gestion manuelle de la persistance
de chaque objet est trop lourde à mettre en œuvre si on a
un système complexe.
 EXCEPTION : si le gestionnaire de ressource utilisé est
une base de données objet Java, on dispose alors
directement de la persistance objet, sans avoir besoin d'un
module additionnel.
 Pour une base de données relationnelle, le gestionnaire de
persistance objet sera un module dit de "mapping
objet/relationnel " (parmi les produits les plus connus
dans ce domaine, on pourra citer TopLink ou encore
CocoBase).
MODÈLE OBJET DE JDO
Enrichissement des classes
persistantes
 Les classes des objets persistants doivent
implémenter l’interface
javax.jdo.spi.PersistenceCapable
 Le code lié à cette interface est automatiquement
ajouté par l’outil JDO Enhancer (enrichissement
des classes persistantes)
 Selon la norme JDO, cet enrichissement peut être
effectué en modifiant le code source ou en
modifiant directement le bytecode (sans doute le
cas le plus fréquent)
CLASSES CAPABLES DE
PERSISTANCE
 Toutes les classes peuvent être capables de
persistance sous quelques conditions.
 Les classes systèmes ne sont pas capables
de persistance. Notamment les classes des
packages suivant:
– Java.lang
– Java.io
– Java.net
CLASSES CAPABLES DE
PERSISTANCE
 Une classe persistante peut avoir des
instances persistances et non persistantes.
 Toutes les instances d’une classe sont
initialement éphémères.
 Les instances deviennent persistantes par:
– Un appel explicite a l’interface
“makePersistent”
– Référence.
Instances de 1ère et de 2ème
classe (FCO et SCO)
 Le modèle objet des données manipulées
par JDO (les instances JDO) contient 2
types d’instances:
– FCO (First Class Object) : instance JDO qui ont
une identité JDO
– SCO (Second Class Object) : elle n’a pas
d’identité JDO par elle-même ; elle correspond
à des données qui sont enregistrées comme une
partie des données d’un FCO
Types des champs persistants
 Les champs persistants peuvent être
– de type primitif
– les classes enveloppantes des types primitifs
– java.util.Locale
– java.math.BigDecimal et BigInteger
– java.util.Date
– java.util.HashSet (optionnellement les
autres classes collections)
– d’une classe « capable de persistance »
Héritage et classes persistantes
 Si on a une hiérarchie d’héritage, une classe
peut être persistante ou non,
indépendamment des autres classes de
l’arborescence (classes dérivées ou
ancêtres)
 Tous les champs persistants le restent dans
les classes dérivées persistantes
Classes et interfaces
de l’API JDO
Paquetages de JDO
 L’API est composée de 2 paquetages :
– javax.jdo : les classes et interfaces
utilisées par les développeurs
– javax.jdo.spi : les classes et
interfaces utilisées par JDO pour son
fonctionnement interne
Classes et interfaces principales
 PersistentManager : interlocuteur principal
du développeur pour gérer la persistance des
instances
 Transaction : permet de démarrer, valider et
invalider des transactions
 Query : pour récupérer des données dans la base
 PersistentManagerFactory : permet de
récupérer un PersistentManager
 JDOHelper : classe utilitaire pour, par exemple,
récupérer une PersistentManagerFactory
Environnement géré vs non géré
• Environnement non géré
Client/serveur, 2-tier
Gestion des connections et des transactions
explicite
• Environnement géré
Serveur d’application, n-tier
Gestion des connections et des transactions
implicite
Interfaces utilisées
• PersistenceManagerFactory
• PersistenceManager
• Transaction
• Query
Objectifs des Transactions
• Transactions distribuées et locales
• ACID
• Stratégies optimiste (optionnel), accès concurrent
pessimiste
• Scalabilité
Objectifs de JDOQL
• Langage d’interrogation neutre
• architecture multi-tier
• Jeu de résultats vaste
• Possibilité de compiler
JDOQL
• PersistenceManager est l’usine à requêtes
• Les requêtes interrogent des collections et
retournent des collections
• Élements requis dans une requête:
• Une collection d’instances candidates
• Ça peut être un extent
• Ça peut être une Collection dans JVM
• Filtre (expression booléenne Java)
Exemple JDOQL
class Livre {
String
isbn;
String
titre;
Integer
anneParution;
String
nomEditeur;
}
Filtre de requête
Class classeLivre=Livre.class;
Extent extLivre=pm.getExtent(classeLivre, false);
String filtre=“isbn==\”0-201-12227-8\””;
Query q=pm.newQuery(classeLivre, extLivre, filter);
q.setOrdering(”anneeParution descending”);
Collection c=(Collection) q.execute();
JDOQL: paramètres
Class classeLivre=Livre.class;
Extent extLivre=pm.getExtent(classeLivre, true);
String filtre = “isbn==isbnRecherche”;
Query q=pm.newQuery(classeLivre, extLivre, filter);
q.declareParameters(“String isbnRecherche”);
Collection c=(Collection) q.execute(”0-201-12227-8”);
État des instances
• Interaction entre l’état d’une instance et son
comportement
• États: éphémére, persistante et nouvelle,
persistante et sale, creuse, persistante et propre…
• Classe JDOHelper: isPersistent(), isDeleted(),
isDirty(), isTransactional(), isNew()
Cycle de vie: persistante et nouvelle
makeTransient
makePersistent
Persistante et
Nouvelle
Éphémére
rollback
commit
Creuse
Cycle de vie: rétroaction aux changements d’état
 Interface InstanceCallback
jdoPostLoad()
jdoPreClear()
jdoPreDelete()
jdoPreStore()
Conclusion
Avantages
 support des relations complexes entre objets
(association, héritage)
 support des objets a granularité fine
 mécanismes de persistance uniformes
Inconvénients
 JDO ne spécifie pas la manière dont la
configuration du mapping s'effectue. Elle
pourra donc différer entre les diverses
implémentations
 Implémentations JDO pas encore généralisées