web-entwicklung mit spring, hibernate und facelets in eclipse

FOM Hochschule für Oekonomie & Management Essen

Berufsbegleitender Studiengang zum Bachelor of Science

4. Semester

Seminararbeit in „Web-Anwendungsentwicklung“

Betreuer: Klaus Stolz

Autorin: Sarah Steffen

Matrikelnr.: 241593

Adresse: Richrather Weg 107, 42551 Velbert

Essen, den 18.07.2011

I

Inhaltsverzeichnis

1 Abkürzungsverzeichnis .......................................................................................................... 1

2 Abbildungsverzeichnis ........................................................................................................... 2

3 Einleitung ............................................................................................................................... 3

3.1 Thema dieser Arbeit ...................................................................................................... 3

3.2 Ziel und Aufbau dieser Arbeit ........................................................................................ 3

4 Verwendete Entwicklungsumgebungen und Frameworks..................................................... 4

4.1 Eclipse ........................................................................................................................... 4

4.2 Das Spring Framework ................................................................................................. 4

4.2.1 POJOs und POJIs ..................................................................................................... 6

4.2.2 Inversion of Control und Dependency Injection ........................................................ 7

4.2.3 Aspektorientierte Programmierung ........................................................................... 8

4.3 Hibernate ....................................................................................................................... 9

5 Verwendete Java-Technologien .......................................................................................... 11

5.1 Servlets ....................................................................................................................... 11

5.2 JavaServer Pages ....................................................................................................... 12

5.3 JavaServer Faces ....................................................................................................... 13

5.4 Facelets ....................................................................................................................... 13

6 Praxis Beispiel: „MyCollection“ ............................................................................................ 14

6.1 Technologie-Auswahl .................................................................................................. 14

6.1.1 Warum Eclipse? ...................................................................................................... 14

6.1.2 Warum Spring? ....................................................................................................... 15

6.1.3 Warum Hibernate? .................................................................................................. 15

6.1.4 Warum JSF? ........................................................................................................... 16

6.1.5 Warum Facelets? .................................................................................................... 17

6.2 Spezifikation ................................................................................................................ 17

6.3 Architektur ................................................................................................................... 18

6.4 Datenbank ................................................................................................................... 18

6.5 Implementierung ......................................................................................................... 18

6.5.1 Die Entitäts-Klassen ................................................................................................ 18

6.5.2 Die Konfiguration von Spring und Hibernate (JPA)................................................. 20

6.6 Views, JSF und Facelets ............................................................................................. 25

7 Fazit ..................................................................................................................................... 26

8 Literaturverzeichnis .............................................................................................................. 27

9 Ehrenwörtliche Erklärung ..................................................................................................... 28

10 Anhang ............................................................................................................................ 29

10.1 Vergleich Spring und EJB3 ......................................................................................... 29

10.2 Datenbank-Modell "MyCollection" ............................................................................... 30

Seminararbeit in „Web-Anwendungsentwicklung“ 1 Abkürzungsverzeichnis

1

1 Abkürzungsverzeichnis

ACID: Atomicity, Consistency, Isolation und Durability (dt; Atomarität, Konsistenz, Isoliertheit

und Dauerhaftigkeit); erwünschte Eigenschaften von Datenbank-Transaktionen in

verteilten Systemen .......................................................................................................... 11

AOP: Aspektorientierte Programmierung; ein Programmierparadigma für die Objektorientierte

Programmierung, um generische Funktionalitäten über mehrere Klassen hinweg zu

verwenden ...................................................................................................................... 5, 8

API: Application Programming Interface; Programmschnittstelle ......................................... 10, 11

