Ausgabe Frühjahr 2013 - Gedoplan

Ausgabe Frühjahr 2013
www.gedoplan.de
Das Kundenmagazin
In dieser Ausgabe:
JBoss7 als Plattform für
hochverfügbare Anwendungen
Vergleich der Netzwerklast -
Vaadin vs. JSF
Systeme für den Anwender -
User Centered Design

EDITORIAL
Liebe Leserin, lieber Leser,
Im ersten Artikel unserer Frühjahrsausgabe beschäftigt
sich Dirk Weil mit der Clusterfähigkeit
des JBoss Applikationsservers. Sowohl unter dem
Aspekt der Ausfallsicherheit als auch unter dem
Aspekt der Lastverteilung betrachtet, bietet die
aktuelle Version fast alle notwendigen Features.
Allerdings mit einigen Einschränkungen, auf die
im Artikel eingegangen wird. Der Autor erwartet
daher gerade in diesem Bereich noch einige
Verbesserungen in der nächsten, der 7.2 Version.
Hendrik Jungnitsch hat Ihnen in der letzten
Ausgabe das Java-Webframework vorgestellt:
Vaadin. Ein häufiges Argument gegen serverseitig
gesteuerte Webframeworks ist der erhöhte
Netzwerkverkehr. Aber wie hoch ist der eigentlich
und gibt es Unterscheide zum Konkurrenten
JSF? Auf beide Fragen finden Sie eine Antwort in
dem Artikel Vaadin vs. JSF.
User Centered Design sollten sich Softwareentwicklung
immer verpflichtet fühlen. Was ist aber
unter diesem abstrakten Begriff zu verstehen?
Der Artikel Systeme für Anwender - User Centered
Design von Reinhard Brüggemeyer gibt darauf
eine Antwort, indem er die Frage nach dem
Anwender, seinen Arbeitsbedingungen, seinen
Verhaltensmustern etc. und den Folgen beleuchtet.
Eine spannende und lohnende Lektüre
wünscht Ihnen Ihr
Termine
Expertenkreis Java
Thema: jBPM und Drools -
Prozess- und Regelgestützte Fachanwendungen
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld
Termin: Donnerstag, 04.07.2013 | 18:00-20:00 Uhr
Referent: Kai Jemella, S&N AG, Paderborn
Thema: Desktop Usability im Browser -
GWT in Business Anwendungen
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld
Termin: Donnerstag, 16.05.2013 | 18:00-20:00 Uhr
Referent: Christian Vögtle, S&N AG, Paderborn
Thema: JBoss 7 als Plattform für hochverfügbare Anwendungen
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld
Termin: Donnerstag, 14.03.2013 | 18:00-20:00 Uhr
Referent: Dirk Weil, GEDOPLAN GmbH
Java User Group Berlin Brandenburg
Thema: Optimierung von JPA-Anwendungen
Termin: Mittwoch, 30.01.2013 | 18:30-20:30 Uhr
Referent: Dirk Weil, GEDOPLAN GmbH
JAX, 23. - 26.04.2013, Mainz
Thema: Java EE hochverfügbar
Termin: Freitag, 26.04.2013 | 09:00 -10:30 Uhr
Thema: Java Persistence in Action –
Features jenseits des EntryLevels
Termin: Dienstag, 23.04.2013 | 14:45-15:45 Uhr
Referent: Dirk Weil, GEDOPLAN GmbH
HR-User-Group
Thema: Das BEM ExpertenSystem
- Betriebliches Eingliederungsmanagement im Portal
Ort: GEDOPLAN GmbH, Stieghorster Str. 60, 33605 Bielefeld
Termin: Mittwoch, 29.05.2013 | 14:30-16:30 Uhr
Referent: Frank Schlinkheider, ITSD Consulting GmbH
Ulrich Hake | ulrich.hake@gedoplan.de
Power Workshop Java EE 6
Ort: IPS IT-Schulungen, Berlin
Termin: 03. - 07.06.2013
2

JBoss 7 als Plattform
für hochverfügbare Anwendungen
Unternehmensanwendungen sollen zügig arbeiten und ausfallsicher sein. Der Parallelbetrieb in einem
Cluster kann das mit Lastverteilung, Replikation und verteilten Caches erreichen, hält aber auch
einige Stolperfallen bereit. JBoss 7 bietet u. a. in seinem Domain Modus die Möglichkeit, mehrere
Serverinstanzen zu einem Cluster zu verbinden. Darin laufende Web-, Remote-(EJB-) und Messaging-Anwendungen
können von Load Balancing und Failover profitieren, DB-Zugriffe können einen
clusterweiten Cache verwenden.
Von Dirk Weil
Der Begriff „Hochverfügbarkeit“ kann im Sinne zweier Ziele interpretiert
werden, die zwar unabhängig voneinander angestrebt werden
können, sich teilweise aber auch gegenseitig beeinflussen: Durch
Lastverteilung werden die Anfragen auf mehrere Cluster-Knoten verteilt,
idealerweise so, dass die einzelnen Systeme optimal ausgelastet
werden und somit der Gesamtdurchsatz im Vergleich zu einem einzelnen
Server vervielfacht wird. Man muss dabei immer das große
Ganze im Blick haben: Eine Einzelanfrage wird durch die Verwaltung
der Lastverteilung bestenfalls nicht spürbar beeinflusst, in der Praxis
aber etwas verlangsamt.
Clusterarchitekturen
Im einfachsten Fall bilden alle betroffenen Server einen Cluster, in
dem jeder Knoten die Anwendungen komplett enthält.
Alternativ ist auch ein mehrschichtiger Cluster denkbar, in dem Anwendungsschichten
wie bspw. Web-Präsentation und Geschäftslogik
auf mehrere Cluster deployt werden. Darüber hinaus ist es auch möglich,
den Cluster so zu segmentieren, dass Teile davon unabhängig
vom Rest bspw. zu Wartungszwecken heruntergefahren oder mit einem
Anwendungsupdate versehen werden können.
Der zweite Aspekt von Hochverfügbarkeit ist die Sicherheit gegen
Ausfälle des Systems. Wird eine Anwendung redundant auf mehreren
Cluster-Knoten betrieben und ihre Sitzungsdaten repliziert, kann
beim Ausall eines Knotens ein zweiter transparent übernehmen. Im
Idealfall bemerkt der Anwender dieses „Fail-over“ nicht. Die Replikation
der Sitzungsdaten belastet die Systeme allerdings teilweise spürbar.
Zudem nutzt man üblicherweise ein sog. Sticky-Session-Verfahren,
bei dem Folgerequests immer dem Knoten zugewiesen werden,
der schon den ersten Request der Session verarbeitet hat, solange
dieser nicht ausfällt. Somit hat der Lastverteiler hier nicht mehr „freie
Hand“, was der optimalen Systemauslastung entgegen wirkt.
JBoss 7 im Clusterbetrieb
Wie schon bei den Vorversionen enthält auch die Version 7 des JBoss
umfangreiche Cluster-Features. Vieles davon ist allerdings noch
„Work in Progress“, was man z. B. an der vielfach lückenhaften und
teilweise auch fehlerhaften Dokumentation erkennen kann.
Ein JBoss-7-Cluster kann zwar auf Basis des Standalone-Modus aufgebaut
werden, der dem Laufzeitmodus der Vorversionen entspricht.
Besser geeignet ist jedoch der mit der Version 7 neu eingeführte
Domänenmodus, da hier eine gemeinsame Administration der Cluster-Server
web- oder kommandozeilenbasiert mittels Administration
Console bzw. Admin CLI möglich ist, was auch das clusterweite
3

