magazinJava • Architekturen • Web • Agile

Android User Interfaces: Grundlagen und Tipps »64

www.javamagazin.de

Clean CodeDesign Pattern Teil 3 »45

RHQAuf die Finger geschaut »82

CD-INHALT

Österreich € 9,80 Schweiz sFr 16,80Deutschland € 8,50 2.2011

Alle CD-Infos ab Seite 3

ADAM BIEN60 Minuten mit

Java EE

Video von der JAX 2010 in voller Länge

strato-pro.deTelefon: 0 18 05 - 00 76 77(0,14 €/Min. aus dem dt. Festnetz, Mobilfunk max. 0,42 €/Min.)

STRATO Pro Server-Technik, die begeistert!

Auf alle Hexa-Core Server

50% Rabatt für die ersten 3 Monate!

NEU!Jetzt Server mit echtenHexa-Core Prozessoren für:

LeistungsstarkeDedicated Server

Vorkonfi gurierteManaged Server

STR0111_AZ_Dedi_Server_A4 1 09.12.10 15:55

CDinkl

.

Java Magazin 2.2011

Clojure

CouchDB Android

TDD mit Scala

Clean Code RHQ

JAVA

Mag

HIGHLIGHTS

Java ist auch eine Insel als OpenBook

Android SDK

Clojure 1.2

WEITERE INHALTEEasyMock 3.0

jCouchDB

ScalaTest

ScalaCheck u.v.CouchDBBequemer Zugriff aus Java »75

TDD mit ScalaMit guten Vorsätzen ins neue Jahr »97

Scrum But(t)Wie viel Anpassung ist gut für Scrum? »110

Multithreading auf der JVM

Alle Infos im Heft »35

Clojure: Wozu wieder eine neue Programmiersprache? »20-34

Interview mit Clojure-Gründer Rich Hickey »16

von Kai Wähner

In der letzten Ausgabe des Java Magazins wurden be-reits die wichtigsten Designentscheidungen im Umfeld von Webframeworks erläutert und eine Kategorisie-rung 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 unterschied-lichen Größenordnungen und verschiedensten Anforde-rungen. 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 Anfor-derungen an ein Webframework erläutert. Dann wird beschrieben, warum ein bestimmter Frameworktyp und eine konkrete Technologie besonders geeignet sind. Ab-schließend werden konkrete Handlungsempfehlungen zur Auswahl eines Webframeworks gegeben. Die Anfor-derungen für sämtliche Beispiele werden aus Sicht eines Java-Entwicklers betrachtet.

Beispiel 1: Unternehmensinterne Anwendung zur Verwaltung von DatenAnforderungen: Die Webanwendung soll ermöglichen, die Weiterbildungsplanung der eigenen Mitarbeiter zu verwalten. Dazu sollen Weiterbildungsmaßnahmen er-zeugt, aktualisiert und entfernt werden können. Die Su-che nach bestimmten Maßnahmen durch verschiedene

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

Java WebStart als Alternative zum Webframework

Viele Unternehmen sehen sich mit der Aufgabe konfrontiert, eine Desk-topanwendung, 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 Java-SE-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 (auto-matisches) 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 Run-time 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-Sche-ma, 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 Entwicklungsauf-wand 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.

WebWebframeworks Teil 2

53www.JAXenter.de javamagazin 2 | 2011

Kriterien muss ebenfalls möglich sein. Außerdem sollen die einzelnen Maßnahmen in unterschiedlichen Ansich-ten dargestellt werden können, z. B. sortiert nach Mit-arbeiter 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 Da-tenmodell persistieren muss, eignet sich in diesem Fall ein CRUD-Framework. Auch ohne Kenntnisse des spe-zifischen 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 Relatio-nen abgebildet werden. Um den Rest kümmert sich das Framework selbst. Für die endgültige Fertigstellung, in-klusive Tests und Anpassung der Darstellung nach den