ASP: Active Server Pages; eine von Microsoft entwickelte Technologie, die (z.B. mit C#)

serverseitig Webseiten erzeugt ........................................................................................ 11

CCC: Cross-Cutting Concern; bezeichnet modul-übergreifend benötigte Funktionen, die nicht

modularisiert bzw. objektorientiert umgesetzt werden können ............................................8

CGI: Common Gateway Interface; Standard zur Kommunikation zwischen Webservern und

Clients ............................................................................................................................... 11

DAO: Data Access Object; Datenzugriffsobjekt, das den Zugriff auf eine Datenquelle so kapselt,

dass diese ausgetauscht werden kann, ohne dass der aufrufende Code geändert werden

muss.................................................................................................................. 5, 21, 22, 24

DI: Dependency Injection; Entwurfsmuster das dazu dient, die Abhängigkeiten zwischen

Komponenten oder Objekten zu minimieren .......................................................................7

EJB: Enterprise JavaBeans; standardisierte Komponenten in der Entwicklung von Business

Applikationen mit JEE ......................................................................................... 5, 6, 15, 27

EL: Expression Language; eine Skriptsprache, mit der über JavaBeans Ausdrücke in Webseiten

eingefügt werden können ................................................................................................. 13

HQL: Hibernate Query Language; SQL-ähnliche Datenbankabfragesprache von Hibernate ....10,

24

HTML: Hypertext Markup Language; eine textbasierte Auszeichnungssprache zur

Strukturierung und Formatierung von Inhalten wie Texten, Bildern und Hyperlinks in

Dokumenten .................................................................................................... 11, 12, 13, 14

IDE: Integrated Development Environment; (dt.) Integrierte Entwicklungsumgebung ........... 4, 14

IoC: Inversion of Control; Programmierparadigma in der objektorientierten Programmierung, bei

der die Steuerung von Objekten an ein Framework übergeben wird ............................. 5, 7

JDBC: Java Database Connectivity; Schnittstelle, die Java-Anwedungen den Zugriff auf

verschiedene Typen von Datenbanken ermöglicht .......................................... 5, 10, 11, 15

JEE: Java Enterprise Edition; Spezifikation einer Softwarearchitektur für die

transaktionsbasierte Ausführung von Java Web-Anwendungen .................. 3, 5, 11, 13, 15

JPA: Java Persistence API; Schnittstelle zur Zuordnung von Java-Objekten und Datenbank-

Entitäten ................................................................................................ 9, 10, 15, 16, 20, 22

Seminararbeit in „Web-Anwendungsentwicklung“ 2 Abbildungsverzeichnis

2

JSF: JavaServer Faces; ein Framework-Standard zur Oberflächen-Entwicklung mit JSP . 13, 14,

16, 17, 25, 26

JSP: JavaServer Pages; eine auf JHTML basierende Web-Programmiersprache zur einfachen

dynamischen Erzeugung von HTML- und XML-Ausgaben eines Webservers 5, 12, 13, 17,

27

JSTL: JavaServer Pages Standard Tag Library; enthält vier Custom-Tag-Bibliotheken für das

Erstellen von JSP-Seiten .................................................................................................. 17

JTA: Java Transaction API; Schnittstelle, die den Einsatz verteilter Transaktionen ermöglicht .11,

15

MVC: Model-View-Controller; 3-Tier Architekturmuster bestehend aus den Schichten

Datenmodell (engl. model), Präsentation (engl. view) und Programmsteuerung (engl.

controller). ................................................................................................... 5, 11, 16, 17, 18

ORM: Objektrelationales Mapping; Übertragung von Daten aus relationalen in objektorientierte

Strukturen und umgekehrt .......................................................................................... 5, 6, 9

PHP: Skriptsprache zur Erstellung dynamischer Webseiten und Webandwendungen .............. 11

POJI: Plain Old Java Interface; einfachste Variante eines Java-Interface ohne Vererbung .........6

POJO: Plain Old Java Object; einfachste Variante einer Java-Klasse ohne Interfaces oder

Vererbung ....................................................................................... 6, 10, 15, 16, 18, 20, 22

SQL: Structured Query Language; Abfragesprache für relationale Datenbanken 3, 9, 10, 15, 16,

23

UML: Unified Modeling Language; graphische Modellierungssprache zur Spezifikation von

Software ...............................................................................................................................4

XML: Extensible Markup Language; Auszeichnungssprache zur Darstellung hierarchisch

strukturierter Daten ............................................................................... 7, 10, 11, 12, 13, 14

2 Abbildungsverzeichnis

Abbildung 1: Eclipse Logo (eclipse.org) .........................................................................................4

Abbildung 2: Spring Source Logo (SpringSource.org) ...................................................................6

Abbildung 3: Die Spring-Module (SpringSource.org) .....................................................................5

Abbildung 4: Beispiel Interceptor (Wikipedia) ................................................................................8

Abbildung 5: Hibernate Logo (Wikipedia) ......................................................................................9

Abbildung 6: Hibernates Rolle in Java-Applikationen (Minter, et al., 2006 S. 2) ...........................9

Abbildung 7: "The evolution of Java web frameworks" (Wadia, et al., 2008 S. 2) ...................... 16

Abbildung 8: POJO für die Entity "Album" .................................................................................. 19

Abbildung 9: JPA Interfaces (Fisher, et al., 2010 S. 53) ............................................................. 20

Abbildung 10: Konfigurationsdatei "spring-jpa.xml" .................................................................... 21

Abbildung 11: Konfigurationsdatei "persistence.xml" ................................................................. 22

Abbildung 12: Generisches DAO ................................................................................................ 23

Seminararbeit in „Web-Anwendungsentwicklung“ 3 Einleitung

3

Abbildung 13: Konkretes DAO .................................................................................................... 24

Abbildung 14: View-Datei "artists.xhtml" ..................................................................................... 25

Abbildung 15: Vorläufige Web-Oberfläche "MyCollection" ......................................................... 26

Abbildung 16: Vergleich Spring und EBJ3 (valtech.com) ........................................................... 30

Abbildung 17: Datenbank-Modell "MyCollection"........................................................................ 31

3 Einleitung

3.1 Thema dieser Arbeit

Thema dieser Arbeit sind die aktuell innerhalb der Java Enterprise Edition (JEE)

verwendeten Open-Source Frameworks Spring und Hibernate, sowie das Web

Template System Facelets. Es handelt sich hierbei um relativ neue Technologien,

die Entwicklern eine interessante Alternative zu konventionellen und kommerziellen

Tools bieten.

3.2 Ziel und Aufbau dieser Arbeit

Ziel dieser Arbeit ist es, einen zusammenfassenden Überblick über die oben ge-

nannten JEE-Technologien zu geben.

Die Frameworks Spring und Hibernate und die Entwicklungsumgebung Eclipse

werden zunächst in Kapitel 4 vorgestellt; anschließend wird in Kapitel 5 die Funkti-

onsweise der behandelten Java Technologien erläutert. Als Praxisbeispiel zur ge-

meinsamen Verwendung der zu Beginn vorgestellten Entwicklungstools wird in Ka-

pitel 6 unter Einbeziehung der Spring Persistence Technologie und einer SQL-

Datenbank ein kurzer Einblick in die Entwicklung einer Web-Anwendung gegeben.

Bei der Beispiel-Anwendung handelt es sich um eine Mini-Plattform zur Verwaltung

von Tonträgerdaten bzw. einer eigenen Plattensammlung. Da eine komplette Do-

kumentation der Entwicklung den Rahmen dieser Arbeit sprengen würde, werden

nur einige grundsätzliche Aspekte der Programmierung bzw. Konfiguration aufge-

zeigt.

Kapitel 7 enthält ein Fazit zur praktischen Verwendung der erwähnten Frameworks

und Technologien in Bezug auf Schwierigkeitsgrad, Kohärenz, Kompatibilität und

Integrierbarkeit der einzelnen Tools.

Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks

4

4 Verwendete Entwicklungsumgebungen und Frameworks

4.1 Eclipse

Eclipse ist eine mehrsprachige Open-Source Ent-

wicklungsumgebung (IDE) für diverse Program-

miersprachen. Es ist ein beliebtes Tool für die

Softwareentwicklung mit Java und verwandten

Sprachen, jedoch gibt es für fast jede erdenkliche

andere Sprache Plug-Ins, so z.B. für Perl, PHP, C

und C++, aber auch Python, Scala, COBOL und

sogar LaTeX. Ebenso lässt sich Eclipse durch etliche weitere Plug-Ins erweitern,

z.B. zum Einbinden anderer Frameworks, wie etwa Spring oder Hibernate, oder

auch zum automatisierten Erstellen von UML-Diagrammen. Im Grunde besteht die

ganze Entwicklungsumgebung nur aus einem leichtgewichtigen Kernel, um den

herum Features durch hinzugefügte Plug-Ins aufgebaut werden.

Eclipse unterstützt mehrere (Open-Source) Server und Servlet Container zur Ent-

wicklung von Web-Applikationen, wie z.B. Apache Tomcat, GlassFish und JBoss.

In dieser Arbeit wird nur auf den Apache Tomcat weiter eingegangen, da dieser die

offizielle Referenzimplementierung eines Servlet Containers ist und für das prakti-

sche Beispiel verwendet wurde.

Eclipse wurde ursprünglich von IBM entwickelt, welche 2001 den Quellcode dazu

freigaben (vgl. eclipse.org); auch das bekannte IBM Produkt "Lotus Notes" bei-

spielsweise wird mit Eclipse entwickelt. Seit dem wird das Projekt Eclipse von der

Eclipse Foundation, einer Non-Profit-Organisation, als frei verfügbare Open Source

Software weiterbetrieben. Es wird ständig weiterentwickelt und ca. jedes Jahr wird

ein neues Release veröffentlicht; am weitesten verbreitet sind zurzeit die Eclipse

Releases 3.5 (Galileo), von 2009, und 3.6 (Helios), von 2010.

4.2 Das Spring Framework

Spring ist ein Open Source Application Framework, das ursprünglich von Rod

Johnson im Jahre 2002 entwickelt wurde; die erste fertige Version wurde 2004 ver-

öffentlicht. Es ist modular aufgebaut und hat einen sehr großen Funktionsumfang,

seine Hauptfunktion ist jedoch, eine Alternative zur Programmierung mit Enterprise

Abbildung 1: Eclipse Logo (eclipse.org)


5

Abbildung 2: Die Spring-Module (SpringSource.org)

JavaBeans (EJB) zu bieten; allerdings unterstützt Spring auch diese. Spring be-

steht aus folgenden Haupt-Modulen:

• Data Access Objects (DAO) (Spring JDBC, Transaction Management)

o Transaktionen o Datenbankzugriffe

• Objektrelationales Mapping (ORM)

• Aspektorientierte Programmierung (AOP)

• JEE (Remoting, EJBs, Email)

• Web

o Servlets o JSPs o Model-View-Controller Architektur (Spring MVC) o PDF o Excel o Viele weitere Funktionen

• Dependency Injection (im IoC Core Container)

Springs ursprüngliche Aufgabe war es, die Entwicklung von serverseitigen Java-

Applikationen zu vereinfachen, indem es die Kopplung der Application Dependen-

cies selbstständig übernahm und so dem Entwickler einen großen Teil sich ständig


6

wiederholender Arbeit abnahm. Aus die-

sem Grund wird Spring oft als Container

bezeichnet, da es die Einbindung und

Zusammenarbeit von Dependencies

mittels Konfiguration statt dem Schreiben von Code ermöglicht. (vgl. Fisher, et al.,

2010 S. 3f). Als Alternative zu EJB-Containern sollte es vor allem den Overhead

reduzieren, der dort vor allem bei Transaktionen und Security-Implementierungen

entsteht: “Time has proven EJB, although powerful in theory, to be a victim of over-

engineering.” (Fisher, et al., 2010 S. 4).

4.2.1 POJOs und POJIs

Die Abkürzung „POJO“ steht für „Plain Old Java Object“. Spring-POJOs sind der

gewollte Gegenentwurf zu Enterprise Java Beans; sie enthalten keine Interfaces

oder Beziehungen zu anderen Klassen bzw. Objekten, stellen zusammengefasst

also die denkbar einfachste Form einer Java Klasse dar.

Enterprise Java Beans sind eine Sonder-Spezifikation von POJOs. Sie unterliegen

bestimmten Konventionen z.B. bei der Namensgebung von Methoden. Sowohl

EJBs als auch die von Spring verwendeten POJOs werden als Entity Beans, als

Entitätsklassen, verwendet. Der Unterschied zwischen beiden wird unter 6.1.3 nä-

her erläutert.

Entity-POJOs werden mit einer Annotation (@Entity) zu einer Entitätsklasse erklärt.

Diese repräsentieren jeweils eine einzelne Tabelle in der mit der Applikation ver-

bundenen Datenbank und dienen dazu, das Mapping festzulegen, in dem die Spal-

ten in der Datenbanktabelle auf die Objekteigenschaften der Java-Entity abgebildet

werden. Dies ist die Voraussetzung für die Realisierung von Persistenz in Java-

Anwendungen, das sogenannte objektrelationale Mapping (ORM). Die POJO-

Entitäten werden letztendlich serialisiert (wodurch individuell unterscheidbare Ob-

jektinstanzen entstehen) und ihre Daten in die Datenbank geschrieben.

Analog zum Akronym POJO steht "POJI" für "Plain Old Java Interface", die ein-

fachste Form eines Java-Interface. POJOs und POJIs bilden die Basis für Stateless

Session Beans bei den EJBs, sind aber im Prinzip ein Grundkonzept das nicht

zwingend an die Verwendung mit EJBs gebunden ist – so z.B. bei dem Einsatz von

POJOs in Spring.

Abbildung 3: Spring Source Logo (SpringSource.org)


7

4.2.2 Inversion of Control und Dependency Injection

Das Prinzip der Inversion of Control (IoC; in etwa: Umkehr der Kontrolle) unterliegt

der Aufgabe von Entwicklungs-Frameworks bei der objektorientierten Programmie-

rung, die die Steuerung des Kontrollflusses von der Anwendung übernehmen. Die

Kontrolle wird also von Framework-Objekten getragen, bei denen bestimmte Funk-

tionen von Objekten registriert werden, die wiederum zu einem späteren Zeitpunkt

vom Framework aufgerufen werden. Oft wird dies vereinfacht "Das Hollywood-

Prinzip" genannt: "Don't call us, we call you." IoC ist eine der Kern-Funktionalitäten

von Spring: “At the simplest level, Spring is a lightweight IoC container, meaning

that it will assume the responsibility of wiring your application dependencies.“

(Fisher, et al., 2010 S. 2).

Eine Umsetzungsform der IoC ist die sogenannte Dependency Injection (DI; in et-

wa: Injizierung von Abhängigkeiten). Diese dient dazu, Komponenten und Funktio-

nen einer Anwendung zu entkoppeln und damit einen modularen Aufbau zu unter-

stützen: „The purpose of dependency injection ist to decouple the work of resolving

external software components from your application business logic.“ (Fisher, et al.,

2010 S. 2). Komponenten sind leichter austauschbar durch andere Technologien

und die Wartbarkeit des Codes wird erhöht. Mit "Abhängigkeiten" sind Objekte und

Ressourcen bezeichnet, die ein Objekt bei der Ausführung seiner Funktionalität

benötigt.

DI findet bei der Erzeugung von Objekten statt, oft in Form von Fabrik-Methoden

(Teil des sogenannten "Factory Pattern", ein entsprechendes Entwurfsmuster). Das

Fabrik-Objekt erzeugt dabei ein anderes Objekt und die Abhängigkeiten des er-

zeugten Objekts werden vom Framework verwaltet bzw. erzeugt. Dem Objekt wird

damit die Aufgabe abgenommen, seine Umgebung und die konkrete Implementie-

rung seiner Abhängigkeiten genau zu kennen – das wäre nötig, wenn das Objekt

wie bisher alle seine Abhängigkeiten selbst erzeugen und verwalten würde.

Durch die Abgabe der Steuerung der Abhängigkeiten an das Framework ist das

Objekt selbst weniger eng mit diesen verwoben (im Idealfall gar nicht) und somit

unabhängig von anderen Klassen, die in seinem Umfeld verwendet werden. Die

Steuerung der Abhängigkeiten wird von den Java-Objekten in XML-

Konfigurationsdateien verlagert und kann so getrennt vom eigentlichen Java-Code

gepflegt werden.


8

4.2.3 Aspektorientierte Programmierung

Aspektorientierte Programmierung (AOP) ist ein Prinzip der objektorientierten Pro-

grammierung, bei dem wiederholt auftretende, abgrenzbare Funktionalitäten (greif-

bar als "logische Aspekte") von der eigentlichen Business-Logik getrennt werden,

sodass sie innerhalb der Anwendung global für viele oder alle Klassen verwendbar

sind. Dies betrifft vor allem Bereiche, die trotz eines objektorientierten Aufbaus

nicht mehr weiter modularisiert werden können, und so im gesamten Code ver-

streut (und oft redundant) implementiert werden.

Ein Begriff für Fälle dieser Problemstellung ist "Cross-Cutting Concern" (CCC). Im

Grunde handelt es sich um Funktionalitäten, die sich nicht eindeutig einem Modul

bzw. einer Architekturkomponente zuordnen lassen und somit von mehreren benö-

tigt werden. AOP ist ein Ansatz, diese CCCs zu lösen und damit Modularität, Wart-

barkeit und Wiederverwendbarkeit des Codes zu erhalten: “Aspect-Oriented Pro-

gramming is aimed at solving this problem by allowing these concerns to be ex-

pressed once, and once only, as aspects, and then weaved into business logic as

necessary.” (Fisher, et al., 2010 S. 9).

Abbildung 4: Beispiel Interceptor (Wikipedia)

Die Sprache AspectJ ist eine Erweiterung von Java mit dem Fokus auf Aspektori-

entierung und kann im Spring-Modul für AOP integriert werden. Ein wichtiger Teil

dieses Moduls sind auch die sogenannten Method Interceptors (interceptor (engl.):

Abfänger, Abschneider), die die Grundlage für die Anwendung der AOP darstellen.

Interceptors werden bei der Kommunikation von Programmkomponenten

"zwischengeschaltet" und können so Einfluss auf den Ablauf nehmen: “An intercep-

tor is code that can be mixed into the execution flow of a method, usually delegat-

ing to the interceptor before and/or after a particular method is invoked.” (Fisher, et

al., 2010 S. 9). Diesem Vorgehen liegt das sogenannte Stellvertreter-

Entwurfsmuster (proxy design pattern) zugrunde (vgl. Fisher, et al., 2010 S. 9). Die

zu Beginn erwähnten "Aspekte", also sich wiederholende, logisch abgrenzbare


9

Funktionalitäten, werden im Sinne der AOP in Interceptors ausgelagert und sind

somit applikationsweit verfügbar, und müssen nicht an vielen Stellen redundant in

den Code geschrieben werden.

4.3 Hibernate

Hibernate (to hibernate (engl.): Winterschlaf

halten; Fachbegriff für den Ruhezustand eines

Computers) ist ein Open Source ORM- und

Persistenz-Framework, welches beispielsweise

im Spring ORM-Modul als Alternative zu TopLink, EclipseLink, iBatis, o.ä. integriert

werden kann. Mittlerweile ist es eines der am weitesten verbreiteten Frameworks

seiner Art; vor allem weil es eines der ersten Frameworks war, das eine Enterprise-

Level Lösung zur Erstellung von Persistence Tiers bereitstellte (vgl. Fisher, et al.,

2010 S. 3).

Hibernate übernimmt die Aufgabe, die Kommunikation bzw. den Datenfluss zwi-

schen Applikation und Datenbank zu koordinieren. Seine Kern-Funktionalität ist die

Abwicklung des objektrelationalen Mappings (ORM), die notwendige Umwandlung

von objektorientierten Daten in relationale Tabellenzeilen und umgekehrt. Das ei-

gentliche Problem ist das Verbinden zweier komplett verschiedener Formen der

Datenstrukturierung: “There is an impedance mismatch between the relational-table

world of databases and the object-oriented world of Java, making an effective ORM

abstraction difficult to implement.“ (Fisher, et al., 2010 S. 3). Hinzu kommt die

Übersetzung von Java-Datentypen in die von SQL-Datenbanken unterstützten Da-

tentypen. Zentraler Punkt ist hierbei, dass Felder in Datenbanktabellen nur skalare

Abbildung 5: Hibernate Logo (Wikipedia)

Abbildung 6: Hibernates Rolle in Java-Applikationen (Minter, et al., 2006 S. 2)


10

Datentypen enthalten können, Java aber auch komplexe Datentypen (z.B. Collec-

tions) verwendet, die prinzipiell eine 1:N-Beziehung zwischen Objekten erfordern.

Auf der Java-Seite der Hibernate-Schnittstelle finden sich die bereits unter 4.2.1

erwähnten POJOs, die die Entitäten der in der Datenbank repräsentierten Objekte

darstellen. Hierzu stellt Hibernate einen sogenannten Entity Manager bereit, der die

Java Persistence API (JPA) nutzt, und somit letztendlich die Möglichkeit zur persis-

tenten Datenspeicherung bietet. Auf der anderen Seite der Schnittstelle werden

grundsätzlich verschiedene Datenbanken unterstützt; Hibernate generiert mithilfe

von JDBC automatisch Statements in der von der Datenbank erwarteten SQL-

Variante. In der Anwendung selbst muss kein konkretes SQL mehr geschrieben

werden, Hibernate verwendet hier die sogenannte Hibernate Query Language

(HQL). HQL ist zwar SQL-ähnlich, aber deutlich simplifiziert und einfacher im ob-

jektorientierten Kontext zu verwenden.

Das OR-Mapping selbst kann in Hibernate entweder über XML-

Konfigurationsdateien oder @-Annotationen in den Java-Klassen gepflegt werden.

Hibernate kann 1:1-Relationen und auch 1:N- und N:M-Relationen (in der Applika-

tion realisiert durch Java-Collections, in der Datenbank durch Relationstabellen)

abbilden. Mögliche Beziehungen sind:

• One to One (1:1)

• One to Many (1:N)

• Many to One (N:1)

• Many to Many (N:M)

Komplexe Datentypen wie Collections (darunter fallen Vektoren, Hashes, Array-

Lists u.ä.) stellen Aggregationen bzw. Kompositionen von Objekten dar, und kön-

nen daher nicht ohne weiteres in eine relationale Datenbank geschrieben werden.

Hibernate übernimmt die Aufgabe, diese Beziehungen in die nötigen Schlüsseltab-

ellen aufzubrechen, und auch wieder zurück in Objekt-Kollektionen zu übersetzen.

Auch Vererbungsbeziehungen zwischen Klassen lassen sich mit Hibernate auf der

Datenbank abbilden. Es werden dazu drei verschiedene Strategien angeboten, wie

die Tabellen für Sub- und Superklassen angelegt werden sollen:

• Single Table (Tabelle pro Vererbungshierarchie)

• Table per Subclass / Joined (Tabelle pro Unterklasse)

• Table per (concrete) class (Tabelle pro konkrete Klasse)

Seminararbeit in „Web-Anwendungsentwicklung“ 5 Verwendete Java-Technologien

11

Ebenso stellt Hibernate Klassen und Funktionen zum Session- und Transaction-

Handling bereit (SessionFactory, Session und Transaction), um die Datenbankope-

rationen (JDBC und JTA) zu koordinieren. Transaktionen funktionieren hierbei nach

dem Alles-oder-nichts-Prinzip, d.h. entweder wird die gesamte Operation erfolg-

reich ausgeführt, oder (wenn auch nur eine Komplikation auftritt) es findet ein Roll-

back auf den Zustand vor Ausführung der Transaktion statt. Einen Leitfaden zum

effizienten Aufbau von Transaktionen stellt das sogenannte ACID-Prinzip dar:

Atomicity, Consistency, Isolation, Durability (Atomarität, Konsistenz, Isoliertheit und

Dauerhaftigkeit).

Des Weiteren bietet Hibernate noch Zusatzfunktionen wie Hibernate Search (Voll-

textindex und Volltextsuche auf Basis von Lucene) und Hibernate Tools.

5 Verwendete Java-Technologien

5.1 Servlets

Der Begriff Servlet (zusammengesetzt aus „Server“ und „Applet“) umfasst einen

bestimmten Typ von Java Klassen. Sie dienen innerhalb von JEE zum Generieren

dynamischer Webinhalte - konkret zur Java-gesteuerten Ausgabe von HTML - und

stellen somit eine Alternative zu Technologien wie PHP, ASP, oder CGI-Scripts

dar. Servlets gehören zum Paket javax und erben normalerweise von der Klasse

javax.servlet.http.HttpServlet. Daran lässt sich schon die Arbeitsweise von Servlets

erahnen: sie liegen auf einem Java-Webserver und verarbeiten http-Anfragen vom

Client, ähnlich PHP- oder Perl- Formularen. Die Zuordnung von Servlet-Klassen zu

den in der URL angehängten Namen erfolgt über ein XML-Mapping in der Datei

web.xml, dem sogenannten Deployment Descriptor (to deploy (engl.): anwenden,

auslösen, ausbringen).

Im Rahmen der Verwendung des MVC-Architekturmusters können Servlets im

View-Bereich eingesetzt werden, dienen dort also der Darstellung der von der An-

wendung bereitgestellten Inhalte. Servlets werden aber auch in der Controller-

Schicht eingesetzt, um dort Benutzereingaben weiter zu verarbeiten. Sie können

über eine Schnittstelle (Servlet API) sowohl mit dem Server, als auch mit anderen

Ressourcen kommunizieren, z.B. Datenbanken oder anderen Java-Applikationen.

12

Die Umsetzung der Java Servlets in eine vom Browser anzeigbare HTML-Ausgabe

wird auf dem Server von einem sogenannten Servlet Container (z.B. Apache

Tomcat) durchgeführt. Dieser greift auf den Deployment Descriptor (web.xml) zu

und setzt das Servlet-Mapping um. Über den Servlet-Namen im Request ruft er die

referenzierte Servlet-Klasse in der Anwendung auf und übersetzt diese in eine

HTML-Seite (Browser erhält Response). Dabei wird, je nachdem welcher HTTP-

Request gesendet wurde, die doGet- oder die doPost-Methode der Servlet-Klasse

aufgerufen, die entweder Geschäftslogik enthält, Methoden zur HTML-Ausgabe,

oder den Request an ein anderes Servlet weitergibt (<jsp:forward> bzw. respon-

se.sendRedirect()). So lassen sich Servlets auch verketten, und die Ausgabe des

einen Servlets wird als Eingabe-Information an das nächste weitergegeben. Ein

Servlet kann aber auch als Filter konfiguriert werden, an den alle Responses vor

der Ausgabe an den Client weitergeleitet werden. So können alle Rückgaben zent-

ral noch einmal bearbeitet werden, z.B. in eine andere Struktur konvertiert.

5.2 JavaServer Pages

JavaServer Pages (JSP) sind quasi eine Weiterentwicklung, bzw. Verfeinerung von

Servlets. Sie werden intern vom Compiler zwar immer noch in Servlets übersetzt,

die Programmiertechnik konzentriert sich hier jedoch mehr auf den HTML-Inhalt;

der Java-Code wird nun in spezielle Tags verpackt. Im Prinzip ist eine JSP eine

normale HTML bzw. XML-Seite mit speziellen Tags, die Java-Code enthalten und

somit die dynamischen Elemente in diesem statischen Kontext bereitstellen. Syn-

taktisch unterscheidbar, aber in gewissen Fällen durchaus austauschbar, sind fol-

gende fünf Formen dieser speziellen Java-HTML-Tags:

• JSP-Deklarationen (<%! code %>) enthalten Instanzvariablen, Methoden

oder innere Klassen

• JSP-Scriptlets (<% code %>) enthalten Java-Anweisungsblöcke

• JSP-Ausdrücke (<%= code %>) sind eine Kurzschreibweise für

out.println(code)

• JSP-Kommentare ( oder <%-- text -->)

• JSP-Direktiven (<%@ Direktivenname { … } %>) beeinflussen den Überset-

zungsvorgang der JSP-Seite (z.B. @ include oder @ page)


13

JSPs werden ebenfalls in der View-Schicht eingesetzt. Der Servlet Container führt

schließlich die Java-Codeelemente aus und gibt die entstandene HTML-Seite an

den Browser weiter. Das Ziel ist mehr Interaktivität mit dem Nutzer, der nicht nur

statische Inhalte lesen, sondern auch mit der Java-Applikation kommunizieren

kann.

5.3 JavaServer Faces

JavaServer Faces (JSF) setzen auf der JSP-Technologie auf. Es handelt sich hier-

bei um ein Framework, das die Darstellung von Web-Oberflächen in JEE-

Applikationen noch weiter vereinfachen, bzw. dynamischer gestalten soll. Auch hier

werden die Quelldateien intern in Servlets umgewandelt, der Entwickler hat bei der

Verwendung von JSF auf der View-Ebene aber eigentlich nur noch XML vor sich.

Die zuvor erwähnten JSP-Tags werden hier von JSF-Tags abgelöst. Innerhalb des

öffnenden JSF-Tags wird dem Elementnamen noch ein sogenannter „Namespace“

vorangestellt, gefolgt von einem Doppelpunkt. Die Standard JSF-Namespaces sind

„h“ (für HTML) und „f“ (für Faces) und sie werden im XML-Header der JSF-Seite

vereinbart. Die h-Tags beispielsweise rendern jeweils ein bestimmtes HTML-

Element, wenn die Seite auf dem Server aufgerufen und an den Browser gesendet

wird (z.B. ergibt <h:panelGrid> ein <table>-Element, und <h:panelGroup> ergibt ein

<div>-Element). Es können aber auch Custom-Tags angelegt und mit eigenem

Namespace verwendet werden. Dazu muss der Programmierer der Applikation

eine eigene Tag-Library hinzufügen (im Verzeichnis /WEB-INF/tags mit der Datei-

endung .tag).

Für die Integration von Ausgaben aus der Java Business-Logik haben JSF eine

eigene Expression Language (EL), mit der z.B. aus Java-Beans ausgelesene Wer-

te ausgegeben bzw. in Attribute der JSF-Ausdrücke geschrieben werden können,

z.B.: #{beanName.methodName} (die Methoden-Klammern werden weggelassen)

oder #{beanName.attributName} (die Getter-Methode wird so automatisch aufgeru-

fen).

