Javabasierte Webtechnologien

1. Javabasierte Webtechnologien Objektrelationales Mapper und JDO

2. Überblick • Motivation • Objektrelationale Mapper - Überblick - Beispiel Hibernate - Performance - Fazit • Java Data Objekt - Überblick - JDO API - Vom normalem Objekt zu einem JDO - Fazit Lars Kägebein

3. Motivation • Lösen des Impendance Mismatch Problems - Objektorientierte Lösungen in komplexen Anwendungen - Zur Speicherung meistens Relationale Datenbanken - unterschiedliche Paradigmen - ziel : Vorteil von beiden vereinen • Probleme - Objektidentität vs Primärschlüssel - Kompositionsmodell vs Fremdschlüssel - Vererbungsmodel vs ? - Verschiedene Datentypen Lars Kägebein

4. Überblick O/R Mapper • Kleiner Projekte eventuell selbst lösen - Sql statments über jdbc / resultSet umwandeln in Datenobjekte • Bei komplexen Anwendungen mapper nutzen - Automatische Generierung von Datenklassen - Performanceoptimierung möglich die den Overhead durch das Mapping ausgleicht - Unabhänigkeit von verschiedenen Datenbank Herstellern - Cayenne , Jakarta OJB , TopLink , Hibernate Lars Kägebein

5. O/R Mapper Hibernate • Warum Hibernate - Open Source (LGPL) - Populär (circa 16.000 downloads / Monat) - Unterstützung aller großen Datenbanken z.b. mySql , PostgreSql, Oracle , DB2 … - Besitzt Optimierungmöglichkeiten wie Caching, Connection-pooling - Möglichkeit zur Nutzung unterschiedlicher Entwicklungsszenarien - Generierung von java klassen wenn DB Schemata vorhanden und umgekehrt - verschiedene Anfragesprachen (hql, sql, criteria Queries) - Ausführliches logging durch log4j Lars Kägebein

6. Funktionsweise von Hibernate • Genereller Aufbau • Hibernate.properties für Datenbank und Optimierungsparameter • Für jede Tabelle in der DB eine .java und eine .hbm.xml • .java beschreibt die Tabelle selber als Objekt • .hbm.xml enthält Datentypen mapping und zusätzliche Parameter Lars Kägebein

7. Arbeiten mit Hibernate • Java Datei • hbm.xml Datei Lars Kägebein

8. Zusammenspiel zwischen der Datenbank und Hibernate • Ablauf im Detail • Zugriff nur über die Datenobjekte die aus der Session kommen (selection) oder in die Session gehen (insert) • Session von SessionFactory generiert , dort auch Optimierungen umgesetzt • Zugriff auf Datenbank erfolgt intern durch JDBC oder ähnliches Lars Kägebein

9. Anfragen am Beispiel • Erstellen und beenden einer Session • Eintrag in die Datenbank • keinerlei Sql ! • nur setter Methoden oder • mit Konstruktoren arbeiten für inserts! Lars Kägebein

10. Anfragen am Beispiel • Verschiedene Abfragen • HQL als Objektorientierte Erweiterung von SQL • - versteht Vererbung, Polymorphie und Assoziationen -Direkte Abfrage über Criteria - kein sql notwendig Lars Kägebein

11. Tools und Performance • Performance • Sehr abhängig von den Einstellungen und der Anwendung (Cache Zuweisungen für Querys) • Schlechte Erfahrungen im Zusammenspiel mit Tomcat • Tools • Kein erstellen der java bzw. xml Dateien notwendig wenn db-schemata schon vorhanden • Hibernate-extensions beinhaltet folgende Tools : - class2hbm, ddl2hbm, hbm2java - dadurch alle Szenarien abgedeckt Lars Kägebein

12. Fazit • Zwar gewisser Aufwand nötig zur Einarbeitung jedoch danach sehr unabhängig von der Datenbank • Entwickler muss nicht wissen wie DB Schemata aufgebaut , sämtliche Möglichkeiten ergeben sich durch die Get und Set Methoden • Durch Criteria keine Kenntnisse von Sql nötig • Nachteil jedoch eventuell Langsamer • wenn DB Schema sich ändert muss alles geändert werden • Kein genereller Standard , unterstützt „nur“ Datenbanken (keine anderen Formate) Lars Kägebein

13. JDO Einführung • JDO = Java Data Objects • Standard (API) zur persistenten Speicherung von Java Objekten • Stellt Interfaces zur Verfügung welche dann von der jeweiligen Implementierung auf den Datenspeicher zugeschnitten sind • Dadurch Anwendung unabhängig vom Speicherort seiner Objekte / Daten, xml-files genauso möglich wie verschiedenste Datenbanken • Soll Objektorientierte Sichtweise auf Daten ermöglichen und Anwendung vom Prozess der Persistierung komplett befreien Lars Kägebein

