Bachelorthesis zur Erlangung des akademischen Grades          Bachelor of Science in Wirtschaftsinformatik                ...
InhaltsverzeichnisAbbildungsverzeichnis                                                                  IIIListingsverzei...
Inhaltsverzeichnis          2.3.6   Implicit Conversions . . . . . . . . . . . . . . . . . . . . . . 29   2.4    Lift Web-...
Abbildungsverzeichnis 2.1   Prozessfluss des Ajax Modells von [Wik] . . . . . . . . . . . . . . .      5 2.2   Lebenszyklus...
Listingsverzeichnis 2.1   Eintragung des Faces-Servlet in der web.xml . . . . . . . . . . . . . 14 2.2   Einbinden der Nam...
Listingsverzeichnis4.6   Raumausstattungen in der Raum Klasse . . . . . . . . . . . . . . . 474.7   Dao Interface für den ...
Listingsverzeichnis4.37 Attribute der Building Klasse . . . . . . . . . . . . . . . . . . . . . 704.38 name Attribut der B...
Listingsverzeichnis4.68 Speichern des ausgewählten Gebäudes . . . . . . . . . . . . . . . . . 944.69 Snippet-Funktionen fü...
AbkürzungsverzeichnisAOP Aspektorientierte ProgrammierungAPI   Application Programming InterfaceCRUD Create, Read, Update,...
1 Einleitung1.1 MotivationDas Entwickeln von Anwendungen für das World Wide Web gewinnt stetig anBedeutung. Bereits heutzu...
1.3 Abgrenzung zu anderen ArbeitenLift soll aus möglichst vielen Blickwinkeln betrachtet werden, damit zum Endeder Arbeit ...
1.4 Aufbau der ArbeitDanach wird die Methodik der Evaluation beschrieben. Dabei werden die ver-wendeten Methoden erläutert...
2 Grundlagen2.1 AjaxDie Begrifflichkeit Ajax ist heutzutage ein gängiges Schlagwort bei der Entwicklungvon Web-Anwendungen. ...
2.2 Java EE               Abb. 2.1: Prozessfluss des Ajax Modells von [Wik]2.2 Java EEDie Java Platform Enterprise Edition ...
2.2 Java EEParsen von XML-Dokumenten.4„Die Java Platform, Enterprise Edition (Java EE) ist ein Aufsatz für die Java SEund ...
2.2 Java EE2.2.1 Java Persistence APIDer Standard für die Persistenzabbildung in Java EE wurde mit JPA im JSR 317spezifizie...
2.2 Java EEdas unteranderem Meta-Informationen für Persistent Entities enthalten kann.13Das Speichern, Löschen, Laden und ...
2.2 Java EEim Zustand Managed sind, werden Änderungen der Attributswerte vom EntityManager registriert und mit der Datenba...
2.2 Java EE2.2.2 Bean ValidationDer JSR 303 (Bean Validation) definiert für Java einen Standard zur Validierung vonObjekten...
2.2 Java EEabhängige Objekte zur Laufzeit injiziert. Das Objekt, dessen Abhängigkeitenaufgelöst werden, ist passiv bei die...
2.2 Java EEdie Daten (Model), die Darstellung (View) und das Verhalten (Controller) vonein-ander getrennt implementiert we...
2.2 Java EEeindeutig identifizierbar sind. Außerdem kann die Darstellung bei Verwendung vonFacelets modular aufgebaut werde...
2.2 Java EEEin weiteres wichtiges Konzept stellen die Managed Beans dar, auch Backing Beansgenannt, über die das Model in ...
2.2 Java EEWebanwendungen in Java EE definiert. So enthält beispielsweise das VerzeichnisWEB-INF in einer WAR-Datei die Kon...
2.3 Programmiersprache Scalawerden. So wird beispielsweise mit dem f:view Tag der Core-Tag-Library derWurzelknoten eines K...
2.3 Programmiersprache ScalaScala interpretiert ausgeführt werden. Dazu liegt der Scala Laufzeitumgebung eininteraktiver I...
2.3 Programmiersprache ScalaParameter vom Typ String, greeting. Die Typangabe erfolgt in Scala nach der An-gabe des Bezeic...
2.3 Programmiersprache Scalaexistiert und ein globaler Zugriff darauf.40 Scala verallgemeinert dieses Muster mitder Nutzung...
2.3 Programmiersprache Scalader apply-Methode existiert eine eingebaute Fabrik-Methode in Scala. In einerapply-Methode wir...
2.3 Programmiersprache ScalaWie bei der Klasse Person zu sehen ist, können Klassen mehrere Traits implemen-tieren. Der ers...
2.3 Programmiersprache ScalaFunktion dec, die über def angelegt wird und anschließend alternativ als Funkti-onsliteral.§  ...
2.3 Programmiersprache Scalap r i n t l n ( d e c L i s t ( L i s t ( 1 , 2 , 3 ) ) ) // Ausgabe : L i s t ( 0 , 1 , 2 )¦ ...
2.3 Programmiersprache ScalaBeim Aufruf von decList in der println Methode wird das Companion Objekt vonList genutzt und i...
2.3 Programmiersprache ScalaKapitel über Pattern Matching gezeigt. Mit dem Trait PartialFunction existierenaußerdem Hilfsf...
2.3 Programmiersprache ScalaDas Ergebnis dieses Aufrufs von subToWith ist das gleiche wie im vorangegangenenListing. Durch...
2.3 Programmiersprache Scalamitunter nicht für alle Werte des Definitionsbereichs definiert. Ist ein solcher Match-Ausdruck ...
2.3 Programmiersprache Scala§                    Listing 2.17: Beispiel einer Self-Type Annotation                        ...
2.3 Programmiersprache Scala2.3.6 Implicit ConversionsMit Implicit Conversions können in Scala Typumwandlungen in Form von...
2.4 Lift Web-Frameworkvon stringToFancyString in ein Objekt des Typs FancyString umwandeln. Damitdie Implicit Conversion v...
2.4 Lift Web-Framework            Abb. 2.5: Kontrollfluss im View-First-Ansatz von Lift aus [Per11]das Java Web-Framework W...
2.4 Lift Web-Framework                         Abb. 2.6: Architektur von Lift aus [DCB11]Lift implementiert mehrere Persis...
2.4 Lift Web-FrameworkTraits. Intern nutzt Mapper die Java SE Datenbankschnittstelle JDBC (JavaDatabase Connectivity).65Zu...
3 Methodik der Evaluation3.1 Beschreibung der EvaluationFür die Evaluation der beiden Technologiestacks werden folgende zw...
3.2 Evaluationskriterien3.2 EvaluationskriterienDie Evaluation wird anhand von Evaluationskriterien durchgeführt, um das E...
3.2 EvaluationskriterienLernaufwand verstanden, der zum Erreichen eines bestimmten Ergebnisses nötigist.Der Autor hat Java...
3.2 EvaluationskriterienEs wird untersucht, welche Persistenztechnologien die Frameworks unterstützenund gezeigt, wie der ...
3.2 EvaluationskriterienFür die Validierung wird bewertet, wie sich die formulierten Validierungsregelnin das Domänenmodel...
3.2 EvaluationskriterienEs gilt zu untersuchen, welche Möglichkeiten und Funktionalitäten die Frameworksfür die lose Koppl...
4 Entwicklung der     Beispielanwendung4.1 Entwurf der AnwendungFür den Vergleich des Scala/Lift Technologiestacks mit dem...
4.1 Entwurf der AnwendungAbb. 4.1: Domänenmodell der Beispielanwendung                                                    ...
4.1 Entwurf der Anwendung4.1.2 AnwendungsfälleEin Anwendungsfall beschreibt ein mögliches Szenario für die Nutzung eines A...
4.2 Umsetzung mit Java EE4.2 Umsetzung mit Java EEDie Java EE Implementierung der Beispielanwendung setzt JSF 1.2 mit Face...
4.2 Umsetzung mit Java EEDa die Objekte der Domänenschicht mittels JPA in einer relationalen Datenbankpersistiert werden, ...
4.2 Umsetzung mit Java EEDa die Gebaeude Klasse einen Konstruktor mit einer nicht leeren Parameterliste hat,der den Defaul...
4.2 Umsetzung mit Java EEVariablen und ihren Wert enthält. Mit dem Ausdruck {Variablenbezeichner} kannein Wert im message ...
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
Upcoming SlideShare
Loading in...5
×

Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell

6,086

Published on

