Fachhochschule Osnabrück. University of Applied Sciences

Transkript

1 Fachhochschule Osnabrück University of Applied Sciences Thema: OR-Mapping Datum: Student: Martin Landwehr (161046) Seite 1 von 21

2 Inhaltsverzeichnis Einleitung... 3 Motivation...3 Grundlagen...3 Objekt-relationaler Bruch...5 Die semantische Lücke... 5 Lösungsansätze... 6 ORM mit Java... 7 Serialisierung...7 Java Database Connectivity... 7 Enterprise Java Beans Bean-Managed Persistence... 8 Container-Managed Persistence...8 Persistence-Frameworks... 8 Java Data Objects...9 Hibernate...9 Enterprise Java Beans Beispiel mit Enterprise Java Beans Beispielanwendung Einfache Persistenz Relationen Vererbung...13 Fassade Query API Persistence Deskriptor...17 Testen der Beispielanwendung B.1 Spezifikationen...20 B.2 Systeme, Bibliotheken, Anwendungen...20 B.3 Artikel und Tutorials Literaturverzeichnis...21 Seite 2 von 21

3 Einleitung Motivation Versicherungen, Banken, Automobilhersteller, Chemiekonzerne und Softwarehäuser sind typische Anwender der Informatik. In diesen Unternehmen werden alle Abläufe durch betriebliche Informationssysteme unterstützt. Die Informationssysteme unterstützen und steuern Abläufe in allen Bereichen eines Unternehmens: im Marketing und Vertrieb, in der Produktion, in der Logistik und auch im Rechnungswesen. Ein Merkmal dieser Systeme ist, dass ihre Anwender auf eine gemeinsame, große und komplexe Datenbank zugreifen. Heutzutage werden in der Regel objektorientierte Programmiersprachen und zur Speicherung von Daten hingegen relationale Datenbanksysteme eingesetzt. Diese beiden Paradigmen unterscheiden sich in ihren Konzepten, was ihre gemeinsame Verwendung insbesondere in großen und komplexen Projekten erschwert. Diese Ausarbeitung beschäftigt sich mit objektorientierten Zugriffsschichten auf relationale Datenbanken und stellt anhand eines praktischen Beispiels die neue Java Persistence API EJB3.0 vor. Grundlagen Die objektorientierte Entwicklung ist eine moderne Methode zur Implementierung von betrieblichen Informationssystemen. Dabei bieten Objekte durch Abstraktion eine Möglichkeit die Systeme zu strukturieren und dadurch die immer weiter steigende Komplexität zu beherrschen. In Unternehmensanwendungen kann auf eine persistente Datenhaltung nicht mehr verzichtet werden, da die gesammelten Daten über einen längeren Zeitraum benötigt werden. Beispiele für diese Applikationen kommen aus dem Bereich der Verwaltung von Personal und Finanzen, aber auch aus dem Bereich der Internetapplikationen. Seite 3 von 21

4 Die Informationen, welche in den Objekten gespeichert sind, müssen auf einen Sekundärspeicher ausgelagert werden, da die Haltung dieser Daten im Arbeitsspeicher schon aufgrund der dauerhaft steigenden Datenmenge nicht möglich wäre. Auch muss nach der Beendigung der Anwendung noch ein Zugriff auf die Daten möglich sein. Um diesen Anforderungen gerecht zu werden kommen Datenbankverwaltungssyteme (engl. Database management systems, DBMS) zum Einsatz. Diese Systeme bieten mehr als nur die reine Datenhaltung, sondern unterstützen Mehrbenutzerbetrieb durch Transaktionen, Hilfe bei der Zugriffskontrolle und bieten Schutz vor Datenverlust. Bei DBMS unterscheidet man drei verschiedene Arten von Systemen: relationale, objekt-relationale und objektorientierte Datenbanksysteme. Bei relationalen DBMS werden die Daten in einer Tabellenstruktur dargestellt. Als Abfragesprache dient SQL. Objektrelationale Datenbanksysteme bauen auf relationalen DBMS auf und erweitern diese. Die Funktionalität wird im Wesentlichen durch den SQL:1999 Standard definiert und umfasst beispielsweise benutzerdefinierte Datentypen und Funktionen, Typ- und Tabellenhierachien. Objektorientierte DBMS bauen hingegen nicht auf Tabellen auf, sondern nehmen Objekte entgegen, welche persistiert werden. Seite 4 von 21