Deployment von Anwendungen umfasst. Als Konfigurationsprofil ist
„ha“ oder „full-ha“ zu wählen für clusterfähige Anwendungen im
Web bzw. Full Profile der Java EE 6.
Web-Anwendungen im JBoss-7-Cluster
Für den Zugriff mittels Webbrowser wird ein Load Balancer benötigt,
der die Web-Requests annimmt und an einen der Clusterserver weiterleitet.
JBoss bringt hierfür ein Plugin namens mod_cluster mit, das
in einen Apache-HTTP-Server integriert werden kann. Es bietet eine
dynamische Konfiguration, d. h. über ein Handshaking mit den Clusterservern
konfiguriert es sich automatisch als lastverteilendes Proxy
für die aktuell deployten, clusterfähigen Webanwendungen. Ebenso
erkennt es selbstständig ausgefallene oder hinzugekommene Knoten.
Die Lastverteilung kann zyklisch gleichverteilt geschehen oder auch
gesteuert durch diverse serverseitige Metriken wie bspw. die akuelle
Last der Clusterserver. Alternative Load Balancer sind natürlich auch
einsetzbar, bspw. mod_jk – ebenfalls ein Apache-Plugin – oder separate
Hardware.
Die Sitzungsdaten der Anwendung können im Cluster repliziert werden,
dazu nutzt JBoss 7 Infinispan, eine ebenfalls als JBoss-Projekt
entwickelte Open-Source-Implementierung eines verteilten Caches.
Die Daten können dabei auf alle anderen Server des Clusters repliziert
werden. Obwohl hierfür Multicast eingesetzt werden kann,
skaliert diese Standard-Replikation nicht gut, da der Speicherbedarf
auf jedem Server linear mit der Anzahl der Knoten im Cluster wächst.
Infinispan bietet als Lösung für größere Cluster ein Verteilungsverfahren
an, bei dem nur eine definierbare, kleine Anzahl von Replikaten
erstellt wird. Dieses Verfahren skaliert recht gut, verfügt aber
naturgemäß über nicht ganz so hohe Ausfallsicherheit. In der Version
7.1 des JBoss ist es allerdings noch nicht fehlerfrei implementiert.
Dies sollte aber mit der derzeit im Pre-Release befindlichen Version
7.2 der Fall sein.
Weitere Dienste im JBoss-7-Cluster
Die Sitzungsdaten von Stateful EJBs können analog zur Web Session
repliziert werden. Die Remoting-Komponente von EJBs enthält zudem
einen Load Balancer in Form eines Proxies, der Remote-Aufrufe
der EJBs an die verschiedenen Knoten des Clusters verteilt und sich
ähnlich zu mod_cluster anpasst, wenn Server ausfallen oder hinzukommen.
4

Der Messaging-Dienst des JBoss 7 – HornetQ – ist ebenfalls clusterfähig:
Der Versand von Point-to-Point-Meldungen geschieht lastverteilt
auf die verschiedenen Server. Im Publish/Subscribe-Modus
werden die Meldungen auf alle Server repliziert, wenn dort ein
entsprechender Empfänger vorhanden ist. Der Meldungsempfang
geschieht immer nur von einem Knoten – dem, an dem der Empfänger
sich angemeldet hat. Im Falle eines Serverausfalls organisiert
sich HornetQ automatisch neu, d. h. die Meldungsverteilung bezieht
immer die derzeit laufenden Server ein. Die Meldungen des ausgefallenen
Knotens sind nicht verloren, wenn sie persistent versendet
wurden. Sie können nach dem späteren Start des ggf. reparierten
Servers weiter verarbeitet werden.
Der Java-Persistence-Provider im JBoss 7 – Hibernate – kann als Second
Level Cache Infinispan nutzen. Der Cache ist damit auch clusterfähig,
wobei hier i. d. R. keine Replikation der Daten genutzt wird
– die sind ja ohnehin in der DB. Vielmehr wird nach der Veränderung
eines persistenten Objektes auf einem Knoten Infinispan zur Invalidierung
der entsprechenden Cache-Einträge der restlichen Knoten
genutzt. Die Infinispan-Integration in der Version 7.1 des Servers
enthält allerdings noch einige Bugs, die die Nutzung des Second Level
Caches derzeit verhindern. Hier liegt die Hoffnung also ebenso
wie zuvor auf der angekündigten Version 7.2.
Fazit
JBoss 7 enthält eine umfangreiche Unterstützung für das Clustering
von Java-EE-Anwendungen, die alle wesentlichen Bereiche abdeckt.
Die Cluster-Features sind allerdings erst spät integriert worden und
befinden sich teilweise noch in der (Weiter-) Entwicklung, so dass
in Teilen noch Einschränkungen zu beachten sind. Die kommende
Version 7.2 wird diese Mängel voraussichtlich beheben.
Zum Thema JBoss 7 führen wir in Kooperation mit unseren Seminarpartnern
Seminare durch, die auch das Thema Clustering abdecken.
Sprechen Sie uns gerne dazu an!
Dirk Weil [ dirk.weil@gedoplan.de ]
Geschäftsführer GEDOPLAN GmbH, darüber hinaus ist er Autor in Fachmagazinen, hält
Vorträge und leitet Seminare und Workshops aus einem eigenen Java-Curriculum.
5