Diese Bachelor-Arbeit vergleicht das Java EE Programmiermodell mit dem Programmiermodell der Sprach Scala und dem Web Framework Lift.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
6,086
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
39
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell

  1. 1. Bachelorthesis zur Erlangung des akademischen Grades Bachelor of Science in Wirtschaftsinformatik Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell Bachelorthesis im Fachbereich Wirtschaftswissenschaften II im Studiengang Wirtschaftsinformatik der Hochschule für Technik und Wirtschaft Berlin in Zusammenarbeit mit der adesso AGvorgelegt von: Felix MüllerMatrikelnummer: 524063eingereicht am: 9. Juni 2011Erstbetreuer: Prof. Dr. Ingo ClaßenZweitbetreuer: Prof. Dr. Harald BrandenburgBetrieblicher Betreuer: Eberhard Wolff
  2. 2. InhaltsverzeichnisAbbildungsverzeichnis IIIListingsverzeichnis IVAbkürzungsverzeichnis VIII1 Einleitung 1 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Abgrenzung zu anderen Arbeiten . . . . . . . . . . . . . . . . . . . 2 1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Grundlagen 4 2.1 Ajax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.1 Java Persistence API . . . . . . . . . . . . . . . . . . . . . . 7 2.2.2 Bean Validation . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2.3 Dependency Injection for Java . . . . . . . . . . . . . . . . . 10 2.2.4 JavaServer Faces . . . . . . . . . . . . . . . . . . . . . . . . 11 2.3 Programmiersprache Scala . . . . . . . . . . . . . . . . . . . . . . . 16 2.3.1 Klassen und Objekte . . . . . . . . . . . . . . . . . . . . . . 17 2.3.2 Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.3.3 Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.4 Pattern Matching . . . . . . . . . . . . . . . . . . . . . . . . 26 2.3.5 Self-Type Annotationen . . . . . . . . . . . . . . . . . . . . 27 I
  3. 3. Inhaltsverzeichnis 2.3.6 Implicit Conversions . . . . . . . . . . . . . . . . . . . . . . 29 2.4 Lift Web-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Methodik der Evaluation 34 3.1 Beschreibung der Evaluation . . . . . . . . . . . . . . . . . . . . . . 34 3.2 Evaluationskriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.2.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 384 Entwicklung der Beispielanwendung 40 4.1 Entwurf der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1.1 Domänenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . 42 4.2 Umsetzung mit Java EE . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.1 Domänenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.2.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . 48 4.3 Umsetzung mit Scala und Lift . . . . . . . . . . . . . . . . . . . . . 68 4.3.1 Domänenmodell . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.3.2 Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . 775 Durchführung der Evaluation 99 5.1 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 5.2 Funktionalität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 5.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1136 Fazit 122 6.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Literaturverzeichnis IXA Inhalt der CD XII II
  4. 4. Abbildungsverzeichnis 2.1 Prozessfluss des Ajax Modells von [Wik] . . . . . . . . . . . . . . . 5 2.2 Lebenszyklus einer Persistent Entity aus [Obj] . . . . . . . . . . . . 8 2.3 MVC-Architektur von JSF aus [MM10] . . . . . . . . . . . . . . . . 12 2.4 JSF Standard Request-Response-Zyklus aus [EJ10] . . . . . . . . . 13 2.5 Kontrollfluss im View-First-Ansatz von Lift aus [Per11] . . . . . . . 31 2.6 Architektur von Lift aus [DCB11] . . . . . . . . . . . . . . . . . . . 32 4.1 Domänenmodell der Beispielanwendung . . . . . . . . . . . . . . . . 41 III
  5. 5. Listingsverzeichnis 2.1 Eintragung des Faces-Servlet in der web.xml . . . . . . . . . . . . . 14 2.2 Einbinden der Namensräume der beiden Standard-Tag-Libraries . . 16 2.3 Einfache Scala Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.4 Klasse mit dazugehörigem Companion Objekt . . . . . . . . . . . . 19 2.5 Beispiel der Nutzung von Traits . . . . . . . . . . . . . . . . . . . . 20 2.6 Beispiel einer einfachen Funktion . . . . . . . . . . . . . . . . . . . 22 2.7 Beispiel der Zuweisung eines Funktionswertes . . . . . . . . . . . . 22 2.8 Anwendung einer Funktion höherer Ordnung . . . . . . . . . . . . . 22 2.9 Vollständig ausgeschriebener Aufruf von map . . . . . . . . . . . . . 23 2.10 Aufruf der map Funktion mit einem Platzhalter . . . . . . . . . . . 23 2.11 Beispiel einer Funktion mit mehreren Parameterlisten . . . . . . . . 24 2.12 Abbildung der sub Funktion auf mehrere Funktionen . . . . . . . . 24 2.13 Beispiel einer partiell angewandten Funktion . . . . . . . . . . . . . 25 2.14 Kontrollstruktur-ähnliche Konstrukte mit subTwoWith . . . . . . . 25 2.15 Bespiel von Pattern Matching in printInt . . . . . . . . . . . . . . . 26 2.16 Pattern Matching in Form einer partiellen Funktion . . . . . . . . . 27 2.17 Beispiel einer Self-Type Annotation . . . . . . . . . . . . . . . . . . 28 2.18 Beispiel einer Implicit Conversion . . . . . . . . . . . . . . . . . . . 29 4.1 JPA Grundgerüst der Java Gebäude Fachklasse . . . . . . . . . . . 43 4.2 String Attribute der Gebäude Klasse . . . . . . . . . . . . . . . . . 45 4.3 Implementierung der Beziehung zwischen Räumen und Gebäuden . 46 4.4 gebaeude Attribut in der Java Raum Fachklasse . . . . . . . . . . . 46 4.5 Anzahl der Fenster eines Raumes . . . . . . . . . . . . . . . . . . . 47 IV
  6. 6. Listingsverzeichnis4.6 Raumausstattungen in der Raum Klasse . . . . . . . . . . . . . . . 474.7 Dao Interface für den Datenbankzugriff . . . . . . . . . . . . . . . . 484.8 Spezifisches Dao Interface für die Raum Klasse . . . . . . . . . . . . 494.9 EntityManager und findById Methode des AbstractJpaDao . . . . . 494.10 configure Methode des PersistenceModule . . . . . . . . . . . . . . 504.11 Erzeugung und Konfiguration des PersistenceModules . . . . . . . . 514.12 warp-persist Servlet Filter Eintrag in der web.xml . . . . . . . . . . 514.13 Bindung der DAO Interfaces an ihre Implementierungen . . . . . . 524.14 Ablegen des Injectors im ServletContext . . . . . . . . . . . . . . . 534.15 Injection durch Guice in AbstractController . . . . . . . . . . . . . 534.16 XHTML Grundgerüst in layout.xhtml . . . . . . . . . . . . . . . . . 554.17 Auszug aus messages Datei für das de Länderkürzel . . . . . . . . . 564.18 Anzeige aller Gebäude in gebaeude.xhtml . . . . . . . . . . . . . . . 564.19 GebaeudeTableModel Eintrag in faces-config.xml . . . . . . . . . . . 574.20 TableModel Interface für die Abbildung von Tabellen . . . . . . . . 584.21 Laden aller Gebäude im GebaeudeTableController . . . . . . . . . . 594.22 Ajax Support zum Nachladen des ausgewählten Gebäudes . . . . . 594.23 GebaeudeTableSelectionHandler Eintrag in faces-config.xml . . . . . 604.24 Ereignisbehandlung in onSelectionChange . . . . . . . . . . . . . . 614.25 Anzeige der Bezeichnung des ausgewählten Gebäudes . . . . . . . . 624.26 Button Tag zum Speichern eines Gebäudes in gebaeude.xml . . . . 634.27 GebaeudeTableService Eintrag in faces-config.xml . . . . . . . . . . 634.28 Speichern des selektierten Gebäudes in AbstractTableController . . 644.29 Auszug des Tags für die Anzeige der Suchergebnisse . . . . . . . . . 654.30 Tag für den Suchbutton . . . . . . . . . . . . . . . . . . . . . . . . 664.31 Suchlogik in sucheRaeume Methode . . . . . . . . . . . . . . . . . . 664.32 Finder Methode für die Raumsuche . . . . . . . . . . . . . . . . . . 664.33 Auszug des Tags für das Löschen von Ausstattungsmerkmalen . . . 674.34 Abfragelogik, ob ein Ausstattungsmerkmal löschbar ist . . . . . . . 684.35 Finder Annotation von getAusstattungenByMerkmal . . . . . . . . 684.36 Deklaration der Scala/Lift Gebäude Fachklasse . . . . . . . . . . . 69 V
  7. 7. Listingsverzeichnis4.37 Attribute der Building Klasse . . . . . . . . . . . . . . . . . . . . . 704.38 name Attribut der Building Klasse . . . . . . . . . . . . . . . . . . 704.39 Generische Signatur einer Mapper Validierungsfunktion . . . . . . . 714.40 Signatur von valMinLen . . . . . . . . . . . . . . . . . . . . . . . . 714.41 rooms Objekt der Building Klasse . . . . . . . . . . . . . . . . . . . 724.42 Überschriebene Löschfunktion der Building Klasse . . . . . . . . . . 734.43 Companion Objekt der Building Klasse . . . . . . . . . . . . . . . . 734.44 Rückgabe des Companion Objekts in getSingleton . . . . . . . . . . 744.45 Deklaration der Scala/Lift Raum Fachklasse . . . . . . . . . . . . . 744.46 Abbildung der Referenz auf ein Gebäude in Room . . . . . . . . . . 754.47 Anzahl der Fenster in der Scala/Lift Room Klasse . . . . . . . . . . 754.48 Erweiterter Validator für Ganzzahlen vom Typ Integer . . . . . . . 754.49 Raumausstattungen in der Room Klasse . . . . . . . . . . . . . . . 764.50 isDeletable Funktion der Attribute Klasse . . . . . . . . . . . . . . 774.51 Datenbankabfrage in der findByAttribute Funktion . . . . . . . . . 774.52 Verbindungseinstellungen für die Datenbank . . . . . . . . . . . . . 784.53 Datenbanksetup der Lift Anwendung . . . . . . . . . . . . . . . . . 794.54 Initialisieren der Datenbank . . . . . . . . . . . . . . . . . . . . . . 804.55 Snippet Konfiguration und Aufbau der SiteMap . . . . . . . . . . . 804.56 Ressourceneinträge für die Sitemap . . . . . . . . . . . . . . . . . . 814.57 Lift Servlet Filter Eintrag in web.xml . . . . . . . . . . . . . . . . . 814.58 Ausschnitt des allgemeinen Templates in default.html . . . . . . . . 834.59 Ausschnitt der Tabelle zum Anzeigen von Gebäuden . . . . . . . . . 844.60 Aufbau einer Tabelle im BaseTableSnippet . . . . . . . . . . . . . . 854.61 Generierung einer Tabellenzeile zur Anzeige eines Gebäudes . . . . 864.62 Erzeugung von selektierbaren Tabellenzeilen in SelectableTableRows 884.63 Ereignisbehandlung in Buildings für einen Klick auf eine Tabellenzeile 904.64 Speichern des ausgewählten Gebäudes in der Session . . . . . . . . 904.65 Anzeige der Gebäudesbezeichnung und des Speichern Buttons . . . 914.66 Validierung der Eingaben für ein Gebäude . . . . . . . . . . . . . . 924.67 Anzeige von Fehlern durch Lift . . . . . . . . . . . . . . . . . . . . 93 VI
  8. 8. Listingsverzeichnis4.68 Speichern des ausgewählten Gebäudes . . . . . . . . . . . . . . . . . 944.69 Snippet-Funktionen für den Such-Button . . . . . . . . . . . . . . . 954.70 Snippet-Funktion für die Ausgabe der Suchergebnisse . . . . . . . . 964.71 Finder-Funktion für die Suche nach Räumen . . . . . . . . . . . . . 964.72 Tags für die Buttons zum Verwalten von Ausstattungsmerkmalen . 974.73 Bedingtes Rendern des Lösch-Button . . . . . . . . . . . . . . . . . 985.1 Exemplarische Gebäude Fachklasse mit CouchDB Anbindung . . . . 1075.2 Injector Trait von Lift für Dependency Injection . . . . . . . . . . . 1145.3 Deklaration der registerInjection Funktion . . . . . . . . . . . . . . 1155.4 Lift Dependency Injection Beispiel . . . . . . . . . . . . . . . . . . 1165.5 Dekoration mit withTransaction . . . . . . . . . . . . . . . . . . . . 1185.6 Service Trait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1195.7 Mögliche Dynamic Proxy Integration in Scala . . . . . . . . . . . . 120 VII
  9. 9. AbkürzungsverzeichnisAOP Aspektorientierte ProgrammierungAPI Application Programming InterfaceCRUD Create, Read, Update, DeleteDAO Data Access ObjectDI Dependency InjectionDSL Domain Specific LanguageHTML HyperText Markup LanguageIDE Integrated Development EnvironmentJCP Java Community ProcessJSON JavaScript Object NotationJSR Java Specification RequestXHTML eXtensible HyperText Markup LanguageXML Extensible Markup Language VIII
  10. 10. 1 Einleitung1.1 MotivationDas Entwickeln von Anwendungen für das World Wide Web gewinnt stetig anBedeutung. Bereits heutzutage verdrängen Web-Anwendungen (z.B. Google Docs)einzelne Desktop-Anwendungen. Auf mobilen Geräten sind Web-Anwendungenbereits eine wirkliche Konkurrenz zu den nativen Applikationen. Daher ist esinteressant und wichtig, Frameworks, die das Entwickeln von Web-Anwendungenerleichtern und verallgemeinern, auf die tatsächliche Einsatztauglichkeit zu prüfenund zu testen.Auf der Hauptseite des Lift Web-Frameworks wird Lift als das derzeit mächtigs-te Framework für die Entwicklung von Web-Anwendungen bezeichnet.1 Mit derProgrammiersprache Scala setzt Lift zudem eine neue Sprache für die JVM einund zeigt damit gleichzeitig den Einsatz dieser neuen Sprache in einem größerenProjekt. Aufgrunddessen wird das Lift Web-Framework in dieser Arbeit mit demetablierten Java EE Programmiermodell verglichen.1.2 Zielsetzung der ArbeitZiel der Arbeit ist es, durch den Vergleich des Lift Web-Frameworks mit dem JavaEE Programmiermodell Antworten auf mehrere Fragestellungen zu erhalten, diefolgend zusammengefasst dargelegt werden. 1 siehe http://liftweb.net 1
  11. 11. 1.3 Abgrenzung zu anderen ArbeitenLift soll aus möglichst vielen Blickwinkeln betrachtet werden, damit zum Endeder Arbeit die Vor- und Nachteile des Frameworks herausgearbeitet sind. Es giltaußerdem zu untersuchen, was die besten Einsatzbereiche des Lift Frameworkssind. Das Hauptziel ist dabei, Lift im Vergleich zum Java EE Programmiermodellzu bewerten, da dieses einen der am häufigsten eingesetzten Standards in derWeb-Entwicklung darstellt. Außerdem setzt Lift auf die Java EE Plattform auf,wie später noch erklärt wird, und tritt damit in mögliche Konkurrenz zum JavaEE Programmiermodell.1.3 Abgrenzung zu anderen ArbeitenAnders als in bisherigen Arbeiten wird Scala in dieser Arbeit nicht auf die Integrationmit bestehenden Java Anwendungen geprüft ([Kal10]) oder die Entwicklung einerWeb-Anwendung mit Scala und Lift ([TF11]) gezeigt. Im Mittelpunkt dieser Arbeitsteht der Vergleich von Scala und Lift als Technologiestack mit dem Java EEProgrammiermodell. Natürlich wurde dafür eine Beispielanwendung jeweils mitScala/Lift und Java EE entwickelt, was auch entsprechend ausführlich erläutertwird. Ebenso wird an einigen Stellen kurz die Integration mit Java angesprochen.Aber dies geschieht dann zwecks des Vergleichs und der Bewertung.1.4 Aufbau der ArbeitZu Beginn der Arbeit werden die Grundlagen der verwendeten Konzepte undeingesetzten Technologien erklärt. Dabei erfolgt eine Einführung in die Program-miersprache Scala. Allerdings kann keine vollständige Sprachdefinition gegebenwerden. Alle Sprachmittel, die zum Verständnis der Arbeit nötig sind, werdengezeigt und erläutert. Außerdem wird davon ausgegangen, dass der Leser dieserArbeit bereits mit der Sprache Java entwickelt, sodass eine Einführung in dieeingesetzten Java EE Techniken für das Verständnis ausreicht. 2
  12. 12. 1.4 Aufbau der ArbeitDanach wird die Methodik der Evaluation beschrieben. Dabei werden die ver-wendeten Methoden erläutert und die Evaluationskriterien vorgestellt. Da fürden Vergleich der beiden Technologiestacks jeweils eine Beispielanwendung ent-wickelt wurde, folgt im Kapitel 4 die Darstellung der Entwicklung. Dabei wirddie Umsetzung der Prototypen anhand von Programmcodeauszügen erläutert. An-schließend wird die Evaluation durchgeführt. Dafür werden die zuvor festgelegtenEvaluationskriterien verwendet.Zum Abschluss wird das Ergebnis der Arbeit im Fazit zusammengefasst und einAusblick gegeben, indem weitere untersuchenswerte Themen benannt werden, diedurch die Arbeit entstanden sind.Die entwickelten Beispielanwendungen liegen dieser Arbeit auf einer CD bei, derenInhalt im Anhang kurz beschrieben wird. 3
  13. 13. 2 Grundlagen2.1 AjaxDie Begrifflichkeit Ajax ist heutzutage ein gängiges Schlagwort bei der Entwicklungvon Web-Anwendungen. Damit wird ein Konzept bezeichnet, dass unter Verwendunggängiger Technologien die asynchrone Übertragung von Daten zwischen Server undClient, meistens dem Browser, ermöglicht. Ajax steht dabei für „AsynchronousJavaScript and XML“.1Web-Anwendungen, in denen Ajax eingesetzt wird, verhalten sich oftmals ähnlicheiner Desktop-Anwendung. Die Webseiten reagieren auf Interaktionen des Nut-zers flüssiger. Dies liegt daran, dass die Webseiten beim Einsatz von Ajax nichtkomplett neu geladen werden. Vielmehr werden sukzessive einzelne Seitenbereichenachgeladen. Damit dies funktioniert, wird auf Seiten des Clients eine Zwischen-schicht eingebaut, die Ajax Engine. Diese Engine ist üblicherweise eine existierendeJavaScript-Bibliothek, die die asynchrone Datenübetragung steuert.Eine Anfrage des Clients wird dabei nicht direkt an den Server gesendet, sondernüber eine Ajax Engine mittels XML, wie in Abbildung 2.1 zu sehen ist.2 Währendder Anfragebearbeitung auf dem Server kann der Client somit noch auf Nutzerin-teraktionen reagieren. Durch die Ajax Engine muss die Server-Antwort nur dienotwendigen Daten zur Änderung der Webseite enthalten, die anschließend von derAjax Engine zur Seitenaktualisierung genutzt werden.3 1 Vgl. [Wik] 2 Neben XML ist auch die Verwendung von HTML oder JSON häufig anzutreffen. 3 siehe [MM10, S. 230 ff.] 4
  14. 14. 2.2 Java EE Abb. 2.1: Prozessfluss des Ajax Modells von [Wik]2.2 Java EEDie Java Platform Enterprise Edition (Java EE) gilt umgangssprachlich als dasJava für Geschäftsanwendungen. Da in diesem Zusammenhang oft unklar ist, wasJava EE wirklich ist und wie es sich in das bestehende Java Ökosystem eingliedert,erfolgt eine Einordnung von Java EE.Oftmals wird nicht zwischen Java als Sprache und Java als Plattform unterschie-den. Wobei mit Java SE, der Java Platform Standard Edition, durchaus dieseUnterscheidung vorliegt. Java SE definiert eine Plattform, die sich aus der JavaStandardbibliothek, der Java Virtual Machine und den Entwicklungstools (z.B. derJava Compiler) zusammensetzt. Hinzu kommen viele Bibliotheken von Drittanbie-tern. Die Java Standardbibliothek implementiert dabei die Kernfunktionalitätender Programmiersprache Java und liefert eine Fülle an bereits implementiertenKlassen. Darunter sind zum Beispiel Klassen für die Entwicklung grafischer Benut-zeroberflächen, für die Kommunikation über das Netzwerk oder auch Klassen zum 5
  15. 15. 2.2 Java EEParsen von XML-Dokumenten.4„Die Java Platform, Enterprise Edition (Java EE) ist ein Aufsatz für die Java SEund integriert Pakete, die zur Entwicklung von Geschäftsanwendungen (Enterprise-Applikationen genannt) nötig sind.“5 Diese Beschreibung fasst es gut zusammen.Zusätzlich ist bei Java EE zwischen der Plattform und dem Programmiermodell zuunterscheiden. Unter Java EE als Plattform werden in dieser Arbeit die Komponen-ten der Laufzeitumgebung für Java Enterprise-Applikationen und die dafür nötigenTechnologien verstanden. So werden z.B. Anwendungen, die mit Java EE entwickeltwurden, üblicherweise in einem Application Server oder Webcontainer installiert,die als Laufzeitumgebung dienen. Java EE als Programmiermodell definiert Pro-grammierschnittstellen (APIs) und Frameworks, mit deren Nutzung mehrschichtige,lose gekoppelte und skalierbare Geschäftsanwendungen entwickelt werden.Java EE besteht dabei aus einer Vielzahl an Spezifikationen bzw. Standards, diedurch den JCP erarbeitet werden. JCP steht für den Java Community Processund bezeichnet einen Zusammenschluss von mehreren Firmen, Vereinigungen undEinzelpersonen, die in einem vorgeschriebenen Verfahren Spezifikationen für dieJava Technologie erarbeiten. Diese Spezifikationen werden Java Specification Re-quests (JSR) genannt. Dabei ist es üblich, dass durch eine Spezifikation lediglichdie abstrakte Programmierschnittstelle definiert wird und die konkreten Implemen-tierungen dafür durch mehrere Anbieter zur Verfügung gestellt werden. Dadurch istder Entwickler nicht von einem Hersteller abhängig und kann die Implementierungjederzeit austauschen.6In den folgenden Abschnitten wird auf die in der Arbeit verwendeten Spezifikationendes Java EE Programmiermodells eingegangen. 4 Vgl. [EJ10, Kapitel 2] 5 [Ull11, Kapitel 1.4.4] 6 siehe [Sta06, S. 22] 6
  16. 16. 2.2 Java EE2.2.1 Java Persistence APIDer Standard für die Persistenzabbildung in Java EE wurde mit JPA im JSR 317spezifiziert. Die Java Persistence API ist dabei zusammen mit EJB 3.0 im JSR 220entstanden.7 Zwar ist JPA eine Java EE Spezifikation, es kann aber genauso inJava SE Anwendungen eingesetzt werden.8JPA definiert unter Nutzung eines objektrelationalen Mappers das Persistierenvon Java Objekten in einer relationalen Datenbank. Dabei wird das Data MapperPattern umgesetzt. Das Data Mapper Pattern ist ein Entwurfsmuster zur Separie-rung von Objekten und der Abbildung dieser in Datenbanktabellen. Die Objektehaben im Data Mapper Pattern keine direkte Kenntniss von der Datenbank. DieAbbildung in den Tabellen wird durch einen korrespondierenden Mapper geregelt.9Die Grundkonzepte von JPA sind Persistent Entities, der Entity Manager, derPersistence Context, die Persistence Unit und der JPA Provider.Der zentrale Bestandteil von JPA sind die Persistent Entities.10 Damit werdeneinfache Java-Objekte (Plain Old Java Objects, abgekürzt POJOs) bezeichnet, dieüber die Entity-Annotation durch JPA persistierbar werden.11 Als POJO wird einJava Objekt bezeichnet, dass keine externen Abhängigkeiten zu anderen Schnitt-stellen oder Frameworks hat und somit keiner Konvention, z.B. hinsichtlich derBenennung von Klassen oder Methoden, unterworfen ist.12 Sämtliche Informationenfür die Abbildung in der relationalen Datenbank werden in der Persistent Entityüber Annotationen angegeben. Alternativ können diese Informationen in Form vonDeployment Deskriptoren beschrieben werden, was dem Vorgehen vor der Nutzungvon Annotationen entspricht. Ein Deployment Deskriptor ist ein XML Dokument, 7 EJB (Enterprise Java Beans) beschreibt ein Programmiermodell zur Entwicklung von Java Komponenten, wobei dem Entwickler die Implementierung von infrastrukturellen Code, z.B. zur Transaktionssteuerung oder Lastverteilung, abgenommen wird. (Vgl. [OI07, S. 32]) 8 siehe [Wol10, S. 189] 9 Vgl. [Fow03, S. 165 ff.]10 In der Arbeit werden für die Persistent Entities auch Synonyme wie JPA Fachklassen oder JPA Entity verwendet.11 Vgl. [OI07, S. 187 f.]12 siehe [Fow] 7
  17. 17. 2.2 Java EEdas unteranderem Meta-Informationen für Persistent Entities enthalten kann.13Das Speichern, Löschen, Laden und Suchen von Persistent Entities in einer Daten-bank übernimmt ein so genannter Entity Manager. Dabei werden die PersistentEntities von einem Entity Manager verwaltet. Mit dem Begriff Persistent Unitwerden dabei alle vom Entity Manager verwalteten Klassen bezeichnet. Im Ge-gensatz dazu werden alle vom Manager verwalteten Entities, also die Objekte derKlassen einer Persistent Unit, unter dem Begriff Persistence Context zusammenge-fasst. Dabei unterliegen die Persistent Entities einem Lebenszyklus, der durch dieVerwendung des Entity Managers bestimmt wird, wie Abbildung 2.2 zeigt.14 Abb. 2.2: Lebenszyklus einer Persistent Entity aus [Obj]Wurde eine Persistent Entity mit dem new-Operator instanziiert, befindet siesich im Zustand New. Zu dem Zeitpunkt ist die Entity nicht in der Datenbankabgebildet. Durch die persist- oder merge-Operation des Entity Managers kanndie Persistent Entity dem Persistence Context hinzugefügt werden. Dann wird dieEntity vom Entity Manager verwaltet und ist im so genannten Managed Zustand.Gleichzeitig wird die Persistent Entity dabei in der Datenbank abgebildet. Entwederwerden neue Datenbankeinträge angelegt oder bestehende aktualisiert. Je nachKonfiguration kann das auch erst beim Commit einer Transaktion oder durch denexpliziten Aufruf der flush-Methode erfolgen. Dadurch dass die Persistent Entities13 siehe [OI07, S. 189 f.]14 Vgl. [OI07, S. 194 ff.] 8
  18. 18. 2.2 Java EEim Zustand Managed sind, werden Änderungen der Attributswerte vom EntityManager registriert und mit der Datenbank synchronisiert. Mit der find-Methodedes Entity Managers können Persistent Entities aus der Datenbank geladen werden.Diese sind dann ebenfalls im Managed Zustand. Sollen Entities in der Datenbankgelöscht werden, genügt es, die remove-Methode vom Entity Manager aufzurufen.Dafür müssen die Entities jedoch im Managed Zustand sein. Wird der EntityManager geschlossen, werden sämtliche Persistent Entities entkoppelt und gelangenin den Detached Zustand.Für die Abfrage von Persistent Entities aus der Datenbank wird in JPA eineAbfragesprache definiert, die Java Persistence Query Language (JPQL). Die JPQList unabhängig von der Persistenzschicht. Das bedeutet, die Abfragen werden nichtin SQL formuliert, sondern auf Ebene der Objekte. Diese Abfragesprache ist jedochSQL-ähnlich bei der Formulierung von Abfragen. Die formulierten JPQL Abfragenwerden über den Entity Manager ausgeführt.15Da JPA lediglich eine Programmierschnittstelle spezifiziert, muss für die Ver-wendung eine Implementierung der Schnittstellen eingebunden werden. SolcheImplementierungen werden JPA Provider genannt. Für JPA in der Version 2.0 istdas Projekt EclipseLink16 die Referenzimplementierung eines JPA Providers.17 Indieser Arbeit wird jedoch Hibernate als JPA Provider eingesetzt.18Konfiguriert wird ein JPA Provider über den Deployment Deskriptor in der Dateipersistence.xml. In der persistence.xml werden die Persistence Units definiertund der Entity Manager konfiguriert. So wird dort z.B. eingestellt, zu welchemZeitpunkt Persistent Entities in die Datenbank geschrieben werden oder welcheCaching Methode verwendet wird, um die Performance der Persistenzschicht zuverbessern.1915 Vgl. [OI07, S. 300 ff.]16 siehe http://www.eclipse.org/eclipselink17 siehe dazu http://www.eclipse.org/org/press-release/20080317_Eclipselink.php18 siehe http://www.hibernate.org19 Vgl. [OI07, S. 200 ff.] 9
  19. 19. 2.2 Java EE2.2.2 Bean ValidationDer JSR 303 (Bean Validation) definiert für Java einen Standard zur Validierung vonObjekten. Dabei werden Klassen und deren Attribute mit Annotationen versehen,die die Informationen zur Validierung enthalten. Einige Annotationen werden durchden Bean Validation Standard bereits vorgegeben. Mit der Size-Annotation kannbeispielsweise die minimale und maximale Größe von Zeichenketten, Arrays undListen festgelegt werden. Möglichkeiten zur Formulierung eigener Annotationensind ebenso gegeben.20Dadurch dass die Validierungsregeln deklarativ mit Annotationen hinterlegt wer-den, ist die Ausführung der Validierung entkoppelt. Diese kann somit an mehrerenStellen in der Anwendung durchgeführt werden, z.B. im Webframework bei derEingabe von Daten in Formularen oder in der Persistenzschicht beim Speichernvon Anwendungsdaten. Der JPA Provider Hibernate bietet mit der Referenzim-plementierung des JSR 303, Hibernate Validator, unteranderem die Möglichkeit,die mit Bean-Validation-Annotationen hinterlegten Validierungsregeln im EntityManager einzusetzen und somit mit JPA zu vereinen.212.2.3 Dependency Injection for JavaWenn Anwendungen in Java entwickelt werden, bestehen diese aus vielen Klassen,die sich gegenseitig nutzen, um die erforderten Funktionalitäten umzusetzen. DieKlassen haben dadurch häufig mehrere Abhängigkeiten zu anderen Klassen. Diesemüssen aufgelöst werden. Das geschieht, indem Objekte von abhängigen Klassen amOrt ihrer Nutzung erzeugt werden oder bestenfalls bei der Erzeugung von Klassenüber den Konstruktor reingereicht werden. Das Problem bei diesem Vorgehen ist dieenge Kopplung der Klassen untereinander und die Unflexibilität bei Änderungen,z.B. beim Austausch einzelner Klassen für Testzwecke. Soll die Implementierungeiner Klasse ausgetauscht werden, müssen überall im Programmcode Änderungenerfolgen. Eine Lösung für dieses Problem ist Dependency Injection. Dabei werden20 Vgl. [Wol10, S. 250 ff.]21 siehe http://www.hibernate.org/subprojects/validator.html 10
  20. 20. 2.2 Java EEabhängige Objekte zur Laufzeit injiziert. Das Objekt, dessen Abhängigkeitenaufgelöst werden, ist passiv bei diesem Vorgang. Das hat den Vorteil, dass zumeinen große Objektnetze einfach erzeugt werden können, da die Objekte ihreAbhängigkeiten injiziert bekommen, und zum anderen ist der Austausch vonImplementierungen darüber sehr leicht möglich.22Mit dem JSR 330, Dependency Injection for Java, werden im Paket javax.injectAnnotationen zur Verfügung gestellt, die die Nutzung und Implementierung vonDI in Java standardisieren. Das Versehen von Attributen, Konstruktoren oderMethoden mit der Inject-Annotation sorgt dafür, dass die abhängigen Objektean dieser Stelle injiziert werden. Um die Dependency Injection feiner zu steuern,können die Qualifier- und Named-Annotationen verwendet werden.23 In der Arbeitwird ausschließlich die Inject-Annotation genutzt.Genau genommen zählt der JSR 330 nicht zu den Java EE Spezifikationen. Aller-dings ermöglicht die Spezifikation das Bauen von lose gekoppelten Systemen in dergesamten Java Technologie, wovon Java EE eine Teilmenge ist.2.2.4 JavaServer FacesJavaServer Faces (JSF) ist ein komponentenbasiertes Framework für die Entwicklungvon Web-Anwendungen.24 Die in der Arbeit verwendete Version 1.2 wird durchden JSR 252 spezifiziert.25 Die Referenzimplementierung von JSF ist das MojarraProjekt, welches ebenfalls in dieser Arbeit eingesetzt wird.26Das zugrundeliegende Entwurfsmuster von JSF ist das Model-View-Controller-Muster (MVC). Durch das MVC-Entwurfsmuster sollen Anwendungen mit einergrafischen Oberfläche besser strukturiert werden. Ziel ist es, die Bestandteile derAnwendung wiederverwendbarer, erweiterbarer und wartbarer zu gestalten, indem22 Vgl. [Wol10, S. 20]23 Vgl. [Wol10, S. 81 ff.]24 Vgl. [MM10, S. 6]25 siehe http://www.jcp.org/en/jsr/detail?id=25226 siehe http://javaserverfaces.java.net 11
  21. 21. 2.2 Java EEdie Daten (Model), die Darstellung (View) und das Verhalten (Controller) vonein-ander getrennt implementiert werden.27 Der Einsatz des MVC-Entwurfsmusters inJSF wird in Abbildung 2.3 gezeigt. Abb. 2.3: MVC-Architektur von JSF aus [MM10]Der Controller wird in JSF durch das Faces-Servlet implementiert. Dabei wird dieServlet Technologie der Java EE Plattform verwendet. Servlets werden durch denJSR 154 beschrieben.28 Für diese Arbeit genügt es zu wissen, dass Servlets denersten Versuch darstellten, dynamische Webseiten mit Java zu erzeugen. ServletKlassen können auf HTTP Anfragen reagieren und diese beantworten, indem sieim Java Code z.B. über Streams HTML schreiben.29 In JSF wird die ServletTechnologie nur intern verwendet. Das Faces-Servlet enthält die Steuerungslogikeiner JSF Anwendung. Dieses Servlet steuert aufgrund einer Anfrage des Clientsden Aufruf des benötigten Views und erzeugt die korrespondierenden Models.JSF unterstützt bisher zwei verschiedene View-Technologien: Facelets und JSP(JavaServer Pages). In dieser Arbeit wird Facelets verwendet. Der View wird beider Nutzung von Facelets durch XHTML-Dokumente implementiert, die spezifischeTags aus der Facelets Tag Library enthalten. Eine Tag Library ist eine Sammlungvon XHTML-Tags, die über einen eigenen XML Namensraum (engl. Namespace)27 Vgl. [Bos04, S. 45 ff.]28 sieh http://www.jcp.org/en/jsr/detail?id=15429 Vgl. [MM10, S. 2 ff.] 12
  22. 22. 2.2 Java EEeindeutig identifizierbar sind. Außerdem kann die Darstellung bei Verwendung vonFacelets modular aufgebaut werden.30Ein View bzw. eine Ansicht wird in JSF aus Komponenten zusammengesetzt. Kom-ponenten sind eigenständige und wiederverwendbare Bausteine. Beim Erzeugeneines Views wird in JSF ein Komponentenbaum erzeugt. Durch den Komponen-tenbaum werden die einzelnen Komponenten einer Ansicht miteinander verknüpft.Das Wurzelelement des Baums wird dabei durch ein Objekt der Klasse UIViewRootrepräsentiert. Die Komponenten einer Ansicht werden als Kindelemente an dasWurzelelement gehängt. Die Bearbeitung einer Anfrage, die sich in JSF in meh-rere Phasen unterteilt, wie Abbildung 2.4 zeigt, beginnt immer mit einem Aufrufeiner Methode des UIViewRoot-Elements, das den Methodenaufruf rekursiv an dieKindelemente weiterleitet. Über diesen Mechanismus kann jede Komponente einerAnsicht auf eine Anfrage reagieren.31 Abb. 2.4: JSF Standard Request-Response-Zyklus aus [EJ10]30 siehe [MM10, S. 157 f.]31 Vgl. [MM10, S. 20 ff.] 13
  23. 23. 2.2 Java EEEin weiteres wichtiges Konzept stellen die Managed Beans dar, auch Backing Beansgenannt, über die das Model in JSF implementiert wird. Managed Beans sindnormale POJOs. Sie liefern die Werte für die im View definierten Komponenten.Managed Beans können dabei verschiedene Gültigkeitsbereiche haben, die sichin der Dauer der Lebenszeit eines Managed Bean Objekts unterscheiden. In JSF1.2 ist dafür die Dauer der Requestbearbeitung, einer HTTP Session oder auchdie gesamte Dauer der Applikationsausführung möglich. Bevor ein normales JavaObjekt als Managed Bean gilt, muss ein Eintrag in der Konfiguration von JSFerfolgen.32Die Konfiguration von JSF wird in der faces-config.xml Datei formuliert. Außerdemmuss JSF in der web.xml Konfigurationsdatei eingerichtet werden. Damit eineJSF Anwendung funktioniert, muss ein Servlet Container (auch Webcontainergenannt) als Laufzeitumgebung genutzt werden.33 Ein solcher Servlet Containernutzt die Informationen aus der web.xml Datei, um z.B. Servlets zu starten. Dieweb.xml Datei ist ein Deployment Deskriptor für einen Servlet Container, eineBereitstellungsbeschreibung einer Anwendung. Das Faces-Servlet muss dort übereinen Eintrag hinterlegt werden.§ Listing 2.1: Eintragung des Faces-Servlet in der web.xml ¤< s e r v l e t> <s e r v l e t −name>Faces S e r v l e t</ s e r v l e t −name> <s e r v l e t −c l a s s> j a v a x . f a c e s . webapp . F a c e s S e r v l e t </ s e r v l e t −c l a s s> <load−on−s t a r t u p>1</ load−on−s t a r t u p></ s e r v l e t>¦ ¥Eine JSF-Anwendung wird in Form einer WAR-Datei bereitgestellt. Mit demWeb Application Archive (WAR) wird eine standardisierte Verzeichnisstruktur für32 Das gilt für JSF 1.2. Im neueren JSF 2.0 Standard ist die Definition von Managed Beans über Annotationen möglich.33 Der Servlet Container war bereits in Abbildung 2.3 in Form der Servlet Engine dargestellt, die ein Teil eines Servlet Containers ist. 14
  24. 24. 2.2 Java EEWebanwendungen in Java EE definiert. So enthält beispielsweise das VerzeichnisWEB-INF in einer WAR-Datei die Konfiguration und Seitenbeschreibungen ei-ner Web-Anwendung. Als Archivierungsformat wird das bekannte JAR-Formatverwendet.Unified Expression LanguageMit der Unified Expression Language werden die Komponenten der Ansicht unddie dahinterliegenden Managed Beans miteinander verbunden. Darüber könnenim View Daten aus den Managed Beans gelesen und in diese geschrieben werden.Weiterhin werden über Expression-Language-Ausdrücke (kurz EL-Ausdruck) Me-thoden für die Ereignisbehandlung von Komponenten im View angegeben. EinEL-Ausdruck beginnt mit einer Raute und wird von geschweiften Klammern um-schlossen. Zwischen den Klammern kann der Name einer Managed Bean stehen unddurch Punkte getrennt die Attribute der Managed Bean. Mit dem Ausdruck #{per-son.vorname} wird beispielsweise auf das Attribut vorname der Managed Beanperson zugegriffen. Ebenfalls können einfache Operationen in einem EL-Ausdruckuntergebracht werden.34Standard-KomponentenJSF bietet eine Palette an Standard-Komponenten. Das sind bereits fertige JSFKomponenten, die die Grundlage für die Entwicklung von JSF Anwendungen bilden.Die Standard-Komponenten von JSF werden in den beiden Tag Libraries HTML-Custom-Tag-Library und Core-Tag-Library implementiert und können durch dasEinbinden des jeweiligen XML Namespaces in einer View-Beschreibung genutztwerden.35Die HTML-Custom-Tag-Library im XML-Namensraum h stellt Komponenten zurHTML-Ausgabe zur Verfügung. Die Core-Tag-Library mit dem XML-Namensraumf vereint wiederum alle Basis-Komponenten, die für die Nutzung von JSF benötigt34 Vgl. [MM10, S. 36 ff.]35 Vgl. [MM10, S. 109] 15
  25. 25. 2.3 Programmiersprache Scalawerden. So wird beispielsweise mit dem f:view Tag der Core-Tag-Library derWurzelknoten eines Komponentenbaums in der Ansicht definiert.Das Einbinden der Namensräume erfolgt bei der Deklaration des HTML-Tags inder Seitenbeschreibung.§ Listing 2.2: Einbinden der Namensräume der beiden Standard-Tag-Libraries ¤<html xmlns=" h t t p : / /www. w3 . o r g /1999/ xhtml " xmlns : h=" h t t p : / / j a v a . sun . com/ j s f / html " xmlns : f=" h t t p : / / j a v a . sun . com/ j s f / c o r e ">¦ ¥RichFaces KomponentenbibliothekDie RichFaces Bibliothek erweitert die JSF Standard-Komponenten um vieleZusatzkomponenten. Außerdem implementiert RichFaces einige Komponenten mitUnterstützung für Ajax, was in JSF 1.2 noch nicht vorhanden ist. Zusätzlich dazubesteht die Möglichkeit, RichFaces Komponenten über einen Theming Mechanismusdurch eine Einstellung in der faces-config.xml im Aussehen anzupassen.2.3 Programmiersprache ScalaAn der École polytechnique fédérale de Lausanne (EPFL) in der Schweiz begann2001 eine Projektgruppe unter Leitung von Martin Odersky mit dem Entwurfeiner neuen Sprache, die objektorientierte und funktionale Programmierparadigmenvereinen sollte. Das Ergebnis dieser Arbeit wurde im Jahr 2003 mit der erstenVersion der Programmiersprache Scala veröffentlicht.36Die Namensgebung soll ausdrücken, dass Scala (aus dem Englischen scalable,skalierbar) an den Anforderungen des Entwicklers wächst.Die Programmiersprache Scala setzt auf die Java SE Plattform auf. Scala Codewird in Java Bytecode kompiliert und durch eine JVM ausgeführt. Außerdem kann36 Vgl. [Bra11, Kapitel 1] 16
  26. 26. 2.3 Programmiersprache ScalaScala interpretiert ausgeführt werden. Dazu liegt der Scala Laufzeitumgebung eininteraktiver Interpreter bei, eine so genannte REPL.37Im Gegensatz zu Java ist Scala vollständig objektorientiert. Alles ist ein Objekt,auch primitive Datentypen. Dadurch dass Scala in Java-Bytecode kompiliert wird,kann von Scala aus Java Code genutzt werden. Scala ist interoperabel mit Java. InScala steht also die gesamte Java Standardbibliothek zur Verfügung und sämtlicheandere Java Bibliotheken.In den nächsten Abschnitten werden die in dieser Arbeit eingesetzten Sprachfeaturesvon Scala erläutert.2.3.1 Klassen und ObjekteScala ist objektorientiert und unterstützt daher das Konzept der Klassen undObjekte. Wie in Java wird das Schlüsselwort class zum Definieren einer Klasseverwendet. Methoden bzw. Funktionen werden mit dem Schlüsselwort def eingeleitet.Das folgende Listing zeigt eine einfach Scala Klasse, die ein typisches Hello-World-Beispiel umsetzt.§ Listing 2.3: Einfache Scala Klasse ¤c l a s s HelloWorld ( val g r e e t i n g : S t r i n g ) { def s a y H e l l o ( ) = p r i n t l n ( g r e e t i n g )}new HelloWorld ( " H a l l o ! " ) . s a y H e l l o ( ) // Ausgabe : H a l l o !¦ ¥Mit dem new-Operator wird wie in Java eine Instanz von HelloWorld erzeugt undanschließend die Methode sayHello ausgeführt.Anders als bei Java wird in Scala der Konstruktor direkt in Form einer Parame-terliste hinter dem Klassennamen angegeben. Die HelloWorld Klasse hat einen37 Die Read-Execute-Print-Loop beschreibt einen Interpreter, der einen Befehl einliest, ausführt, das Ergebnis ausgibt und anschließend auf die nächste Befehlseingabe wartet. 17
  27. 27. 2.3 Programmiersprache ScalaParameter vom Typ String, greeting. Die Typangabe erfolgt in Scala nach der An-gabe des Bezeichners und mit einem Doppelpunkt getrennt. Mit dem Schlüsselwortval wird greeting als unveränderbares Feld definiert. Das ist mit der Verwendungvon final in Java vergleichbar. Soll greeting veränderbar sein, wird das Schlüsselwortvar anstalle von val verwendet.Die Sichtbarkeit von sayHello ist automatisch public. Anders als in Java habenMethoden und Felder standardmäßig nicht die Sichtbarkeit friendly, sondern public.Mit den Zugriffsmodifizierern private und protected kann die Sichtbarkeit wie inJava eingestellt werden.Die Methode sayHello hat nur eine Aufgabe: den mit greeting übergebenen Wertauf dem Standardausgabestrom ausgeben. Dazu wird die Methode println desPredef -Objektes aufgerufen. Das Predef -Objekt wird automatisch vom Compilerin jede Scala-Datei importiert und stellt oft benötigte Funktionen zur Verfügung.38Obwohl Scala statisch typisiert ist, muss der Rückgabetyp von sayHello nichtangegeben werden, da Scala über einen Typinferenz-Mechanismus verfügt. Darüberkann der Compiler feststellen, welchen Typ ein Wert im Aufrufkontext hat. Indiesem Fall, wird der Typ Unit hergeleitet, vergleichbar mit dem void Typ in Java.Da println lediglich eine Zeichenkette auf dem Standardausgabestrom ausgibt, wirdder Typ Unit zurückgegeben.Aufgrund der funktionalen Natur von Scala hat alles in Scala einen Wert. Andersals in Java muss zum Zurückgeben eines Wertes nicht return verwendet werden, esgilt der Wert des letzten Ausdrucks eines Programmblocks als Rückgabewert.Neben der Typinferenz verfügt Scala ebenfalls über eine Semikoloninferenz. Semi-kolons sind in Scala nicht notwendig, um das Ende eines Befehls zu signalisierenund werden größtenteils weggelassen.Ein Scala eigenes Sprachmittel sind Singleton Objekte.39 Die Idee des Singletonsentstammt einem Entwurfsmuster, bei dem von einer Klasse genau eine Instanz38 Außerdem werden dort auch wichtige Typ-Synonyme und Implicit Conversions definiert.39 Die Begriffe Objekt und Singleton werden in dieser Arbeit als Synonyme für den Begriff der Singleton Objekte verwendet. 18
  28. 28. 2.3 Programmiersprache Scalaexistiert und ein globaler Zugriff darauf.40 Scala verallgemeinert dieses Muster mitder Nutzung des Schlüsselworts object und unterstützt es direkt in der Sprache.In Singleton Objekten werden in Scala statische Werte und Methoden implemen-tiert. Statische Methoden mit dem Schlüsselwort static wie in Java zu definieren,ist nicht möglich. Hierbei trennt Scala zwischen nicht-statischen und statischenProgrammcode-Teilen. Sollen einer Klasse statische Felder oder Methoden hinzuge-fügt werden, existiert in Scala dafür das Companion Objekt, welches im folgendenListing für das Hello-World-Beispiel implementiert ist. An der Implementierungder HelloWorld-Klasse ändert sich dabei nichts.§ Listing 2.4: Klasse mit dazugehörigem Companion Objekt ¤c l a s s HelloWorld ( val g r e e t i n g : S t r i n g ) { def s a y H e l l o ( ) = p r i n t l n ( g r e e t i n g )}object HelloWorld { def apply ( ) = new HelloWorld ( " Standard Meldung " ) def sayHi ( ) = p r i n t l n ( " Hi ! " )}HelloWorld ( ) . s a y H e l l o ( ) // Ausgabe : Standard MeldungHelloWorld . sayHi ( ) // Ausgabe : Hi !¦ ¥Ein Companion Objekt ist ein spezielles Singleton Objekt, das den gleichen Na-men wie eine Klasse hat und sich in der selben Quellcode-Datei befindet. ImCompanion Objekt HelloWorld werden zwei Methoden definiert, apply und say-Hi. Die sayHi Methode stellt eine normale statische Methode dar, die über denNamen des Companion Objekts aufgerufen werden kann. Die abgebildete apply-Methode ist eine Besonderheit bei der Nutzung von Companion Objekten. Mit40 Vgl. [EG95, S. 127] 19
  29. 29. 2.3 Programmiersprache Scalader apply-Methode existiert eine eingebaute Fabrik-Methode in Scala. In einerapply-Methode wird eine Instanz der Klasse des Companion Objektes erzeugt undzurückgegeben. Der Vorteil dabei ist, Scala erlaubt das Weglassen des Aufrufs derapply-Methode. So kann HelloWorld().sayHello() geschrieben werden, was vomCompiler zu HelloWorld.apply().sayHello() erweitert wird. Die apply-Methode kannnatürlich beliebige Parameter aufnehmen.2.3.2 TraitsEin neues Sprachmittel, dass mit Scala eingeführt wird, sind Traits, die die aus Javabekannten Interfaces ersetzen. Ein Trait ist mit einem Java Interface vergleichbar.Allerdings mit dem Unterschied, dass Traits neben der Deklaration von Methodenauch Implementierungen beinhalten können. Ein Trait wird mit dem Schlüsselworttrait definiert, wie im folgenden Listing zu sehen ist.§ Listing 2.5: Beispiel der Nutzung von Traits ¤t r a i t HasName { val name = "Name von etwas "}t r a i t HasAge { def c a l c u l a t e A g e : I n t}c l a s s Person extends HasName with HasAge { def c a l c u l a t e A g e = 18 override val name = "Name e i n e r Person "}¦ ¥ 20
  30. 30. 2.3 Programmiersprache ScalaWie bei der Klasse Person zu sehen ist, können Klassen mehrere Traits implemen-tieren. Der erste Trait wird immer mit extends hinzugefügt, alle folgenden mitdem Schlüsselwort with. Scala unterstützt allerdings keine Mehrfachvererbung. Eshandelt sich dabei um einen so genannten Mixin-Mechnismus. Ein Mixin ist einewiederverwendbare Einheit, die zusammengehörige Funktionen bündelt.41 In diesemZusammenhang wird auch vom Einmixen eines Traits gesprochen. Mögliche Proble-me, die bei Mehrfachvererbung auftreten, wie z.B. das Diamond Problem, werdenbei Traits mit Hilfe von Linearisierung umgangen. Dabei werden die eingemixtenTraits und Klassen der Vererbungshierarchie in der Reihenfolge des Einmixen inForm einer Liste aufeinander gelegt, wodurch Methoden, die in unterschiedlichenTypen mehrfach definiert sind, für den Compiler auflösbar bleiben.42Im Listing 2.5 ist außerdem zu erkennen, dass in Scala mit override ein speziellesSchlüsselwort für das Überschreiben von Methoden und Feldern existiert. DacalculateAge noch keine Implementierung in HasAge hat, ist override bei dieserMethode nicht notwendig. Es kann jedoch angegeben werden.2.3.3 FunktionenDa Scala neben den objektorientierten Programmierparadigmen ebenfalls funktio-nale Paradigmen einschließt, sind Funktionen einer der wichtigsten Bestandteileder Sprache. Funktionen sind in Scala so genannte First Class Values, auch FirstClass Citizens genannt, was bedeutet, sie werden als Werte behandelt und könnenals solche Variablen zugewiesen werden oder als Parameter anderen Funktionenübergeben werden. Ebenso ist es möglich, dass Funktionen andere Funktionen alsRückgabewert zurückgeben.43Eine Funktion wird mit dem Schlüsselwort def definiert, was bereits in den voran-gegangenen Abschnitten gezeigt wurde. Alternativ dazu besteht die Möglichkeit,Funktionen über Funktionsliterale zu definieren Das folgende Listing zeigt die41 Vgl. [Bra11, S. 84]42 siehe [MO08, Kapitel 12.6]43 Vgl. [Bra11, Kapitel 5.2] 21
  31. 31. 2.3 Programmiersprache ScalaFunktion dec, die über def angelegt wird und anschließend alternativ als Funkti-onsliteral.§ Listing 2.6: Beispiel einer einfachen Funktion ¤def dec ( i : I n t ) = i − 1// F u n k t i o n s l i t e r a l f ü r dec( i : Int ) = i − 1 >¦ ¥Ein Funktionsliteral wird dabei mit einem Doppelpfeil angegeben.44 Links davonsteht die Parameterliste der Funktion und rechts davon die Befehle der Funktion.Beide Schreibweisen erzeugen das gleiche Ergebnis. Der Vorteil des Funktionsliteralsist, dass eine Funktion darüber sehr einfach als Wert zugewiesen werden kann,was im Listing 2.7 zu sehen ist. Ebenfalls wird durch Funktionsliterale die Angabeanonymer Funktionen erleichtert.§ Listing 2.7: Beispiel der Zuweisung eines Funktionswertes ¤val d e c F u n c t i o n = ( i : I n t ) = i − 1 >p r i n t l n ( d e c F u n c t i o n ( 4 ) ) // Ausgabe : 3¦ ¥Funktionen höherer OrdnungMit dem Begriff der Funktionen höherer Ordnung werden Funktionen bezeichnet,bei denen Parameter oder der Rückgabewert aus einer Funktion bestehen. Das istein hilfreiches Mittel zur Abstraktion von allgemeinem Verhalten, wie das folgendeListing zeigt.45§ Listing 2.8: Anwendung einer Funktion höherer Ordnung ¤def dec ( i : I n t ) = i − 1def d e c L i s t ( l i s t : L i s t [ I n t ] ) = l i s t map dec44 Der Doppelpfeil setzt sich aus einem Gleichheitszeichen und einem Pfeil zusammen.45 siehe [Bra11, Kapitel 5.3] 22
  32. 32. 2.3 Programmiersprache Scalap r i n t l n ( d e c L i s t ( L i s t ( 1 , 2 , 3 ) ) ) // Ausgabe : L i s t ( 0 , 1 , 2 )¦ ¥In der Funktion decList wird die Dekrementierungsfunktion dec auf alle Elementeder übergebenen Liste angewendet. Dazu wird die Funktion höherer Ordnungnamens map verwendet. Die map Funktion gehört zur Collections API von Scala.map wendet die übergebene Funktion dec auf alle Elemente der Liste an und gibtdie dadurch neu enstandene Liste als Ergebnis zurück. In der decList Funktionkommen gleich mehrere Scala-Besonderheiten zum Einsatz, die den Aufruf vonmap verkürzen. In der vollen Länge wird map hier wie folgt aufgerufen.§ Listing 2.9: Vollständig ausgeschriebener Aufruf von map ¤l i s t . map ( ( i : I n t ) = dec ( i ) ) >¦ ¥In dieser Form macht das Funktionsliteral, das map als Parameter übergebenwird, deutlich, dass es sich um eine Funktion höherer Ordnung handelt. Durch dieTypinferenz kann Int in der Parameterliste des Funktionsliterals weggelassen werden.Da dec ledigleich einen Parameter erwartet, kann die Angabe des Parameters iebenfalls entfallen. Der Scala Compiler setzt dann einen automatisch generiertenPlatzhalter an der Stelle für i ein. Dieser Platzhalter hätte auch explizit mit einemUnterstrich angegeben werden können.§ Listing 2.10: Aufruf der map Funktion mit einem Platzhalter ¤l i s t . map( dec (_) )¦ ¥Als weitere Möglichkeit der Vereinfachung wird abschließend die Infix-Operator-Schreibweise46 für Funktionen verwendet, wodurch der in Listing 2.8 gezeigte Aufrufder map Funktion zustandekommt. Da Operatoren in Scala auch nur Methodenvon Klassen sind, kann die Infix-Operator-Schreibweise bei Funktionen verwendetwerden.4746 Dabei steht ein Operator zwischen seinen zwei Operanden.47 Vgl. [MO08, Kapitel 5.3] 23
  33. 33. 2.3 Programmiersprache ScalaBeim Aufruf von decList in der println Methode wird das Companion Objekt vonList genutzt und intern die apply-Methode aufgerufen. Denn der Aufruf List(1, 2,3) wird vom Compiler zu List.apply(1, 2, 3) erweitert.CurryingUnter Currying wird das Abbilden einer Funktion mit mehreren Parametern, aufmehrere Funktionen mit je einem Parameter verstanden. In Scala gilt dies ebensofür Funktionen mit Parameterlisten. Dadurch können Funktionen mit mehrerenParameterlisten definiert werden, wie das folgende Listing zeigt.48§ Listing 2.11: Beispiel einer Funktion mit mehreren Parameterlisten ¤def sub ( x : I n t ) ( y : I n t ) = x − yp r i n t l n ( sub ( 2 ) ( 3 ) ) // Ausgabe : −1¦ ¥Die Auflösung einer solchen Funktion durch den Compiler kann wie folgt veran-schaulicht werden.§ Listing 2.12: Abbildung der sub Funktion auf mehrere Funktionen ¤def sub ( x : I n t ) = ( y : I n t ) = x − y >¦ ¥Die sub Funktion hat nur noch eine Parameterliste und in der Funktion selbst wirdein Funktionsliteral mit der zweiten Parameterliste definiert. Der Aufruf dieserFunktion gestaltet sich genauso, wie von der in Listing 2.11 gezeigten Funktion.Partielle FunktionenBei den partiellen Funktionen muss zwischen den partiellen und den partiell ange-wandten Funktionen unterschieden werden.Eine partielle Funktion ist eine Funktion, die nicht für alle Werte ihres Definitions-bereichs definiert ist.49 Anwendungen solcher Funktionen werden im nachfolgenden48 siehe [Bra11, Kapitel 5.5]49 Vgl. [Bra11, S. 124] 24
  34. 34. 2.3 Programmiersprache ScalaKapitel über Pattern Matching gezeigt. Mit dem Trait PartialFunction existierenaußerdem Hilfsfunktionen, um beispielsweise zu bestimmen, ob eine Funktion füreinen bestimmten Wert ihres Definitionsbereichs definiert ist.50Eine partiell angewandte Funktion hingegen ist eine Funktion, die auf einen Teilihrer Parameter bereits angewendet ist.51 Es ist häufig der Fall, dass partiellangewandte Funktionen zusammen mit Currying eingesetzt werden, indem eineParameterliste bereits angewendet wird und eine weitere zur Aufnahme zusätzlicherParameter dient. Im folgenden Beispiel wird die sub Funktion aus dem Listing 2.11partiell angewendet und einem Wert zugewiesen.§ Listing 2.13: Beispiel einer partiell angewandten Funktion ¤val subTwoWith = sub ( 2 ) _p r i n t l n ( subTwoWith ( 3 ) ) // Ausgabe : −1¦ ¥Der Unterstrich dient hierbei als Platzhalter für die zweite Parameterliste. DieSignatur der in subTwoWith gespeicherten Funktion lautet Int => Int. Es wirddabei also eine neue Funktion mit nur einer Parameterliste erzeugt, die intern aufdie sub Funktion zugreift.Die wirkliche Stärke dieses Sprachmittels wird deutlich, wenn anstatt des einfachenParameters mit dem Zahlenwert 3 eine Funktion verwendet wird, wie im folgendenListing.§ Listing 2.14: Kontrollstruktur-ähnliche Konstrukte mit subTwoWith ¤p r i n t l n ( subTwoWith { val n i n e = 4 + 5 val s i x = 2 + 4 nine − s i x})¦ ¥50 Die Funktion dafür lautet isDefinedAt.51 Vgl. [MO08, S. 147] 25
  35. 35. 2.3 Programmiersprache ScalaDas Ergebnis dieses Aufrufs von subToWith ist das gleiche wie im vorangegangenenListing. Durch die Verwendung der geschweiften Klammern und der Formulierungeines Funktionsblocks wirkt die Verwendung von subTwoWith wie eine Scala-eigeneKontrollstruktur. Solche Konstrukte sind bei der Verwendung von Scala häufiganzutreffen.2.3.4 Pattern MatchingPattern Matching kann für einen Java Entwickler als Erweiterung der Switch-Case-Kontrollstruktur erklärt werden. Beim Pattern Matching wird ein Wert mitMustern verglichen. Die Besonderheit bei Scala ist, dass nicht nur Werte als Musterangegeben werden können, sondern auch Typen.52 Eine einfache Anwendung vonPattern Matching zeigt das folgende Beispiel.53§ Listing 2.15: Bespiel von Pattern Matching in printInt ¤def p r i n t I n t ( i : I n t ) = i match { case 1 = p r i n t l n ( " Eins " ) > case 2 = p r i n t l n ( " Zwei " ) > case _ = p r i n t l n ( " e i n e a n d e r e Zahl " ) >}p r i n t I n t ( 2 ) // Ausgabe : Zwei¦ ¥Mit dem Schlüsselwort match wird ein Pattern-Matching-Ausdruck eingeleitet undin diesem Fall auf den Parameter i angewendet. Mit case werden die einzelnen Mus-ter definiert, gegen die i verglichen wird. Der Doppelpfeil leitet den Codeblock ein,der ausgeführt wird, sollte das jeweilige Muster passt. Nachdem ein Muster gepassthat, kehrt die Ausführung aus dem Match-Ausdruck zurück. Der Rückgabewertentspricht dem des ausgeführten Codeblocks.Mit dem Unterstrich wird das Wildcard-Pattern definiert, das auf jeden Wert undTypen passt. Wird das Wildcard-Pattern weggelassen, ist der Match-Ausdruck52 siehe [Bra11, Kapitel 5.4]53 in Anlehnung an [Bra11, S. 115] 26
  36. 36. 2.3 Programmiersprache Scalamitunter nicht für alle Werte des Definitionsbereichs definiert. Ist ein solcher Match-Ausdruck die einzige Anweisung einer Funktion, wird die Funktion zur partiellenFunktion, wie das folgende Listing zeigt.54§ Listing 2.16: Pattern Matching in Form einer partiellen Funktion ¤def printType ( v a l u e : Any) = v a l u e match { case i : I n t = p r i n t l n ( " I n t : " + i ) > case d : Double = p r i n t l n ( " Double : " + d ) >}printType ( 2 ) // Ausgabe : I n t : 2¦ ¥Die printType Funktion verwendet für den Mustervergleich Typen. Außerdemist diese Funktion eine partielle Funktion, da sie nur für Int und Double Typendefiniert ist, obwohl der Definitionsbereich Any ist. Any ist der Basistyp des Scala-Typsystems. Wird printType beispielsweise mit einer Zeichenkette aufgerufen, wirdzur Laufzeit ein MatchError erzeugt, da die Funktion für den String-Typ nichtdefiniert ist.2.3.5 Self-Type AnnotationenSelf-Type-Annotationen ermöglichen es, den Typ des this Wertes explizit zu dekla-rieren. Dadurch können Funktionalitäten einer Klasse modular verteilt in mehrerenTraits implementiert werden oder aber ein Trait kann Abhängigkeiten festlegen,die seine Funktionen benötigen und durch das Einmixen in die richtigen Klassenaufgelöst werden.55 Ein Beispiel für den Einsatz einer Self-Type Annotation wirdim folgenden Listing gezeigt.5654 in Anlehnung an [Bra11, S. 116]55 siehe [Bra11, S. 160 ff.]56 entnommen aus [Bra11, S. 161] 27
  37. 37. 2.3 Programmiersprache Scala§ Listing 2.17: Beispiel einer Self-Type Annotation ¤trait Noise { def makeNoise : Unit}t r a i t Food { def e a t : Unit}t r a i t Animal { t h i s : N o i s e with Food => def run = { makeNoise eat makeNoise }}¦ ¥Eine Self-Type-Annotation wird zu Beginn einer Typ-Definition formuliert. Siebesteht dabei aus dem Schlüsselwort this,57 der Typangabe, die gewohnt mit einemDoppelpunkt vom Bezeichner getrennt wird und einem Doppelpfeil. Dadurchdass der Animal Trait die Self-Type Annotation Noise with Food hat, kann ernur in Klassen eingemixt werden, die diese beiden Traits ebenfalls einmixen undimplementieren. Animal kann außerdem auf die Methoden (und Felder) von Noiseund Food zugreifen.57 Alternativ kann auch self verwendet werden. Da this jedoch deutlicher aussagt, dass der Typ des this Wertes überschrieben wird, ist diese Variante zu bevorzugen. 28
  38. 38. 2.3 Programmiersprache Scala2.3.6 Implicit ConversionsMit Implicit Conversions können in Scala Typumwandlungen in Form von Methodendefiniert werden. Wird eine Methode mit dem vorangestellten Schlüsselwort implicitdefiniert, gilt sie als Implicit Conversion.Erwartet der Compiler ein Objekt eines bestimmten Typs, findet jedoch ein Objekteines inkompatiblen Typen vor, sucht er nach einer Implicit Conversion. Findetder Compiler eine passende Umwandlung, führt er die Methode aus. Durch diesesSprachmittel können in Scala bestehende Klassen um zusätzliche Funktionenerweitert werden. Das wird auch als Pimp-my-Library-Pattern bezeichnet.58 Wieeinfach die Nutzung von Implicit Conversions ist, zeigt das nachfolgende Listing.§ Listing 2.18: Beispiel einer Implicit Conversion ¤c l a s s F a n c y S t r i n g ( val s t r : S t r i n g ) { def d o F a n c y S t u f f = s t r + " f a n c y "}object F a n c y S t r i n g { i m p l i c i t def s t r i n g T o F a n c y S t r i n g ( s t r : S t r i n g ) : F a n c y S t r i n g = new F a n c y S t r i n g ( s t r )}import F a n c y S t r i n g ._p r i n t l n ( " H a l l o " . d o F a n c y S t u f f ) // Ausgabe : H a l l o f a n c y¦ ¥Die Klasse String der Java Standardbibliothek wird hierbei durch FancyStringund die im Companion Objekt implementiere Typumwandlung um die MethodedoFancyStuff erweitert. Obwohl diese Methode nicht in der String Klasse definiertist, kann sie dadurch an einem String Objekt aufgerufen werden. Vor dem Aufrufvon doFancyStuff wird der Compiler das String-Objekt „Hallo“ dafür mit Hilfe58 siehe http://www.artima.com/weblogs/viewpost.jsp?thread=179766 29
  39. 39. 2.4 Lift Web-Frameworkvon stringToFancyString in ein Objekt des Typs FancyString umwandeln. Damitdie Implicit Conversion vom Compiler gefunden wird, importiert die Anweisungimport FancyString._ die Felder und Methoden von FancyString.2.4 Lift Web-FrameworkIm Jahr 2007 startete die Entwicklung von Lift. Das Lift Framework ist ein inScala entwickeltes Framework zur Entwicklung von Web-Anwendungen. Es istein so genanntes Full-Stack Web-Framework. Das bedeutet, neben Funktionenzur Erzeugung von Webseiten werden z.B. auch Funktionalitäten zum Speichernder Anwendungsdaten in einer Datenbank angeboten oder für die Validierungder Nutzereingaben. Ohne die Nutzung anderer Bibliotheken kann mit Lift einekomplette Web-Anwendung entwickelt werden.Lift baut auf bewährte Konzepte anderer Web-Frameworks auf und versucht diesezu vereinen. So wird beispielsweise der Ansatz der Convention over Configurationbefolgt, der vom Web-Framework Ruby on Rails59 inspiriert wurde. Mit Conventionover Configuration soll der Aufwand und die Komplexität der Konfiguration undNutzung des Frameworks gesenkt werden, indem sinnvolle Vorgaben und Annahmenvom Framework über die Nutzung getroffen werden, wie z.B. eine vorgegebeneVerzeichnisstuktur.Lift ist allerdings kein MVC-Framework wie JSF.60 In Lift wird ein selbstdefiniertesEntwurfsmuster verwendet. Die Lift-Entwickler verfolgen den View-First-Ansatzfür den Entwurf von Web-Anwendungen, wobei ein als View-ViewModel-Modelbeschreibbares Entwurfsmuster eingesetzt wird, das in Abbildung 2.5 zu sehen ist.61Der View-First-Ansatz besagt, dass in der Beschreibung der Seitendarstellungausschließlich valide Standard XHTML-Tags verwendet werden und wurde durch59 siehe http://rubyonrails.org60 Wobei MVC mit Lift sehr wohl umsetzbar ist. Das hat der Hauptentwickler von Lift, David Pollak, exemplarisch gezeigt. (siehe dazu [Pol, Kapitel 12 und 13])61 Vgl. [Per11, S. 7 f.] 30
  40. 40. 2.4 Lift Web-Framework Abb. 2.5: Kontrollfluss im View-First-Ansatz von Lift aus [Per11]das Java Web-Framework Wicket62 inspiriert. In Lift wird ein View daher in Formvon XML-Dokumenten beschrieben, die bestenfalls ausschließlich Standard XHTMLTags enthalten.Snippets sind das wichtigste Konzept von Lift. Als Snippet wird eine Funktionbezeichnet, die XML-Knoten transformiert.63 Snippets sind das ViewModel imView-First-Ansatz und sorgen für die Generierung von dynamischen Seiteninhalten.Dabei verbinden sie den View mit dem Model, das die Fachentitäten der Anwendungdarstellt. Dabei kann ein View durchaus mehrere Snippets nutzen. Im Gegensatzzum View können Snippets zustandsbehaftet sein. Auch wenn das Snippet in derAbbildung 2.5 wie ein Controller gemäß dem MVC-Muster aussieht, ist es das nicht.Ein Snippet übernimmt nicht die Steuerung des Kontrollflusses.Außerdem baut das Lift Framework auf der Java EE Plattform auf. Über die ServletTechnologie integriert sich Lift in Java EE Webcontainer, was unteranderem inAbbildung 2.6 dargestellt wird. Wie eine JSF-Anwendung werden Lift-Anwendungenin Form von WAR-Dateien bereitgestellt.62 siehe http://wicket.apache.org63 In der Arbeit werden teilweise auch die Klassen als Snippet bezeichnet, die eine solche Funktion enthalten. 31
  41. 41. 2.4 Lift Web-Framework Abb. 2.6: Architektur von Lift aus [DCB11]Lift implementiert mehrere Persistenzlösungen. Die Standard-Persistenzlösungnennt sich Mapper. Die Mapper Bibliothek implementiert unter Nutzung des ActiveRecord Patterns die Abbildung von Objekten in einer relationalen Datenbank.Beim Active Record Pattern befindet sich die Logik für den Datenbankzugriff imDomänenobjekt. Außerdem repräsentiert ein Domänenobjekt bei Active Recordeinen Datenbankeintrag.64 Gleichzeitig ist Mapper, wie es der Name bereits andeutet,ein objektrelationaler Mapper. Die Doppeldeutigkeit von Mapper als Umsetzung desActive Record Patterns und objektrelationaler Mapper ist auf die Art und Weise derImplementierung zurückzuführen. Lift Mapper Funktionalitäten werden mit Traitsin die Domänenobjekte eingemixt. Dadurch ist die Logik für den Datenbankzugriffzwar in den Domänenobjekten, aber implementiert wird sie separiert in den Mapper64 Vgl. [Fow03, S. 160 f.] 32
  42. 42. 2.4 Lift Web-FrameworkTraits. Intern nutzt Mapper die Java SE Datenbankschnittstelle JDBC (JavaDatabase Connectivity).65Zusätzlich bietet Lift eine Abstraktionsschicht für Ajax und JavaScript, wodurchJavaScript-Befehle und Ajax Aufrufe in reinem Scala-Code formuliert werdenkönnen. Dabei wird intern die JavaScript-Bibliothek JQuery66 eingesetzt. Alternativkann YUI67 verwendet werden.65 Vgl. [Per11, S. 13]66 siehe http://jquery.com67 siehe http://developer.yahoo.com/yui 33
  43. 43. 3 Methodik der Evaluation3.1 Beschreibung der EvaluationFür die Evaluation der beiden Technologiestacks werden folgende zwei Methodeneingesetzt: • Literaturstudium • Umsetzung einer prototypischen BeispielanwendungDurch das Literaturstudium wird der Blick in die Interna der jeweiligen Frameworksermöglicht. Dieser wäre ohne ein solches Studium nicht möglich. Die alleinige Im-plementierung einer prototypischen Anwendung führt zwar zur Auseinandersetzungmit der API der jeweiligen Technologie. Jedoch sind dadurch nicht zwangsläufigdie internen Mechanismen geklärt. Mögliche Stärken und Schwächen, die sich nichtdurch die Nutzung der API zeigen, würden somit auch nicht in die Evaluationeinfließen.Die Ergebnisse aus dem Literaturstudium werden beim Vergleich der beiden imple-mentierten Lösungen eingebracht.Die wichtigste Grundlage für die Evaluation ist die Entwicklung einer prototypischenBeispielanwendung. Für jeden Technologiestack wird ein Prototyp für die imAbschnitt 4.1.2 formulierten Anwendungsfälle entwickelt. Der Fokus liegt dabei aufdem Einsatz der jeweiligen Frameworkspezifika und nicht auf der bestmöglichenUmsetzung der Anforderungen. Die implementierten Prototypen sind nicht für denproduktiven Einsatz vorgesehen. 34
  44. 44. 3.2 Evaluationskriterien3.2 EvaluationskriterienDie Evaluation wird anhand von Evaluationskriterien durchgeführt, um das Ergebnismöglichst objektiv und für den Leser transparent zu gestalten.Die Auswahl der Evaluationskriterien für diese Arbeit orientiert sich an gängigenStandards und Erkenntnissen der Softwareentwicklung sowie den Erfahrungswertendes Autors. Dabei spielen ebenso einfache Faktoren wie die reine Funktionalitäteine Rolle als auch Faktoren, die die Struktur und den Aufbau des Programmcodesbetreffen.3.2.1 AllgemeinesBeim Vergleich von Technologien und Frameworks gibt es allgemeingültige Kriterienwie z.B. die Integration in die Entwicklungswerkzeuge, die bei jedem Vergleichanwendbar sind.DokumentationBeschäftigt sich ein Entwickler mit Technologien, so wird eine gute Dokumentationerwartet. Die Dokumentation sollte dabei eine Spezifikation der API enthalten,als auch beschreibende Anleitungen zu Anwendungsfällen. Ebenso zählt zur Doku-mentation das Vorhandensein von Büchern zur Einführung und Vertiefung in dieTechnologie.Im Verlauf der Entwicklung der Prototypen hat sich gezeigt, dass es sehr wohl Unter-schiede in der Qualität und Quantität der Dokumentationsmaterialien gibt. Daherwird bei diesem Kriterium die Dokumentation der Technologiestacks beurteilt.LernkurveEignen sich Softwareentwickler Kenntnisse über neue Sprachen und Frameworksan, gibt es eine so genannte Lernkurve. Unter der Lernkurve wird der nötige 35
  45. 45. 3.2 EvaluationskriterienLernaufwand verstanden, der zum Erreichen eines bestimmten Ergebnisses nötigist.Der Autor hat Java EE im November 2010 kennengelernt. Für diese Arbeit hat erScala und Lift gelernt. Daher sind die Ergebnisse zur Lernkurve reine Erfahrungs-werte, die einen Eindruck vermitteln sollen, in welchem Verhältnis die Lernaufwändefür die beiden Technologiestacks stehen.ToolchainDie Toolchain bezeichnet umgangssprachlich die Werkzeugkiste eines jeden Soft-wareentwicklers. Damit sind die Programme gemeint, die der Entwickler für seineArbeiten einsetzt. Im heutigen Entwicklungsgeschäft ist es wichtig, dass sich dieeingesetzen Techniken reibungslos in die Toolchain integrieren lassen. Dies steigertdie Produktivität und ist somit von großer Bedeutung.Es gilt bei der Toolchain zu untersuchen, in welchem Maße sich die jeweiligenFrameworks in die eingesetzten Programme integrieren lassen und welche Vor- undNachteile durch diese Integration entstehen.3.2.2 FunktionalitätBei der Entwicklung von Web-Anwendungen treten oft ähnliche Anforderungenan die verwendeten Frameworks und Technologien auf. Daher werden die beidenentwickelten Lösungen auf die Unterstützung der im folgenden Abschnitt beschrie-benen Funktionalitäten untersucht und bewertet. Die Auswahl dieser Kriterienwurde maßgeblich durch [Wan08] beeinflusst.PersistenzmechanismenHeutzutage kommt keine Web-Anwendung ohne einen entsprechenden Persistenz-mechanismus aus. Die Daten der Anwendung und des Nutzers müssen für die Dauereiner Sitzung und über die Laufzeit der Anwendung hinweg gespeichert werden. 36
  46. 46. 3.2 EvaluationskriterienEs wird untersucht, welche Persistenztechnologien die Frameworks unterstützenund gezeigt, wie der so genannte objektrelationale Mismatch gelöst wird. Aufgrundder Verschiedenheit Daten objektorientiert und relational abzubilden, gibt es beider Persistierung eines objektorientierten Domänenmodells in eine releationaleDatenbank eine Unverträglichkeit; einen Mismatch, den es zu lösen gilt.1 Weiterhinwird die Umsetzung in den jeweiligen Lösungen aufgrund der Integration in dasbestehende Domänenmodell und der Funktionalität bewertet.DarstellungskonzeptJede Anwendung stellt die Daten für den Nutzer auf dem Bildschirm in irgend-einer Form dar. Frameworks bieten unterschiedliche Konzepte, wie diese Ansichtaufzubauen und mit dem Rest der Anwendung zu verbinden ist.Hier gilt es zu untersuchen, wie naht- und reibungslos sich die unterschiedlichen Dar-stellungskonzepte mit den anderen Anwendungsteilen verbinden lassen. Ebenfallswird aufgezeigt, welche Vor- und Nachteile die unterschiedlichen Ansätze bieten.Ajax-UnterstützungIn den letzten Jahren hat sich Ajax als Technologie für hochgradig interaktiveAnwendungen durchgesetzt. Dabei werden Inhalte vom Server asynchron in Formvon XML durch den Client nachgeladen. Dies geschieht für den Nutzer transparentim Hintergrund. Ein Neuladen der Seite ist nicht erforderlich.Die eingesetzten Frameworks werden daraufhin untersucht und bewertet, inwiefernAjax unterstützt wird und welche Qualität die Ajax-Integration aufweist.ValidierungDie Validierung von Nutzereingaben ist in jeder Anwendung wichtig. Die Eingabenmüssen auf bewusst falsche Angaben und fachliche Inkonsistenzen geprüft werden. 1 Vgl. [Röd10, Kapitel 1] 37
  47. 47. 3.2 EvaluationskriterienFür die Validierung wird bewertet, wie sich die formulierten Validierungsregelnin das Domänenmodell einpflegen lassen, welche Möglichkeiten zur Validierungdurch das Framework bereits angeboten werden und wie sich die Validierung in dieanderen Frameworkteile integriert.InternationalisierungWeb-Anwendungen werden nicht ausschließlich in der Muttersprache des Kundenausgeliefert. Da diese Anwendungen in den meisten Fällen von Nutzern unterschied-licher Sprachen genutzt werden, sind die Beschriftungen und Texte so zu gestalten,dass sie dynamisch ladbar sind. Abhängig von der Spracheinstellung des Nutzerswird die Anwendung in einer anderen Sprache dargestellt.Es gilt zu untersuchen, welche Mechanismen die Technologiestacks für diese Formder Internationalisierung von Anwendungen zur Verfügung stellen und wie sichdiese in die Anwendung integrieren.3.2.3 ArchitekturLaut [Bal01] kann Softwarearchitektur als „eine strukturierte oder hierarchischeAnordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“ defi-niert werden. Dem zugrundeliegend werden die beiden Technologiestacks aufgrundarchitekturspezifischer Funktionalitäten bewertet. Dabei wird bewertet, welcheFunktionen existieren, um Enterprise-Anwendungen strukturiert und lose gekoppeltzu entwickeln.Lose KopplungBei der Komplexität heutiger Anwendungen ist es von großer Bedeutung, Objekt-netze flexibel aufzubauen. Dabei steht die lose Kopplung einzelner Komponentenund einfache Konfiguration dieser im Vordergrund. Unteranderem soll dadurch dieTestbarkeit eines Systems verbessert werden. 38
  48. 48. 3.2 EvaluationskriterienEs gilt zu untersuchen, welche Möglichkeiten und Funktionalitäten die Frameworksfür die lose Kopplung eines Anwendungssystems anbieten.Cross Cutting ConcernsIn Softwaresystemen gibt es so genannte Querschnittsbelange (engl. Cross CuttingConcerns), die mit herkömmlicher objektorientierter Programmierung ohne Verlet-zung des DRY-Prinzips nicht umsetzbar sind.2 Querschnittsbelange werden auchorthogonale Belange genannt. Dies sind z.B. Funktionalitäten wie Tracing,3 Trans-aktionssteuerung oder Exception Handling. Solche Funktionen sind in irgendeinerForm in jeder Anwendungsschicht vorhanden. Sie befinden sich orthogonal zu denAnwendungsschichten. So finden sich z.B. in vielen Methoden eines Anwendungs-systems Programmzeilen, die für das Tracing verantwortlich sind. Dadurch wirdCode mit gleicher Funktionalität regelmäßig in den einzelnen Methoden dupliziert.Dies widerspricht dem DRY-Prinzip. Dieses besagt „Don’t Repeat Yourself“ undist ein Grundprinzip guter Softwareentwicklunng.Es wird untersucht, ob es Möglichkeiten gibt, diese Querschnittsbelange separatvom Anwendungscode zu formulieren. Wenn dies nicht möglich ist, wird diskutiert,welche anderen Arten der Implementierung existieren und wie gehaltvoll diese sind. 2 Vgl. [Wol10, S. 100 f.] 3 Tracing bezeichnet das detaillierte Loggen von Methoden. In den allermeisten Fällen wird dabei der Methodeneintritt mit den übergebenen Parameter sowie der Austritt geloggt. 39
  49. 49. 4 Entwicklung der Beispielanwendung4.1 Entwurf der AnwendungFür den Vergleich des Scala/Lift Technologiestacks mit dem Java EE Programmier-modell wird eine prototypische Raumverwaltungssoftware entwickelt. Der Nutzerist mit dieser Software in der Lage, Gebäude mit Räumen zu verwalten. Dabei giltdie Vorgabe, dass für die Verwaltung der Gebäude und Räume so wenige Seitenwie möglich aufzurufen sind. Bestenfalls existiert eine Seite pro Anwendungsfall.4.1.1 DomänenmodellDas Domänenmodell einer Anwendung beschreibt die fachlichen Entitäten einerProblemlösung und die Beziehungen dieser untereinander. Bei der zu entwickeln-den Raumverwaltungsanwendung besteht das Domänenmodell aus vier Entitäten:Gebäuden, Räumen, Ausstattungen der Räume und Ausstattungsmerkmalen. DieAbbildung 4.1 zeigt das Domänenmodell der Beispielanwendung. Zusätzlich existie-ren Regeln für die zulässigen Werte einiger Attribute.Sämtliche Bezeichnungen dürfen nicht leer sein. Das heißt, die Zeichenkettenmüssen mindestens ein Zeichen enthalten und Null ist ebenfalls nicht als Wertzulässig. Des Weiteren sind sämtliche Zahlen als positive ganze Zahlen abzubilden,Primärschlüssel ausgeschlossen. 40
  50. 50. 4.1 Entwurf der AnwendungAbb. 4.1: Domänenmodell der Beispielanwendung 41
  51. 51. 4.1 Entwurf der Anwendung4.1.2 AnwendungsfälleEin Anwendungsfall beschreibt ein mögliches Szenario für die Nutzung eines An-wendungssystems. Die Beispielanwendung behandelt drei Anwendungsfälle: dieVerwaltung von Gebäuden, die Suche nach Räumen und das Verwalten von Aus-stattungsmerkmalen.Gebäude verwaltenDer Hauptanwendungsfall ist das Verwalten von Gebäuden. Dabei soll der Nutzerneue Gebäude anlegen, Veränderungen an Gebäudedaten speichern und existierendeGebäude löschen können. Dies gilt natürlich ebenfalls für die Räume der Gebäudeund Ausstattungen der Räume.Räume suchenDer Nutzer soll die Möglichkeit haben, nach Räumen mit einem bestimmtenAusstattungsmerkmal zu suchen. Dabei kann der Benutzer die Wahl treffen zwischenallen vorhandenen Ausstattungsmerkmalen.Ausstattungsmerkmale verwaltenEin Raum kann mehrere Raumaustattungen besitzen. Eine Raumaustattung istdabei die Zuordnung eines Ausstattungsmerkmals mit einer Menge zu einem Raum.Diese Ausstattungsmerkmale soll der Nutzer ebenfalls verwalten können. Dabeigilt die Vorgabe, dass Ausstattungsmerkmale nur gelöscht werden dürfen, wenndiese bei keinem Raum in einer Raumausstattung verwendet werden. Andernfallswürden bestehende Daten fehlerhaft. Das Hinzufügen und Verändern bestehenderAusstattungsmerkmale soll ebenso möglich sein. 42
  52. 52. 4.2 Umsetzung mit Java EE4.2 Umsetzung mit Java EEDie Java EE Implementierung der Beispielanwendung setzt JSF 1.2 mit Faceletsals View-Technologie ein. Für die Persistenzschicht wird JPA 2.0 mit Hibernate alsJPA Provider verwendet.4.2.1 DomänenmodellDas Domänenmodell wird im Paket de.htw.berlin.jroomyweb.domain entwickelt.Dabei wird für jede fachliche Entität eine Klasse implementiert. Ein Gebäude wirdalso durch die Klasse Gebaeude repräsentiert, wie das folgende Listing zeigt.§ Listing 4.1: JPA Grundgerüst der Java Gebäude Fachklasse ¤@Entitypublic c l a s s Gebaeude implements S e r i a l i z a b l e { @Id @GeneratedValue private Long i d ; protected Gebaeude ( ) { // f ü r JPA } public Long g e t I d ( ) { return i d ; } public void s e t I d ( Long i d ) { this . id = id ; }}¦ ¥ 43
  53. 53. 4.2 Umsetzung mit Java EEDa die Objekte der Domänenschicht mittels JPA in einer relationalen Datenbankpersistiert werden, hat jede Fachklasse die Entity-Annotation. Diese Annotationkennzeichnet für JPA eine Klasse, die auf eine Datenbank abzubilden ist. Weiterhinfällt auf, dass Gebaeude das Interface Serializable implementiert. Das SerializableInterface kennzeichnet Klassen, die serialisierbar sind. Damit ist das Abbilden einesObjektes der Klasse auf einen Bytestrom oder anderes Übetragungsformat (z.B.XML) gemeint. Für die reine Persistierung über JPA ist das nicht notwendig. Jedochist es eine Best-Practice, im Java EE Kontext die JPA Fachklassen serialisierbar zumachen. Sollte die Anwendung in einem verteilten System eingesetzt werden, kannes vorkommen, dass Objekte der Domänenschicht zwischen verschiedenen Servernhin- und hergeschickt werden. Dafür müssen die Objekte serialisiert werden. DasSpeichern von Domänenobjekten in der HTTP Session eines Nutzers kann ebenfallsdas Serialisieren für die Zwischenspeicherung auf der Festplatte des ApplicationServers zur Folge haben.Alle Domänenobjekte werden mit einer eindeutigen Identifikationsnummer gespei-chert. Diese entspricht dem Primärschlüssel in der Datenbank. Daher hat dieGebaeude Fachklasse ein id Attribut. Dieses ist mit einer Id-Annotation versehen,die den Primärschlüssel der Objekte für die Abbildung in der Datenbank kennzeich-net. Außerdem wird mit der GeneratedValue-Annotation festgelegt, dass der Wertvon id automatisch durch JPA generiert wird. In den meisten Konfigurationen be-wirkt dies das Anlegen einer automatisch hochzählenden Datenbankspalte.1 Damitein JPA Provider auf das id Attribut von Gebaeude zugreifen kann, muss ein sogenanntes Getter-Setter-Methodenpaar implementiert werden. Diese Vorgabe derGetter-Setter-Zugriffsmethoden gilt für alle Attribute, die durch JPA persistiertwerden.Die Verwendung von JPA in der Gebaeude Klasse verlangt des Weiteren die Imple-mentierung eines Konstruktors mit einer leeren Parameterliste. Das ist notwendig,da ein JPA Provider Objekte von Gebaeude über die Java Reflections API erzeugt,indem dieser leere Konstruktor aufgerufen wird, und die Gebaeude Objekte z.B.anschließend über die Setter-Methoden mit den Daten aus der Datenbank befüllt. 1 Oftmals wird dafür der Terminus AUTO_INCREMENT verwenden. 44
  54. 54. 4.2 Umsetzung mit Java EEDa die Gebaeude Klasse einen Konstruktor mit einer nicht leeren Parameterliste hat,der den Default-Konstruktor von Java überdeckt, musste dieser leere Konstruktorzusätzlich fomuliert werden.2 Um zu verhindern, dass ein Gebaeude Objekt uner-laubter Wise im Programmcode über diesen leeren Konstruktor erzeugt wird, hater die Sichtbarkeit protected und ist damit nur im Paket der Fachklassen sichtbar.Alle Attribute von Gebaeude werden durch die Nutzung von JPA automatisch inder Datenbank abgebildet.3 So auch die vier String-Attribute der Gebäude Entitätaus dem Domänenmodell, wie das folgende Listing zeigt. Nicht abgebildet, sind dieobligatorischen Getter- und Setter-Methoden.§ Listing 4.2: String Attribute der Gebäude Klasse ¤@NotEmpty ( message= " Der Name e i n e s Gebäudes d a r f n i c h t l e e r s e i n . " )private S t r i n g b e z e i c h n u n g ;private S t r i n g s t r a s s e ;private S t r i n g p l z ;private S t r i n g o r t ;¦ ¥Das Domänenmodell verlangt, dass sämtliche Bezeichnungen nicht leer sein dürfen.Daher wurde das Attribut bezeichnung mit NotEmpty annotiert. Die NotEm-pty-Annotation ist eine Erweiterung des Bean Validation Standards und stehtdurch die Nutzung der Hibernate Validator Bibliothek zur Verfügung. Durch dieAnnotation wird festgelegt, dass bezeichnung weder den Wert Null noch eine Zei-chenkette einer Länge kleiner 1 aufnehmen kann. Mit dem message Attribut derNotEmpty-Annotation wird die Fehlernachricht angegeben, die bei Verletzung derValidierungsregel ausgegeben wird.Die Fehlernachrichten von Bean-Validation-Annotationen sind zusätzlich überRessourcendateien lokalisierbar. Dazu muss mindestens eine ValidationMessa-ges.properties Datei im Klassenpfad abgelegt werden, die in Schlüssel-Wert-Paaren 2 Der Konstruktor mit der nicht leeren Parameterliste ist in dem Listing aus Gründen der Übersicht nicht dargestellt ist. 3 Sollen einzelne Attribute nicht persistiert werden, sind diese mit @Transient zu annotieren. 45
  55. 55. 4.2 Umsetzung mit Java EEVariablen und ihren Wert enthält. Mit dem Ausdruck {Variablenbezeichner} kannein Wert im message Attribut einer Bean-Validation-Annotation geladen werden.Über Länder- und Sprachkürzel als Suffix des Dateinamen können einzelne Valida-tionMessages_xx_XX.properties Dateien für bestimmte Sprachen definiert werden.Das wurde im Prototypen jedoch nicht implementiert.Die 1-n Beziehung zwischen Gebäuden und Räumen wird in der Gebaeude Klassedurch ein Set implementiert. Ein Raum wird in der Java EE Lösung durch diegleichnamige Klasse Raum repräsentiert.§ Listing 4.3: Implementierung der Beziehung zwischen Räumen und Gebäuden ¤@OneToMany( c a s c a d e=CascadeType . ALL, mappedBy=" gebaeude " )private Set<Raum> raeume = new HashSet<Raum>() ;¦ ¥Durch das Annotieren des raeume Sets mit OneToMany wird die Art der Beziehungdefiniert. Die zwei Attribute, cascade und mappedBy, konfigurieren diese Beziehung.Über das cascade Attribut der OneToMany-Annotation werden kaskadierendeOperationen eingestellt. Das heißt, ist das umgebene Gebaeude Objekt durcheine JPA Operation, wie z.B. das Speichern oder Löschen in der Datenbank,betroffen, wird diese Operation auf alle Raum Objekte in raeume angewendet.In diesem Fall werden durch die Angabe von CascadeType.ALL alle Operationenkaskadierend auf das Set raeume angewendet. Das zweite Attribut, mappedBy,betrifft die Abbildung der Beziehung in der Datenbank. Darüber wird definiert, dassdie Beziehung in der Datenbank durch die Spalte des gebaeude Attributs der RaumKlasse abgebildet wird. Dies entspricht der Speicherung eines Fremdschlüssels in derRaum Tabelle auf die ID Spalte der Gebäude Tabelle. Damit diese Konfigurationüber mappedBy funktioniert, wird das gebaeude Attribut der Raum Klasse mitManyToOne annotiert.§ Listing 4.4: gebaeude Attribut in der Java Raum Fachklasse ¤@ManyToOne( o p t i o n a l=f a l s e )private Gebaeude gebaeude ;¦ ¥ 46

×