Fuhrparkverwaltung - Architekturbeschreibung - im Studiengang Application Architectures / Master of Science an der Fakultät Wirtschaftsinformatik der Hochschule Furtwangen University vorgelegt von: Michael Hupe, Florian Kalisch, Andreas Lauer, Denis Radjenovic Vorlesung : Softwarearchitektur Betreuer : Prof. Dr. Ulf Schreier eingereicht am : 30.06.2012 / Sommersemester 2012
44
Embed
Fuhrparkverwaltung - ArchitekturbeschreibungGeschäftslogikschicht: Die Geschäftslogikschicht ist in Java mit simplen POJOs (Plain Old Java Objects) umgesetzt. Datenzugriffsschicht:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Fuhrparkverwaltung
- Architekturbeschreibung -
im Studiengang Application Architectures / Master of Science
an der Fakultät Wirtschaftsinformatik der Hochschule Furtwangen University
vorgelegt von:
Michael Hupe, Florian Kalisch, Andreas Lauer,
Denis Radjenovic
Vorlesung : Softwarearchitektur
Betreuer : Prof. Dr. Ulf Schreier
eingereicht am : 30.06.2012 / Sommersemester 2012
I
Inhaltsverzeichnis
1 Einführung und Ziele ......................................................................................................... 1
1.1 Ziele des Dokuments ................................................................................................... 1
Tabelle 1: Festlegung der verwendeten Sprachen ....................................................................... 3 Tabelle 2: Tabellenkonventionen in JPA ................................................................................. 19 Tabelle 3: Logging Level und ihr Einsatz ................................................................................ 31 Tabelle 4: Vergleich JSF und Play .......................................................................................... 38
IV
Listing-Verzeichnis
Listing 1: Einbindung der main.scala.html ................................................................................ 9
Listing 2: Definition der übergebenen Parameter ....................................................................... 9
Listing 3: Einbinden von Parameter innerhalb der Views ........................................................... 9
Listing 4: Prüfung ob DOM aufgebaut ist ................................................................................. 9
Listing 5: Einbinden des Datepickers ........................................................................................ 9
Zur Generierung wird auf die Scala-Notation zurückgegriffen, bei welcher mit einer for-Schleife über die anzuzeigenden Datenzeilen iteriert und jede relevante Spalte ausgegeben wird. Dieses Vorgehen zeigt das nachfolgende Listing.
'_label -> "Wo endet die Fahrt?", '_showConstraints -> false,
'onchange -> "calcRoute()")
</li>
Listing 16: Aufruf der Funktion calcRoute()
3.2.6 CSS
Alle CSS-Files werden unter „Public/Stylesheets“ abgelegt und in der „main.scala.html“ einge-
bunden. Es wird ein eigenständiges CSS entwickelt um das Look & Feel der Anwendung zu ver-
bessern und vereinheitlichen. Weiterhin kommt es zur Einbindung von eigenständigen CSS-
Dateien für die Datatables und jQuery UI Elemente.
In den Views selber ist es nicht gestattet CSS-Code direkt einzubinden. CSS-Elemente müssen
aussagekräftige Bezeichnungen besitzen.
3.2.7 HTTP-Routing und Controller-Handling
Alle Seiten, die über den Webbrowser erreicht werden sollen müssen unter „conf/routes“ einge-tragen werden und auf die entsprechende Controller-Funktion verweisen. Die Einbindung erfolgt
Beispielhaft wie im
Listing 17.
GET /URI controllers.ControllerName.controllerMethod1()
POST /URI controllers.ControllerName.controllerMethod2()
GET /URI/:id controllers.ControllerName.controllerMethod3(id:Long)
Listing 17: Abbildung von HTTP-Routen auf Controller-Methoden
Im Controller wird geregelt was dann im speziellen Fall mit der REST-Anfrage geschieht und
welche Daten an die View übertragen werden sollen.
Folgendes Listing zeigt die beispielhafte Implementierung eines Controllers. Zur Vereinfachung
der Auswertung von Formulareingaben bietet Play eine Kapselung der HTTP-Anfrage in eine
extra hierfür implementierte Form-Klasse. Durch diese Funktionalität werden die jeweiligen
Formularfelder auf die entsprechenden Attribute der Form-Klasse abgebildet. Bevor mit der
Form-Klasse im Controller gearbeitet werden kann, muss diese auf Eingabefehler überprüft wer-
den. Das kann über die Methode „hasErrors()“ realisiert werden. Als Rückgabewert dient eine
Folgende Abbildung zeigt die Struktur der Datenbank der Fuhrparkverwaltung. Sichtbar werden
hier die Komponenten „reservation“, „location“, „vehicle“, „user“, „role“ und „driver_license“.
Außerhalb dieser Komponenten befinden sich vom Persistenzframework automatisch erstellte
Tabellen (z.B. „vehicle_purpose“), welche Many-to-many-Beziehungen abbilden. Falls in Zu-
kunft weitere Tabellen dazu kommen, sollten diese einer der bestehenden Komponente zugeord-
net werden, um die vorhandene Struktur beizubehalten.
Abbildung 15: Datensicht
30
5 Querschnittliche Systemaufgaben
Hier wird beschrieben, wie allgemeine und querschnittliche Systemaufgaben behandelt und gelöst
werden.
5.1 Sicherheit
Eine wichtige Aufgabe ist die Absicherung der Anwendung, so dass nur authentifizierte Nutzer
diese benutzen können. Diese muss bis auf die einzelnen Controller heruntergebrochen werden,
da sie mittels URLs angesteuert werden und bei nicht ordnungsgemäßer Absicherung eine Si-
cherheitslücke darstellen. Bewerkstelligt wird das durch die folgende Play-Annotation, mit wel-
cher jede Controller-Klasse annotiert werden muss.
@Security.Authenticated(Secured.class)
Listing 30: Authensisierungs-Annotation
Dadurch wird bei jedem Zugriff auf einen Controller zuerst die Klasse „Secured“ aufgerufen.
Darin befindet sich die überschriebene Methode „getUserName(…)“, mit der die Session auf
Informationen geprüft wird. Sind diese Informationen nicht vorhanden, wird der Nutzer über die
Methode „onUnauthorized(…)“ auf die Anmeldeseite weitergeleitet. Im anderen Fall wird dem
angemeldeten Nutzer die Controller-Funktionalität bereitgestellt.
5.2 Transaktionsmanagement
Das Standard-Persistenzframework Ebeans verwendet implizite Transaktionen. Somit müssen
Datenbankoperationen nicht explizit als Transaktionen definiert werden. EBeans kümmert sich
automatisch um Transaktionsoperationen wie „commit“ oder „roll-back“.
Sollte jedoch der Bedarf an expliziten Transaktionen bestehen, kann dies über verschiedene Mög-
lichkeiten erzielt werden:
@Transactional
public static Result save() {
...
}
Listing 31: Beispiel @Transactional
Durch die Annotation „@Transactional“ kümmert sich EBeans um die automatische Ausfüh-
rung der Transaktion im Rahmen der ausgeführten Methode oder Klasse.
Die folgende Art entspricht der programmatischen Methode von „@Transactional“:
Ebean.execute(new TxRunnable() {
public void run() {
// durchzuführende Transaktion
}
});
Listing 32: Beispiel TxRunnable
Beide Varianten können ohne Probleme gemischt werden.
31
Die letzte Art beschreibt die klassiche Variante mit try-finally-Block:
Ebean.beginTransaction();
try {
// fetch some stuff...
User u = Ebean.find(User.class, 1);
...
// save or delete stuff...
Ebean.save(u);
...
Ebean.commitTransaction();
} finally {
Ebean.endTransaction();
}
Listing 33: Beispiel Transaktion mit try-finally
Der Standard Isolation Level von Ebeans ist „READ_COMMITTED“. Um diesen zu ändern
muss in der obigen Methode die Transaktion beispielsweise mit „Ebe-
an.beginTransaction(Transaction.SERIALIZABLE)“ gestartet werden.
5.3 Protokollierung
Die Protokollierung von Ereignissen erfolgt standardmäßig in der Datei „application.log“. Alle
auftretenden Ausnahmen werden hier protokolliert. Sollen explizit bestimmte Ereignisse (z.B. das fehlerhafte Anmelden eines Nutzers) aufgezeichnet werden, kann dies über die Klasse „play.Logger“ erfolgen. Diese Klasse bietet unterschiedliche Stufen an:
Stufe Anwendungsgebiet
Logger.debug() Soll sehr intensiv für Debug und Entwicklerinformationen verwendet wer-den. Information. Diese werden im produktiven Umfeld nicht ausgegeben.
Logger.error()
Deutet auf einen Bug oder eine generelle Fehlerbedingung hin. Es muss sich dabei aber nicht unbedingt um einen Fehler handeln, welcher das Sys-tem zum Absturz bringt.
Logger.fatal() Ist in extremen Situationen einzusetzen.
Logger.info()
Der Einsatz ist für grundlegende Informationen gedacht. Kann vor und nach Code, welcher eine sehr lange Ausführungszeit besitzt, verwendet werden, um festzustellen, was die Anwendung gerade macht. Die Ausga-bemeldungen auf dieser Stufe sollten nicht allzu ausführlich sein.
Logger.warn()
Fehlfunktionen, die sich nicht negativ auf die Ausführung oder das zu er-wartende Resultat bezieht. Z.B. fehlende Konfiguration – es wird mit Defaultwerten weitergearbeitet.
Tabelle 3: Logging Level und ihr Einsatz
Je nach Situation ist der passende Logging-Level auszuwählen. Als Parameter der Methoden dienen ein String, welcher eine Nachricht aufnimmt und bei Bedarf, die Ausnahme, die geworfen wird. Das Mitübergeben der Ausnahme ist anzustreben.
32
5.4 Ausnahmebehandlung
Eine umfassende Fehlerbehandlung ist Merkmal und integraler Bestandteil einer Anwendung mit
hoher Qualitätsgüte. Dementsprechend wichtig ist die Vorgabe von Richtlinien in der Architek-
turbeschreibung, so dass die Ausnahmebehandlung konsequent und mit Verzicht auf Antipat-
terns umgesetzt werden kann.
Als Konsequenz aus dem Einsatz von Java auf Seiten des Backends, ergibt sich, dass die Java-
Typischen Ausnahmekategorien vorzufinden sind:
„checked exception“:
Diese Ausnahmen stellen ein erkanntes Problem dar, welches während der normalen Sys-
temausführung aufgetreten ist. Dabei kann es sich beispielsweise um fehlerhafte Benut-
zereingaben handeln. Eine der beiden nachfolgenden Reaktionen darauf ist möglich:
o Erneuter Versuch zu einem späteren Zeitpunkt
o Erneuter Versuch mit korrigierten Parametern
„unchecked exception“:
Diese Ausnahmen weisen auf ein unerwartetes Problem hin, welches sehr wahrscheinlich
durch einen Bug im Quellcode hervorgerufen wird.
Allgemein ist als Regel festzuhalten:
Wenn der Client-Code nichts zur Fehlerbehebung beitragen kann, dann ist eine „unche-
cked exception“ zu wählen.
Kann der Client-Code fehlerbehebende Maßnahmen auf Grundlage der Exception-
Information durchführen, dann ist eine „checked exception zu wählen“.
Die Frage ob ein Verhalten jetzt eine Ausnahme ist oder nicht muss immer im Kontext beurteilt
werden. Leitgedanke soll sein, dass wann immer möglich keine Implementierungsdetails nach
außen gegeben werden (Exception Wrapping).
Um die Aussagekraft der Ausnahmen zu erhöhen, sollen nach Möglichkeit „Nested-Exceptions“
verwendet werden. Den fachlichen Ausnahmen sind aussagekräftige Fehlermeldungen zuzuord-
nen. Eine strikte Trennung zwischen der eigentlichen Fehlermeldung und der Klasse der Aus-
nahmen sorgt für Transparenz und kann wie folgt erzielt werden:
Die Fehlermeldung dient dem Benutzer.
Die Fehlerklasse dient der Implementierung, um eventuell mit Hilfe von try-catch spezi-
fisch darauf zu reagieren.
Alle Ausnahmen, die auftreten können, müssen mit der in Kapitel 5.3 dargestellten Maßnahmen
protokolliert werden, damit eine spätere Analyse möglich ist.
Beispiel zum Protokollieren einer Ausnahme beim Parsen eines Datums:
33
public Date parseDateString(String date, String time) {
Date newDate = null;
try {
newDate = DATE_FORMAT.parse(date + " " + time);
} catch (ParseException e) {
Logger.error("Fehler beim parsen des Datums", e);
}
return newDate;
}
Listing 34: Beispiel für Ausnahmebehandlung
Die nachfolgende Beschreibung stellt existierende Anti-Patterns in Bezug auf die Ausnahmebe-
handlung dar. Diese sind zu vermeiden.
Log and Throw
catch (NoSuchMethodException e) {
LOG.error("Fehlermeldung", e);
throw e;
}
Listing 35: Beispiel Log an Throw
Obige Abbildung zeigt ein Beispiel für diese Art. Ein Loggen und gleichzeitiges Werfen der Aus-
nahme findet statt und ist eine der lästigsten Verwendungen, welche sich sehr negativ für den
Support und die Fehlerbehebung auswirken. Entweder sollte die Ausnahme aufgezeichnet oder
geworfen, aber nicht beides, werden.
Das Werfen von Exceptions
Ein Werfen der abstrakten Fehlerklasse Exception sagt lediglich aus, dass ein Fehler aufgetreten
ist, führt zu keinem Mehrgewinn an Information und ist zu vermeiden.
Das Werfen mehrerer „checked exceptions“
public void myFunction() throws MyException,
NotherExpression, YetAnotherException
{
}
Listing 36: Beispiel "checked Exception"
Das Werfen mehrerer, ähnlicher, Ausnahmen ist ebenfalls zu vermeiden und sollte über ein Kap-
seln (Wrapping) in einer eigenen Ausnahmeklasse vollzogen werden.
Destruktives Wrapping
catch (NoSuchMethodException e) {
throw new MyException("Error Message: " +
e.getMessage());
}
Listing 37: Beispiel Destruktives Wrapping
In jedem Fall ist diese Art Fehlerbehandlung zu vermeiden, da der Stack Trace zerstört wird.
34
5.5 JNDI
Falls die Datenbank per JNDI veröffentlicht werden soll, kann dies wie folgt geschehen:
db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:play"
db.default.jndiName=DefaultDS
Listing 38: Datenbank über JNDI veröffentlichen
Durch diese Methode wird die In-Memory Datenbank des Play Frameworks über den Name
DefaultDS im JNDI bekannt gemacht. Diese Methode kann mit jeder beliebigen angebundenen
Datenbank geschehen.
35
6 Alternativen
Dieses Kapitel Begründet, aus welchem Grund die einzelnen Bibliotheken, welche zum Einsatz
kommen, gewählt wurden, gibt eine Bewertung zu diesen ab und führt mögliche Alternativen an.
6.1 jQuery
Im Bereich der Client-Seitigen Bibliotheken gibt es sehr viele mögliche Alternativen. Die
Grundintension dieser besteht darin, die durch JavaScript vorgegebene Funktionalitäten, mit dem
Ziel der einfacheren Handhabung und browserübergreifenden und einheitlichen Ausführung, zu
kapseln.
Durch die hohe Vielzahl an vorhandenen Bibliotheken fällt die Auswahl nicht leicht. Der Einsatz
von jQuery ist aus folgenden Gründen sinnvoll:
Innerhalb des Open-Source Segments die am meisten verwendete Bibliothek
Leichte Einarbeitung möglich – viel qualitativ hochwertige Literatur vorhanden
Weist eine offene PlugIn-Architektur auf, wodurch beliebige Entwickler aus der Open-
Source Community an der Weiterentwicklung partizipieren können. Dies beschleunigt
die Verbesserung und Weiterentwicklung der jQuery Funktionalität.
Im Open Source Bereich existiert keine nennenswerte Alternative. Was in Erwägung gezogen
werden kann, wenn man auch die Bibliotheken unter kommerzieller Lizenz mit einbeziehen
möchte, ist ExtJS ab der Version 4.0. Ein Look-And-Feel, das einer Desktop-Anwendung nahe
kommt, sowie umfangreiche AJAX Unterstützung und eine MVC basierte (über REST angebun-
dene) Oberfläche wird geboten. Hauptsächlich der MVC bedingte Overhead und die Komplexität
der Bibliothek führte zu dem Entscheid, diese Bibliothek nicht einzusetzen.
6.2 Play Framework
Dieses Unterkapitel evaluiert das Play Framework in Bezug auf die Eignung für die Entwicklung
von Enterprise Applications. Dies ist notwendig, da die Architekten und Entwickler noch keine
Expertise darin besitzen und vor der Bewertung keine Aussage dazu treffen können.
6.2.1 Business-Sicht
Die Entwicklung von heutigen Enterprise Anwendungen sieht sich mit zwei hauptsächlichen
Herausforderungen konfrontiert:
1. Time-To-Market
Die Zeit zwischen Projektstart und der Einführung des Produkts am Markt, wird immer
wichtiger.
2. Skalierbarkeit
Ein weiterer wichtiger Aspekt moderner Anwendungen, ist die mögliche Skalierbarkeit
und Ausfallsicherheit. Bei höherer Last sollten mehr Ressourcen zur Verfügung stehen.
Die Auswahl eines geeigneten Frameworks kann nicht immer ganz autark - ohne Einbeziehung
des Projektkontexts - getroffen werden. Viele Faktoren, wie die Art des zu entwickelnden Front-
ends, das Backend und andere existierende Systeme (Integrationsaspekte) müssen mit berücksich-
tigt werden. So ist beispielsweise bei einem existierenden, komplexen, JavaEE Backends der Ein-
satz von Java Server Faces (JSF) sehr naheliegend.
36
Das Fuhrparkverwalngssystem baut auf keinen existierenden Systemen auf, so dass die Wahl
eines geeigneten Frameworks ohne Berücksichtigung von Einflussfaktoren getroffen werden
kann.
Welcher Play Framework wurde sehr schnell sehr bekannt. Da es noch sehr jung ist, lassen sich
keine repräsentativen Referenzapplikation für eine Bewertung heranziehen. Lediglich die nach-
folgend dargestellten Projekte zeigen, dass es bereits Produktivanwendungen gibt, die mit dem
Play Framework entwickelt wurden:
Französisches Job-Portal „Express Board“:
Dieses Job-Portal5 für Frankreich stellt eine Plattform für die Vermittlung von Jobs aus
dem Bereich der Softwareentwicklung zwischen Unternehmen und Technik-Freaks und
Enthusiasten dar. Die Realisierung geschah mit Play.
Plancruncher:
Die Webanwendung Plancruncher6 dient der einfachen Erstellung kurzer Businesspläne,
anhand eines Wizards. Auch diese Umsetzung erfolgte mit dem Play Framework.
Webseite des Play Frameworks:
Die Webseite des Play-Frameworks basiert selbst auf dem Play Framework und ist etwas
repräsentativer in Bezug auf Enterprise Anwendungen. Dies wird deutlich, wenn man
sich Zugriffszahlen betrachtet. So liegen die Zugriffszahlen bei 100.000 Zugriffen pro Tag,
welche ohne Performanzprobleme möglich sind.
6.2.2 Technische Sicht
Nachdem drei Echtanwendungen vorgestellt wurden, soll sich die Beurteilung des Play Frame-
works in Bezug auf den Einsatz für Enterprise Anwendungen an einer theoretischen Betrachtung
orientieren.
Es bietet einen sehr schnellen Entwicklungsstart dadurch, dass der leistungsstarke Appli-
kationsserver JBoss Netty, das Persistenzframework EBeans, eine In-Memory Daten-
bank, sowie ein Build-Tool (Simple Build Tool) mit ausgeliefert werden. Das beeinflusst
die Time-To-Market Zeit sehr positiv.
Trotzdem besteht volle Flexibilität
o Ein Deployment auf einen externen Applikationsserver ist möglich, wenngleich
die Play Version 2.0 noch Probleme mit der Bildung von Web Application Ar-
chivs (*.war) hat.
o Das Simple Build Tool ermöglicht das Einbinden von Maven Repositories mittels
Apache Ivy.
o Alternative Persistenzframeworks wie Hibernate, etc. können eingebunden wer-
den.
Webapplikationen stehen als zustandslose REST Services zur Verfügung. Dies wirkt sich
positiv auf den Aspekt der Skalierbarkeit von Enterprise Anwendungen aus, denn die Zu-
standslosigkeit erlaubt ein sehr einfaches Stacking mehrerer Applikationsserver, welche
über einen vorgeschalteten Front-Proxy verwaltet werden. Auch die Verfügbarkeit wird
dadurch beeinflusst, denn die Server können wechselseitig aus dem Verbund gelöst wer-
den, um beispielsweise ein Softwareupdate durchzuführen.
Modularisierung ist von Play über die sogenannten Play-Modules unterstützt. Diese kön-
nen zwar nicht ganz mit der Modularisierung aus der Objektorientierung verglichen wer-
den, jedoch versuchen sie der Entwicklung von Webapplikationen gerecht zu werden.
Funktionalität lässt sich in diesen kapseln und ist prinzipiell vergleichbar mit einem ei-
genständigen Play Projekt. Somit lässt sich die Wiederverwendbarkeit steigern. Viele der
Module stehen aber leider noch nicht für die Play Version 2.x zur Verfügung, da eine Por-
tierung noch nicht erfolgte.
6.2.3 Entwickler-Sicht
Durch das Play Framework werden an die Entwickler verschiedene Anforderungen gestellt, die
beachtet werden müssen. Die Wichtigsten soll dieses Kapitel erläutern.
6.2.3.1 Entwurfsmuster
Das MVC-Muster ist dasjenige, welches am offensichtlichsten und stärksten Einfluss auf die
Entwicklung mit Play ausübt. Dieses Muster hat sich zum Standard bei modernen Webanwen-
dungen entwickelt und bietet durch die klare Trennung von Model, View und Controller eine
lose Kopplung dieser Komponenten.
Die Views des Play Frameworks können nach dem Kompositum-Muster aufgebaut werden:
ViewKomponente
View ViewKompositum
*
Abbildung 16: View-Kompositum
Das erlaubt eine Verschachtelung und Wiederverwendung von sich wiederholenden Teilen einer
Webseite (z.B. Header und Footer).
6.2.3.2 Extreme Zustandslosigkeit
Die starke Zustandslosigkeit, wie sie auch bereits im vorhergehenden Kapitel in Bezug auf die
Skalierbarkeit genannt wurde, führt dazu, dass während der Entwicklung mehr zu beachten ist.
Beispielsweise muss jede Anfrage ausreichend viele Informationen enthalten, so dass diese verar-
beitet werden kann.
38
6.2.3.3 Vergleich mit JSF
Dieses Unterkapitel vergleicht die Programmierkonzepte der Java Server Faces (JSF) und des
Play Frameworks. Für eine gute Übersichtlichkeit liegt dieser Vergleich in Form einer Tabelle
vor, welche nachfolgend aufgeführt ist.
Java Server Faces (JSF) Play Framework (Play)
Basis Basiert auf der Servlet API (FacesServlet) und muss somit in einem Servlet Container ab-laufen.
Basiert nicht auf der Servlet API und benötigt keinen Serv-let Container zur Ausführung, kann aber, wenn nötig mit der
Servlet API zusammenspielen.
Zustandbehaftetkeit Konzipiert als zustandsbehaftet (stateful) mit folgenden Vortei-len:
Einfacheres Programmier-modell
und Nachteilen:
Layer 7 Load-Balancing
Session Failover
Aber auch stateless ist mit JSF
möglich.
Konzipiert als zustandlos (stateless) mit folgenden Vor-teilen:
Einfaches Load-Balancing durch Hinzufügen beliebig vieler Applikationsserver-Instanzen
und Nachteilen:
Komplexeres Program-miermodell
Templating (Composite Pattern)
Das Templating wird durch spezielle JSF Tags unterstützt um eine Gesamtseite aus Seiten-Fragmenten zusammenzuset-zen.
Das Templating geschieht durch Scala basierte Ausdrücke und ermöglicht ebenfalls das Zusammensetzen von Seiten-fragmenten zu einer Gesamt-seite.
Navigationslogik Die Logik zur Navigation zwi-schen den Seiten ist in einer Datei zentralisiert und ermög-licht eine leichtere Abänderung
des Navigationsflusses, da sich die Änderungen nicht durch mehrere Seiten ziehen. Eine visuelle Darstellung der Seiten-vernetzungen wird mitgeliefert.
Eine zentrale Navigationslogik ist nicht vorhanden und somit steckt das Wissen um den Sei-tenfluss in den einzelnen Seiten
und eine Änderung führt zu Änderungen in den Seiten. Eine visuelle Darstellung der Seitenvernetzung ist nicht mög-lich.
Mapping zwischen HTML/Entity Elementen
Die Zuordnung zwischen den Elementen der Präsentationsschicht und den korrespondierenden Elementen der Modelle geschieht in beiden Frameworks auf eine ähnliche Weise. JSF greift dabei auf eine Expression Language zurück, während in Play die Sprache Scala Anwendung findet.
Tabelle 4: Vergleich JSF und Play
39
Zusammenfassend kann festgehalten werden, dass die Frameworks sich hauptsächlich durch die
Zustandsbehaftung und die Umsetzung der Navigationslogik unterscheiden. Die Navigation in
JSF ist besser umgesetzt, während die Zustandslosigkeit in Play als bessere Lösung zu werten ist.
Beide Frameworks eignen sich gut für die Umsetzung von Enterprise Anwendungen, jedoch
kann dem Play Framework, durch die genannten Argumente, dennoch ein leichter Vorzug gege-
ben werden. Gerade durch den geringen Konfigurationsaufwand, kann zu Projektbeginn viel Zeit
gespart werden.
6.2.4 Fazit
Zusammenfassend bleibt noch die Frage offen, ob das Play Framework für den Einsatz bei der
Entwicklung von Enterprise Anwendungen empfohlen werden kann. Die betrachteten Punkte
legen dies nahe, womit prinzipiell eine Empfehlung ausgesprochen werden kann. Die mangelnde
Portierung der Module von Version 1.x auf 2.x wirkt sich aber stark auf die Produktivität und
Möglichkeiten aus, so dass der Einsatz erst ab Version 2.1 empfohlen werden kann.