5 Objekt-relationaler Bruch Bei der Verwendung von objektorientierten Programmiersprachen und relationalen Datenbanken steht man dem Problem des objekt-relationalen Bruchs gegenüber. Im Folgenden wird der Begriff semantische Lücke und danach Lösungsmöglichkeiten erläutert. Die semantische Lücke Bei der Implementierung einer Anwendung in einer objektorientierten Programmiersprache, zum Beispiel Java, und der Verwendung einer relationalen Datenbank als Persistenzmedium steht man einigen Problemen gegenüber. Dies liegt an den unterschiedlichen Paradigmen der beiden Konzepte. Der objektorientierte Ansatz befasst sich mit der Frage, wie Daten und Verhalten von Objekten der realen Welt in selbstständige, kleine Dateneinheiten gekapselt werden können. Dem Gegenüber steht der relationale Ansatz, welcher den Fokus auf die vollständige und redundanzfreie Speicherung von Daten legt. In der objektorientierten Programmiersprache kann man objektorientierte Konzepte, wie mehrwertige oder benutzerdefinierte Typen, Vererbung oder auch Beziehungen zwischen Objekten nutzen. Abbildung 1: objektorientierte Sicht In der relationalen Welt gibt es diese Konzepte nicht. Man muss dies mit Hilfe der dort zur Verfügung stehenden Mittel wie zum Beispiel Fremdschlüsselbeziehungen lösen. Im Folgenden werden die verschiedenen Seite 5 von 21

6 bestehenden Ansätze zur Überwindung des objekt-relationalen Bruchs beschrieben. Abbildung 2: Datenbanksicht Lösungsansätze Als erste Möglichkeit gibt es Sprachen der vierten Generation (z.b. SQL), welche stark von der Hardware und dem Betriebssystem abstrahieren und für die Anbindung von Datenbanksystemen entwickelt wurden. Nachteil dieser Sprachen ist, dass sie sehr unterschiedliche Nutzbarkeiten haben. Viele dieser Sprachen sind nur für einen kleinen Anwendungsbereich nutzbar. Ein weiterer Nachteil ist, dass es nur schwer möglich ist eine Schichtenarchitektur einzuhalten. Ein weiterer Ansatz ist der Einsatz von Objektorientierten Datenbanksystemen. Diese bieten die Möglichkeit, Objekte direkt an das Datenbanksystem zu übergeben welches die Daten transparent persistiert. Die Performanz dieser Systeme ist allerdings bei anfrageintensiven Anwendungen deutlich schlechter als die Performanz relationaler Datenbanksysteme. Eine weitere Möglichkeit bietet der Einsatz von objekt-relationalen Mapping oder unterstützender Frameworks. Hier werden die Objekte entweder manuell oder mit Hilfe von Tools auf die einzelnen Relationen abgebildet. Seite 6 von 21