5.4 Facelets

Das Web Template System Facelets stellt eine Alternative zur Definition der Views

mit JSP-Seiten (Dateiendung .jsp) im JSF-Framework dar. Facelets verwenden

Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“

14

XML-Dateien im .xhtml-Format und basieren im Prinzip auf normalen HTML-Tags,

die JSF-Ausdrücke wandern dabei in Attribute der Tags, z.B. jsfc=“h:form“ oder

action=“#{beanName.methodenName}. Beim Kompilieren werden diese Attribute

dann ausgelesen und eine normale HTML -Ausgabe erzeugt.

Der Vorteil dieses Ansatzes ist, dass im Prinzip eine ganz gewöhnliche HTML -

Datei vorliegt, ohne spezielle Tags und quasi ganz ohne Java – es liegen keine

unbekannten Tags vor und unbekannte Attribute können ignoriert werden. Der Ja-

va-Code ist so komplett in die Beans und Utility-Klassen verlagert und von der Dar-

stellungsebene entkoppelt. Ein weiteres besonderes Feature ist die sehr simple

Möglichkeit, mit Facelets das Templating von View-Seiten zu realisieren. Ein kon-

kretes Beispiel dazu wird unter 6.6 erläutert.

6 Praxis Beispiel: „MyCollection“

In diesem Kapitel wird anhand einer Beispiel-Applikation die praktische Anwendung

der zuvor vorgestellten Technologien auszugsweise aufgezeigt. Zunächst werden

diesen Alternativen gegenüber gestellt und die Gründe für die konkrete Auswahl

dargelegt. Anschließend wird die Spezifikation der Anwendung kurz erläutert; die

letztendliche Implementierung der Applikation wird nur ansatzweise besprochen, da

der umfängliche Rahmen dieser Arbeit dies erfordert.

6.1 Technologie-Auswahl

6.1.1 Warum Eclipse?

Als wichtigste Alternative zu Eclipse IDE als Entwicklungsumgebung stand NetBe-

ans IDE zur Auswahl. Wie Eclipse ist NetBeans ein Open Source Produkt; ur-

sprünglich von Sun Microsystems entwickelt, wird es seit der Übernahme 2010

durch Oracle vertrieben. Beide IDEs haben im Prinzip die gleichen Features und es

ist schwierig, sie qualitativ voneinander abzugrenzen.

Das Beispiel-Projekt hätte durchaus problemlos auch in Netbeans umgesetzt wer-

den können, die Wahl fiel jedoch auf Eclipse, da der Autor mit diesem Tool vertrau-

ter war und mehr Erfahrungen gesammelt hatte.


15

6.1.2 Warum Spring?

Spring und EJB sind nicht das gleiche, eigentlich nicht mal vergleichbar. Enterprise

