Introduction Architecture Persistance des objets métiers

1. JDOUniversité du Québec à MontréalINF7115: Bases de DonnéesProfesseur: Robert GodinÉtudiants: Naby D. Soumah Abdeltif Harrouchi Ovidiu NacuLundi 9 décembre 2002

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

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

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

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

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

7. Architecture JDO (1)

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

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

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

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

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

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

14. MODÈLE OBJET DE JDO

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

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

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

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

19. 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 »

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

21. Classes et interfaces de l’API JDO

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

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

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

25. Interfaces utilisées • PersistenceManagerFactory • PersistenceManager • Transaction • Query

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

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

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

29. Exemple JDOQL class Livre { String isbn; String titre; Integer anneParution; String nomEditeur; }

30. 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();

31. 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”);

32. É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()

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

34. Cycle de vie: rétroaction aux changements d’état • Interface InstanceCallbackjdoPostLoad()jdoPreClear()jdoPreDelete()jdoPreStore()

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