Vergleich der Netzwerklast -
Vaadin vs. JSF
Bei Vaadin und JSF handelt es sich um serverseitig gesteuerte Webframeworks, welche einen Großteil
der Steuerungslogik auf dem Server verrichten und den Client (Browser) hauptsächlich für eine reine
Darstellung der GUI verwenden. Diese Architektur könnte daher für einen erhöhten Netzwerkverkehr
gegenüber einer Rich-Client-Anwendung (z. B. GWT) sorgen. Insbesondere im Zusammenhang mit
Vaadin wird dieser Aspekt oft als ein Nachteil des Frameworks aufgeführt. Dementsprechend lag
es nahe, einmal genauer zu untersuchen, wie sich die Webframeworks bezüglich ihrer verursachten
Netzwerklast verhalten.
Von Hendrik Jungnitsch
Testumgebung
Zuerst muss eine geeignete Testanwendung für den Vergleich konzipiert
werden. Diese soll zwar nicht allzu komplex sein, da eine
vergleichbare Implementierung sowohl in Vaadin als auch in JSF
notwendig ist, allerdings ist es natürlich wünschenswert, dass die
Anwendung möglichst viele verschiedene Anwendungsfälle abdeckt.
Somit soll die Testanwendung folgende Elemente beinhalten, um einen
einigermaßen umfassenden Vergleich zu gewährleisten:
• Zwei verschiedene Seiten (Seitenwechsel) (Seiten müssen
„bookmarkable“ sein)
• Anzeigen von Datensätzen (Tabelle) (laden vom Server)
• Auswahl von Datensätzen
• Bearbeiten von Datensätzen (speichern auf Server)
• Validierung der Eingaben
• Felder mit Validierung bei Verlassen des Feldes validieren
• Formatierung von Feldinhalten
• Ein-/Ausblenden eines Bereichs
• Hinzufügen, Entfernen von Elementen
• De-/aktivieren von Feldern
• Anzeigen von Bildern
Testanwendung
Bei der aus diesen Überlegungen entstandenen Mini-Anwendung
handelt es sich um eine Kundenstammdaten-Verwaltung, welche auf
der ersten Seite eine Übersichtstabelle über alle Datensätze bietet.
In der Tabelle kann ein Datensatz ausgewählt und anschließend über
einen Button „Bearbeiten“ auf einer neuen Seite verändert werden.
Alle zu validierenden Felder werden jeweils gleich nach Verlassen
ausgewertet. Um das Formular etwas komplexer zu gestalten, gibt
es einen Bereich für das Verwalten der Kontaktdaten des Kunden,
welcher aus- und eingeklappt werden kann. In der tabellarischen
Ansicht besteht die Möglichkeit, Kontakte zu ändern, zu löschen und
hinzuzufügen.
Die Anwendungen sind gegen ein gemeinsames Backend, welches
die Daten- und Serviceklassen umfasst, programmiert.
Für die Vaadin-Variante kommt das neue View-und-Navigator-Konzept
von Vaadin 7 zum Einsatz, um den Seitenwechsel zu realisieren.
Das Template für die Seiten ist über die entsprechende Implementierung
der UI-Klasse realisiert. Um den Vergleich realistisch zu
gestalten, wird JSF nicht „pur“, sondern mit der Aufsatzbibliothek
Primefaces verwendet. Dies zum einen aus dem Grund, dass in der
Praxis JSF meist mit entsprechenden Komponentenbibliotheken zusammen
genutzt wird und zum anderen, um ein ähnlich komplexes
Theming und vergleichbare Ajax-Funktionalitäten zu erhalten, wie
dies bei Vaadin der Fall ist. Denn es ist wohl davon auszugehen, dass
durch die dafür benötigten CSS- und JavaScript-Dateien ein nicht
unbedeutender Teil der Netzwerklast verursacht wird. Die Navigation
in der JSF-Anwendung erfolgt, wie man es in der Praxis wohl auch
umsetzen würde, mit Hilfe von Outcomes und Navigation-Rules.
8