Java Beans sind eine Spezifikation und Spring ist eine Implementierung - Spring ist

ein Framework und EJB eine Architektur; beide arbeiten auf der JEE Plattform.

Doch es gibt auch Bereiche, in denen sie sich überschneiden, da sie beide die

Möglichkeit bieten, Java Web-Applikationen und –Services zu erstellen

(valtech.com S. 3). Sie besitzen vergleichbare Features in Bereichen wie Persis-

tenz, Transaktionalität, Statefulness, Messaging, Remoting, Dependency Manage-

ment, uvm. Im Anhang dieser Arbeit befindet sich eine Liste mit einer Gegenüber-

stellung vieler dieser Eigenschaften von Spring und EJB3. Als besonders wichtig

hinsichtlich der Entscheidung für Spring sind jedoch zu nennen:

• Spring unterstützt viele verschiedene Persistence Frameworks (u.a. Hiber-

nate), EJB3 nur JPA

• Spring unterstützt mehrere Transaktionstypen (Hibernate, JDBC, JTA),

EJB3 nur JTA

• Spring unterstützt eine größere Bandbreite an zusätzlichen Open Source

Tools

• Spring ist flexibler hinsichtlich Scoping, Remote Objects und Test-Klassen.

EJB erwarten meist spezifische JEE-Objekte und Spring arbeitet an diesen