7 ORM mit Java In der Programmiersprache Java stehen unterschiedliche, einfache Mechanismen wie Serialisierung und JDBC zu Verfügung, mit deren Hilfe sich Objekte persistieren lassen. Darüber hinaus haben sich in den letzten Jahren neben einer Vielzahl von Frameworks auch zwei Standards - Enterprise Java Beans Container-Managed Persistence und Java Data Objects entwickelt. Serialisierung Diese Art der Persistierung ist eine Standardkomponente einer jeden Java Virtual Machine. Dabei wird ein Objekt in einen ByteStream abgelegt und so in Form eines Files im Dateisystem gespeichert. Serialisierung kann schnell angewandt werden, das Objekt muss nur die Schnittstelle Serializable implementieren. Dadurch kann die Laufzeitumgebung eine Standard Serialisierung vornehmen. Reicht diese nicht aus, kann die Serialisierung auch händisch bewerkstelligt werden. Anforderungen einer robusten Persistenzschicht, wie z.b. die Unterstützung von Transaktionen, Skalierbarkeit oder Anfragen werden allerdings nicht erfüllt so dass sich Serialisierung nicht als ein Verfahren für Massendatenhaltung eignet. Java Database Connectivity Java Database Connectivity (JDBC) ist eine Standard Schnittstelle in Java, um mit RDBS zu interagieren. Sie ermöglicht es, SQL konforme Befehle an die Datenbank weiterzuleiten. Jeder Hersteller von RDBS bietet in der Regel Treiber an, welche SQL Befehle auf die Implementierung der eigenen Datenbank bestmöglich umsetzen. Durch Verwendung des SQL-Standards werden Anfragen und Transaktionen direkt unterstützt. Das Ergebnis einer Anfrage ist immer eine Menge von Attributen, die Transformation vom relationalen auf das objektorientierte Modell muss also händisch vorgenommen werden. JDBC wird meist für handgemachte ORM Lösungen verwendet. Auch hier muss auf die Problematik der Objektidentität Rücksicht genommen werden. Features wie Caching oder Lazy Loading müssen zusätzlich programmiert werden, da JDBC sie nicht von Haus aus unterstützt. Seite 7 von 21

8 Enterprise Java Beans 2.1 Die Enterprise Java Beans (EJB2.1) Spezifikation definiert das serverseitige Komponentenmodell, mit dem es möglich ist, verteilte Anwendungen zu entwickeln. Neben vielen unterschiedlichen Diensten werden auch zwei unterschiedliche Möglichkeiten unterstützt, um die Geschäftsobjekte zu persistieren. Die Geschäftsobjekte werden in diesem Zusammenhang auch als Entity-Beans bezeichnet. Bean-Managed Persistence Bei Bean-Managed Persistence (BMP) muss eigener Programmcode geschrieben werden, um den Zustand des Objektes in die Datenbank zu übertragen. In diesem Szenario kommt meist wieder JDBC zum Einsatz, es kann aber auch ein Persistence-Framework verwendet werden. Container-Managed Persistence Wird Container-Managed Persistence (CMP) verwendet, so muss kein eigener Datenbankzugriffscode geschrieben werden. Dies wird dem Container überlassen. Jedoch ist es nötig, Metadaten in Form von Deskriptoren bereitzustellen, aus welchen der Container die entsprechenden Informationen für die Persistierung ableiten und somit die SQL-Zugriffe generieren kann. Obwohl es bei CMP so aussieht, als ob sich die Persistierung äußerst komfortabel bewerkstelligen ließe, hat die Vergangenheit jedoch gezeigt dass sich um ein sehr zeit- und fehleranfälliges Verfahren handelt. Persistence-Frameworks Im Laufe der Zeit wurden sowohl kommerzielle, als auch Open-Source Lösungen entwickelt, welche die Persistierung von Objekten automatisieren und dadurch erleichtern. Hier müssen zusätzliche Metainformationen bereitgestellt werden, aus welchen zur Laufzeit Code für den Datenzugriff generiert wird. Der Einsatz eines Persistence-Frameworks erlaubt es zum einen, die Persistierung mit deutlich weniger anwendungsspezifischem Code vornehmen zu können. Zum anderen bieten die meisten Lösungen eine umfangreiche Werkzeugunterstützung an, was die Entwicklung zusätzlich beschleunigt. Im Folgenden werden zwei bekannte Vertreter dieser Kategorie vorgestellt: Seite 8 von 21