Testaufbau
Die Testanwendungen laufen auf einem JBoss-Server, die Testzugriffe
erfolgen von einer anderen Maschine aus, um „echten“ Netzwerkverkehr
zu generieren. Um dabei die anfallende Netzwerklast
festzuhalten, kommt das Programm Wireshark zum Einsatz. Zugriffe
von mehreren Clients gleichzeitig werden mit Hilfe von JMeter simuliert.
Alle Daten werden vorerst in nichtkomprimierter Form zwischen
Client und Server ausgetauscht.
Ein Testdurchlauf beinhaltet insgesamt 22 verschiedene Aktionen,
die auf der Web-GUI ausgeführt werden.
Vermutungen vor dem Test
Wahrscheinlich werden sich Vaadin und JSF +Primefaces nicht großartig
unterscheiden, was das verursachte Datenvolumen angeht. Auf
der einen Seite müssen erst einmal die Funktionalität (JavaScript)
und das Theme (CSS, Bilder) geladen werden, zum anderen müssen
in beiden Fällen die zu verarbeitenden Daten in gleichem Umfang an
den Server bzw. zum Client übertragen werden.
Ein Blick auf die IO-Graphen aus Wireshark bestätigt diese Vermutung:
Abbildung1 : IO-Graph Vaadin
Testergebnisse
Bei 100 Durchläufen ergaben sich folgende Werte für das jeweilige
gesamte Datenvolumen:
Vaadin: 140,52 MB
JSF+Primefaces : 178,20 MB
Traffic Vaadin JSF
Gesamtvolumen 140,52 MB 178,20 MB
HTTP-Requests 4500 4100
Pakete 143251 178607
durchschn. Paketgröße 1028 106
Der erste Eindruck nach diesem Ergebnis ist wohl, dass Vaadin zwar
weniger Traffic in diesem Test verursacht hat, allerdings nicht wirklich
so viel weniger, als dass man daraus jetzt sofort eine notwendig
optimalere Netzwerklast gegenüber JSF schlussfolgern könnte. Die
Unterschiede könnten sich zum Beispiel allein aus dem Umfang der
jeweils verwendeten Themes ergeben. Um also eine genauere Aussage
treffen zu können, liegt es nahe, einen Blick auf die Größe der
Dateien zu werfen, welche zu Beginn bei Aufruf der Seite geladen
werden.
Bei Erstaufruf der JSF Seite ergeben sich insgesamt 444 KB, wovon
407 KB für die Primefaces Styles und JavaScript-Dateien anfallen.
Nun würde man vielleicht vermuten, dass diese anfängliche „Ladelast“
bei Vaadin etwas geringer ausfällt, was allerdings nicht der Fall
ist. Bei Vaadin werden zu Beginn 1,3 MB übertragen, wovon gut 1
MB für die JavaScript-Engine und 200 KB für den Style bei draufgehen.
Die am Anfang zu ladenden Daten sind also bei Vaadin deutlich
umfangreicher als dies bei JSF der Fall ist. Was dann natürlich die
Frage aufwirft, wie es dann möglich ist, dass Vaadin unter dem Strich
doch ein geringeres Datenvolumen verursacht.
Die nächstliegende Erklärung ist wohl, dass alle weiteren Aktionen,
die auf der Vaadin-Anwendung aufgerufen werden, einfach entsprechend
weniger Netzwerkverkehr verursachen.
Abbildung2 : IO-Graph JSF
Das dargestellte Szenario hat sich durch Nutzung von 100 JMeter
Threads, die innerhalb einer Ramp-up-Zeit von 120s gestartet wurden,
ergeben. Daran ist deutlich zu sehen, dass Vaadin nach dem
anfänglichen Laden für alle weiteren Aktionen wesentlich weniger
Bandbreite benötigt, als dies bei JSF der Fall ist. Das führt dazu, dass
für die JSF-Anwendung zum einen, auch nach Initialisieren aller Sessions
der Netzwerkverkehr nicht so stark abfällt, zum anderen aber
auch die Höchstwerte deutlich über denen der Vaadin-Applikation
liegen.
Wie aber kommt es zu diesem doch recht deutlichen Unterschied?
Da davon auszugehen ist, dass wohl die meisten Daten bei Seitenwechsel
übertragen werden, schauen wir uns diesen genauer an: Bei
der Vaadin-Anwendung werden bei dem Wechsel von der Übersicht
in die Detailbearbeitung 7,2 KB übertragen, bei JSF sind es dagegen
255 KB. Dies liegt zum einen daran, das hier noch eine Primefaces
JavaScript-Bibliothek nachgeladen wird, die erst auf dieser Seite
zum Einsatz kommt, zum anderen ist aber auch die Seite selber mit
28 KB doch deutlich größer. Die größere Datenmenge für die Seite
selbst kann durch die Art und Weise, wie die Navigation in Vaadin
und JSF realisiert ist, erklärt werden. Bei JSF wird bei Nutzung der
standardmäßigen Navigationsfunktion (mit Redirekt) die komplette
Seite neu geladen, was auch durch die Nutzung eines Templates
nicht geändert wird. Dagegen arbeitet Vaadin 7 in der Art, dass das
Template (UI) erhalten bleibt und nur der Inhaltsbereich gegen die
aktuelle View ausgetauscht wird. Dies gilt wie bereits angemerkt unter
der Voraussetzung, dass jeweils die Standardmechanismen für die
Navigation zum Einsatz kommen.
Allerdings ist der Navigationsaspekt hier nicht der einzige Unterschied
zwischen den beiden Frameworks. Die Datenmenge, die bei
einer Aktion zu übertragen ist, wird auch durch die unterschiedlichen
Datenaustauschmechanismen beeinflusst. Während, im Falle von
JSF, auch bei AJAX-Anfrage immer XHTML-Fragmente zurückgelie-
9