Stellen mit einfachen POJOs.

Im Vergleich ist Spring schließlich flexibler bei der Entwicklung von Java Web-

Anwendungen und bietet einen größeren Funktionsumfang.

6.1.3 Warum Hibernate?

Als Alternative zu Hibernate können EBJs mit JPA zur Realisierung von Persistenz

verwenden. Entity Beans können auf einem EJB Server in zwei Konzepten ver-

wendet werden: Bean-Managed-Persistence (BMP) und Container-Managed-

Persistence (CMP). Während bei der BMP jede Beans selbst für die Speicherung

ihrer Daten, SQL-Operationen, etc., verantwortlich ist, übernimmt dies bei der CMP

der Container, der die Bean-Daten verwaltet. Dies ist im Rahmen von EJB3 eine

mögliche Lösung zur Persistenz-Implementierung, doch es gibt einige Gründe,

weshalb sich an dieser Stelle der Einsatz vom Hibernate als ORM-Framework an-

bietet (Minter, et al., 2006 S. 4-5):


16

• CMP Entity Beans setzen ein 1:1-Mapping mit der Datenbank voraus

• CMP Entity Beans können keine Vererbungsbeziehungen abbilden

• CMP Entity Beans sind nicht serialisierbar

• Hibernate setzt kein 1:1-Mapping einer POJO voraus, n:m ist möglich

• Hibernate unterstützt Vererbung und andere Beziehungen zwischen

Klassen

• Hibernate unterstützt serialisierbare POJOs

• Die von Hibernate genutzten POJOs können leicht für die Verwendung in

anderen Applikationen verallgemeinert werden

Des Weiteren ermöglicht es Hibernate, die Anwendung komplett unabhängig vom

verwendeten Datenbanktyp zu entwickeln. Sollte das Datenbanksystem ausge-

wechselt werden müssen, müssen im Applikationscode selbst keine Änderungen

vorgenommen werden. Durch den Einsatz der Hibernate Query Language muss

kein aufwendiges SQL mehr geschrieben werden.

Es gibt zwar weitere Open Source Alternativen mit vergleichbaren Features, wie

z.B. EclipseLink (offizielle Referenzimplementierung von JPA 2.0) oder iBatis, doch

Hibernate hat die größte Community und den größten Verbreitungsgrad. Die Wahl

fiel unter anderem auf Hibernate, da es dazu im Web am meisten Support gibt.

6.1.4 Warum JSF?

Vor der Entwicklung von JSF durch Sun Microsystems im Jahre 2004, war eines

der meist verwendeten Application Frameworks Struts. Es war entwickelt worden,

als einige Jahre vorher das MVC-Architekturmuster der de-facto Standard für Java

Abbildung 7: "The evolution of Java web frameworks" (Wadia, et al., 2008 S. 2)


17

Web-Entwicklung geworden war und unterstützte dieses Muster, so wie u.a. die

Frameworks Spring MVC, Stripes und Tapestry (vgl. Wadia, et al., 2008 S. 4). Al-

lerdings waren diese in großer Anzahl verfügbaren Frameworks für sich wiederum

sehr spezialisiert und mussten oft mühsam miteinander kombiniert werden, um den

gewollten Funktionsumfang zu erreichen.

JSF war die Lösung, die diese unübersichtliche Situation mit einem einheitlichen

Standard ablöste. Dieses Framework wurde für das Projekt gewählt, da es eine

zeitgemäße Standard-Plattform zur Entwicklung von Java Web-Applikationen ist

und einen angemessen großen Funktionsumfang hat.

6.1.5 Warum Facelets?

Es gibt mehrere Gründe, warum es sich anbietet, Facelets statt JSP-Seiten zum

Erzeugen der Views bei JSF zu nutzen. Die Kombination von JSP und JSF bringt

einige Schwierigkeiten durch Inkompatibiltät bestimmter Komponenten mit sich,

ebenso kann JSTL nicht mit JSF genutzt werden. Facelets umgehen das Problem

dieser Inkompatibilität und bieten unter anderem auch die Möglichkeit des Code-

Templating, was einen enormen Vorteil hinsichtlich Redundanz-Reduktion, Code-

Wartbarkeit und -Wiederverwendbarkeit darstellt. Ebenso funktionieren Facelets

mit jeder JSF-Version und benötigen keinen speziellen Web-Container (vgl.

Aranda, et al., 2008 S. 2-3).

6.2 Spezifikation

Das Projekt „MyCollection“ umfasst eine Web-Applikation zur Verwaltung von Ton-

träger-Datensätzen. Dabei soll der Benutzer zum einen unabhängig von seinen

eigenen Besitztümern Daten zu Künstlern, Gruppen, Alben, etc. in die Datenbank

einfügen und die Informationen wieder abrufen können; zum anderen kann mit vor-

handenen Datensätzen die eigene Musik-Sammlung digital abgebildet und festge-

halten werden.

Eine Benutzerverwaltung ist zunächst nicht vorgesehen, aber evtl. für spätere Ver-

sionen geplant. Diese Version wird benutzerneutral erstellt, man kann also nur Ton-

träger als im eigenen Besitz oder nicht im eigenen Besitz festlegen.


18

6.3 Architektur

Das Project wurde mit dem Build-Management Tool Apache Maven erstellt und als

Web-Applikation mit 3-Tier MVC-Architektur aufgebaut.

Folgende Frameworks wurden dabei eingebunden:

• JSF 2.0 (Apache Myfaces 2.0.2)

• Spring 3.0.2

• Hibernate 3.5.0

6.4 Datenbank

Die Datenbank ist eine lokale MySQL-Datenbank auf dem Server "localhost". Be-

trieben wird dieser mit dem Open Source Tool XAMPP, das sowohl einen Dienst

für einen MySQL-Server als auch einen Apache-Server bereitstellt.

Erstellt wurde die Datenbank mit der Open Source Applikation "phpMyAdmin" und

sie enthält 15 Tabellen vom Typ InnoDB.

6.5 Implementierung

6.5.1 Die Entitäts-Klassen

Die Entity- POJOs befinden sich im Paket "MyCollection/src/main/java/model". Sie

alle implementieren das Interface java.io.Serializable (siehe Zeile 3 bzw. 14), was

eine Serialisierung des Objektinstanzen und somit eine Persistierung der einzelnen

Objekte ermöglicht. Der Aufbau der Entity-POJOs wird nun am Beispiel der Klasse

Album.java erläutert (siehe Abbildung 8).

Die Annotation "@Entity" (Zeile 12) deklariert die Klasse als Entität einer verbun-

denen Datenbank, die Annotation "@Table" (Zeile 13) gibt den konkreten Namen

der Tabelle an, die mit der Entität abgebildet werden soll. Im Folgenden werden die

Spalten der Tabelle auf die Attribute des Objektes gemappt. Die Annotation "@Id"

kennzeichnet den Primärschlüssel, bzw. das Attribut, über das die individuellen

Objekte identifizierbar sind. In diesem Fall ist es ein Integer-Wert, der auf der Da-

tenbank mit Auto Increment erhöht wird. Bei den Attributen "id" und "title" sind die

Attribut-Bezeichnung in Java und der Spaltenname in der Datenbank identisch,

deshalb entfällt dort eine explizite Mapping-Annotation. Bei dem Attribut "alterna-

teTitle" ist der Spaltenname in der Datenbank "alternate_title"; um diese beiden


19

unterschiedlichen Bezeichnungen dennoch zu verknüpfen, wird mit der Annotation

"@Column" (Zeile 22) explizit der referenzierte Spaltenname angegeben.

Die folgenden Objekt-Attribute stellen Beziehungen zu anderen Entitäten dar, somit

