FOM Hochschule für Oekonomie & Management Essen
Berufsbegleitender Studiengang zum Bachelor of Science
4. Semester
Seminar...
I
Inhaltsverzeichnis
1 Abkürzungsverzeichnis.................................................................................
Seminararbeit in „Web-Anwendungsentwicklung“
1 Abkürzungsverzeichnis
1
1 Abkürzungsverzeichnis
ACID: Atomicity, Consistenc...
Seminararbeit in „Web-Anwendungsentwicklung“
2 Abbildungsverzeichnis
2
JSF: JavaServer Faces; ein Framework-Standard zur O...
Seminararbeit in „Web-Anwendungsentwicklung“
3 Einleitung
3
Abbildung 13: Konkretes DAO .....................................
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
4
4 Verwendete Entwicklung...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
5
Abbildung 2: Die Spring-...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
6
wiederholender Arbeit ab...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
7
4.2.2 Inversion of Contr...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
8
4.2.3 Aspektorientierte ...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
9
Funktionalitäten, werden...
Seminararbeit in „Web-Anwendungsentwicklung“
4 Verwendete Entwicklungsumgebungen und Frameworks
10
Datentypen enthalten kö...
Seminararbeit in „Web-Anwendungsentwicklung“
5 Verwendete Java-Technologien
11
Ebenso stellt Hibernate Klassen und Funktio...
Seminararbeit in „Web-Anwendungsentwicklung“
5 Verwendete Java-Technologien
12
Die Umsetzung der Java Servlets in eine vom...
Seminararbeit in „Web-Anwendungsentwicklung“
5 Verwendete Java-Technologien
13
JSPs werden ebenfalls in der View-Schicht e...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
14
XML-Dateien im .xhtml-Format und basiere...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
15
6.1.2 Warum Spring?
Spring und EJB sind ...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
16
• CMP Entity Beans setzen ein 1:1-Mappin...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
17
Web-Entwicklung geworden war und unterst...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
18
6.3 Architektur
Das Project wurde mit de...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
19
unterschiedlichen Bezeichnungen dennoch ...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
20
werden OR-Mapping-Annotationen nötig. Ei...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
21
In der Beispiel-Applikation werden diese...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
22
Die zu persistierenden Entitäten müssen ...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
23
von Try-Catch-Blöcken zu den SQL-Operati...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
24
Beans implementiert wird. Somit können d...
Seminararbeit in „Web-Anwendungsentwicklung“
6 Praxis Beispiel: „MyCollection“
25
6.6 Views, JSF und Facelets
Die Weboberf...
Seminararbeit in „Web-Anwendungsentwicklung“
7 Fazit
26
Der JSF-Tag <h:dataTable> (Zeile 15) erzeugt eine Tabelle, in die ...
Seminararbeit in „Web-Anwendungsentwicklung“
8 Literaturverzeichnis
27
Als Ergebnis dieser Analyse ist festzuhalten, dass ...
Seminararbeit in „Web-Anwendungsentwicklung“
9 Ehrenwörtliche Erklärung
28
Wikipedia. Hibernate (Java). [Online] [Zitat vo...
Seminararbeit in „Web-Anwendungsentwicklung“
10 Anhang
29
10 Anhang
10.1 Vergleich Spring und EJB3
Seminararbeit in „Web-Anwendungsentwicklung“
10 Anhang
30
Abbildung 16: Vergleich Spring und EBJ3 (valtech.com)
10.2 Daten...
Seminararbeit in „Web-Anwendungsentwicklung“
10 Anhang
31
Abbildung 17: Datenbank-Modell "MyCollection"
Nächste SlideShare
Wird geladen in …5
×

Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse

3.260 Aufrufe

Veröffentlicht am

Seminararbeit in „Web-Anwendungsentwicklung“
Berufsbegleitender Studiengang zum Bachelor of Science
4. Semester
-
Term paper for "Web Application Development"
Bachelor of Applied Science (B.A.Sc.), Business Informatics
Semester 4

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.260
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
7
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Web-Entwicklung mit Spring, Hibernate und Facelets in Eclipse

  1. 1. 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
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 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.
  6. 6. 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)
  7. 7. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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
  8. 8. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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)
  9. 9. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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.
  10. 10. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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
  11. 11. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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)
  12. 12. Seminararbeit in „Web-Anwendungsentwicklung“ 4 Verwendete Entwicklungsumgebungen und Frameworks 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)
  13. 13. 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.
  14. 14. Seminararbeit in „Web-Anwendungsentwicklung“ 5 Verwendete Java-Technologien 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 (<!-- text --> oder <%-- text -->) • JSP-Direktiven (<%@ Direktivenname { … } %>) beeinflussen den Überset- zungsvorgang der JSP-Seite (z.B. @ include oder @ page)
  15. 15. Seminararbeit in „Web-Anwendungsentwicklung“ 5 Verwendete Java-Technologien 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
  16. 16. 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.
  17. 17. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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):
  18. 18. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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)
  19. 19. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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.
  20. 20. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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
  21. 21. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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"
  22. 22. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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)
  23. 23. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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"
  24. 24. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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"
  25. 25. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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
  26. 26. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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
  27. 27. Seminararbeit in „Web-Anwendungsentwicklung“ 6 Praxis Beispiel: „MyCollection“ 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"
  28. 28. 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/)
  29. 29. 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.
  30. 30. 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)
  31. 31. Seminararbeit in „Web-Anwendungsentwicklung“ 10 Anhang 29 10 Anhang 10.1 Vergleich Spring und EJB3
  32. 32. Seminararbeit in „Web-Anwendungsentwicklung“ 10 Anhang 30 Abbildung 16: Vergleich Spring und EBJ3 (valtech.com) 10.2 Datenbank-Modell "MyCollection"
  33. 33. Seminararbeit in „Web-Anwendungsentwicklung“ 10 Anhang 31 Abbildung 17: Datenbank-Modell "MyCollection"

×