fert werden, um einen Bereich zu aktualisieren, findet der Austausch
bei Vaadin mit Hilfe der Frameworkeigenen UIDL, welche auf JSON
Basis realisiert ist, statt. Mit Hilfe dieser UIDL ist es möglich, die
Informationen in einer deutlich kompakteren Form auszutauschen.
Optimierung Vaadin
Ein extrem großer Teil des Datenverkehrs wird allein von der JavaScript-Engine
und insbesondere dem sogenannten Widgetset,
welches die Clientseitige Implementierung der Oberflächenkomponenten
beinhaltet, verursacht. Um also die Netzwerklast einer Vaadin-Anwendung
zu reduzieren, kann es sinnvoll sein, das Widgetset
noch einmal mit dem GWT-Compiler zu übersetzen. Mit Hilfe einer
eigenen BundleLoaderFactory kann für die einzelnen Komponenten
festgelegt werden, ob diese sofort bei Anwendungsstart oder „lazy“
im Programmverlauf geladen werden sollen. Wenn nur die Widgets,
die auch wirklich in der Anwendung benötigt werden, für das Eager-
Loading gekennzeichnet sind, so reduziert sich die Größe des Widgetsets
deutlich. Bei der hier vorgestellten Testanwendung konnte
eine Reduktion von ca. 1 MB auf gut 600 KB erzielt werden. Insgesamt
belief sich das Datenvolumen bei 100 Durchläufen nun nur
noch auf 101,17 MB gegenüber den vorher gemessenen 140,52 MB.
Optimierung JSF
Hier ist kein so offensichtlicher Optimierungsansatz gegeben. Sicher
würde die Anwendung anfänglich weniger Daten laden müssen, würde
man auf Primefaces verzichten, allerdings stände dann auch bei
weitem nicht der Funktionsumfang, wie er von Vaadin geboten wird,
zur Verfügung. Eine Möglichkeit, die Datenlast etwas zu senken,
bestünde darin, auf das Navigieren mit Redirect zu verzichten und
dafür zu sorgen, dass bei Seitenwechsel auch nur der Inhaltsbereich
per AJAX ausgetauscht wird, was dann allerdings erst einmal den
Verzicht auf Bookmarkable-URLs nach sich ziehen würde.
Optimierung Allgemein
Um für eine deutliche Absenkung der zu übermittelnden Datenmenge
zu sorgen, können die Seiteninhalte auch in gzip-komprimierter
Form an den Client ausgeliefert werden, sofern dieser das unterstützt.
Mit Hilfe der Datenkompression ist es gelungen, das gesamte
übertragene Datenvolumen, das in dem Testszenario angefallen ist,
im Falle von JSF auf 58,25 MB und bei der optimierten Vaadin-Anwendung
auf 36,92 MB zu drücken.
Überblick Datenmenge mit und ohne Optimierung:
Datenvolumen
Vaadin 140,52
JSF 178,20
Vaadin optimiert 101,17
Datenvolumen
durchschn. Paketgröße 58,25
Vaadin optimiert + GZIP 36,92
Fazit
Vaadin hat in diesem Testszenario eine geringere Netzwerklast verursacht
als JSF, was hauptsächlich über den AJAX-gestützten Seitenwechsel
und die UIDL, für den Informationsaustausch zwischen
Server und Client, zu erklären ist. Allerdings kann daraus natürlich
nicht allgemeingültig geschlossen werden, dass Vaadin-Programme
immer einen Vorteil in dieser Hinsicht gegenüber JSF-Anwendungen
haben. Schon allein der Einsatz einer anderen Komponentenbibliothek
für JSF oder das Implementieren einer AJAX-gestützten Navigation
könnten hier für einen großen Unterschied sorgen. Auch über
Nutzung eines anderen Themes könnte die Menge und Größe der zu
übertragenden Dateien beeinflusst werden.
Auffällig war vor allem bei Vaadin, dass der bei weitem größte Teil
der Datenmenge allein von dem anfänglichen Laden der Anwendung
herrührt. Das ist insofern interessant, als im Allgemeinen davon ausgegangen
wird, dass es sich bei der Datenlast, die durch das Verarbeiten
aller Aktionen auf dem Server entsteht, um einen der großen
Nachteile dieses Frameworks handelt. Natürlich ist bei solch einer
AJAX-gestützten Vorgehensweise die Anzahl der Anfragen an den
Server insgesamt größer, die Datenmengen, die dabei entstehen, fallen
allerdings wohl verhältnismäßig gering aus.
Es bleibt also festzuhalten, dass die Serverseitige Steuerung, die Vaadin
und JSF zu Grunde liegt, nicht unbedingt zu einer unverhältnismäßig
hohen Datenmenge führen muss. Daten für den Aufbau von
Seiten/Views und Styles sowie natürlich auch die in der Anwendung
darzustellenden und zu verarbeitenden Daten müssen bei jeder Webanwendung
zwischen Client und Server ausgetauscht werden. Wobei
es natürlich sehr schwer ist, hier allgemeine Aussagen diesbezüglich
zu treffen. Wenn man z. B. bei einer Webanwendung davon ausgeht,
dass diese von den Benutzern nur einmal am Tag geladen wird und
anschließend zehntausende verschiedene Aktionen darauf ausgeführt
werden, dann fällt natürlich auch irgendwann das Übertragen
jeweils kleiner Datenmengen (z. B. Validierung eines einzelnen Wertes)
stärker ins Gewicht.
Zur Optimierung von Webanwendungen empfiehlt es sich auf jeden
Fall, diese auch mit GZIP-Encoding anzubieten, da dies vor allem bei
den großen JavaScript-/CSS-/XML-/JSON-Dateien zu einer erheblichen
Reduktion des Datenvolumens führen kann.
Hendrik Jungnitsch [hendrik.jungnitsch@gedoplan.de ]
Entwickler und Trainer im Bereich Java bei der Gedoplan GmbH. Sein Tätigkeitsschwerpunkt
ist das Realisieren von Java-EE-basierten Webanwendungen.
10