Designvorgaben des Unternehmens, sollte mit weiteren zwei bis drei Personentagen gerechnet werden. Demnach kann die Anwendung bereits nach etwa fünf Personen-tagen Entwicklungszeit produktiv eingesetzt werden.

Technologieauswahl: Für diese Webanwendung bie-ten sich das Roma Framework oder Spring Roo an, da im Gegensatz zu Alternativen wie Grails oder Lift kei-ne neue Programmiersprache gelernt werden muss. Bei CRUD-Frameworks ist allerdings zu beachten, dass oft ein Großteil der Anforderungen schnell realisiert wer-den kann, wohingegen bei einigen wenigen Zusatzan-forderungen, 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.

Beispiel 2: Durchführung von Einstellungstests für BewerberAnforderungen: Ein Einstellungstest soll realisiert wer-den, bei dem der Bewerber diverse Fragen beantworten muss und zwischen den Fragen navigieren kann. In be-stimmten 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 Desktopanwen-dung 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 Ein-stellungstests auch kurze Netzprobleme zu überstehen, um keine Daten zu verlieren. Ein bestimmter Webbrow-ser sollte dem Bewerber nicht vorgeschrieben werden.

Lösung: Es bietet sich an, die Anwendung durch ein Rich-Client-Framework zu realisieren. Durch die sin-gle-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-Client-Webframeworks kann auch eine Java-Desktopanwen-dung 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 Implemen-tierung, 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 wer-den. Für die Hilfestellungen von der Webanwendung in bestimmten Situationen wird das Comet-Konzept einge-setzt (Kasten: „Comet – das Push-Konzept).

JavaScript Caching speichert die vom Benutzer einge-gebenen Daten im Arbeitsspeicher des Clients zwischen.

Abb. 1: Kategorisierung von Webframeworks

Abb. 2: Einordnung von Webframeworks bezüglich Frameworktyp und Komplexität

Web Webframeworks Teil 2

54 www.JAXenter.dejavamagazin 2 | 2011

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 JavaScript-Kenntnisse realisierbar. Dafür ist das Modul JavaScript Foreign Function Interface (JSFFI, früher JSNI) verfüg-bar, eine gute Einführung gibt es unter [1].

Beispiel 3: Gestaltung von Unterhaltungssoftware für MarketingzweckeAnforderungen: Eine optisch anspruchsvolle Unterhal-tungssoftware soll auf der offiziellen Webseite zur Reise-buchung platziert werden. Diese dient insbesondere dem Marketing und ermöglicht das Erspielen von Rabatten für Buchungen. Notwendig dafür sind ein professionel-les Design und eine moderne Darstellung mit integrier-ten 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 „Brow-serfeatures“, wie Vor- und Zurücknavigation, werden hier nicht benötigt. Die Oberfläche wird beim Start voll-ständig auf den Client geladen (Werbevideos ausgenom-men, da die Ladezeit zu lange wäre) und bietet eine hohe Benutzerfreundlichkeit. Leider ist der Einsatz eines Plug-ins nicht vermeidbar, dafür ist jedoch gesichert, dass die Anwendung unabhängig vom Webbrowser immer die-selbe Darstellung und Benutzung garantiert.

Technologieauswahl: Im Java-Umfeld steht als Frame-work 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 ver-fügbaren GUI-Komponenten nach Einschätzung vieler noch relativ gering ausfällt und die Entwicklungstools professionellen Ansprüchen noch nicht in allen Belan-

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 Ereig-nis 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 auftreten-den Probleme und gibt einen Ausblick, wie HTML 5 diese Probleme in absehbarer Zukunft mit WebSockets standardisiert lösen soll.

Anzeige

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 wer-den, 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-

WebWebframeworks Teil 2

Anzeige

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 Mo-ment leider kein Weg vorbei, wenn eine RIA benötigt wird.