Abbildung 8: POJO für die Entity "Album"


20

werden OR-Mapping-Annotationen nötig. Ein Album beispielsweise hat genau ei-

nen Künstler zu dem es gehört, ein Künstler kann aber mehrere Alben haben, da-

her liegt hier eine Many-to-One Beziehung vor. Die Annotation "@JoinColumn" gibt

an, mit welcher anderen Tabelle die Relation hergestellt werden soll; es wird dann

auf den entsprechenden Primärschlüssel referenziert (siehe Zeile 26-27). Ein Al-

bum kann in verschiedenen Auflagen erschienen sein, also gehören mehrere Ton-

träger (Records) mit unterschiedlichen Katalognummern, Erscheinungsjahren und

ggf. Labels zu einem Album-Datensatz (der wiederum zeigt später in der Applikati-

on automatisch die Daten der Erstausgabe (primary issue) an. Andere Auflagen

können dann vom Benutzer zum Anzeigen ausgewählt werden). Es liegt hier eine

One-to-Many Beziehung vor: mehrere Tonträger gehören zu einem Album. In der

Datenbank ist dies so gelöst, dass jeder Tonträger einen Fremdschlüssel "album"

hat, der auf den Primärschlüssel des entsprechenden Album-Datensatzes referen-

ziert. In Java wird hier ein objektorientierter Ansatz gewählt: das Attribut "records"

ist eine typisierte Liste von Objekten der Klasse "Record", also ein komplexer Da-

tentyp. Die Annotation "@OneToMany(mappedBy="album")" (Zeile 41) gibt den

Namen der Spalte der Fremdschlüssels an, der in der relationalen Datenbank diese

Beziehung abbildet. So kann das Framework relationale Datensätze in Objekte und

umgekehrt konvertieren.

Die POJO-Klasse besitzt nun noch einen einfachen, parameterlosen Konstruktor

(Zeile 44) und Setter und Getter für jedes Attribut (omittiert), die später dem Abru-

fen und Persistieren von Eigenschaften des Objekts dienen.

6.5.2 Die Konfiguration von Spring und Hibernate (J PA)

Damit die Anwendung überhaupt Daten von der Datenbank abrufen bzw. dort spei-

chern kann, muss zunächst eine Verbindung zu der Datenbank hergestellt werden.

Die folgende Abbildung zeigt den Zusammenhang der JPA-Interfaces, die für das

Persistieren von Entitäten nötig sind:

Abbildung 9: JPA Interfaces (Fisher, et al., 2010 S. 53)


21

In der Beispiel-Applikation werden diese über Spring konfiguriert, in der Datei

"spring-jpa.xml", die im Ordner "META-INF" liegt (siehe Abbildung 10). Es wird eine

Java Bean mit dem Namen "dataSource" aus der Spring-Klasse "DriverManager-

DataSource" erzeugt (Zeile 11 -17). Dieser werden Parameter zum Treiber, der

URL, dem Usernamen und dem dazugehörigen Passwort der Datenbank hinzuge-

fügt. Der Spring-eigene Namespace "p" dient dabei nur zur Abkürzung der

Schreibweise.

An dieser Stelle werden noch zwei weitere, wichtige Spring Beans konfiguriert: die

"entityManagerFactory" (aus der Klasse "LocalEntityManagerFactoryBean", Zeile

19-21) und der "transactionManager" (aus der Klasse "TransactionManager", Zeile

23-25). Die Entity Manager Factory wird später in den DAO-Beans den lokalen En-

tity Manager bereitstellen, der die Entität verwaltet, und der Transaction Manager

wird die Datenbankoperationen koordinieren.

Abbildung 10: Konfigurationsdatei "spring-jpa.xml"


22

Die zu persistierenden Entitäten müssen der JPA-Schnittstelle noch bekannt gege-

ben werden. Dies geschieht (ganz unabhängig ob Hibernate oder z.B. EclipseLink

benutzt wird) in der Datei "persistence.xml" im Ordner "META-INF" (siehe Abbil-

dung 11). Es wird eine sogenannte Persistence Unit angelegt (Zeile 5-21), die die

angegebenen Klassen als Verbund von mit der Datenbank zu synchronisierenden

Objekten zusammenfasst.

Die Entity-POJOs enthalten in ihren Attributen zwar die Daten, die letztendlich in

die Datenbank geschrieben werden, doch sie besitzen keine Methoden zum Spei-

chern, Ändern oder Löschen der Datensätze; von ihnen aus werden keine Persis-

tenz-Operationen ausgeführt. Dazu werden sogenannte DAOs geschrieben, die

entsprechende Methoden auf den Entity-Beans ausführen.

Da einige Objekte in jedem DAO benötigt werden, wurde zunächst ein generisches

DAO geschrieben (siehe Abbildung 12), von dem die konkreten DAOs erben. Es

enthält u.a. eine Setter-Methode für den zuvor erwähnten Entity Manager (Zeile

23), und einer Hibernate SessionFactory (Zeile 19), die Sessions für die Ausfüh-

rung von Datenbankoperationen bereitstellt. Die Spring-Klasse "HibernateTempla-

te" wiederum arbeitet mit diesem Objekt (sie erhält es als Konstruktor-Parameter,

siehe Zeile 30) und nimmt dem Programmierer einige, sich wiederholende Aufga-

ben ab – wie z.B. das Öffnen einer Datenbankverbindung, das Starten einer Trans-

aktion, die entsprechenden abschließenden Aktionen, oder auch das Hinzufügen

Abbildung 11: Konfigurationsdatei "persistence.xml"


23

von Try-Catch-Blöcken zu den SQL-Operationen – indem die die benötigten Para-

meter aus den XML-Konfigurationsdateien ausliest und diese Aufgaben automa-

tisch und selbstständig durchführt.

Neben diesen konfigurationstechnischen Inhalten enthält die Klasse noch folgende

verallgemeinerte Methoden:

• public T get(int id)

• public List<T> getAll()

• public void save(T object)

• public void remove(T object)

Diese erwarten keine spezifischen Objekte, bzw. geben diese zurück, sondern ar-

beiten mit dem generischen Platzhalter "T". Dieser Platzhalter wiederum implemen-

tiert das leere Interface "DomainObject", welches wiederum auch von allen Entity-

Abbildung 12: Generisches DAO


24

Beans implementiert wird. Somit können die oben erwähnten Methoden auf alle

vorhandenen Entity-Beans angewendet werden.

Die konkrete DAO-Klasse (siehe Abbildung 13) erbt nun von der generischen DAO-

Klasse, und damit auch die oben erwähnten generischen Methoden. Die konkrete

DAO-Klasse ist die, mit der der User später über die Benutzeroberfläche kommuni-

ziert. Sie enthält vor allem solche Abfrage-Methoden, die nicht zu jedem Typ von

Entity-Bean passen, so kann man z.B. ein Album nach "Titel" suchen, nicht aber

einen Künstler, denn dessen Tabelle hat keine Spalte mit dem Namen "Titel". Als

Beispiel wird im Folgenden die Methode "getAlbumByTitle(String title)" abgebildet

(Zeile 22-36). Die ganze explizite Kommunikation mit der Datenbank beschränkt

sich auf das Erstellen eines kurzen Querys in HQL (Zeile 27), und dem ausführen

der Methode "getResultList()" des Query-Objekts.

Abbildung 13: Konkretes DAO


25

6.6 Views, JSF und Facelets

Die Weboberfläche der Beispiel-Applikation besteht aus .xhtml-Dateien, in denen

sowohl JSF- (Namespace "h" und "f"), Facelets- (Namespace "ui") als auch

Custom-Tags (Namespace "ct") verwendet werden.