Systeme für die Anwender
- User Centered Design
Bei einer neuen Anwendung steht die Funktionalität im Mittelpunkt. Die Anforderungen werden mit
verschiedenen Methoden wie Use Cases, Klassendiagrammen und Prototypen der Masken definiert.
So wird sichergestellt, dass jede Aufgabe des Anwenders irgendwie mit dem System durchgeführt
werden kann. Aber ist das ausreichend für ein erfolgreiches System? Es ist nicht nur wichtig, was
ein System leistet, sondern auch, wie es die Anwender unterstützt. Das System soll die Aufgaben der
Anwender optimal aus ihrer Sicht unterstützen. Der Anwender ist ebenso wichtig wie die Funktionalität.
Nur so wird ein System akzeptiert und damit erfolgreich.
Von Reinhard Brüggemeyer
Vom Modell zum Design
Die Klassenmodelle beschreiben genau die Objekte, die im System
verwaltet werden sollen. Dabei liefert das Modell auch die Beziehungen
zwischen den Objekten. So hat eine Person verschiedene
abhängige Objekte wie Anschriften, Bankverbindungen und Konten.
Der Name, das Geburtsdatum und weitere Angaben zur Person werden
auf dem Hauptschirm verwaltet. Für jedes Unterobjekt der Person
gibt es einen eigenen Reiter. So können Anschriften, Bankverbindungen
und Konten zur Person verwaltet werden. Das User Interface
entspricht exakt dem Klassenmodell. Spezielle Sichten der Anwender
sind allerdings nicht berücksichtigt.
Use Cases beschreiben die Funktionen, die die Anwender benötigen.
Wie können die Use Cases im UI Design abgebildet werden? Es ist
sicherlich zu einfach, alle Use Cases zu einem Objekt zusammenzufassen
und in einem Dialog abzubilden. Ein Antrag muss geprüft, korrigiert,
berechnet und abgeschlossen werden. Evtl. muss der Antrag
storniert werden. Es ist nicht sinnvoll, die gesamte Funktionalität
in einem Dialog abzubilden. Der Dialog würde viel zu komplex. Die
Funktionen werden ja auch nicht alle von denselben Personen ausgeführt.
Es macht also Sinn, Personen in Anwendergruppen aufzuteilen
und dafür Rollen zu bilden. Für die Verwaltung des Antrages gibt es
dann mehrere Sichten, die jeweils die speziellen Anforderungen einer
Rolle berücksichtigen.
Usability, wie wird der Anwender unterstützt
Anwenderfreundliche Systeme sind unbestritten das Ziel der Softwareentwicklung
– doch wie kann dies beurteilt werden? Die ISO
9241 Software Ergonomie liefert folgende Definition: Usability ist
das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem
bestimmten Nutzungskontext genutzt werden kann, um bestimmte
Ziele effektiv, effizient und zufriedenstellend zu erreichen. Die Anwendung
soll …
• die Ziele des Anwenders unterstützen
• Selbsterklärend sein
• standardgemäße Oberflächenelemente bieten
• Dem Benutzer die Steuerung überlassen, nicht umgekehrt
• Möglichkeiten zur Individualisierung bieten
Usability Engineering stellt in den Vordergrund, wie ein System gestaltet
wird. User Centered Design stellt die Sicht des Anwenders in
den Mittelpunkt. Aber wer ist überhaupt unser Anwender? Ein Modell
des Anwenders wird durch „Personas“ erstellt.
User Centered Design, der Anwender steht im Mittelpunkt
User Centered Design betrachtet die verschiedenen Nutzungsszenarien
einer Anwendung. Szenarien werden von verschiedenen Anwendergruppen
aufgerufen. Die Navigation und das Design sind für die
gesamte Anwendung einheitlich. Die Interaktion mit dem System ist
durchaus abhängig von der Anwendergruppe. Ein Anwender, der permanent
mit dem System arbeitet, erwartet eine andere Interaktion
als jemand, der sporadisch das System zu Recherchezwecken nutzt.
Die Erwartungen der User an das System sind der entscheidende Input
beim User Centered Design.
Eine Anwendung zeichnet sich durch einfache Navigation, freundliches
Design und intuitive Interaktion aus. Die Navigation ist einfach
zu finden und auf allen Seiten gleich. Alle Seiten sind klar benannt
und der Anwender weiß über den „breadcrumb“ immer, wo er
sich befindet. Das Design von Seiten mit ähnlicher Funktionalität
ist weitgehend identisch. Der Seitenaufbau entspricht einer festen
Struktur. Meldungen und Kontextinformationen erscheinen immer
an derselben Position. Farben, Schriftgrößen und Schriftarten sind
11

für die gesamte Anwendung vorgegeben. Die Benutzerinteraktion
legt den Focus auf die wichtigsten Funktionen. Sie werden zentral,
möglichst oben auf der Maske dargestellt. Der Anwender kann Informationen
von „high level“ nach „low level“ verfolgen. Die natürliche
Bedienungsreihenfolge ist offensichtlich. Die Anzahl der Steuerungselemente
ist minimiert. Es werden Standardelemente mit exakten
Bezeichnungen genutzt.
Moderne Systeme entlasten Anwender von Routineaufgaben. Standardfälle
werden automatisch durch eine Dunkelverarbeitung abgewickelt.
Die Steuerung erfolgt über ein integriertes Workflowsystem.
In Ausnahmefällen, die durch Regeln vom Workflowsystem erkannt
werden, wird eine manuelle Bearbeitung erforderlich. Das System
stellt die Vorgänge in anwenderspezifische Postkörbe. Die jeweilige
Ausnahme wird transparent dargestellt. Der Anwender ruft vom
Postkorb direkt die Funktionalität auf, die er zur manuellen Bearbeitung
benötigt. So ist bei Workflowsystemen eine spezifische Benutzerinteraktion
implementiert, die den Anwender direkt zur benötigten
Funktionalität führt.
„Persona“, wer ist unser Anwender
In welchen Szenarien arbeitet unser Anwender, wie sind seine Arbeitsbedingungen
und welche Funktionen benötigt er überwiegend?
Diese und ähnliche Fragen stellen wir uns, um eine Vorstellung von
den zukünftigen Anwendern des Systems zu bekommen. Wir wollen
ein Modell von unseren Anwendern entwerfen. Bereits 1995 hat
Alan Cooper die Methode „Personas“ beschrieben. „Personas“ sind
erdachte Personen, die auf den Verhaltensmustern und Zielen der
Anwender basieren. Es sind Beschreibungen von fiktiven Anwendern
für ein interaktives System. Sie entstehen aus der Diskussion mit den
Projektbeteiligten und liefern ein grundlegendes Verständnis von den
Anwendergruppen. „Personas“ sind Kommunikationswerkzeuge. Im
Normalfall hat ein Projekt maximal 3 – 5 „Personas“. Eine „Persona“
ist stellvertretend für eine Gruppe von Mitarbeitern. Über eine Matrix
der unterschiedlichen Mitarbeitergruppen und zugeordneten Aufgaben
werden die verschiedenen „Personas“ ersichtlich.
12