Beispiel 4: Externe UnternehmensdarstellungAnforderungen: Die Webseite eines Reiseveranstalters, die Informationen zum Unternehmen bietet und gleich-zeitig 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 klas-sischen Webanwendung. Eine multi-page-Struktur mit Lesezeichen und Vorwärts-/Rückwärtsnavigation wird benötigt. Nicht gewünscht hingegen sind die Notwen-digkeit eines Plug-ins auf dem Client oder Ladezeit beim Start der Anwendung.

Technologieauswahl: Die Auswahl des Webframe-works hängt immer auch von der Größe der zu erstel-lenden 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, Kundenver-waltung) 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 an-dere sinnvolle Erweiterungen verfügbar, beispielswei-se JBoss Seam zur nahtlosen Verbindung von JSF mit anderen Java-EE-Komponenten. Auch die Verbreitung durch Community und Fachliteratur ist bei dieser Tech-nologie 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äftsfelderAnforderungen: Diverse Anwendungen für unterschied-liche Aufgaben erhöhen die Komplexität in einem großen Versicherungsunternehmen. Die verschiedenen Anwen-dungen, die bisher unterschiedliche Technologien einge-setzt haben, müssen in eine einheitliche Webanwendung integriert werden. Damit sowohl der Versicherungsver-treter 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-

Abb. 3: Vergleich von JSF, JavaFX und Grails mit Google Trends

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 zukunfts-sicher ist oder nicht. Zur Bewertung der Eignung und Zukunftsfähigkeit eines Frameworks sollten mehrere Quellen herangezogen werden: Verfügbarkeit von Fachbüchern und Komponentenbibliotheken, Me-dienberichte (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 an-gesagt ein Webframework ist. Die Seite stellt grafisch dar, wie oft der eingegebene Suchbegriff in den letzten Jahren bei dem Suchmaschi-nenmarktfü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 ver-schiedener Webframeworks. Der Suchbefehl jsf, javafx, grails stellt

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 Stich-wort) 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.

ww

w.e

ntw

ickl

er-p

ress

.de

Frisch aus der Presse!

Weitere Informationen und Bestellmöglichkeiten finden Sie unter www.entwickler-press.de. Unsere Bücher erhalten Sie auch in jeder gut sortierten Buchhandlung.

Das Buch erklärt den Begriff „Cloud Computing“ und ermög-licht es somit, echte Cloud-Plattformen zu identifi zieren. Dabei werden die technischen Hintergründe verschiedener Plattformen und die wirtschaftlichen und rechtlichen Elemente des Cloud Computings ausführlich beschrieben. Neben den Grundlagen wie Load Balancing, Skalierung und softwareseitige Techniken wird ein besonderes Augenmerk auf die Plattformen gelegt und die aktuell wichtigsten wie Google Apps & Docs, Amazon EC2, Windows Azure und Salesforce vorgestellt. Mehrere Kapitel zu Wirtschaftlichkeit, Einführungsstrategien und zu rechtlichen Grundlagen runden das Buch ab.

NEU!Mario Meir-Huber

Cloud ComputingPraxisratgeber und Einstiegsstrategien

210 Seiten, Softcover, November 2010

PRINT ISBN: 978-3-86802-055-7 Preis: 34,90 / 35,90 (A)E-BOOK ISBN: 978-3-86802-242-1 Preis: 23,00

Alois Reitbauer, Michael Kopp

Java Enterprise PerformancePerformance und Skalierbarkeit von Java-Enterprise-Anwendungen verstehen und managen

250 Seiten, Softcover, Januar 2011

PRINT ISBN: 978-3-86802-040-3 Preis: 34,90 / 35,90 (A)E-BOOK ISBN: 978-3-86802-226-1 Preis: 23,00

Java Enterprise Performance befasst sich mit großen, verteilten Java-Anwendungen. Die Performance und Skalierbarkeit dieser Anwendun-gen sind kritische Faktoren für den Erfolg eines Unternehmens, und Fehler können sich schnell geschäftsschädigend auswirken. Das Buch nähert sich diesem komplexen Themenbereich, indem zunächst die Grundlagen von Java Performance und Skalierbarkeit beleuchtet wer-den. Darauf aufbauend werden weiterführende Themenbereiche wie die Anbindung von Datenbanken, O/R Mapping und Remoting-Mecha-nismen beleuchtet. Abgerundet werden die Themen durch zahlreiche Praxisbeispiele und Performance-Anti-Patterns.

COMING SOON!

Web Webframeworks Teil 2

56 www.JAXenter.dejavamagazin 2 | 2011

Mehrkanalfähigkeit benötigt. Die Darstellung muss trotz verschiedener Anwendungen einheitlich sein.

Lösung: Hierfür erscheint nur der Einsatz eines Por-tals sinnvoll, wobei die Auswahl eines geeigneten Portal-servers nicht Bestandteil dieses Artikels sein soll. Damit können auch Webanwendungen verschiedener Frame-works in eine Oberfläche integriert werden, denn fast alle aktuellen Frameworks ermöglichen eine Integration in Portlets. Durch das Portal kann auch die Enterprise-Mehrkanalfähigkeit umgesetzt werden, da für jeden Mitarbeiter nur die relevanten Portlets angezeigt wer-den. 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 Mitarbei-ter kann alle relevanten Daten vor Ort beim Kunden speichern und bei der nächsten verfügbaren Onlinever-bindung mit dem Server synchronisieren. Eine Migra-tion 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 Unter-stü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 sinn-voll sein, beispielsweise wenn für ein Portlet „RIA-Fea-tures“ benötigt werden. Nicht zu unterschätzen ist der zusätzliche Aufwand für die Kommunikation zwischen verschiedenen Portlets.

EmpfehlungenNach 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 effizi-ent einsetzen. Alle wichtigen Begriffe, wie beispielsweise „Web-•framework“ 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“).

WebWebframeworks Teil 2

Anzeige

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 HTML-Oberflä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 Navi-gation 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 effizien-te 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 An-forderungen der Anwendungslandschaft auch tatsächlich verlangen.

CRUD-Frameworks sind der effizienteste Weg zur neuen Anwendung!

Meinung: Das manuelle Erstellen einer Oberfläche ist unnö-tiger Aufwand und nicht mehr zeitgemäß. Codegeneration, Convention over Configuration und moderne Programmierspra-chen 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 Gren-zen 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.

Links & Literatur

[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

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

Weitere Faktoren, wie etwa das bereits vorhande-•ne Wissen der Mitarbeiter oder politische Aspekte, müssen von Beginn an bei der Evaluierung beachtet werden.

Neben den genannten Empfehlungen sind wichtige An-ti-Patterns bei der Auswahl eines Webframeworks zu beachten (Kasten: „Anti-Patterns bei der Auswahl eines Webframeworks“).

ZusammenfassungJe 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 verschiede-nen Frameworktypen durchgeführt werden sollte und die unüberschaubar große Auswahl sich sinnvoll ein-schrä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.

28. Februar – 4. März 2011München

Veranstalter:presented by powered by

www.entwicklertage.de

Nicht verpassen!Frühbucherrabatt bis 28. Januar!

Alle Infos unter: www.entwicklertage.de

Das Trainingsevent rund um Java, Architektur und Webtechnologien

TRAINERTRAINER

EKKEHARD GENTZIndependent Softwarearchitect

STEFAN TILKOVinnoQ Deutschland GmbH

ANDY BOSCH Berater und Trainer

BASTIAN FEDER Liip Ag

JENS SCHUMANNOpenKnowledge GmbH

MICHAEL PLÖD Senacor Technologies AG

JAKOB WESTHOFF

Web Webframeworks Teil 2

58 www.JAXenter.dejavamagazin 2 | 2011