JDO Université du Québec à Montréal INF7115: Bases de Données Professeur: Robert Godin Étudiants: Naby D. Soumah Abdeltif Harrouchi Ovidiu Nacu Lundi.

Présentation au sujet: "JDO Université du Québec à Montréal INF7115: Bases de Données Professeur: Robert Godin Étudiants: Naby D. Soumah Abdeltif Harrouchi Ovidiu Nacu Lundi."— Transcription de la présentation:

1

2 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

3 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 PLAN

4 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

5 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

6 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.

7 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)

8 Architecture JDO (1)

9 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

10 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.

11 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)

12 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).

13 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).

14 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).

15 MODÈLE OBJET DE JDO

16 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)

17 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

18 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.

19 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

20 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 »

21 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

22 Classes et interfaces de l’API JDO

23 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

24 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

25 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

26 Interfaces utilisées PersistenceManagerFactory PersistenceManager Transaction Query

27 Objectifs des Transactions Transactions distribuées et locales ACID Stratégies optimiste (optionnel), accès concurrent pessimiste Scalabilité

28 Objectifs de JDOQL Langage d’interrogation neutre architecture multi-tier Jeu de résultats vaste Possibilité de compiler

29 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)

30 Exemple JDOQL class Livre { Stringisbn; Stringtitre; IntegeranneParution; StringnomEditeur; }

31 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();

32 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”);

33 É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()

34 Cycle de vie: persistante et nouvelle makePersistent rollback Éphémére Persistante et Nouvelle Creuse commit makeTransient

35 Cycle de vie: rétroaction aux changements d’état  Interface InstanceCallback jdoPostLoad() jdoPreClear() jdoPreDelete() jdoPreStore()

36 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