Die Unterscheidung der Anwendergruppen erfolgt in erster Linie
durch Gruppierung der notwendigen Funktionalität. Darüber hinaus
ist aber auch der Anwendertyp von Bedeutung. Wie häufig benutzt er
das System? Benötigt er detaillierte oder verdichtete Informationen?
Ist schnelle oder selbsterklärende Navigation gewünscht? Soll das
System, wenn möglich, Werte vorschlagen?
Nach diesen Kriterien definieren wir „Personas“ für die Sachbearbeitergruppen
und Anwendertypen. Eine „Persona“ bekommt einen
Namen und bestimmte Eigenschaften. Anhand dieser Beschreibung
wird überprüft, ob das Anwendungsdesign unsere „Persona“ optimal
unterstützt. So benötigt unser Antragssachbearbeiter in bestimmten
Situationen Zusatzinformationen aus der Stammdatenverwaltung.
Dazu musste aufwendig in die Stammdatenverwaltung navigiert
werden. Das Design wurde so geändert, dass der Sachbearbeiter aus
der Antragsbearbeitung direkt ein Kontextmenu mit den entsprechenden
Informationen aufrufen kann.
System zu gestalten ist. Sie gelten übergreifend für alle Funktionen
und treffen keine Unterscheidung nach Anwendergruppen. In
der Praxis zeigt sich aber, dass ein System von unterschiedlichen
Gruppen genutzt wird. User Centered Design berücksichtigt diesen
Aspekt. „Personas“ liefern ein Konzept, unterschiedliche Anwendergruppen
zu definieren und zu beschreiben. Sie liefern den Input für
das Anwendungsdesign. Nach den Grundsätzen des Usability Engineering
werden das Navigations- , Design- und Interaktionskonzept
entwickelt. Das erstellte Design kann jederzeit gegen die „Personas“
verifiziert werden.
Fazit
Im klassischen Requirements Engineering wird zwischen funktionalen
und nicht funktionalen Anforderungen unterschieden. Die nicht
funktionalen Anforderungen sollen den Input dafür liefern, wie das
Reinhard Brüggemeyer [ reinhard.brueggemeyer@gedoplan.de ]
Seniorberater GEDOPLAN GmbH. Seine Schwerpunkte sind Anforderungsanalyse, Modellierung
von Geschäftsprozessen und Projektmanagement – insbesondere agile Vorgehensweisen.
13

- Anzeige -
Java-Schulungsprogramm 2013
Objektorientierung, Java SE, Java EE, Tools, Testing & mehr.
IPS bietet professionelle Einsteiger- und Umsteigerschulungen für Java und die Java Enterprise Edition (Java EE). Auf Wunsch organisieren
wir für Entwicklerteams auch Projektworkshops.
"Java ist eine zuverlässige Plattform zur objektorientierten Softwareentwicklung, die eine weitreichende Standardisierung mit der
notwendigen Offenheit kombiniert und die durch eine große Community getragen und weiterentwickelt wird. Zum Erfolg von Java
tragen sicher auch die hervorragenden Entwicklungswerkzeuge und die große Menge frei verfügbarer Tools und Bibliotheken bei."
Dirk Weil, IPS-Trainer, Fachautor und Leiter des Enterprise Java Teams.
JJava und Java EE
Java - Programmierung (Java SE) Tage € zzgl. MwSt. Kurscode
Java für Programmierer ohne Vorkenntnisse der Objektorientierung 5 1.940,-- JAV-100-OOJ
Java für Umsteiger einer objektorientierten Programmiersprache 4 1.680,-- JAV-105-OOU
Java Effective 2 1.070,-- JAV-130-EFF
Java Performance Tuning 3 1.290,-- JAV-120-JPT
Refactoring 2 1.080,-- JAV-350-REF
Grundlagen Java SE Security 1 520,-- JAV-500-SEC
Java - Java Edition (Java EE) Tage € zzgl. MwSt. Kurscode
Power Workshop Java EE 6 5 2.125,-- JAV-310-JEE
Java-EE-Überblick: Workshop mit Dirk Weil 1 590,-- JAV-300-JEE
Enterprise JavaBeans (EJB 3) mit JPA 4 1.790,-- JAV-321-EJB
Java-Anwendungsentwicklung mit CDI 2 960,-- JAV-360-CDI
Liferay 2 960,-- JAV-900-LRP
Java Persistence API (JPA) 3 1.390,-- JAV-330-JPA
Java-Webanwendungen mit JavaServer Faces (JSF) 4 1.790,-- JAV-350-JSF
Enterprise Java für Architekten 2 1.070,-- JAV-305-JEE
Java EE Design Patterns 3 1.590,-- JAV-340-DES
Java - Entwicklerwerkzeuge Tage € zzgl. MwSt. Kurscode
Eclipse - Grundlagen 1 520,-- DEV-120-ECL
Eclipse Modeling Framework (EMF) 2 1.100,-- DEV-140-EMF
Apache-Maven-Grundlagen 1 520,-- DEV-300-MVN
Build- und Release-Management mit Apache Maven 2 960,-- DEV-310-MVMB
Hudson / Jenkins- Grundlagen 1 520,-- DEV-400-HUD
IPS IT-Schulungen - Ihr deutschlandweiter Partner für IT-Schulungen
Nutzen Sie die Erfahrung aus mehr als 20 Jahren IT-Schulungen für Einsteiger, Umsteiger und Professionals. Der IPS-Kurskatalog 2012/2013
umfasst über 300 Kurse zu aktuellen IT-Themen. Das IPS-Team unterstützt Sie persönlich, professionell und lernzielorientiert.
Berlin - Bielefeld - Hamburg - Hannover - Köln - Krefeld - Nürnberg - Wiesbaden - Stuttgart
Sprechen Sie uns an – wir beraten Sie gerne! Tel. (0521) 2088930 Beratung@IPS-IT-Schulungen.de www.IPS-IT-Schulungen.de

