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

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

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

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.

4 Verwendete Entwicklungsumgebungen und Frameworks
4
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)

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

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.
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 (JPA)
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"

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

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.

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)

10 Anhang
29
10 Anhang
10.1 Vergleich Spring und EJB3

10 Anhang
30
Abbildung 16: Vergleich Spring und EBJ3 (valtech.com)
10.2 Datenbank-Modell "MyCollection"

10 Anhang
31
Abbildung 17: Datenbank-Modell "MyCollection"

Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse

Ähnlich wie Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse (20)

Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse