U4_U1_JM 2.11.indd

für die ersten 3 Monate!
Österreich € 9,80 Schweiz sFr 16,80
Java • Architekturen • Web • Agile
www.javamagazin.de
Clean Code
RHQ
Design Pattern
Teil 3 45
Auf die Finger
geschaut
82
inkl.
»
»
HIGHLIGHTS
Java ist auch
eine Insel als
OpenBook
Multithreading auf der JVM
Android SDK
Clojure 1.2
WEITERE INHALTE
EasyMock 3.0
ScalaCheck
u.v.
Alle CD-Infos ab Seite 3
CouchDB
Clojure: Wozu wieder eine neue
Programmiersprache? » 20-34
Interview mit ClojureGründer Rich Hickey » 16
Bequemer Zugriff aus Java
TDD mit Scala
» 75
Mit guten Vorsätzen ins neue Jahr
strato-pro.de
» 35
Video von der JAX 2010
in voller Länge
ScalaTest
Telefon: 0 18 05 - 00 76 77
Alle Infos im Heft
ADAM BIEN
60 Minuten mit
Java EE
jCouchDB
(0,14 €/Min. aus dem dt. Festnetz, Mobilfunk max. 0,42 €/Min.)
2.2011
magazin
CD-INHALT
RHQ
50% Rabatt
Clean Code
Auf alle Hexa-Core Server
TDD mit Scala
Vorkonfigurierte
Managed Server
Android
Leistungsstarke
Dedicated Server
Deutschland € 8,50
» 64
CouchDB
Jetzt Server mit echten
Hexa-Core Prozessoren für:
Clojure
NEU!
JAVA Mag
Server-Technik, die begeistert!
Java Magazin 2.2011
STRATO Pro
CD
Android User Interfaces: Grundlagen und Tipps
Scrum But(t)
» 97
Wie viel Anpassung ist gut für Scrum?
» 110
Webframeworks Teil 2 Web
Welche Webframeworks für welche Projekte?
Einsatzgebiete von
Webframeworks
Im Java-Umfeld ist eine fast unüberschaubar große Auswahl an Webframeworks verfügbar. Diese nutzen verschiedene Technologien, realisieren unterschiedliche Designkonzepte und unterscheiden sich
durch eine Vielzahl weiterer Merkmale. Daher stellt sich die Frage, welches Webframework für welches
Projekt eingesetzt werden sollte. Einige Beispiele aus dem Unternehmensalltag sowie Empfehlungen
durch Erfahrungen aus der Praxis zeigen, wie bei der Entscheidung für ein konkretes Webframework
vorgegangen wird.
von Kai Wähner
In der letzten Ausgabe des Java Magazins wurden bereits die wichtigsten Designentscheidungen im Umfeld
von Webframeworks erläutert und eine Kategorisierung nach Frameworktypen vorgenommen (Abb. 1).
Die gängigsten Frameworks wurden bezüglich dieser
Informationen eingeordnet (Abb. 2, die Komplexität
wird dabei aus Sicht eines Java-Entwicklers betrachtet).
Dieser Artikel widmet sich nun einigen beispielhaften
Projekten aus dem Unternehmensalltag mit unterschiedlichen Größenordnungen und verschiedensten Anforderungen. Auf diese Weise lässt sich gut demonstrieren,
wann welcher Frameworktyp sinnvoll eingesetzt werden
kann. Geeignete Webframeworks lassen sich wie folgt
weiter evaluieren, um die bestmögliche Entscheidung zu
treffen.
Für jedes Praxisbeispiel werden zunächst die Anforderungen an ein Webframework erläutert. Dann wird
beschrieben, warum ein bestimmter Frameworktyp und
eine konkrete Technologie besonders geeignet sind. Abschließend werden konkrete Handlungsempfehlungen
zur Auswahl eines Webframeworks gegeben. Die Anforderungen für sämtliche Beispiele werden aus Sicht eines
Java-Entwicklers betrachtet.
Beispiel 1: Unternehmensinterne Anwendung zur
Verwaltung von Daten
Anforderungen: Die Webanwendung soll ermöglichen,
die Weiterbildungsplanung der eigenen Mitarbeiter zu
verwalten. Dazu sollen Weiterbildungsmaßnahmen erzeugt, aktualisiert und entfernt werden können. Die Suche nach bestimmten Maßnahmen durch verschiedene
www.JAXenter.de
Java WebStart als Alternative zum Webframework
Viele Unternehmen sehen sich mit der Aufgabe konfrontiert, eine Desktopanwendung, die mit einem Server kommuniziert, als Webanwendung
anzubieten. Grund ist unter anderem die Aufwandreduzierung durch
weniger Installations- und Wartungsaufwand. Für eine Neuentwicklung
kann ein Webframework verwendet werden. Sofern es sich um eine
bereits existierende Java-SE-Anwendung handelt, ist auch eine deutlich
kostengünstigere Alternative verfügbar.
Java WebStart
Java WebStart ist eine Technik, die das Laden und Starten einer JavaSE-Anwendung über das Internet ermöglicht. Die Anwendung läuft dann
nicht im Webbrowser, sondern als „ganz normale“ Java-Anwendung.
Sie bleibt im Cache der Festplatte des Clients gespeichert. Ein (automatisches) Update ist lediglich bei einer neuen Version der Anwendung
notwendig. Die Anwendung kann daher auch ohne Internetverbindung
verwendet werden. Diese Technologie ist seit Java 1.4 in das Java Runtime Environment (JRE) integriert. Auf Clientseite ist eine installierte JRE
die einzige Voraussetzung und kann, falls noch nicht vorhanden, auch
beim ersten Start der Anwendung mitinstalliert werden [2].
Java Network Launching Protocol (JNLP)
WebStart verwendet das JNLP-Protokoll. Dieses spezifiziert ein XML-Schema, um die Konfiguration der Anwendung festzulegen, beispielsweise den
Ort der JAR-Datei oder den Namen der Main Class. Der Quellcode der
Anwendung selbst muss nicht verändert werden. Der Entwicklungsaufwand ist also sehr gering im Gegensatz zur Neuentwicklung mit einem
Webframework. Lediglich die JAR-Dateien müssen signiert werden, falls
ein Zugriff auf das Betriebssystem notwendig ist, beispielsweise wegen
Netzwerk- oder Festplattenzugriffs. Daher sollte Java WebStart durchaus
als Alternative evaluiert werden.
javamagazin 2 | 2011
53
Web Webframeworks Teil 2
Designvorgaben des Unternehmens, sollte mit weiteren
zwei bis drei Personentagen gerechnet werden. Demnach
kann die Anwendung bereits nach etwa fünf Personentagen Entwicklungszeit produktiv eingesetzt werden.
Technologieauswahl: Für diese Webanwendung bieten sich das Roma Framework oder Spring Roo an, da
im Gegensatz zu Alternativen wie Grails oder Lift keine neue Programmiersprache gelernt werden muss. Bei
CRUD-Frameworks ist allerdings zu beachten, dass oft
ein Großteil der Anforderungen schnell realisiert werden kann, wohingegen bei einigen wenigen Zusatzanforderungen, wie etwa komplexen Abhängigkeiten im
Datenmodell, der Aufwand auch über den von anderen
Frameworks hinausgehen kann. Dieser fällt dann schnell
deutlich höher aus, als zunächst erwartet.
Abb. 1: Kategorisierung von Webframeworks
Abb. 2: Einordnung von Webframeworks bezüglich Frameworktyp und Komplexität
Kriterien muss ebenfalls möglich sein. Außerdem sollen
die einzelnen Maßnahmen in unterschiedlichen Ansichten dargestellt werden können, z. B. sortiert nach Mitarbeiter oder Karrieremodell. Gleichzeitig müssen aber
die Kosten gering gehalten werden, insbesondere in die
äußere Erscheinung der Webanwendung ist nur geringer
Aufwand zu stecken.
Lösung: Da diese Anwendung nur ein einfaches Datenmodell persistieren muss, eignet sich in diesem Fall
ein CRUD-Framework. Auch ohne Kenntnisse des spezifischen Frameworks ist ein funktionsfähiger Prototyp
nach ca. ein bis zwei Personentagen erzeugt, da viele
Konventionen vom Framework genutzt werden und
das gesamte Codegrundgerüst der Persistierung und
Darstellung generiert wird. Dazu muss im Prinzip nur
das vorhandene Datenmodell in Tabellen und Relationen abgebildet werden. Um den Rest kümmert sich das
Framework selbst. Für die endgültige Fertigstellung, inklusive Tests und Anpassung der Darstellung nach den
54
javamagazin 2 | 2011
Beispiel 2: Durchführung von Einstellungstests für
Bewerber
Anforderungen: Ein Einstellungstest soll realisiert werden, bei dem der Bewerber diverse Fragen beantworten
muss und zwischen den Fragen navigieren kann. In bestimmten Situationen soll der Bewerber Hilfestellungen
von der Anwendung angezeigt bekommen, damit er auch
bei eventuell auftretenden Problemen weiterkommt. Die
Bedienung soll dabei den Komfort einer Desktopanwendung bieten und intuitiv steuerbar sein, damit sich der
Bewerber ausschließlich auf die eigentlichen Fragen
konzentrieren kann. Damit der Bewerber den Test auch
zu Hause durchführen kann, sind für die Dauer des Einstellungstests auch kurze Netzprobleme zu überstehen,
um keine Daten zu verlieren. Ein bestimmter Webbrowser sollte dem Bewerber nicht vorgeschrieben werden.
Lösung: Es bietet sich an, die Anwendung durch ein
Rich-Client-Framework zu realisieren. Durch die single-page-Struktur wird eine desktopähnliche Nutzung
möglich. Weder Lesezeichen noch Durchsuchbarkeit
durch Suchmaschinen sind erforderlich. Durch den
clientzentrischen Ansatz wird die Anwendung beim
Start vollständig geladen und somit werden eventuelle
Netzwerkprobleme den Benutzer nach dem Start des
Einstellungstests nicht weiter bei der Darstellung der
Oberfläche behindern.
Als Alternative zur Verwendung eines Rich-ClientWebframeworks kann auch eine Java-Desktopanwendung ins Web gebracht werden (Kasten: „Java WebStart
als Alternative zum Webframework“).
Technologieauswahl: Als Webframework empfiehlt sich
hier das Google Web Toolkit (GWT). Die große Auswahl
an Komponenten ermöglicht eine sehr schnelle Implementierung, beispielsweise durch den Einsatz einer der beiden
Komponentenbibliotheken ExtGWT oder SmartGWT.
Die Anwendung wird plattformunabhängig sein und kann
ohne Plug-in auf jedem verbreiteten Browser benutzt werden. Für die Hilfestellungen von der Webanwendung in
bestimmten Situationen wird das Comet-Konzept eingesetzt (Kasten: „Comet – das Push-Konzept).
JavaScript Caching speichert die vom Benutzer eingegebenen Daten im Arbeitsspeicher des Clients zwischen.
www.JAXenter.de
Webframeworks Teil 2 Web
Da nur ein kurzfristiger Ausfall der Verbindung beachtet
werden muss, ist diese Lösung für die Realisierung der
Offlinefähigkeit ausreichend. Allerdings ist zum jetzigen
Zeitpunkt die Offlinefähigkeit nicht ohne JavaScriptKenntnisse realisierbar. Dafür ist das Modul JavaScript
Foreign Function Interface (JSFFI, früher JSNI) verfügbar, eine gute Einführung gibt es unter [1].
Beispiel 3: Gestaltung von Unterhaltungssoftware für
Marketingzwecke
Anforderungen: Eine optisch anspruchsvolle Unterhaltungssoftware soll auf der offiziellen Webseite zur Reisebuchung platziert werden. Diese dient insbesondere dem
Marketing und ermöglicht das Erspielen von Rabatten
für Buchungen. Notwendig dafür sind ein professionelles Design und eine moderne Darstellung mit integrierten Animationen und Werbevideos.
Lösung: Um sich von der Konkurrenz abzusetzen,
reicht eine klassische Webanwendung nicht aus. Zur
Realisierung wird daher eine Rich Internet Application
(RIA) erstellt, da nur so die hohen Ansprüche an die
Darstellung erfüllt werden können. Klassische „Browserfeatures“, wie Vor- und Zurücknavigation, werden
hier nicht benötigt. Die Oberfläche wird beim Start vollständig auf den Client geladen (Werbevideos ausgenommen, da die Ladezeit zu lange wäre) und bietet eine hohe
Benutzerfreundlichkeit. Leider ist der Einsatz eines Plugins nicht vermeidbar, dafür ist jedoch gesichert, dass die
Anwendung unabhängig vom Webbrowser immer dieselbe Darstellung und Benutzung garantiert.
Technologieauswahl: Im Java-Umfeld steht als Framework nur JavaFX zur Verfügung. Allerdings wird diese
Technologie oft als noch nicht ganz reif für den Einsatz
in Unternehmen angesehen [4], da die Anzahl der verfügbaren GUI-Komponenten nach Einschätzung vieler
noch relativ gering ausfällt und die Entwicklungstools
professionellen Ansprüchen noch nicht in allen Belan-
gen gerecht werden. Auch das Deployment weist noch
Mängel auf [5]. Außerdem wird JavaFX vollständig
verändert [6]: JavaFX Script wird durch eine Java-API
abgelöst. Zusätzlich soll auch HTML5 unterstützt werden, wodurch die Anwendung ohne Plug-in gestartet
werden kann. Durch diese Änderungen könnte JavaFX
in Zukunft sicherlich eine sehr interessante Alternative
für die RIA-Entwicklung werden (geplanter Release von
JavaFX 2.0: 3. Quartal 2011). Bis dahin ist allerdings
noch ein weiter Weg. Die Anwendung sollte zum jet-
Comet – das Push-Konzept
Comet beschreibt ein Konzept, wodurch der Server neue Daten an den
Webbrowser „pushen“ kann, ohne dass dieser eine explizite Anfrage
durchführt. Das Push-Konzept ermöglicht dem Benutzer eine komfortable
Webanwendung, da ohne Verzögerung immer die aktuellen Daten beim
Client angezeigt werden.
Zur Realisierung existieren verschiedene Möglichkeiten, wobei meistens
Ajax, oder genauer gesagt das XMLHttpRequest-Objekt, eingesetzt wird,
das auf der Clientseite einfach zu implementieren ist und durch jeden
JavaScript-fähigen Browser unterstützt wird. Der Browser stellt dabei
eine Anfrage an den Server, die offen gelassen wird, bis der Server neue
Daten an den Browser schickt. Nach dem Erhalt der Antwort initiiert der
Browser eine neue, lang gehaltene Anfrage, um auch das nächste Ereignis wieder empfangen zu können. Viele aktuelle Webframeworks bieten
mittlerweile – zumindest durch zusätzliche Komponentenbibliotheken
– eine Lösung für Push-Nachrichten an, wie beispielsweise ICEFaces für
JSF oder SmartGWT für GWT.
Comet erfordert ein Umdenken bezüglich der Architektur und Entwicklung
einer Webanwendung. Dabei treten einige Probleme auf, da jeder Client
eine persistente Verbindung zum Server offen hält und ein Engpass der
verfügbaren Ressourcen die Folge sein kann. [3] erläutert die auftretenden Probleme und gibt einen Ausblick, wie HTML 5 diese Probleme in
absehbarer Zukunft mit WebSockets standardisiert lösen soll.
Anzeige
Anzeige
Web Webframeworks Teil 2
Abb. 3: Vergleich von JSF, JavaFX und Grails mit Google Trends
zigen Zeitpunkt daher besser mit Adobe Flex realisiert
werden. Die Integration mit Java ist aufwändiger, wird
aber mittlerweile sehr gut durch Tools wie Granite DS
unterstützt, wie unter [7] nachzulesen ist. Und an einer
neuen Programmiersprache (ActionScript und MXML
für Flex statt JavaFX Script für JavaFX) führt im Moment leider kein Weg vorbei, wenn eine RIA benötigt
wird.
Beispiel 4: Externe Unternehmensdarstellung
Anforderungen: Die Webseite eines Reiseveranstalters,
die Informationen zum Unternehmen bietet und gleichzeitig als Buchungsplattform dient, basiert auf veralteten
Technologien und soll komplett neu entwickelt werden.
Im Vordergrund stehen maximale Erreichbarkeit und
hohe Nutzerfreundlichkeit.
Lösung: Die Anforderungen entsprechen einer klassischen Webanwendung. Eine multi-page-Struktur mit
Lesezeichen und Vorwärts-/Rückwärtsnavigation wird
benötigt. Nicht gewünscht hingegen sind die Notwendigkeit eines Plug-ins auf dem Client oder Ladezeit beim
Start der Anwendung.
Hype oder Trend?
Oft stellt man sich die Frage, wie weit verbreitet ein Webframework
eigentlich ist. Daraus möchte man dann folgern, ob es auch zukunftssicher ist oder nicht. Zur Bewertung der Eignung und Zukunftsfähigkeit
eines Frameworks sollten mehrere Quellen herangezogen werden:
Verfügbarkeit von Fachbüchern und Komponentenbibliotheken, Medienberichte (Zeitschriften, Blogs, Konferenzen), IDE-Plug-ins (z. B.
GUI-Builder), Anzahl der Jobinserate in bekannten Jobportalen sowie
die Größe der Community.
Google Trends – ein Blick in die Glaskugel
Google Trends [11] ist ein weiterer Indikator, um zu bewerten, wie angesagt ein Webframework ist. Die Seite stellt grafisch dar, wie oft der
eingegebene Suchbegriff in den letzten Jahren bei dem Suchmaschinenmarktführer „Google“ eingegeben wurde. Dadurch ist erkennbar, in
welche Richtung der Trend geht, also ob dieser beispielsweise stetig
steigend, etwa gleich bleibend oder gar stark fallend ist.
Die Suche ermöglicht auch die Durchführung eines Vergleichs verschiedener Webframeworks. Der Suchbefehl jsf, javafx, grails stellt
56
javamagazin 2 | 2011
Technologieauswahl: Die Auswahl des Webframeworks hängt immer auch von der Größe der zu erstellenden Anwendung ab. Für die konkrete Aufgabe sind
verschiedene Frameworks gut geeignet.
Bei kleineren und mittleren Anwendungen können
mit Tapestry oder Wicket schnell gute Ergebnisse erzielt
werden, da die Programmierung hauptsächlich in Java
erfolgt (objektorientiert bei Wicket, annotationsbasiert
bei Tapestry). Spring MVC ist eine gute Alternative, falls
für die Anwendungslogik (Reisebuchungen, Kundenverwaltung) ebenfalls Spring eingesetzt wird.
Soll hingegen eine sehr große Anwendung entstehen,
ist der JSR-Standard Java Server Faces (JSF) die erste
Wahl. Neben sehr vielen Komponentenbibliotheken
(z. B. ICEFaces, RichFaces, PrimeFaces) sind noch andere sinnvolle Erweiterungen verfügbar, beispielsweise JBoss Seam zur nahtlosen Verbindung von JSF mit
anderen Java-EE-Komponenten. Auch die Verbreitung
durch Community und Fachliteratur ist bei dieser Technologie dank des Standards am größten. Dadurch ist die
Zukunftssicherheit für Bugfixes und Change Requests
sowie die Suche nach weiteren Entwicklern höher als bei
anderen Frameworks.
Beispiel 5: Große Enterprise-Anwendung für diverse
Geschäftsfelder
Anforderungen: Diverse Anwendungen für unterschiedliche Aufgaben erhöhen die Komplexität in einem großen
Versicherungsunternehmen. Die verschiedenen Anwendungen, die bisher unterschiedliche Technologien eingesetzt haben, müssen in eine einheitliche Webanwendung
integriert werden. Damit sowohl der Versicherungsvertreter vor Ort beim Kunden (auch offline) als auch der
Verkäufer im Büro und der Berater im Call-Center auf
die Anwendung zugreifen können, wird auch Enter­prise-
beispielsweise die unterschiedlichen Verläufe dieser drei Frameworks
dar (Abb. 3). Auch eine Abstufung nach verschiedenen Sprachen und
Regionen ist möglich.
Vorsicht vor Gegenüberstellungen verschiedener Frameworks
Mit den Ergebnissen von Google Trends muss aber sehr vorsichtig
umgegangen werden. Gut erkennbar ist sicherlich der Trend eines
Frameworks. Vergleiche hingegen sind sehr gefährlich, da Benutzer
sehr oft nach mehreren Begriffen suchen (nicht nur nach einem Stichwort) und viele Frameworks keine Eigennamen besitzen. Es sollte also
nicht verwundern, dass lift den Konkurrenten grails deutlich hinter sich
lässt – sogar schon in Jahren, in denen dieses Framework noch gar
nicht existierte.
Fazit
Google Trends ist sicherlich ein guter Indikator, um zu analysieren,
ob ein Framework nur ein kurzer Hype ist oder sich im Markt etabliert
hat. Aufgrund eines Vergleichs verschiedener Frameworks mit diesem
Service sollte aber auf keinen Fall die letztendliche Entscheidung für
oder gegen ein Framework getroffen werden.
www.JAXenter.de
Webframeworks Teil 2 Web
Mehrkanalfähigkeit benötigt. Die Darstellung muss trotz
verschiedener Anwendungen einheitlich sein.
Lösung: Hierfür erscheint nur der Einsatz eines Portals sinnvoll, wobei die Auswahl eines geeigneten Portalservers nicht Bestandteil dieses Artikels sein soll. Damit
können auch Webanwendungen verschiedener Frameworks in eine Oberfläche integriert werden, denn fast
alle aktuellen Frameworks ermöglichen eine Integration
in Portlets. Durch das Portal kann auch die EnterpriseMehrkanalfähigkeit umgesetzt werden, da für jeden
Mitarbeiter nur die relevanten Portlets angezeigt werden. Beim Außendienstmitarbeiter erfolgt auf einem
kleinen Laptopbildschirm dann ein anderer Prozess und
eine andere Darstellung als beispielsweise beim Berater
im Call-Center. Durch GEARS wird Offlinefähigkeit in
der jeweiligen Webanwendung realisiert. Der Mitarbeiter kann alle relevanten Daten vor Ort beim Kunden
speichern und bei der nächsten verfügbaren Onlineverbindung mit dem Server synchronisieren. Eine Migration von GEARS auf den noch nicht fertigen Standard
HTML 5 und dessen Features für Offlinefähigkeit wird
von Beginn an bei der Planung beachtet.
Technologieauswahl: Bei einer neu hinzukommenden
Webanwendung ist zusätzlich zur sonstigen Evaluierung
noch zu prüfen, ob und wie einfach sich ein Framework
in ein Portlet integrieren lässt. Positiv zu erwähnen ist
hier sicherlich JSF, das für JSF 1.2 durch die beiden JSRs
301 und 329 Portlet Bridge for JSF eine sehr gute Unterstützung bietet. Auch für JSF 2.0 sind bereits „Bridge“Implementierungen von JBoss [8] und Liferay [9] in
Arbeit. Der Einsatz verschiedener Webframeworks
kann für die unterschiedlichen Portlets natürlich sinnvoll sein, beispielsweise wenn für ein Portlet „RIA-Features“ benötigt werden. Nicht zu unterschätzen ist der
zusätzliche Aufwand für die Kommunikation zwischen
verschiedenen Portlets.
Empfehlungen
Nach diesen konkreten Beispielen aus dem Unternehmens­
alltag sollen nun noch einige generelle Empfehlungen zur
Auswahl eines Webframeworks gegeben werden:
•Ein Team sollte sich über mehrere Projekte hinweg
auf ein paar wenige, konkrete Frameworks jedes
Frameworktyps konzentrieren und diese dafür effizient einsetzen.
•Alle wichtigen Begriffe, wie beispielsweise „Webframework“ oder „RIA“, sollten vor der Evaluierung
in einem Glossar definiert werden, da ansonsten sehr
schnell Missverständnisse und unnötige Diskussionen
entstehen können.
•Bei der unüberschaubar großen Anzahl an verfügbaren
Webframeworks ist darauf zu achten, dass nicht nur
einem Hype gefolgt wird (Kasten: „Hype oder Trend“).
Anzeige
Web Webframeworks Teil 2
Anti-Patterns bei der Auswahl eines
Webframeworks
Im Folgenden werden einige Anti-Patterns vorgestellt, die bei
der Auswahl eines Webframeworks beachtet werden sollten.
Jede moderne Anwendung muss eine RIA sein!
Meinung: Eine RIA ist modern. Jedes moderne Unternehmen
hat RIAs. Der Benutzer möchte unbedingt eine RIA verwenden,
statt eine veraltete klassische Webanwendung mit HTMLOberfläche.
Sachlage: Anwendungen benötigen in erster Linie eine
übersichtliche Struktur. Informationen sollen leicht gefunden
werden. Die Navigation soll intuitiv und sinnvoll sein. Eine
klassische Webanwendung mit einfachen HTML-Links und
PDFs zum Download ist dem Benutzer oftmals wichtiger
als bunte Optik, Animationen sind allemal lieber als lange
Ladezeiten, eine Bedienung ohne Menüs und sichtbare Navigation oder unter Umständen sogar die vorherige Installation
eines Plug-ins.
Fazit: Eine RIA ist modern und eindrucksvoll, deswegen aber
noch lange nicht immer sinnvoll. Der Benutzer möchte in erster
Linie eine Anwendung, die seinen Ansprüchen gerecht wird.
Wir haben mehrere Webanwendungen. Dann nehmen
wir doch ein Portal!
Meinung: Mit einem Portal kann auf sehr einfache und effiziente Weise eine Menge von Anwendungen zusammengefügt und
als eine Einheit dargestellt werden.
Sachlage: Portale dienen der Integration, Zusammenarbeit
und Personalisierung von Anwendungen. Diese Ziele müssen
allerdings mit enormem Zusatzaufwand bei der Entwicklung
erkauft werden, da Portalserver sehr komplexe Produkte sind
und jede Webanwendung zusätzlich zu ihren eigentlichen
Aufgaben noch für diese „Bonusfeatures“ bereit gemacht
werden muss.
Fazit: Ein Portal macht nur dann Sinn, wenn es die Anforderungen der Anwendungslandschaft auch tatsächlich
verlangen.
•Weitere Faktoren, wie etwa das bereits vorhandene Wissen der Mitarbeiter oder politische Aspekte,
müssen von Beginn an bei der Evaluierung beachtet
werden.
Neben den genannten Empfehlungen sind wichtige Anti-Patterns bei der Auswahl eines Webframeworks zu
beachten (Kasten: „Anti-Patterns bei der Auswahl eines
Webframeworks“).
Zusammenfassung
Je nach Einsatzgebiet werden an Webanwendungen
sehr unterschiedliche Anforderungen gestellt. Die
Auswahl des richtigen Webframeworks ist essenziell
für eine gelungene Realisierung und den langfristigen
Erfolg. Anhand unterschiedlicher Beispiele aus dem
Unternehmensalltag und generellen Empfehlungen
wurde gezeigt, wie eine Vorauswahl von verschiedenen Frameworktypen durchgeführt werden sollte und
die unüberschaubar große Auswahl sich sinnvoll einschränken lässt. Der Leser kann nun für sein konkretes
Projekt entscheiden, welche Webframeworks in Frage
kommen und weiter evaluiert werden sollten. Bei einem
größeren Projekt ist ein Proof of Concept mit mehreren
potenziellen Kandidaten sinnvoll.
Kai Wähner ist als IT-Consultant bei „MaibornWolff et al“ tätig.
Seine Schwerpunkte liegen in den Bereichen JEE, EAI und SOA.
Außerdem berichtet Kai auf http://www.kai-waehner.de/blog über
seine Erfahrungen mit neuen Technologien, IT-Konferenzen und
Zertifizierungen. Feedback zum Artikel gerne an kai.waehner@mwea.
de (Twitter: @KaiWaehner).
CRUD-Frameworks sind der effizienteste Weg zur neuen
Anwendung!
Links & Literatur
Meinung: Das manuelle Erstellen einer Oberfläche ist unnötiger Aufwand und nicht mehr zeitgemäß. Codegeneration,
Convention over Configuration und moderne Programmiersprachen nehmen dem Entwickler sehr viel Arbeit ab.
Sachlage: Für Anwendungen zur Verwaltung von Daten
sind CRUD-Frameworks sehr gut geeignet. Wie auch im
Erfahrungsbericht unter [10] zu lesen ist, können einige
Fallstricke den schnellen Erfolg aber leicht zunichte machen.
Gerade bei einem komplexeren Datenmodell sind die Grenzen oft schnell erkennbar. Auch der Aufwand zum effizienten
Anwenden einer neuen Programmiersprache ist nicht zu
unterschätzen.
Fazit: CRUD-Frameworks sind in erster Linie für CRUD-Clients
mit einfachem Datenmodell sehr gut geeignet.
[1] http://code.google.com/webtoolkit/doc/latest/
DevGuideCodingBasicsJSNI.html
[2] http://download.oracle.com/javase/1.5.0/docs/guide/javaws/
developersguide/autodl.03.06.html
[3] http://www.infoq.com/news/2008/12/websockets-vs-comet-ajax
[4] Demann, Tim; Kestler, Thomas: „JavaFX goes Enterprise“, Java Magazin 4.10
[5] http://www.dzone.com/links/r/javafx_does_it_have_a_future.html
[6] http://javafx.com/roadmap/
[7] Müller, Florian: „Enterprise Flex mit Granite DS“, Java Magazin 6.10
[8] http://planet.jboss.org/post/jboss_portlet_bridge_3_0_0_alpha_
jsf_2_0_portlet_support
[9] http://www.portletfaces.org/projects/portletfaces-bridge
[10] Schiffer, Bernd: „Grails-Erfahrungsbericht“, Java Magazin 8.09
[11] http://www.google.com/trends
58
javamagazin 2 | 2011
www.JAXenter.de