9 Java Data Objects JDO ermöglicht die Persistierung von Objekten. Sie bietet eine Reihe von Schnittstellen, welche von unterschiedlichen Anbietern implementiert werden können. Man ist somit komplett unabhängig von einem speziellen Anbieter, als auch von der darunter liegenden Datenbank, egal ob RDMS oder ODBS. JDO lässt sich in unterschiedlichen Szenarien einsetzten und ist damit sowohl für Einzelanwendungen, als auch für verteilte Systeme verwendbar. Gerade bei Applikationsservern findet JDO großen Anklang da eine brauchbare Alternative zu EJB CMP geschaffen wurde. Hibernate Neben einer Vielzahl von Open-Source OR-Mappern ist Hibernate wohl eines der am weitesten entwickelten Persistence-Frameworks. Es zeichnet sich sowohl durch die hohe Performance, als auch durch die umfangreiche Werkzeugunterstützung bei der Entwicklung aus. Mit Hibernate können die meisten verfügbaren relationalen Datenbanksysteme verwendet werden. Der Zugriff ist dabei auf die Datenbank optimiert, da sich Hibernate mit unterschiedlichen Datenbankdialekten verwenden lässt. Die benötigten Metainformationen für den Zugriff auf die jeweilige Datenbank werden in einer Konfigurationsdatei angegeben, welche bei der Instanzierung der SessionFactory geladen wird. Diese Konfigurationsdatei beinhaltet auch die Namen der Klassen, für deren Instanzen eine Persistierung möglich sein soll. Wie auch bei JDO ist es hier nötig, XML-Dateien mit Metainformationen für die persistenten Klassen bereitzustellen. Hier werden, ähnlich wie bei JDO, Beziehungen, die Vererbungshierarchie oder die Art der ID-Generierung für die Objektidentifikation festgelegt. In Bereichen wie Caching oder Transaktionsmanagement bietet Hibernate ähnlichen Funktionsumfang wie JDO. Für Anfragen wird ebenfalls eine eigene Sprache zur Verfügung gestellt, die Hibernate Query Language (HQL). Sie ist wiederum stark an die JDOQL angelehnt. Hibernate zeichnet sich gegenüber vergleichbaren Persistence-Frameworks durch den fortgeschrittenen Entwicklungsgrad, als auch durch umfassende Dokumentation und Werkzeugunterstützung aus, wodurch die Implementierung erheblich erleichtert wird. Seite 9 von 21

10 Enterprise Java Beans 3.0 Bereits kurz nach der Einführung der Enterprise Java Beans 2.1 wurde von vielen Entwicklern erkannt, dass die Spezifikation viel zu kompliziert ist. So ist bereits im Jahre 2004 der Java Specification Request 220 entstanden, der zu einer neuen Version der Enterprise Java Beans führen sollte. Seit Mitte 2006 liegt diese finale Spezifikation vor und erstaunlicherweise konnten einige Anwendungsserver kurze Zeit später mit einer vorläufigen Version von EJB3.0 ausgestattet werden, so dass die Entwickler das bisher Spezifizierte auch testen konnten. Die erste Implementierung eines EJB3.0-fähigen Anwendungsservers wurde von der JBoss-Group bereitgestellt, die auch selbst aktive Mitglieder der JSR220-Expertengruppe war. Mit EJB3.0 wurden die alten Persiszenztechniken CMP und BMP abgeschafft ; anstelle dieser wurde das Beste aus den beiden Welten Hibernate und JDO übernommen und eine erheblich einfacher und gleichzeitig mächtigere Persistenz-API zur Verfügung gestellt. Zum jetzigen Zeitpunkt befinden sich die unterschiedlichen EJB3.0-Implemtierungen noch im Entwicklungszustand. Es ist aber zu erwarten, dass sich EJB3.0 langfristig als die dominierende Persistenztechnik in Java-Umfeld durchsetzen wird. Im folgenden Kapitel wird der Einsatz der neuen Java Persistence API demonstriert. Seite 10 von 21

11 Beispiel mit Enterprise Java Beans 3.0 Beispielanwendung Das folgende Beispiel soll der Prototyp einer Adressverwaltung darstellen; es besteht aus: vier Entity-Beans OrganizationalUnit Phone Kreditor Debitor wobei Kreditor und Debitor Geschäftsobjekte repräsentieren, die Eigenschaften der Klasse OrganizationalUnit erben. Zusätzlich zeigt das Beispiel eine 1-zu-N-Beziehung zwischen OrganizationalUnit und Phone. Einen zustandslosen Session Bean EntityUnit mit dem zugehörigen Interface UnitManager. Dieses Session-Bean ist das einzige Bean, das dem entfernten Client zugänglich ist. Zu den allgemein anerkannten Entwurfsmustern gehört, dass Entity-Beans dem entfernten Client nicht direkt zugänglich gemacht werden, sondern ein Session Bean als Mittler (facade) dazwischengesetzt wird. Einfache Persistenz Das neue Persiszenzframework basiert ausschließlich auf POJOs und sollte daher den meisten Java-Programmierern natürlich vorkommen. Über die werden die POJOs als Entity-Beans bezeichnet. Optional kann die angegeben werden, mit der die Datenbanktabelle bezeichnet wird. Entity-Beans müssen das Interface Serializable implementieren. Auf die wird später eingegangen. Seite 11 von 21