- Anzeige -
Individuelle Firmenschulungen
Viele Unternehmen nutzen die Kursbeschreibungen im offenen IPS-Schulungsprogramm als Ausgangspunkt für die Planung individueller Firmenschulungen.
Unter Berücksichtigung von Vorkenntnissen, Unternehmensvorgaben und gewünschten Zielen erarbeiten wir daraus gemeinsam mit
Ihnen maßgeschneiderte Weiterbildungsangebote. Durchführung bei IPS oder bei Ihnen vor Ort.
Java Application Server
JBoss Tage € zzgl. MwSt. Kurscode
Entwicklung und Betrieb von Anwendungen auf JBoss AS 7 3 1.520,-- JBO-AS-ADM7
Hochverfügbarkeit mit dem JBoss AS 7 3 1.390,-- JBO-AS-HOCH7
JBoss - Clustering 2 960,-- JBO-AS-CLUS
JBoss EAP6 – Eintägige Update-Schulung 1 520,-- JBO-AS-UPD6
Java und SAP Tage € zzgl. MwSt. Kurscode
SAP NetWeaver - Entwicklung von Java EE - Anwendungen 5 auf Anfrage SAP-NETW-JEE71
Softwareentwicklung und Datenbanken
Java Frameworks Tage € zzgl. MwSt. Kurscode
Spring Framework Grundlagen 3 1.490,-- JAV-600-SPR
Spring Web-Service 2 990,-- JAV-610-SPR
Java-Webanwendungen mit Vaadin 3 1.490,-- DEV-400-VAA
Google Web Toolkit (GWT) - Grundlagen 3 1.520,-- JAV-150-GWT
Grails 2 1.130,-- JAV-130-GRA
Java Software Testing Tage € zzgl. MwSt. Kurscode
Java Software Testing-Grundlagen 1 520,-- JAV-400-STG
Java Software Testing in der Praxis 4 1.790,-- JAV-410-STP
Java Software Testing für die Enterprise Edition 4 1.790,-- JAV-420-STE
Oracle Tage € zzgl. MwSt. Kurscode
Oracle - Datenbankprogrammierung mit PL/SQL Grundlagen 5 1.890,-- DB-ORA-02
Oracle - Datenbankprogrammierung mit PL/SQL Aufbau 3 1.290,-- DB-ORA-34
Oracle - Real Application Cluster (RAC) und Grid Infrastructure 5 1.990,-- DB-ORA-08
IPS-Kurse im Internet suchen und buchen
Mehr über Inhalte, Termine, Voraussetzungen etc. unter www.ips-it.de/< Kurscode>
Suchbeispiel: www.ips-it.de/JAV-100-OOJ
Berlin - Bielefeld - Hamburg - Hannover - Köln - Krefeld - Nürnberg - Wiesbaden - Stuttgart
Sprechen Sie uns an – wir beraten Sie gerne! Tel. (0521) 2088930 Beratung@IPS-IT-Schulungen.de www.IPS-IT-Schulungen.de

GEDOPLAN ist seit über 30 Jahren spezialisiert auf die Entwicklung
von IT-Systemen. Unsere Experten haben langjährige Erfahrung
in der Analyse, Konzeption und Realisierung von Unternehmenssoftware.
Individuallösungen realisieren wir auf Basis objektorientierter
Techniken. Die leistungsfähige und umfangreiche Plattform Java
EE bildet dafür schon seit über 10 Jahren einen unserer Schwerpunkte.
Es ist unser Anspruch, gut strukturierte und wartbare
Anwendungen zu entwickeln. Mit modernen Entwicklungsumgebungen
und entwicklungsbegleitenden, automatisierten Tests
stellen wir eine hohe Softwarequalität sicher.
Im Bereich der Standardsoftware unterstützen wir Sie bei der
Einführung und Anpassung von SAP®-Lösungen, insbesondere in
Fragen der Basis-Administration und des Personalmanagements.
Anpassungen oder Erweiterungen können wir mit ABAP und
Java auf Basis von SAP® NetWeaver durchführen.
Wir entwickeln IT-Systeme als Komplettpakete, unterstützen unsere
Kunden aber auch vor Ort. Unsere Experten geben ihr Wissen
gerne weiter – in Form von projektbegleitenden Coachings
oder Seminaren bei unseren Schulungspartnern.
GEDOPLAN
Unternehmensberatung und
EDV-Organisation GmbH
Stieghorster Straße 60
33605 Bielefeld
Fon: 0521 2 08 89 10
Fax: 0521 2 08 89 45
E-Mail: info@gedoplan.de
Herausgeber: GEDOPLAN Unternehmensberatung und EDV-Organisation GmbH | Stieghorster Straße 60 | 33605 Bielefeld
Verantwortlich: Dipl.-Inform. Dirk Weil | Redaktionsleitung: Ulrich Hake | Fon: 0521 2088910 | E-Mail: info@gedoplan.de
Produktion: networker Medienfabrik GmbH | Nachdruck, auch auszugsweise, nur nach Rücksprache mit der Redaktion.
www.gedoplan.de