14. JDO API Bestandteile (1) • JDOHelper für statische Hilfsmethoden und zur Erzeugung • der PMF , zusätzlich noch Methoden zum ermitteln des • Zustandes bestimmter JDO Objekte Lars Kägebein

15. JDO API Bestandteile (2) • PMF fordert einzelne Instanzen des PM an die darüber konfiguriert werden können • Parameter zur Optimierung möglich wie Transaktionstrategie und Cachesematik einstellungen • Angabe der Datasource • PM verwaltet JDO-Objekte die dort angelegt,gesucht und gelöscht werden können • Jeder PM hat exklusiven Objektcache und genau einen Transaktionskontex zwecks transaktionaler Absicherung • Query-Interface dient zur Absetzung von Suchanfragen • sind in JDO-Query Language formuliert Lars Kägebein

16. Vom Objekt zu JDO Objekt (1) • Leicht zu Erreichen und Stärke von JDO • Angabe von den persistenten Eigenschaften von allen Klassen im Package der Anwendung in XML Metadatei • Mögliche persistence-modifier hierbei : - none , transactional, persistent • Persitente Attribute : erfordern Speichermediumabgleich ,unterliegen Transaktionsgrenzen • Transactionale Attribute : unterliegen Transaktionsgrenzen • None : sonstige • Persistent und Transactional müßen von JDO Implemtierung beachtet werden Lars Kägebein

17. Vom Objekt zu JDO Objekt (2) • Code Enhancer erweitert automatisch den .class Bytecode der Normalen Klasse um JDO Erweiterung • Je nach Definition in der Meta Datei klasse nun : • Persistent Capable , muss auf jeden Fall erweitert werden • Persistent Aware , klasse selber hat keine persistenten Attribute greift aber auf welche zu (Vererbung etc) • Sonstiges muss nicht vom Enhancer betrachtet werden • Vorteil : sehr schnelle Erweiterung vorhandener Objekte • Nachteil : inwiefern widersprechen Veränderungen im ByteCode der Java Grundidee der Unabhängigkeit ? Lars Kägebein

18. Identität von JDO Objekten • In Java Anwendungen von == bestimmt (gleicher Speicherbereich innerhalb der JVM) • Bei JDO nicht sicher da Objekt von Anwendung oder Speichermedium kommen kann ! • Je nach Design der Anwendung : • Application Identity , dabei Verwaltet die Anwendung die Datenobjekte durch hinzufügen von Objekt-Id klasse zur eigentlichen klasse • Sinnvoll für hoch portable Klassen für verschiedene Anwendungen , nutzbar über verschiedene JDO Implementationen hinweg • Datastore Identity , hier verwaltet eine Objekt id Klasse alle Objekte die aus der Speicherquelle kommen und garantiert dadurch Identität (nicht sichtbar) Lars Kägebein

19. JDO Objektzustände • Können über JDOHelper abgefragt werden • Mögliche zustände hierbei : • Persistent (im Speichermedium) • transactional (mit Transaktion verbunden) • dirty (geändert in der Transaktion) • new (während der Transaktion persitent geworden) • deleted (innerhalb der Transaktion gelöscht) • Stellt im Prinzip die Eigenschaften dar die in der Meta Datei festgelegt wurden • Dient zur internen Verwaltung der Transaktionen in JDO Lars Kägebein

20. Anfragesprache JDO-QL • Ziel ist es ein Objekt zurückzuliefern oder eine Collection über die dann per Get Methoden die Werte ausgelesen werden können • WHERE deklaration durch Filter abgebildet • Keine Like Operatoren sondern startWith() und endsWith() Anwendung auf das Ergebnis Objekt Lars Kägebein

21. Fazit • Vorteile • Performanceeinschätzungen schlecht möglich da sehr stark abhängig von JDO Implementierung • Dadurch das als Standart definiert verschiedenste Implementierungen denkbar • Sehr schnelle Erreichbarkeit von Objektpersistenz • Anwendungen können ihr Speichermedium schnell ändern ,doppelte Verwendung von JDO Objekten denkbar z.b. online / offline Umgebungen • Nachteile • Inwiefern widersprechen Veränderungen im ByteCode der Java Grundidee der Unabhängigkeit ? • Anfragesprache (noch) nicht sehr mächtig , soll aber in der Zukunft erweitert werden Lars Kägebein

22. Quellen • www.hibernate.org • www.jdocentral.com • Studienarbeit Tobias Vogel • Artikel : Freie Sicht auf Daten (Javamagazin 06/04) Lars Kägebein

23. Fragen ? Vielen Dank für Ihre Aufmerksamkeit Lars Kägebein