12 Auszug OrganizationalUnit.java: Jedes EntityBean muss einen eindeutigen Identifikator besitzen der in der entsprechenden Tabelle als Primärschlüssel dienen kann. Die entsprechende Variable wird mit versehen. Normale zu persistierende Variablen werden mit gekennzeichnet. Über entsprechende Annotiationen ist es auch möglich die zu generierenden Datenbankfelder feiner zu granulieren (nullable = true/false, Länge von Zeichenketten in VarChar-Feldern etc.). Auszug OrganizationalUnit.java: Seite 12 von 21

13 Relationen Zwischen OrganizationalUnit und Phone besteht eine bidirektionale 1-zu-N- Beziehung. Bidirektionale Beziehungen besitzen sowohl ein besitzendes Ende als auch eine inverses Ende. Das besitzende Ende bestimmt, wann Updates in der Datenbank vorgenommen werden. Dabei gelten folgende Regeln: das inverse Ende der Beziehung muss das besitzende Ende referenzieren und zwar mittels des mappedby-member oder Das N-Ende einer 1-zu-N-Beziehung muss besitzendes Ende sein. Darum kann das mappedby-member nicht in vorkommen. Auszug OrganizationalUnit.java: Auszug Phone.java: Vererbung Mit der neuen Persistenz-API lassen sicher Vererbungen erstaunlich einfach abbilden. Wie in der normalen Objektorientierten Programmierung wird sie mit dem Schlüsselwort extends realisiert. Über die kann zwischen unterschiedlichen Strategien der Datenbanklayouterzeugung unterschieden werden. So kann beispielweise gewählt werden ob jede vererbte Klasse in einer separaten Datenbanktabelle oder alle Klassen in nur einer Datenbanktabelle abgelegt werden. Des Weiteren ist es auch möglich einzelne vererbte Klassen mit oder ohne den Variablen der Basisklasse anzulegen. Seite 13 von 21

14 Auszug OrganizationalUnit.java: Auszug Debitor.java: Auszug Kreditor.java: Fassade Über das Interface UnitManager kann ein entfernter Client auf die Entity-Beans zugreifen. Auszug UnitManager.java: Seite 14 von 21

15 Die Beanklasse EntityUnit implementiert das Interface UnitManager. In dieser Klasse werden über den EntityManager - der in EJB3.0 eine zentrale Rolle spielt die eigentlichen Datenbankoperationen durchgeführt. Auszug EntityUnit.java Es folgen Beispiele für Datenbankstandartoperationen: Auszug EntityUnit.java Seite 15 von 21

16 Query API Das vorherige Beispiel hat sich mit Basisoperationen persistenter Objekte beschäftigt. Über die leistungsfähige Query API können aber auch komplexe Anfragen formuliert werden. Die verwendete Query Language orientiert sich dabei stark an SQL und ist um objektorientierte Eigenschaften wie die Navigation über JavaBean-Eigenschaften ergänzt worden. Auszug EntityUnit.java Seite 16 von 21

17 Persistence Deskriptor Ein großer Teil der Konfiguration des Persistenzkontextes wird vom EJB- Container (dem ApplicationServer) übernommen. Daher reduziert sich der Persistence Deskriptor unter EJB3.0 auf ein Minimum. Es müssen lediglich symbolische Namen für die Persistence-Unit und die zu verwendende JTA- Datenquelle angegeben werden: Im folgenden Beispiel wird auf eine Postgres-Datenbank zugegriffen, die innerhalb des JBoss unter dem Namen Address_Simple2 erreichbar ist. Des Weiteren wird der ApplicationServer angewiesen, die erforderlichen Tabellen selbst zu erstellen und vor einem ReDeploy der Anwendung diese wieder zu löschen. persistence.xml Seite 17 von 21