Als Beispiel ist der Code der Seite artists.xhtml abgebildet (der Übersichtlichkeit

halber etwas vereinfacht, siehe Abbildung 14), der eine Auflistung aller bisher in

der Datenbank eingetragenen Künstler ausgibt. In alle View-Seiten ist das gleiche

Compositions-Template eingebunden, "WEB-INF/layout/layout.xhtml". Das Templa-

te enthält bereits die komplette Formatierung der Seite aus DIV-Elementen und

Graphiken. Der Inhalt des Tags <ui:define name="content> (Zeile 12) wird bei Auf-

ruf der Seite an die Stelle des Templates eingefügt, an der dort der Tag <ui:insert

name="content"> platziert ist; die Zuordnung erfolgt über den Namen. Diese Mög-

lichkeit des Templating bei Facelets reduziert die Code-Redundanz enorm; in der

Ausgabe mehrfach auftretende Seitenelemente müssen programmierseitig nur

einmal geschrieben werden.

Abbildung 14: View-Datei "artists.xhtml"

Seminararbeit in „Web-Anwendungsentwicklung“ 7 Fazit

26

Der JSF-Tag <h:dataTable> (Zeile 15) erzeugt eine Tabelle, in die die Objekte der

Rückgabe des Ausdrucks #{ArtistDaoJpa.getAll} eingespeist werden. Im Custom-

Tag <ct:column> (Zeile 18) wird die Eigenschaft "name" aus der jeweiligen Bean-

Instanz ausgelesen, der Tag <ct:columnCommand> (Zeile 21) liefert eine Spalte

mit einem Link zum Ändern des jeweiligen Datensatzes, und der JSF-Tag <f:facet

name="footer"> (Zeile 23) erzeugt einen Tabellenfuß mit einem Link zum Hinzufü-

gen eines Datensatzes.

Die Ausgabe der Datei artists.xhtml sieht fertig generiert folgendermaßen aus:

Hiermit ist der zu Demonstrationszwecken der verwendeten Technologien geplante

Implementierungsumfang erreicht. Die Anwendung wurde nicht nur für diese Arbeit

geschrieben, sondern wird auch darüber hinaus noch weiterentwickelt.

7 Fazit

Das Ziel dieser Arbeit war es, die aktuell bei Entwicklern bzw. Programmierern im-

mer mehr bevorzugten Frameworks Spring, Hibernate und Facelets bezüglich ihrer

Features genauer zu untersuchen, diese in einem praktischen Beispiel auszutesten

und ggf. deren Vorteile herauszustellen.

Abbildung 15: Vorläufige Web-Oberfläche "MyCollection" (Graphik: http://www.techwebsound.com/)

Seminararbeit in „Web-Anwendungsentwicklung“ 8 Literaturverzeichnis

27

Als Ergebnis dieser Analyse ist festzuhalten, dass bei der Nutzung aller drei Tools

keine größeren Schwierigkeiten auftraten. Die Konfiguration von Spring stellte sich

als etwas diffiziler heraus als zunächst angenommen; die nahezu nahtlose und

effektive Zusammenarbeit mit Hibernate (z.B. bei der Hibernate Session und dem

Hibernate Template von Spring, siehe 6.5.2) entschädigte jedoch dafür. Der Ver-

zicht auf EJB als Implementierungsvariante brachte mehr Übersichtlichkeit mit sich,

da nicht gezwungenermaßen mit (mehreren) Interfaces gearbeitet werden musste.

Die Verwendung von Facelets statt JSP hat die Gestaltung der Benutzeroberfläche

wesentlich vereinfacht und folgt nicht zuletzt auch einem aktuellen Trend, dem man

sich durchaus anschließen sollte. Auch der Einsatz von Eclipse als Entwicklungs-

umgebung war sehr komfortabel, da sich die Frameworks dort sehr gut integrieren

ließen. Insgesamt ist zu sagen, dass die untersuchten Open-Source Frameworks

alle ihre Besonderheiten haben und den Entwicklern die Realisierung ihrer Anwen-

dungen zielgemäß erleichtern.

8 Literaturverzeichnis

Aranda, Bruno und Wadia, Zubin. 2008. Facelets Essentials - Guide to JavaServer Faces

View Definition Framework. s.l. : Apress, 2008.

Burns, Ed, Schalk, Chris und Griffin, Neil. 2009. JavaServer Faces 2.0 - The Complete

Reference. s.l. : McGraw-Hill, 2009.

Downey, Tim. 2007. Web Development with Java using Hibernate, JSPs, and Servlets.

London : Springer, 2007.

eclipse.org. Eclipse - The Eclipse Foundation open source community website. [Online] [Zitat

vom: 15. Juli 2011.] http://www.eclipse.org/.

Fisher, Paul Tepper und Murphy, Brian D. 2010. Spring Persistence with Hibernate. New

York : Apress, 2010. 978-1-4302-2633-8.

Hemrajani, Anil. 2006. Agile Java Development with Spring, Eclipse and Hibernate. s.l. : Sams

Publishing, 2006. 0-672-32896-8.

Minter, Dave und Linwood, Jeff. 2006. Beginning Hibernate: from novice to professional. s.l. :

Apress, 2006.

SpringSource.org. [Online] [Zitat vom: 15. Juli 2011.] http://www.springsource.org/.

valtech.com. Spring & EJB3 compared.pdf. [Online] [Zitat vom: 2011. Juli 17.]

http://www.valtech.com/etc/medialib/library/performance/en.Par.70567.File.tmp/Spring%

20&%20EJB3%20compared.pdf.

Wadia, Zubin, et al. 2008. The Definitive Guide to Apache MyFaces and Facelets. s.l. : Apress,

2008.

Seminararbeit in „Web-Anwendungsentwicklung“ 9 Ehrenwörtliche Erklärung

28

Wikipedia. Hibernate (Java). [Online] [Zitat vom: 15. Juli 2011.]

http://en.wikipedia.org/wiki/Hibernate_%28Java%29.

—. Interceptor (Entwurfsmuster). [Online] [Zitat vom: 15. Juli 2011.]

http://de.wikipedia.org/wiki/Interceptor_(Entwurfsmuster).

—. Spring Framework. [Online] [Zitat vom: 15. Juli 2011.]

http://en.wikipedia.org/wiki/Spring_Framework.

9 Ehrenwörtliche Erklärung

Hiermit versichere ich, dass die vorliegende Arbeit von mir selbstständig und ohne

unerlaubte Hilfe angefertigt worden ist, insbesondere dass ich alle Stellen, die wört-

lich oder annähernd wörtlich aus Veröffentlichungen entnommen sind, durch Zitate

als solche gekennzeichnet habe. Ich versichere auch, dass die von mir eingereich-

te schriftliche Version mit der digitalen Version übereinstimmt. Weiterhin erkläre

ich, dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungs-

behörde vorgelegen hat. Ich erkläre mich damit nicht einverstanden, dass die Ar-

beit der Öffentlichkeit zugänglich gemacht wird. Ich erkläre mich damit einverstan-

den, dass die Digitalversion dieser Arbeit zwecks Plagiatsprüfung auf die Server

externer Anbieter hoch geladen werden darf. Die Plagiatsprüfung stellt keine Zur-

verfügungstellung für die Öffentlichkeit dar.

(Ort, Datum) (Eigenhändige Unterschrift)

Seminararbeit in „Web-Anwendungsentwicklung“ 10 Anhang

29

10 Anhang

10.1 Vergleich Spring und EJB3


30

Abbildung 16: Vergleich Spring und EBJ3 (valtech.com)

10.2 Datenbank-Modell "MyCollection"


31

Abbildung 17: Datenbank-Modell "MyCollection"

web-entwicklung mit spring, hibernate und facelets in eclipse

Technology