18 Testen der Beispielanwendung Für den Test der Beispielanwendung empfiehlt es sich die unter Anhang A aufgelistete Software zu installieren. Vor dem Start der Anwendung muss ein JBoss Applicaton-Server so konfiguriert werden, dass er PostgreSQL als Datenquelle einsetzen kann: Hierzu ist es ausreichend die Datei JBOSS_HOME/server/default/deploy/postgres-ds.xml mit der im Quelltext ausgelieferten zu ersetzen. Danach kann der Server mit $./run.sh c default b IP_ADRESSE_DES_SERVERS gestartet werden. Sollte kein externer ApplicationServer genutzt werden muss für IP_ADRESSE_DES_SERVERS gewählt werden. Nach erfolgreichem Start des Servers erscheint die Meldung JBoss_4_0_4_GA date=xxx] Started in 1m:00s:00ms Nun können die Enterprise-Beans ausgeliefert werden. Hierzu wird die dem Quellcode hinzugefügte Komponente Simple_Address_9b.jar in das Verzeichnis JBOSS_HOME/server/default/deploy/ kopiert. Abhängig vom Debug-Level des JBoss wirft dieser einige Informationsmeldungen. Die Client kann am komfortabelsten über das dem Quellcode hinzugefügten Eclipse-Projekt gestartet werden. Ggf. muss die IP-Adresse des Servers in der Datei jndi.properties angepasst werden: java.naming.provider.url=ip_adresse_des_servers:1099 Seite 18 von 21

19 Anhang A Verwendete Software A.1 Java EE 5 SDK Als Basis wird das Enterprise SDK benötigt, welches unter bezogen werden kann. Die Beispielanwendung wurde mit der Version 5_02 entwickelt und getestet. A.2 JBoss Application Server Der JBoss Application Server ist die Implementierung eines Application-Servers nach dem JEE-Standard. JBoss ist neben BEA Weblogic und IBM Websphere einer der drei verbreitesten JEE-Applicationserver. Der JBoss AS ist unter verfügbar. Die Beispielanwendung wurde mit der Version 4.0.4GA-Patch1 entwickelt und getestet. A.3 JBoss IDE für Eclipse Die JBoss IDE für Eclipse bietet neben der integrierten Entwicklungsumgebung eine Vielzahl vonplug-ins welche die Entwicklung im Umfeld der Java Enterprise Edition stark vereinfachen. Sie kann unter bezogen werden. Die Beispielanwendung wurde mit der Version GA entwickelt und getestet. A.4 HSQLDB HSQLDB ist ein open-source Relationales Datenbank- Managementsystem. Es ist in Java implementiert und daher auf allen Java-Plattformen lauffähig. HSQLDB ist relativ weit verbreitet und wird zusammen mit dem JBoss Application-Server ausgeliefert. A.5 PostgreSQL PostgreSQL ist eines der ältesten und am weitesten fortgeschrittenen objektrelationalen Datenbanksysteme im Bereich der freien Software. PostgreSQL kann unter bezogen werden. Die Beispielanwendung wurde mit der Version entwickelt und getestet. Seite 19 von 21

20 Anhang B URL-Verzeichnis B.1 Spezifikationen JSR 220: Enterprise JavaBeans B.2 Systeme, Bibliotheken, Anwendungen Hibernate Hibernate-Tools Java Data Objects (JDO) Container Managed Persistence Java Persistence API (EJB3.0) JRelationalFramework Cayenne ObJectRelationalBridge Turbine/Torque B.3 Artikel und Tutorials J2EE Designpattern Tutorial Hibernate Tutorial EJB3.0 Seite 20 von 21

21 Anhang C Literaturverzeichnis Jürgen Zimmermann, Gerd Beneken: Verteilte Komponenten und Datenbankanbindung. Addison-Wesley 2000 Thomas Stark: Java EE 5. Addison-Wesley 2006 Heiko W.Rupp: JBoss. Dpunkt.Verlag 2004 Seite 21 von 21