Diplomarbeit

Diplomarbeit
Untersuchungen zum Einsatz von MDSD zur
Entwicklung AJAX- basierter Informationssysteme
Haubold, Tobias
geb. am 9.10.1981 in Reichenbach
Studiengang Informatik
Studienrichtung Wirtschaftsinformatik
Westsachsische Hochschule Zwickau (FH)
Fachbereich Physikalische Technik/Informatik
Fachgruppe Informatik
Betreuer, Einrichtung:
Prof. Dr. Georg Beier, WH Zwickau (FH)
Abgabetermin:
15.10.2006
Danksagung
Besonderen Dank gilt Prof. Dr. Georg Beier, welcher mir nicht nur ein interessantes
Diplomthema ermoglichte, sondern mich auch mit der Modell- getriebenen Softwareentwicklung konfrontierte. Diese hat mein Interesse so stark geweckt, dass sie einen wesentlichen Teil meiner naheren Zukunft einnehmen wird. Vielen Dank auch in die investierte
Zeit fur stundenlange Meetings und mehrmaliger Korrekturen der Arbeit, wodurch diese
in der jetzigen Form erst ermoglicht wurde.
Vielen Dank auch an Dipl.- Inf. Dirk Mittmann, der mir als Ansprechpartner von MD
Consulting fur seine Hinweise und Anmerkungen zu dieser Arbeit stets weitergeholfen
hat.
Ein groes Dankeschon gehort ebenfalls meinen Freunden fur ihr in mich gesetztes Vertrauen, sowie der notwendigen Abwechslung zur Arbeit.
Inhaltsverzeichnis
Abbildungsverzeichnis
iv
Tabellenverzeichnis
v
Quellcodeverzeichnis
vii
1 Aufgabenstellung und Motivation
1.1 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 MDSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Zusammenarbeit mit MD Consulting & Informationsdienste GmbH
1.4 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Beispielanwendung . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Anmerkung zu genutzten Technologien . . . . . . . . . . . . . .
2 AJAX Allgemein
2.1 Abgrenzung von herkommlichen Webanwendungen
2.2 Anmerkung zu Webstandards . . . . . . . . . . . .
2.3 Bedienbarkeit . . . . . . . . . . . . . . . . . . . .
2.3.1 Moglichkeiten mit AJAX . . . . . . . . . .
2.3.2 Aktualitat der Daten . . . . . . . . . . . .
2.3.3 Hindernisse bei AJAX- Webanwendungen .
2.4 Barrierefreiheit . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 AJAX Plattform
3.1 Interaktionsmechanismen . . . . . . . . . . . . . . . .
3.1.1 RESTful Service . . . . . . . . . . . . . . . .
3.1.2 RPC Service . . . . . . . . . . . . . . . . . .
3.2 Datenformate fur den Nachrichtenaustausch . . . . . .
3.2.1 URL Querystring . . . . . . . . . . . . . . . .
3.2.2 HTML . . . . . . . . . . . . . . . . . . . . . .
3.2.3 XML . . . . . . . . . . . . . . . . . . . . . . .
3.2.4 JSON . . . . . . . . . . . . . . . . . . . . . .
3.3 Umfang der AJAX Funktionalitat einer Webanwendung
3.3.1 Hybride Webanwendungen . . . . . . . . . . .
3.3.2 Single Page Applications . . . . . . . . . . . .
i
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
1
2
2
3
.
.
.
.
.
.
.
4
4
5
5
5
6
7
7
.
.
.
.
.
.
.
.
.
.
.
9
9
9
11
13
13
14
14
14
15
15
16
3.4 Integration in Client- und Server Infrastruktur
3.4.1 Serverzentrierte Webanwendungen . .
3.4.2 Clientzentrierte Webanwendungen . .
3.5 Klassizierung von Webanwendungen . . . .
3.6 Betrachtung vorhandener AJAX Frameworks
3.6.1 Auswahl . . . . . . . . . . . . . . . .
3.6.2 Mogliche Einteilung . . . . . . . . . .
3.6.3 Gegenuberstellung . . . . . . . . . .
3.7 Zusammenfassung . . . . . . . . . . . . . . .
4 Konzept einer clientzentrierten Webanwendung
4.1 Bestimmung der AJAX Infrastruktur . . . . .
4.1.1 Serverplattform . . . . . . . . . . . .
4.1.2 AJAX Plattform . . . . . . . . . . .
4.2 Architektur . . . . . . . . . . . . . . . . . .
4.2.1 Spring Architekturmodell . . . . . . .
4.2.2 Angepasstes Architekturmodell . . . .
4.3 Auswahl der Frameworks . . . . . . . . . . .
4.3.1 Dojo Toolkit . . . . . . . . . . . . .
4.3.2 Direct Web Remoting . . . . . . . .
4.4 Design einer Single Page Application . . . . .
4.5 Inhalte von Webanwendungen . . . . . . . .
4.5.1 Statische und dynamische Inhalte . .
4.5.2 Login- basierte Funktionalitat . . . .
4.6 Authentizierung . . . . . . . . . . . . . . .
4.7 History- und Bookmarkfahigkeit . . . . . . .
4.8 Das Widget System von dojo . . . . . . . . .
4.8.1 Das Properties Konzept . . . . . . .
4.8.2 Das Konzept der Platzhalter . . . . .
4.8.3 Konzept der dojo Attach Points . . .
4.8.4 Konzept von dojo Attach Event . . .
4.8.5 Wichtige Funktionen . . . . . . . . .
4.9 Anwendung des dojo Widget Systems . . . .
4.9.1 Inhalte von Widgets . . . . . . . . .
4.9.2 Data Binding . . . . . . . . . . . . .
4.9.3 Widget Beziehungen . . . . . . . . .
4.9.4 Accessibility . . . . . . . . . . . . . .
4.9.5 Internationalisierung und Lokalisierung
4.9.6 Validierung von Benutzereingaben . .
4.10 Zusammenfassung . . . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
17
17
18
19
20
20
26
27
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
30
30
30
31
32
33
33
34
36
38
39
39
39
40
41
42
43
44
45
45
48
48
48
49
50
51
53
56
58
5 Aspekte der Modell- getriebenen Softwareentwicklung
5.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Modellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1 Domain- spezische Modelle . . . . . . . . . . . . . . . . .
5.2.2 Anmerkung zur Verwendung von UML Prolen . . . . . . .
5.3 Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Allgemeines zu openArchitectureWare . . . . . . . . . . . .
5.3.2 Der MDSD Entwicklungsprozess mit openArchitectureWare
6 Videothek als Beispiel einer clientzentrierten Webanwendung
lungsprozess mit MDSD
6.1 Konzipierung . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 U bersicht der verwendeten Tools . . . . . . . . . . .
6.2 Server Infrastruktur . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Applikationsschicht . . . . . . . . . . . . . . . . . .
6.2.2 Service- Schicht . . . . . . . . . . . . . . . . . . . .
6.2.3 Persistenzschicht . . . . . . . . . . . . . . . . . . .
6.2.4 Controller- und Kommunikationsschicht . . . . . . .
6.3 Client Infrastruktur . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Controller- und Kommunikationsschicht . . . . . . .
6.3.2 Prasentationsschicht . . . . . . . . . . . . . . . . .
6.4 Weitere Aspekte im Entwicklungsprozess mit MDSD . . . .
6.4.1 Modell- Validierungen . . . . . . . . . . . . . . . . .
6.4.2 Entwicklungsunterstutzung bei der Implementierung
6.5 Die entstandene Demo- Applikation . . . . . . . . . . . . .
6.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
59
59
59
60
61
61
61
61
.
.
.
.
.
.
.
im Entwick-
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
63
65
65
66
67
69
71
72
76
83
83
85
86
88
7 Abschlussbemerkungen
90
7.1 Bewertung und Entwicklungstendenzen bei AJAX Frameworks . . . . . . 90
7.2 Einsatz von MDSD bei der Entwicklung von AJAX Webanwendungen . . 92
7.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Literaturverzeichnis
95
Thesen
103
Eidesstattliche Erklarung
104
iii
Abbildungsverzeichnis
3.1 Programmiermodell einer serverzentrierten Webanwendung aus [1] am
Beispiel Microsoft Atlas . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Programmiermodell einer clientzentrierten Webanwendung aus [1] am
Beispiel Microsoft Atlas . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Schema zur Klassizierung von Webanwendungen . . . . . . . . . . . .
3.4 Die Architektur des Microsoft Atlas Frameworks aus [1] . . . . . . . .
4.1
4.2
4.3
4.4
4.5
Das Architekturmodell von Spring fur Webanwendungen aus [2] . . . .
Architekturmodell fur clientzentrierte Webanwendungen . . . . . . . . .
Aufbau des dojo Toolkits aus [3, Seite 8] . . . . . . . . . . . . . . . .
Die Schichten der dojo Architektur aus [3, Seite 12] . . . . . . . . . .
Darstellung des Widgets 4.10 im Webbrowser vor Ausfuhrung der JavaScript Anweisung in Listing 4.12 . . . . . . . . . . . . . . . . . . . . . .
4.6 Darstellung des Widgets 4.10 im Webbrowser nach Ausfuhrung der JavaScript Anweisung in Listing 4.12 . . . . . . . . . . . . . . . . . . . .
4.7 Aufbau der Verzeichnisstruktur zur Internationalisierung eines Widgets .
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
6.12
. 17
. 18
. 19
. 22
.
.
.
.
. 46
. 47
. 54
Die Business Klassen der Videothek . . . . . . . . . . . . . . . . . . . .
Einige Service Klassen der Videothek . . . . . . . . . . . . . . . . . . . .
Das Data Access Object Pattern aus [4] . . . . . . . . . . . . . . . . . .
Die Umsetzung des Data Access Object Patterns fur die Videothek . . .
Verwendung des Business Delegate Patterns bei der Client Architektur
der Videothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modellierung eines Business Delegate der Videothek als eigenstandige
Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modellierung eines dojo Widgets als Klasse . . . . . . . . . . . . . . . .
Modellierung eines Composite Widgets . . . . . . . . . . . . . . . . . . .
Beispiel einer modellierten Widget Klasse mit Fehlern . . . . . . . . . . .
Beispielubersicht des recipe Frameworks nach ausgefuhrten U berprufungen
Darstellung aller Produkte einer Kategorie in der Videothek . . . . . . . .
Darstellung eines Produktes in der Videothek . . . . . . . . . . . . . . .
iv
32
33
34
36
66
67
68
69
72
74
78
80
85
86
87
88
Tabellenverzeichnis
3.1 Einordnung der betrachteten AJAX Frameworks nach Gliederung in Abschnitt 3.6.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Einordnung der betrachteten AJAX Frameworks nach Framework, Toolkit
und Bibliothek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Einordnung der betrachteten AJAX Frameworks nach ihren Lizenzbestimmungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Einordnung der betrachteten AJAX Frameworks nach dem Umfang der
Unterstutzung des Entwicklers . . . . . . . . . . . . . . . . . . . . . .
3.5 Einordnung der betrachteten AJAX Frameworks nach der Kategorie der
entwickelbaren Webanwendung . . . . . . . . . . . . . . . . . . . . . .
v
. 27
. 28
. 28
. 28
. 29
Quellcodeverzeichnis
3.1
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
Beispielcode in JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel zur Verwendung des dojo Package Systems in einer Webseite . .
Konguration von dojo . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bereitstellung eines Spring Beans als Remote Objekt in DWR . . . . . .
Konguration von DWR zur Konvertierung bestimmter Java Typen nach
JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Denition der Widget Properties im JavaScript Template . . . . . . . . .
Setzen der Property Werte beim Einbinden des Widgets in eine XHTML
Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Werte der Properties, nachdem der Parser diese gesetzt hat . . . . . . .
Verwendung von Platzhaltern im HTML Template eines Widgets . . . . .
Ersetzen der Platzhalter eines Widgets . . . . . . . . . . . . . . . . . . .
Verwendung von dojo Attach Points im HTML Template eines Widgets .
Zuweisung von Inhalt bei Verwendung des Widgets . . . . . . . . . . . .
JavaScript Anweisung fur den Zugri auf einen DOM Knoten mit dojo
Attach Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel zur Zuweisung von Events und Eventhandlern mit dojo Attach
Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementierung der Event- Handler im Widget Objekt . . . . . . . . . .
Bereitstellung lokalisierter Ressourcen . . . . . . . . . . . . . . . . . . .
Bereitstellung spezieller lokalisierter Ressourcen . . . . . . . . . . . . . .
Konguration des DWR Controller Servlets . . . . . . . . . . . . . . . .
Konguration eines abstrakten Proxy Objekts fur das Transaktionsmanagement als Spring Bean . . . . . . . . . . . . . . . . . . . . . . . . . . .
Konguration eines Service Objekts als Spring Bean, welches das Transaktionsmanagement von einem anderen Spring Bean erbt . . . . . . . . .
Einbindung von DWR und der JavaScript Proxy Objekte in eine Webseite
Generativ erzeugte Funktion eines Business Delegate Objekts . . . . . .
Generativ erzeugte Funktion postMixInProperties des Widgets aus Abbildung 6.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generativ erzeugte Funktion llInTemplate des Widgets aus Abbildung 6.7
Generativ erzeugte Funktion zur Aktualisierung der Darstellung des DTOs
aus Abbildung 6.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Generativ erzeugte Funktion zur Aktualisierung des DTOs gekapselter
Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
15
35
36
37
38
43
44
44
44
45
46
46
47
47
47
54
55
69
70
70
72
73
77
78
79
80
6.10 Zuweisung der Event- Handler Funktion eines Widgets zu einem deklarativ
erzeugten Button- Widget . . . . . . . . . . . . . . . . . . . . . . . .
6.11 Generativ erzeugter Code fur ein Aktions- Widget . . . . . . . . . . . .
6.12 Validierungsregel zur U berprufung der referenzierten DTOs bei Widget
Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.13 Validierungsregel zur U berprufung der referenzierten Attribute von DTOs
bei Widget Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.14 Fehlermeldungen durch Anwendung der beiden Validierungsregeln in Listing 6.12 und 6.13 auf Abbildung 6.9 . . . . . . . . . . . . . . . . . .
vii
. 82
. 83
. 84
. 84
. 85
1 Aufgabenstellung und Motivation
1.1 AJAX
AJAX1 ist ein Modebegri der sich seit einiger Zeit sehr groer Beliebtheit erfreut. Hintergrund ist ein JavaScript Objekt, das das Laden von Daten ohne Page Reload im
Webbrowser ermoglicht. Welches Potential solch eine Moglichkeit bietet, ist an der Zahl
von 134[5, Stand: 15.05.2006] verfugbarer AJAX Frameworks abzulesen. Grund genug,
die Anwendbarkeit von AJAX in Enterprise Webanwendungen genauer zu untersuchen.
1.2 MDSD
Bei der Programmierung von Software entsteht an vielen Stellen regelmaig wiederkehrender Code. Dies sind z.B. die Klassendenitionen mit Attributen und Methoden sowie
die Zugrismethoden fur einige Attribute. Solche Art von wiederkehrenden Code kann
haug von einer Entwicklungsumgebung generiert werden, da er von der Programmiersprache abhangig ist. Daneben gibt es haug auch wiederkehrenden Code, der von der
Architektur und Domain der Software abhangig ist. Hier versagen die Code- Generatoren
der Entwicklungsumgebungen und der Programmierer nutzt haug Copy and Paste. Dies
birgt naturlich Gefahren bei A nderungen des kopierten Codes. Ein Ansatz der MDSD2 ist,
den wiederkehrenden Architektur- und Domain- spezischen Code generativ zu erzeugen.
Dieser interessante Ansatz soll bei der Architektur AJAX- basierter Webanwendungen genutzt werden.
1.3 Zusammenarbeit mit MD Consulting &
Informationsdienste GmbH
Das Unternehmen MD Consulting verfolgt das Thema AJAX seit einiger Zeit. Dabei
wurde mit der Entwicklung eines AJAX Frameworks begonnen. Die Weiterentwicklung
1
2
AJAX ist die Abkurzung fur Asynchronous JavaScript and XML.
MDSD ist die Abkurzung fur Model Driven Software Development.
1
wurde aufgrund der Vielzahl vorhandener Frameworks nicht weiter verfolgt. Im Vordergrund steht die Untersuchung des Einsatzes von AJAX in Webanwendungen. Dabei soll
eine Anwendungsplattform fur AJAX- basierte Informationssysteme herausgearbeitet und
naher speziziert werden. Diese soll im praktischen Teil der Diplomarbeit mit Hilfe der
MDSD anhand einer Beispielanwendung umgesetzt werden. Die MDSD dient dabei als
Konzeptstudie bei MD Consulting. Da MD Consulting bei der Serverplattform auf die
Microsoft .Net Architektur setzt, sollte der clientseitige Teil weitestgehend plattformunabhangig sein.
1.4 Aufgabenstellung
Im ersten Teil der Diplomarbeit soll eine Anwendungsplattform fur AJAX- basierte Informationssysteme herausgearbeitet werden. Dazu gibt Kapitel 2 einen Einblick in das
Thema AJAX mit seinen Vor- und Nachteilen. In Kapitel 3 werden unterschiedliche AJAX
Plattformen betrachtet, sowie die daraus resultierenden Unterschiede bei AJAX- basierten Webanwendungen. Die Auswahl und detaillierte Betrachtung der AJAX Anwendungsplattform erfolgt in Kapitel 4.
Anschlieend beginnt mit einem kurzen Einstieg in die Modell- getriebene Softwareentwicklung in Kapitel 5 der zweite Teil der Diplomarbeit. Darauf aufbauend wird in Kapitel
6 eine Beispielanwendung mit Hilfe der Modell- getriebenen Softwareentwicklung umgesetzt.
1.5 Beispielanwendung
Fur den praktischen Teil der Diplomarbeit wurde in Abstimmung mit MD Consulting eine Videothek als AJAX- basierte Webanwendung ausgewahlt. Diese soll teilweise funktionsfahig sein und wesentliche Konzepte der ausgewahlten AJAX Plattform verdeutlichen.
Dabei werden Teile der Architektur mit Hilfe der MDSD generiert, die anschlieend fertig
implementiert werden. An dem Beispiel sollen die Anwendbarkeit und das Potential von
MDSD deutlich werden.
Das Videotheksbeispiel wird in Kapitel 6 genauer eingefuhrt, aber schon vorher zur
Erlauterung bestimmter Techniken herangezogen.
2
1.6 Anmerkung zu genutzten Technologien
Fur die Konzipierung einer Webanwendung muss zwischen einer Vielzahl von Technologien
abgewogen werden. Die nahere Betrachtung der einzelnen Technologien ist im Rahmen
dieser Diplomarbeit nicht moglich. Daher wird in solchen Fallen auf die Webseite der
jeweiligen Technologie oder auf den Artikel bei der Wikipedia[6] verwiesen, um den Leser
einen Einblick in die betrachtete Technologie zu ermoglichen.
3
2 AJAX Allgemein
2.1 Abgrenzung von herkommlichen Webanwendungen
Wie bereits in Abschnitt 1.1 erwahnt, ist AJAX ein Modebegri, der die Nutzung bereits
etablierter Webtechnologien innerhalb eines neuen Kontextes beschreibt. Dieser basiert
auf einem ActiveX Objekt von Microsoft, mit dem sich Anfragen an einen Webserver ohne
Page Reload durchfuhren lassen. Dadurch konnen Daten bezogen und angezeigt werden,
ohne den Benutzer in seinem Workow durch einen Page Reload zu unterbrechen. Dieses
Objekt wird XmlHttpRequest Objekt1 genannt und wurde von den meisten graschen
Webbrowsern nachimplementiert, wodurch es in jedem aktuellen Webbrowser verfugbar
ist. Neben den XmlHttpRequest Objekt nutzen AJAX- Webanwendungen die folgenden
Technologien:
HTML / XHTML Wird zur Strukturierung des Inhalts einer Webanwendung genutzt.
CSS Dient zur Formatierung der Elemente einer Webanwendung. Neben dem Aussehen
wird auch die Positionierung mit Hilfe von Cascading Style Sheets beschrieben.
DOM Das Document Object Model [7] dient als Schnittstelle (API2 ) fur den Zugri auf
das HTML / XHTML Dokument.
JavaScript Dient als Scriptsprache fur den Zugri auf das DOM und so zur Veranderung
der Webseite.
Im Zusammenhang mit AJAX wird auch oft DHTML3 [9] genannt, welches ebenso eine
Kombination von Technologien ist: HTML, DOM und JavaScript. Neben diesen Basistechnologien, welche jede AJAX Anwendung benotigt, gibt es noch andere, deren Nutzen
sich anbieten kann. Diese werden im Laufe der Diplomarbeit im Kontext ihrere Anwendung betrachtet.
Durch die Vermeidung von Page Reloads konnen AJAX Webanwendungen die Interaktionsmoglichkeiten zwischen Benutzer und Webseite steigern. In diesem Sinne spricht man
auch von AJAX Rich Clients.
Das XmlHttpRequest Objekt wird auch oft mit XHR- Objekt abgekurzt.
API ist die Abkurzung fur Application Programming Interface. Eine Beschreibung ist unter [8] zu nden.
3 DHTML steht f
ur Dynamic HTML.
1
2
4
2.2 Anmerkung zu Webstandards
Das von Netscape entwickelte JavaScript[10] wurde 1996 bei der ECMA4 [11] zur Standardisierung eingereicht und 1997 als ECMA-262 Version 1[12] standardisiert. Microsoft
hat zu dieser Zeit ebenfalls eine clientseitige Scriptsprache namens JScript[13] entwickelt.
JavaScript und JScript sind beides Implementierungen des ECMAScript und verfugen uber
zusatzliche Komponenten und Sprachkonstrukte. Neben diesen beiden gibt es auch noch
weitere Implementierungen des ECMAScript Standards.
In dieser Diplomarbeit wird der Begri JavaScript stellvertretend fur alle Implementierungen von Scriptsprachen in Webbrowsern benutzt, welche AJAX Webanwendungen
ermoglichen.
Neben der Scriptsprache sind die Objekte, die der Scriptsprache vom Webbrowser zur
Verfugung gestellt werden, einerseits nicht alle standardisiert und konnen andererseits
implementierungsspezische Methoden und Eigenschaften enthalten. Nicht standardisiert ist neben dem XmlHttpRequest Objekt auch das Window Objekt. Mehr zu dieser Problematik ist bei selfhtml[14] nachzulesen[15]. Das W3C5 [16] mochte allerdings
im Rahmen von Rich Web Clients [17] u.a. diese beiden Objekte standardisieren (XmlHttpRequest Objekt[18] und Window Objekt[19]). Neben dem W3C bemuht sich auch
die WHATWG6 [20] um die Standardisierung von Technologien zur Entwicklung von
Webanwendungen[21].
2.3 Bedienbarkeit
Durch die Moglichkeit der Interaktion zwischen Webbrowser und Webserver im Hintergrund der Webanwendung, ohne dem Benutzer mit einem Page Reload zu storen, haben
sich vollig neue Gestaltungsmoglichkeiten fur Webanwendungen herausgebildet. In diesem Abschnitt soll kurz gezeigt werden, welche Moglichkeiten AJAX bietet und welcher
zusatzlicher Aufwand notwendig ist.
2.3.1 Moglichkeiten mit AJAX
Sehr haug wird als Beispiel das Autocomplete - Feature genannt. Bei Eingabe eines Textes in ein Textfeld werden im Hintergrund Eingabemoglichkeiten vom Server abgerufen
und in einer Liste angezeigt. Aus dieser kann der Benutzer seinen Eintrag, sofern vorhanden, wahlen und ubernehmen. Ein Beispiel hierfur ist Google Suggest[22], welches
4
5
6
ECMA ist die Abkurzung fur European Computer Manufacturers Association.
W3C ist die Abkurzung fur World Wide Web Consortium.
WHATWG ist die Abkurzung fur Web Hypertext Application Technology Working Group.
5
dem Benutzer Vorschlage fur Suchworter wahrend der Eingabe macht, die von anderen
Nutzern genutzt wurden.
Viele Webanwendungen verwenden zur genauen Spezizierung von Sachverhalten Auswahlfelder7 . Haug benden sich davon mehrere auf einer Webseite, die untereinander
verknupft sind. In Abhangigkeit der Auswahl des ersten Felders, werden alle moglichen
Eintrage fur das zweite bezogen und angezeigt. Dieses Fullen geschieht bei herkommlichen Webanwendungen mit einem Page Reload, weshalb der Benuzter in seinem Workow, die Auswahl zu tatigen, fur kurze Zeit unterbrochen wird. Je mehr Auswahlfelder
miteinander verbunden sind, umso storender wirkt dies.
Hier kann mit AJAX eine erhebliche Verbesserung der Bedienbarkeit erzielt werden. Die
moglichen Eintrage fur die jeweilig abhangigen Auswahlfelder werden im Hintergrund vom
Server bezogen. Somit wird nicht nur der Page Reload vermieden, auch sind, abhangig
von Latenzzeit der Internetverbindung und Anzahl der Eintrage, diese bereits mit der
Komponente verknupft, wenn der Benutzer mit der Maus bei dieser ist, um einen Eintrag
auszuwahlen.
Weiterhin seien noch Tabellen mit einer groen Anzahl an Zeilen genannt. Aus Grunden
der U bersichtlichkeit werden haug nur eine bestimmte Anzahl an Zeilen angezeigt. Mit
AJAX entfallt nicht nur der Page Reload, sondern ist auch eine Navigation im Stil von
Standard Tabellenkalkulationen wie OpenOce Calc und Microsoft Excel moglich.
2.3.2 Aktualitat der Daten
Neben den Verbesserungen der Bedienbarkeit konnen die Daten einer Webseite durch
Polling des Server oder sogenannten Long- lived HTTP Connections aktuell gehalten
werden.
Als Polling wird die in regelmaigen Zeitabstanden wiederholte Anfrage an den Server
bezeichnet. Der Client wertet diese Daten aus und stellt fest, ob sie sich verandert haben.
Bei Veranderung werden diese Daten in der Darstellung aktualisiert. Mehr dazu ndet
sich im Artikel uber das Pattern Periodic Refresh von ajaxpatterns.org [23] unter [24].
Bei den sogenannten Long- lived HTTP Connections wird nach der U bertragung der Daten vom Server zum Client die Verbindung nicht beendet. Dadurch konnen bei A nderung
der Daten auf dem Server, diese vom Server uber dieselbe Verbindung zum Client gesendet werden. Mehr Informationen zu dieser Methode benden sich auf ajaxpatterns.org in
der Erlauterung des Patterns HTTP Streaming unter [25].
7
Auswahlfelder werden auch als ComboBox bezeichnet.
6
2.3.3 Hindernisse bei AJAX- Webanwendungen
Neben diesen Vorteilen gibt es auch Eekte, die besondere Beachtung bei AJAX Webanwendungen erfordern, um das erwartete Verhalten herkommlicher Webanwendungen wiederzuspiegeln. Durch den fehlenden Page Reload werden vom Webbrowser keine HistoryEintrage erzeugt. Somit verweist der Back- Button des Webbrowsers nicht wie erwartet
auf den letzten Zustand der aktuellen Webanwendung, sondern auf die vorherige Webanwendung. Weiterhin bleibt die URL konstant und verweist immer auf die Startseite der
Webanwendung, da lediglich der Inhalt der Webseite verandert wird. Dadurch ist es einem
Benutzer unmoglich, einen bestimmten Zustand der Webanwendung in seine BookmarkSammlung aufzunehmen, zu verschicken oder per Link darauf zu verweisen. Auch die
Webcrawler der Suchmaschinen werden daran gehindert, die Inhalte zu indizieren, die
dynamisch eingebunden werden.
Um das Verhalten herkommlicher Webanwendungen wiederzuspiegeln, bedarf es zusatzlichen Aufwands bei der Konzipierung einer Webanwendung. Der Wikipedia Artikel uber
AJAX[26] beschreibt noch weitere Probleme mit AJAX Webanwendungen und moglichen
Losungsansatzen. Auerdem enthalt er eine Liste mit AJAX Anwendungsbeispielen.
2.4 Barrierefreiheit
Das W3C hat Richtlinien[27] fur die Entwicklung von Webanwendungen entworfen, welche die Zuganglichkeit von Webanwendungen fur Menschen mit korperlichen Beeintrachtigungen sicherstellen. In einigen Landern ist diese Zuganglichkeit allgemein mit
Gesetzen geregelt[28], in Deutschland sind lediglich die oentlich zuganglichen Webseiten von Behorden der Bundesverwaltung per Gesetz dazu verpichtet.
Einige dieser Richtlinien lassen sich auch mit AJAX Webanwendungen umsetzen. Dazu
gehoren u.a. die folgenden:
ˆ U bersichtliche Gliederung der Webseite
ˆ Verwendung gut lesbarer Schriftarten
ˆ Verwendung von Kontrastreichen Farben fur Schrift, Hintergrund, Rahmen, etc.
ˆ Steuerung der Webanwendung mit der Tastatur statt mit der Maus
Andere Richtlinien aber scheitern an den technologischen Voraussetzungen fur AJAXbasierte Webanwendungen. Der Wikipedia Artikel unter [29] gibt einen guten U berblick
der Barrieren von Webseiten.
Neben den am haugsten benutzten graschen Webbrowsern, gibt es auch spezielle andere. Dazu gehoren die Mini- Versionen der graschen Browser fur kleinere Gerate mit
7
eingeschrankten Hardware- Fahigkeiten sowie Text- basierten Webbrowser. Letztere bieten auch eine geeignete Grundlage fur Sprach- basierte Webbrowser. Die Entwicklung
solcher alternativen Webbrowser basiert auf unterschiedlichen Aspekten. Der Hauptgrund
sollte sein, Menschen mit Behinderungen das Internet zuganglich zu machen. Daneben
gibt es auch Hardwareplattformen mit eingeschrankten Fahigkeiten, wie z.B. Handys.
Was bei den graschen Webbrowsern quasi- Standard ist, gilt leider fur die Alternativbrowser noch nicht. So fehlt bei diesen die Unterstutzung fur die einzelnen AJAX Technologien. Dadurch konnen Menschen, die auf solche alternativen Browser angewiesen sind,
die Inhalte AJAX- basierter Webanwendungen nicht erfassen.
Um den Richtlinien konforme Webanwendungen zu entwickeln, ware es zur Zeit notwendig, neben der AJAX Webanwendung eine separate fur Alternativbrowser zu entwickeln. Dazu muss der Webserver beim ersten Request anhand von Parametern bestimmen konnen, welche Webanwendung der Webbrowser darstellen kann, und zu dieser
weiterleiten. Durch die verschiedenen Derivate von Webbrowsern ist dies jedoch ziemlich aufwandig. Eine Unterscheidung anhand der Rendering Engine 8 , wurde dies etwas
vereinfachen.
Einen anderen Weg geht das Mobilfunk- Konsortium mTLD[30]. Dieses hat die neue
Top Level Domain .mobi eingefuhrt, die speziell fur Mobilgerate gedacht ist und von der
ICANN9 [31] auf internationaler Ebene anerkannt wurde. Fur die Entwicklung von Webanwendungen fur diese Domain wurde ein spezieller Guide[32] entwickelt, der als Standard
gilt. Dies ist ein Schritt in die Richtung, Webanwendungen fur spezielle Plattformen10
zu entwickeln. Ob sich diese Richtung durchsetzten wird, bleibt abzuwarten. Solch eine
Portabilitat von Webanwendungen auf verschiedene Plattformen ist sicher ein Thema
welches im Rahmen von Web 2.0 11 naher zu betrachten ist.
Rendern bezeichnet die Umsetzung der formalen Beschreibung einer Webseite in die Darstellung dieser.
Verschiedene Webbrowser konnen dabei die selbe Rendering Engine nutzen.
9 ICANN ist die Abk
urzung fur Internet Corporation for Assigned Names and Numbers.
10 Plattform steht hier im Sinne von vergleichbaren F
ahigkeiten fur die Darstellung von Webseiten.
11 Web 2.0 ist ein anderer Modebegri, der f
ur interaktive Techniken und Dienste im Internet steht. Der
Wikipedia Artikel unter [33] gibt einen guten U berblick daruber.
8
8
3 AJAX Plattform
3.1 Interaktionsmechanismen
Bei einer Webanwendung werden von dem Webserver Dienste bereitgestellt, die der Webbrowser benutzt. Bei AJAX Webanwendungen konnen die Dienste des Webservers prinzipiell in zwei Kategorien eingeteilt werden:
ˆ Applikationsprovider
ˆ Datenprovider
Ein Dienst stellt auf einer bestimmten URL, i.d.R. der Homepage, die AJAX Webanwendung bereit. Diese wird mit der ersten Server- Anfrage auf den Webbrowser ubertragen und dort gestartet. Wahrend die Webanwendung ihre asynchronen Server- Anfragen
durchfuhrt, wird der Webserver als Datenprovider genutzt.
Die Art und Weise, wie Dienste als Datenprovider bereitgestellt und genutzt werden
konnen, wird als Interaktionsmechanismus bezeichnet. Neben der Technik von herkommlichen Webanwendungen gibt es zwei allgemeine Pattern die beschreiben, wie Dienste im
Internet bereitgestellt werden konnen:
ˆ Representational State Transfer Services
ˆ Remote Procedure Call Services
3.1.1 RESTful Service
Prinzip
Das Representational State Transfer- Pattern[34, 35] bezeichnet ein zustandsloses ClientServer- Protokoll. Jede HTTP Anfrage enthalt alle notwendigen Informationen, die der
Server benotigt, um die Nachricht zu verstehen. Die in der Praxis genutzten Techniken zur
Zustandserhaltung, wie z.B. Cookies, durfen nur zu Authentizierungszwecken genutzt
werden. Weiterhin gelten folgenden Prinzipien:
9
ˆ Jede Ressource, die als Teil einer API uber das Internet zuganglich sein soll, wird
auf eine eindeutige URL abgebildet. Zu den Ressourcen gehoren u.a. die Business
Objekte.
ˆ Die Aktionen, die mit den Ressourcen durchgefuhrt werden sollen, werden mit Hilfe
von HTTP Methoden beschrieben.
Verwendung der HTTP Methoden
Durch die Beziehung zwischen HTTP Methode und Aktion, die mit einer Ressource
durchgefuhrt werden soll, ist mit der HTTP Methode eine bestimmte Semantik verbunden. Folgend ein U berblick uber die Semantik der genutzten HTTP Methoden:
GET Wird fur Anfragen an den Server genutzt, die dessen Zustand nicht verandern.
DELETE Wird fur das Loschen eines Objektes genutzt.
POST Wird fur das Erstellen eines Objektes genutzt.
PUT Wird fur das Verandern vorhandener Objekte genutzt.
Eine Zustandsanderung des Servers liegt vor, wenn sich die Daten des Servers verandern.
Eine doppelt ausgefuhrt GET- Anfrage, ohne jedoch eine andere HTTP- Methode am
Server auszufuhren, liefert identische Ergebnisse.
Anwendung
Durch die Aussagefahigkeit der HTTP- Methoden konnen diese mit CRUD1 verglichen
und auf SQL- Befehle abgebildet werden:
create Fur das Erstellen von Eintragen in Tabellen wird der SQL Befehl insert verwendet. Das REST- Pattern benutzt hier die HTTP Methode POST.
retrieve Eine Abfrage wird mit dem SQL- Befehl select realisiert. Bei REST wird die
HTTP Methode GET genutzt.
update Vorhandene Eintrage konnen mit dem SQL Befehl update verandert werden.
Die Aktualisierung von Objekten wird mit der HTTP Methode PUT durchgefuhrt.
delete Fur das Loschen von Eintragen in Tabellen gibt es den SQL Befehl delete. REST
nutzt hierfur die gleichnamige HTTP Methode delete.
1
CRUD ist ein Akronym fur die Datenbankoperationen Create, Retrieve, Update, Delete. Siehe CRUD
bei Wikipedia unter [36]
10
Im Videotheksbeispiel konnte das Video, mit der ID 42 in der Datenbank, folgende URL
erhalten: http://videolib.sample.com/videos/42. Eine HTTP- GET- Anfrage an
diese URL hatte eine Produktbeschreibung als Antwort zur Folge.
Konsequenzen
Ein Vorteil dieses Patterns in Bezug auf AJAX ist, das es eindeutige URLs verwendet und
diese auf Zustande einer Webanwendung abbildet. Bei AJAX Anwendungen sind eindeutige URLs z.B. fur die Funktionalitat des Zuruck - Buttons notwendig. Siehe Abschnitt
2.3.3.
Der grote Nachteil ist eine fehlende Methode search fur das Suchen nach bestimmten
Objekten. Hierfur werden Workarounds notwendig, die sich nachteilig auf die Wohldeniertheit der HTTP- Methoden auswirken. Notwendig ist die Unterstutzung durch die
Serverplattform und die konsistente Bearbeitung der HTTP- Methoden durch die Webbrowser.
Interessant ist dieses Pattern im Zusammenhang mit Java EE 5, welches REST- basierte
Anwendungen unterstutzt. Speziell die Unterstutzung REST- basierter WebServices mit
JAX-WS 2.0 ist im Zusammenhang mit AJAX interessant.
Ein AJAX Framework, welches auf dem REST- Pattern basiert, ist AjaxCaller [37].
3.1.2 RPC Service
Prinzip
Der Grundgedanke beim Remote Procedure Call [38] ist, Methoden eines Objekts auf einem entfernten Webserver uber das Internet aufzurufen. Dazu werden auf Client- und Serverseite Proxy2 - Objekte bereitgestellt, welche die Kodierung und Dekodierung der Nachrichten ubernehmen. Das JavaScript- Proxy- Objekt auf Client- Seite hat die Methoden
des Server- Objekts. Beim Aufruf einer Methode wird eine Nachricht erstellt, die u.a. den
Methodenname sowie die Parameter beinhaltet. Diese wird mit dem XmlHttpRequestObjekt an das Proxy- Objekt des Servers geschickt, welches die Nachricht dekodiert und
einen lokalen Methodenaufruf ausfuhrt. Der Ruckgabewert wird wieder in einer Nachricht
kodiert, welche zu dem Proxy- Objekt auf Client- Seite zuruckgeschickt wird.
2
siehe Proxy Pattern bei Wikipedia unter [39]
11
Verwendung der HTTP Methoden
Im Gegensatz zu RESTful Services (siehe Abschnitt 3.1.1) werden bei RPC i.d.R. nur
zwei HTTP Methoden genutzt:
GET Fur Anfragen, die den Zustand des Servers nicht verandern.
POST Fur Anfragen, die den Zustand des Servers verandern konnen.
Die HTTP- Methoden PUT und DELETE sind nicht notwendig, da die Semantik in der
aufgerufenen Methode des Servers beschrieben ist.
Anwendung
Um die RPC- Technik zu nutzen gibt es plattformubergreifende Standards und in Bezug auf AJAX sogenannte AJAX Stub Frameworks. Nachfolgend eine Auistung von
Standards, die fur AJAX Webanwendungen geeignet sind:
XML- RPC Nutzt als Nachrichtenformat XML. Der Vorteil ist die einfache Handhabung
und der einfache Aufbau der XML Datei. Nachteil ist die schlechte Unterstutzung
fur benutzerdenierte Datentypen.
SOAP Das Simple Object Access Protocol benutzt auch XML. Benutzerdenierte Datentypen werden sehr gut unterstutzt. Einziger Nachteil ist der relativ komplexe
Aufbau der XML Datei und der dadurch verursachte Overhead bei der U bertragung.
JSON- RPC Ist ein Nachbau des XML- RPC Standards, wobei als Nachrichtenformat
JSON3 genutzt wird. Vorteil ist ein geringerer Overhead als bei XML und die einfachere Nutzung von JSON kodierten Daten in JavaScript.
Eine weitere Moglichkeit ist die Nutzung von sogenannten AJAX Stub Frameworks. Diese bilden eine Art Hulle um den Interaktionsmechanismus, indem sie auf Server- sowie
auf Client- Seite die entsprechenden Proxy- Dienste bereitstellen, welche die Kodierung,
Dekodierung und den Versand der Nachrichten ubernehmen.
3
JSON ist die Abkurzung fur JavaScript Object Notation. Wird detaillierter in Abschnitt 3.2.4 beschrieben.
12
Konsequenzen
Ein Vorteil von RPC liegt darin, dass eine groe Anzahl von AJAX Stub Frameworks
bereits verfugbar ist. Haug wird als Nachteil von RPC bei Webanwendungen die oene
API genannt[40, S. 113]. Daher sollte jedes Stub Framework ein gut kongurierbares
Sicherheitskonzept besitzen.
RPC- Frameworks, die fur mehrere Server- Plattformen verfugbar sind, sind das AJAX
Stub Framework SAJAX [41] und die jeweiligen plattformspezischen Implementierungen
von JSON-RPC [42]. Fur die Java Plattform gibt es DWR [43], welches in Abschnitt 3.6.1
genauer betrachtet wird.
3.2 Datenformate fur den Nachrichtenaustausch
Die Kommunikation zwischen Webserver und Webbrowser basiert auf speziell kodierten
Nachrichten, die mit dem Hypertext Transfer Protocol verschickt werden. Der Webserver muss die Anfrage des Webbrowsers verstehen und darauf antworten konnen. Der
Webbrowser wiederum muss die Antwort interpretieren konnen.
Das XmlHttpRequest - Objekt unterstutzt jedes beliebige Format zur Kommunikation.
Auf die ublichsten Moglichkeiten soll im folgenden eingegangen werden, jedoch konnen
auch wahlfreie Textbeschreibungen verwendet werden. Bei AJAX Webanwendungen bieten sich allerdings strukturierte Datenformate an.
3.2.1 URL Querystring
Herkommliche Webanwendungen nutzen fur die Parameterubergabe bei Serveranfragen
einen speziell kodierten String. Ein Parameter besteht aus einem Key- Value- Paar der
Form key=value. Werden mehrere Parameter benotigt, werden diese mit dem Zeichen &
voneinander getrennt. Bei HTTP- GET- Anfragen wird der Querystring mit dem Fragezeichen direkt an die URL angehangt. Bei HTTP- POST- Anfragen wird dieser dagegen
als eigenstandiger Teil im Body der Anfrage gesendet und nicht an die URL angehangt.
Der URL Querystring ist nur fur Serveranfragen interessant.
Diese Art der Anfrage ist auch bei AJAX Webanwendungen moglich. Besonderes Augenmerk sollte auf die Erstellung des Querystrings gelegt werden, da dieser bestimmte Zeichen nicht enthalten darf. Zum Kodieren und Dekodieren von URIs gibt es die
JavaScript- Funktionen encodeURI und decodeURI. Bei der U bertragung von komplexen
Daten konnte sich aber die Unstrukturiertheit als Nachteil herausstellen.
13
3.2.2 HTML
Das Standard- Antwortformat des Servers bei herkommlichen Webanwendungen kann
auch fur AJAX Webanwendungen verwendet werden. Der Webserver schickt als Antwort nicht mehr eine komplette Webseite, sondern lediglich den veranderten Inhalt als
HTML- Stub. Mit der DOM[7] Eigenschaft innerHTML[44] kann relativ einfach HTMLCode in das Dokument eingebunden werden. Als Format fur Serveranfragen ist HTML
ungeeignet.
Bei einer Anreicherung der Webseite mit AJAX Funktionalitat kann bereits vorhandener
Quellcode genutzt werden. Nachteilig ist jedoch die hohe Kopplung zwischen Server und
Client. Der Webserver stellt genau fur den Client generierte HTML- Stubs zur Verfugung.
Neben einer klaren Trennung zwischen Struktur, Inhalt und Aussehen der Daten besteht
das Problem der Wartbarkeit.
3.2.3 XML
Als strukturiertes Datenformat bietet sich die Verwendung von XML Dokumenten an.
Der Zugri ist durch Standards wie SAX und DOM gesichert. Serverseitig wird es von
einer Vielzahl von Bibliotheken plattformubergreifend unterstutzt. Auf Clientseite gibt es
ebenso mehrere JavaScript Bibliotheken, die den Umgang mit XML Dokumenten vereinfachen. Unter [45] ndet sich dazu eine U bersicht. Als Beispiel sei hier die Bibliothek
Google AJAXSLT [46] genannt, die XSLT und XPath beherrscht. Durch die server- und
clientseitige Unterstutzung, bietet sich XML nicht nur als Anfrage-, sondern auch als
Antwortformat an.
Nachteilig bei XML ist der ziemlich ausfuhrliche Aufbau und der dadurch verursachte Overhead bei der U bertragung. XML wird zur U bertragung benotigt, wenn mit dem
Protokoll SOAP auf Web Services zugegrien werden soll. Der Overhead wird bei Verwendung von SOAP noch viel groer.
3.2.4 JSON
Als kompakteres Datenformat zeichnet sich die JavaScript Object Notation aus. Ein
kleines Beispiel bendet sich in Listing 3.1. Sie ist strukturiert und hat einen geringeren
Overhead bei der U bertragung als XML. Wird JSON als Antwortformat genutzt, bedarf
es clientseitig keiner Konvertierung der Daten, weil sie schon in JavaScript vorliegen
und direkt genutzt werden konnen. Eine U bersicht von Bibliotheken fur die serverseitige
Unterstutzung von JSON bendet sich unter [47]. Fur die popularsten Serverplattformen
steht auch eine Implementierung des RPC- Frameworks JSON-RPC[42] zur Verfugung
(siehe 3.1.2). Dadurch ist JSON auch als Anfrageformat nicht ungeeignet. In der AJAX
14
Community wird bereits der Begri JSON WebService gepragt. Als Beispiel sei hier der
Yahoo WebService genannt, der neben XML auch in JSON antworten kann.
1
//
an
2
hello
object
=
a
f
3
//
4
message
with
member
two
with
members
a
string
: " h e l l o JSON" ,
and
one
function
value
5
6
//
a
member
holding
an
array
7
lang
: ["hello", "hallo"] ,
//
function
of
strings
8
9
10
11
12
13
a
with
no
parameter
: function ( ) f
r e t u r n t h i s . message ;
sayHello
g;
g
Listing 3.1: Beispielcode in JSON
3.3 Umfang der AJAX Funktionalitat einer
Webanwendung
Die Moglichkeiten, AJAX Funktionalitat in Webanwendungen zu integrieren, sind sehr
weitreichend. Doch sollte sorgfaltig abgewogen werden, inwieweit solche Integrationen
noch sinnvoll sind. An einigen Stellen ist der Verzicht auf AJAX Funktionalitat aufgrund
eines unausgewogenen Aufwand- Nutzen- Verhaltnisses sicher angebracht. Solche Entscheidungen sind neben dem Projekt selbst auch von vielen anderen Faktoren abhangig,
wie Wissen und Erfahrung der Entwickler.
3.3.1 Hybride Webanwendungen
Der Entwicklungsprozess herkommlicher Webanwendungen hat sich im Laufe der Zeit gefestigt und wird von den meisten Softwareentwicklern gut verstanden. Zudem ist hierfur
genugend Literatur verfugbar, wie z.B. das Java EE Tutorial von Sun[48]. Wird AJAX
Funktionalitat in herkommliche Webanwendungen integriert, so nennt man diese hybride
Webanwendungen. Diese kombinieren AJAX Technologien zur Verbesserung der Bedienbarkeit mit dem gewohnten Page Reload.
Durch die Integration von AJAX Funktionalitat in die Webtechnologien der jeweiligen
Plattformen wird der Einstieg in die AJAX Welt vereinfacht. Vorhandene Webanwendungen konnen durch relativ geringen Aufwand mit AJAX Funktionalitat ausgestattet
15
werden. Der Entwicklungsprozess der Webanwendungen bleibt dabei fast unberuhrt und
die Bedienbarkeit kann sich je nach Webanwendung wesentlich verbessern. Durch den Page Reload bleibt die Moglichkeit gegeben, zwischen den U bertragungsprotokollen HTTP
und HTTPS zu wechseln. Das Vorhandensein mehrerer Webseiten sowie der Verbindung
dieser mit Hyperlinks erleichtert Webcrawlern, den Inhalt der Webanwendung zu indizieren.
Der Wechsel der Zustande einer hybriden Webanwendung geschieht weiterhin durch einen
Page Reload. Dadurch ist der Einsatz von AJAX Techniken zur Veranderung des Inhaltes
nur beschrankt moglich, weil es sonst zu Problemen mit der History- und Bookmarkfahigkeit der Webanwendung kommt. Wie weitreichend solche nicht- historyfahigen Veranderungen sein konnen, ist vom Kontext der Webanwendung abhangig. Layoutveranderungen
sind i.d.R. ein Zustandswechsel und sollten historyfahig sein.
Jedoch besteht mit AJAX das Potenzial, Page Reloads ganz zu vermeiden. Dies erfordert
allerdings A nderungen im Entwicklungsprozesses von Webanwendungen.
3.3.2 Single Page Applications
Wird die Integration von AJAX Funktionalitaten in eine Webanwendung solange fortgefuhrt bis kein Page Reload mehr notwendig ist, wird von Single Page Applications [49]
gesprochen. Dabei stellt der Webserver auf der Homepage eine Webanwendung zur
Verfugung, die innerhalb eines Webbrowsers lauahig ist. Der Webbrowser bezieht diese
von der URL und startet sie anschlieend. Jegliche zusatzliche Daten werden im Hintergrund vom Server bezogen. Dieses Konzept kommt einer normalen Desktop- Anwendung
sehr nahe, benotigt allerdings einen Webbrowser als Laufzeitumgebung.
So vielversprechend diese Moglichkeit auch klingt, ist diese in der Praxis mit einigen
Aufwand verbunden. Im Entwicklungsprozess der Webanwendung muss explizit betrachtet werden, welche Zustande historyfahig, bookmarkfahig oder beides sein sollen. Den
bookmarkfahigen Zustanden muss eine eindeutige URL zugewiesen werden. Ein anderer
Aspekt ist die Betrachtung der Indizierung des Inhaltes der Webanwendung durch den
Webcrawler einer Suchmaschine. Hier muss im Entwicklungsprozess festgelegt werden,
welche Daten einer Suchmaschine zuganglich sein sollen und wie dies erreicht werden
kann.
Bedingt durch das Sicherheitskonzept von JavaScript, muss sich fur ein U bertragungsprotokoll entschieden werden. Ein Wechsel zwischen HTTP und HTTPS ist aktuell nicht
ohne Page Reload moglich.
16
3.4 Integration in Client- und Server Infrastruktur
In herkommlichen Webanwendungen hat der Client fast ausschlielich die Aufgabe, vom
Webserver generierte Webseiten anzuzeigen. In den Webtechnologien wurden aktive Elemente mit JavaScript kaum unterstutzt und eingesetzt. Die Steuerlogik der Webanwendung, sowie das Layout der Webseiten ist auf Serverseite hinterlegt. Um AJAX Funktionalitat auf Webseiten zu Nutzen, ist JavaScript Code erforderlich. Dadurch werden Teile
der Logik der Webanwendung auf dem Client abgearbeitet.
3.4.1 Serverzentrierte Webanwendungen
Wird bei AJAX Webanwendungen der Hauptteil der Prasentationslogik auf Serverseite
belassen, so handelt es sich um serverzentrierte Webanwendungen. Der Client leitet den
wesentlichen Teil der Benutzeraktionen an den Server weiter, der diese dann auswertet.
Die Steuerungslogik der Webanwendung ist zum Groteil auf dem Server hinterlegt. In
Abbildung 3.1 ist dies anhand des Microsoft Atlas Frameworks verdeutlicht.
Abbildung 3.1: Programmiermodell einer serverzentrierten Webanwendung aus [1] am
Beispiel Microsoft Atlas
Der Vorteil von serverzentrierten Losungen ist die Vermeidung von JavaScript Programmierung durch Generierung des benotigten Codes. Softwarentwickler haben haug weniger Erfahrung damit, wodurch auch viele Frameworks die komplette Vermeidung von
JavaScript Programmierung verfolgen.
17
Bei serverzentrierten Webanwendungen sind die Business- und Prasentationslogik eng
miteinander verbunden, wodurch die Gefahr besteht, beide miteinander zu vermischen.
Durch die U bertragung der Benutzeraktionen zum Server entsteht ein hoher Kommunikationsaufwand. Bei starker Auslastung des Servers kann sich die erhohte Latenzzeit
negativ auf das Verhalten der Webanwendung auswirken. Durch die Vermeidung von JavaScript Programmierung erfordern die AJAX Komponenten auf Clientseite eine spezielle
Serverschnittstelle, welche die Daten in einem speziell aufbereiteten Format bereitstellt.
3.4.2 Clientzentrierte Webanwendungen
Die durch Nutzung von AJAX Funktionalitat verursachte Verlagerung der Steuerlogik
der Webanwendung vom Server auf den Client kann soweit fortgefuhrt werden, bis die
komplette Prasentationslogik der Webanwendung sich auf dem Client bendet. Verarbeitet der Client den wesentlichen Teil der Prasentationslogik, so wird von clientzentrierten
Webanwendungen gesprochen. Die Verantwortlichkeit des Servers beschrankt sich im Extremfall nur noch auf die Bereitstellung der Daten. Abbildung 3.2 verdeutlicht dies anhand
des Microsoft Atlas Frameworks.
Abbildung 3.2: Programmiermodell einer clientzentrierten Webanwendung aus [1] am
Beispiel Microsoft Atlas
Durch die Verlagerung der Prasentationslogik auf den Client ist eine Trennung zwischen
Business- und Prasentationslogik sichergestellt. Benutzerinteraktionen konnen sofort ausgewertet werden, wodurch ein schnelles Antwortverhalten der Webanwendung gewahr-
18
leistet ist. Der wesentliche Teil der Kommunikation mit dem Server entfallt auf den Datenzugri. Erfolgt dieser uber eine standardisierte Schnittstelle, konnen die Daten auch
auerhalb der Webanwendung verwendet werden.
Ein Nachteil ist die geringe Erfahrung fur die Entwicklung clientzentrierter Webanwendungen. Auch sind die Moglichkeiten durch die Sicherheitskonzepte von JavaScript begrenzt.
3.5 Klassizierung von Webanwendungen
Durch die in den Abschnitten 3.3 und 3.4 betrachtete Unterscheidung konnen Webanwendungen klassiziert werden. Abbildung 3.3 soll dies verdeutlichen.
Abbildung 3.3: Schema zur Klassizierung von Webanwendungen
Herkommliche Webanwendungen besitzen keine AJAX Funktionalitat. Die Verwendung
von JavaScipt, z.B. zur Validierung von Benutzereingaben, wurde durch die Frameworks
kaum unterstutzt. Die Prasentationslogik war auf dem Server verankert, wodurch sich
herkommliche Webanwendung eindeutig als serverzentrierte Webanwendungen klassizieren lassen.
Wird in einer AJAX Webanwendung weiterhin der Page Reload verwendet, werden durch
diesen samtliche Daten auf dem Client verworfen. Somit sind hybride, clientzentrierte Webanwendungen nicht sinnvoll einsetzbar, wodurch sie eindeutig als serverzentriert
klassiziert werden konnen.
Verwendet die AJAX Webanwendung keinen Page Reload mehr, ist es eine Single Page
Application. Um diese als client- oder serverzentriert zu klassizieren, bedarf es einer
genaueren Untersuchung der Architektur, ob sich der wesentliche Teil der Prasentationslogik auf Client- oder Serverseite bendet. Serverzentrierte Single Page Applications
benotigen haug ein spezielles Framework.
19
3.6 Betrachtung vorhandener AJAX Frameworks
3.6.1 Auswahl
Die in diesem Abschnitt betrachteten AJAX Frameworks, Bibliotheken und Toolkits wurden nicht nach bestimmten Kriterien aus Listen von AJAX Frameworks4 herausgesucht.
Der Autor wurde wahrend dieser Arbeit durch Nachrichten und Hinweise aus der AJAX
Community5 auf diese aufmerksam. Die hier betrachteten Frameworks sollen die unterschiedlichen Ansatze fur AJAX Webanwendungen verdeutlichen.
Google Web Toolkit
Der von Google veroentlichte Web Toolkit (GWT) [53] ist ein Java- Entwicklungsframework fur die Erstellung von clientzentrierten AJAX Webanwendungen. Die AJAX
Webanwendung wird mittels Java entwickelt und wird anschlieend nach JavaScript und
HTML kompiliert. Zur Entwicklungszeit lauft die AJAX Webanwendung innerhalb einer
Java- Laufzeitumgebung, wodurch die Nutzung des Java- Debuggers der verwendeten
Entwicklungsumgebung moglich wird. Dies ist wesentlich komfortabler als die Nutzung
diverser JavaScript Debugger.
Die Serverseite wird mit speziellen Java Servlets bereitgestellt, wofur der GWT entsprechende Basisklassen bietet. Der Kommunikationsmechanismus basiert auf dem RPC und
wird vom GWT ubernommen. Die Widget Bibliothek ist mit eigenen Widgets erweiterbar.
Genugt die Funktionalitat der Klassenbibliothek nicht, kann mittels JavaScript Native Interface JavaScript Code eingebettet werden. Die mit GWT erstellten Webanwendungen
sind Single Page Applications, die ohne Kenntnis von JavaScript erstellt werden konnen.
GWT kann frei fur kommerzielle, nicht kommerzielle und Enterprise Anwendungen genutzt werden. Weitergehende Bestimmungen nden sich in den Terms of use [54].
ZK
Das OpenSource Framework ZK[55] fur Java- basierte Webanwendungen wurde von Potix veroentlicht. Es verfolgt das gleiche Ziel wie GWT: AJAX Webanwendungen ohne
JavaScript Programmierung zu erstellen. ZK ist ereignisgesteuert und komponentenorientiert. Die Synchronisation des Inhalts der Komponenten, die Ereignisweiterleitung zum
4
5
Eine Auistung von AJAX Frameworks bendet sich u.a. auf der Webseite ajaxpatterns.org unter [50].
Diese umfassen insbesondere Meldungen auf den Webseiten von heise.de [51], ajaxpatterns.org [23] und
ajaxian.com[52].
20
Server und die Veranderung der Webseite erfolgt automatisch. Zur Clientprogrammierung setzt ZK auf eine User Interface Markup Language 6 namens ZUML7 . Darin konnen
XUL8 und XHTML Komponenten zur Webseitengestaltung genutzt werden. Die Ereignisbehandlungen konnen entweder in Java oder in Java EL9 Ausdrucken verfasst werden.
Die Engine von ZK lauft auf dem Server und interpretiert ZUML Dateien wahrend der
Laufzeit. Diese generiert daraus die Webseite und ubernimmt die komplette Kommunikation sowie die notwendige Aktualisierung der Webseite. ZK Webanwendungen sind
serverzentrierte Single Page Applications.
Weiterhin lassen sich Widgets von Clientbibliotheken wie dojo integrieren. Das Springframework wird von ZK unterstutzt. ZK ist OpenSource und lizenziert unter der GPL.
Backbase
Neben ZK setzt auch Backbase[62] auf eine User Interface Markup Language, die unter
dem Namen BXML[57] entwickelt wurde. Im Gegensatz zu ZK ist Backbase clientzentriert, d.h. die Backbase- Engine, welche die BXML Datei interpretiert, lauft auf dem
Client. Damit ist Backbase im Gegensatz zu ZK plattformunabhangig und kann mit jeder
Serverplattform zusammenarbeiten, die XHTML bereitstellen kann. Die Ereignissbehandlung erfolgt deklarativ mit Elementen in BXML oder mit JavaScript- Code. Mit Backbase
erstellte Webanwendungen sind clientzentrierte Single Page Applications.
Backbase ist ein kommerzielles AJAX Framework. Es gibt eine Community Edition fur
nicht- kommerzielle und nicht- institutionelle Nutzung. Ein Plugin fur Visual Studio 2005
bzw. fur Eclispe und eine JSP Taglib sind nur in der kommerziellen Version vorhanden.
Atlas
Microsoft Atlas[63] ist das AJAX Framework fur die .Net 2.0 Plattform von Microsoft.
Es erweitert ASP.NET und unterteilt sich in ein Client- und Serverframework. Die Architektur von Atlas ist in Abbildung 3.4 dargestellt.
Eine User Interface Markup Language steht fur die deklarative Beschreibung von Benutzerschnittstellen
auf Basis von XML. Nicht zu Verwechseln mit dem Standard UIML (User Interface Markup Language)
[56]. Mehr Informationen nden sich im Wikipedia Artikel unter [57].
7 ZUML steht f
ur ZK User Interface Markup Language. Weiterfuhrende Informationen auf der Homepage
von ZK (unter [55]) und der Wikipedia unter [58].
8 XUL ist die XML User Interface Language des Mozilla Projektes, die auch von der Gecko Rendering
Engine [59] unterstutzt wird. Genauere Informationen nden sich unter [60].
9 Java EL ist die Abk
urzung fur Java Expression Language. Mehr Informationen dazu nden sich in dem
Wikipedia Artikel zu Java Server Pages (JSP) 2.0 unter [61].
6
21
Abbildung 3.4: Die Architektur des Microsoft Atlas Frameworks aus [1]
Die Clientbibliotheken sind modular aufgebaut, wodurch sie nicht komplett geladen werden mussen. Sie basieren auf einer speziellen Scriptsprache namens xml-script 10 . Mit
dieser werden die Komponenten und Controls, sowie ihr Verhalten mit Hilfe von XML
Elementen deklarativ beschrieben. Dadurch ist es nicht notwendig, JavaScript programmieren zu mussen. Die Kernbibliothek kann allerdings auch direkt von JavaScript genutzt
werden. Die Clientkomponenten konnen unabhangig von den Serverkomponenten genutzt
werden. Den Clientkomponenten ist es auch moglich, direkt Web Services aufzurufen.
Somit sind mit Atlas clientzentrierte als auch serverzentrierte Webanwendungen moglich
(siehe Artikel [1]).
Das Serverframework basiert auf ASP.NET und besteht somit hauptsachlich aus Erweiterungen dafur. Die ASP.NET Seiten werden mit Atlas- Server- Controls sowie den
Serverkomponenten beschrieben und anschlieend durch Kompilierung in xml-script umgesetzt. Atlas unterstutzt die Serialisierung von Objekten zur U bertragung nach XML
und JSON.
10
Nicht zu verwechseln mit der XML Transformationssprache http://www.xmlscript.org/. xml-script von
Microsoft wird eventuell auch noch in Atlas Script umbenannt. Mehr Informationen daruber im Blog
von Nikhil Kothari [64].
22
AjaxTags
AjaxTags[65] ist eine JSP11 Tag Library mit AJAX Funktionalitat fur die JSP und Servlet
Technologie der Java Plattform. Neben Standardkomponenten fur Webseiten sind spezielle Komponenten enthalten, die bestimmte Bereiche der Webseite aktualisieren. Folgend
einige der unterstutzten Komponenten:
Autocomplete Zeigt, wahrend der Benutzer eine Eingabe tatigt, eine Liste mit Werten
an, die den eingegebenen Wert entsprechen konnten.
Tab Panel Zeigt eine karteikartenahnliche Darstellung an, deren jeweiliger Inhalt asynchron vom Server bezogen wird.
Ajax Display Tag Fugt den bei JSP haug verwendeten Display Tag[66] AJAX Funktionalitat hinzu.
Die asynchronen Anfragen werden an Servlets gerichtet. Als Nachrichtenformat wird der
URL Querystring (siehe 3.2.1) genutzt. Die URL sowie die ubertragenen Parameter des
Querystrings, konnen mit den JSP Tags frei konguriert werden. Fur die Antwort kann
jedes beliebige Nachrichtenformat genutzt werden. Bei eigenen Datenformaten ist allerdings JavaScript Programmierung notwendig, um die Daten in die Webseite einzubinden.
AjaxTags beinhaltet jedoch mehrere Parser fur Standardformate. Wenn diese genutzt
werden ist kein zusatzlicher JavaScript Code notwendig.
AjaxTags ist OpenSource und unter der Apache Lizenz Version 2 veroentlicht.
Rialto
Der Rich Internet AppLication TOolkit [67] ist eine JavaScript Bibliothek fur Widgets.
Neben einer JavaScript API, sind auch Implementierungen fur verschiedene Servertechnologien in Entwicklung, die auf der JavaScript API basieren:
ˆ Rialto Taglib fur JSP Technologie
ˆ Rialto Struts Adapter fur das Struts Framework
ˆ Rialto JSF
ˆ Rialto .Net
ˆ Rialto PHP
ˆ Rialto Python
11
JSP ist die Abkurzung fur Java Server Pages.
23
Rialto versteht sich als Werkzeug fur Single Page Applications, die innerhalb von Netzwerken genutzt werden. Die Betonung eines Netzwerks basiert auf der Tatsache, dass die
JavaScript Bibliothek recht uppig ist. Da sie nicht modular aufgebaut ist, wird sie komplett mit Stylesheets und Bildern fur die Widgets, beim Start der Webanwendung auf den
Webbrowser ubertragen. Dies fuhrt zu einer verlangerten Startzeit der Webanwendung.
Die Bibliothek ist nicht nur plattformunabhangig nutzbar, sondern stellt auch als integrierte Servertechnologie keine Anforderungen an den Kommunikationsmechanismus. Rialto
ist OpenSource und steht unter der Lizenz von Apache.
DWR
Direct Web Remoting [43] ist ein Java Framework fur den Kommunikationsmechanismus
einer AJAX- basierten Webanwendung. Es nutzt den RPC und bietet fur Methoden der
Serverobjekte auf der Clientseite eine JavaScript Schnittstelle an. Das Marshalling und
Unmarshalling der Objekte ubernimmt das Framework. Die Ruckgabewerte der Methoden
sind in JSON kodiert. Es integriert sich gut in das Springframework, Webframeworks wie
Struts oder JSF und arbeitet gut mit anderen JavaScript Bibliotheken zusammen. Im
Framework ist auch eine JavaScript Bibliothek mit nutzlichen Funktionen enthalten. Mit
dem Sicherheitskonzept von DWR ist es u.a. moglich, die Veroentlichung der Methoden
zu kongurieren. Weiterhin integriert es sich mit dem Acegi Security Framework[68] und
dem Sicherheitskonzept von Java EE.
DWR ist wie JSON-RPC fur den Datenzugri auf den Server einer AJAX Webanwendung
zustandig. Der Vorteil gegenuber dem Standard JSON-RPC ist die Integrierung in die
Server Technologie von Java. DWR ist von GetAhead als OpenSource unter der Apache
Lizenz veroentlicht.
Dojo Toolkit
Der dojo toolkit [69] ist ein Projekt der dojo Foundation. Es ist ein DHTML Toolkit
der in JavaScript geschrieben ist und andere Bibliotheken und Toolkits integriert. Die
enthaltenen build tools erlauben es, kommandozeilenbasierte Unit Tests fur JavaScript
Code zu schreiben. Der dojo Toolkit ist modular mit Packages aufgebaut, ahnlich den Java
Packages. Jedes Package beinhaltet ein oder mehrere JavaScript Dateien. Um den dojo
Toolkit zu nutzen wird eine relativ kleine JavaScript Bibliothek eingebunden. Zusatzlich
benotigte Bibliotheken werden bei Nutzung asynchron nachgeladen. Mit den build tools ist
es auch moglich, die dojo Bibliothek speziell nach den Anforderungen der Webanwendung
zu erstellen. Folgend eine kleine Auswahl an Packages, die im dojo Toolkit enthalten
sind:
24
dojo.event Ereignissgesteuerte API, die AOP12 Fahigkeiten besitzt und spezielle Konzepte fur die Zuweisung und Behandlung von Ereignissen bietet.
dojo.logging Ein Logging Framework.
dojo.widget Ein Widget Framework, mit dem sich wiederverwendbare HTML / JavaScript Widgets erstellen lassen. Erlaubt Markup- basierte Anwendungsentwicklung
(ahnlich den User Interface Markup Languages).
dojo.crypto Bietet Unterstutzung fur MD5, AES, SHA und Blowsh.
Dojo unterstutzt Markup- basierte Webanwendungen mit der Dojo ML, stellt aber auch
eine JavaScript API bereit. Leider ist die Dokumentation des Toolkits noch sehr verbesserungswurdig. Der Dojo Foundation sind bereits eine ganze Reihe von Unternehmen
beigetreten, u.a.:
ˆ IBM
ˆ Sun
ˆ Jotspot
ˆ AOL
ˆ OpenLaszlo
Dojo ist ein Toolkit und unterstutzt die Clientprogrammierung in JavaScript. Dadurch ist
er von Serverplattform und -technologie unabhangig. Er ist unter der ATL und der BSD
Lizenz veroentlicht.
Yahoo UI
Die Yahoo! User Interface Library [70] ist hauptsachlich eine JavaScript Bibliothek fur
Widgets, besitzt aber auch einige Hilfsfunktionen. Die Bibliothek enthalt vorgefertigte
und anpassbare Webseitenlayouts und Standardwidgets wie Autocomplete, Menu und
TreeView. Weiterhin unterstutzt die Bibliothek den Entwickler bei der Zuweisung von
Events, Drag and Drop und Animationen.
Diese Bibliothek besitzt eine gute Dokumentation und kann nach den Bestimmungen der
BSD Lizenz genutzt werden.
12
AOP ist die Abkurzung fur Aspect Oriented Programming.
25
Google AjaXSLT
Ein weiteres Produkt von Google ist die JavaScript Bibliothek Google AjaXSLT [46],
welche XSL Transformationen durchfuhren kann. Da XSLT13 XPath nutzt, ist auch eine Implementierung von XPath vorhanden. Mit dieser Bibliothek ist es moglich, XML
Dokumente, die asynchron vom Server geladen wurden, in ein anderes Format zu transformieren. Dies konnte HTML sein, um es direkt in den Webbrowser einzubinden, aber
auch JSON um die Daten mit JavaScript weiterzubearbeiten. Mit Hilfe von XPath konnen
Teile des XML Dokumentes speziziert werden, um die Daten leichter in die Webseite
einzubinden.
Diese Bibliothek ist von Google unter der BSD Lizenz veroentlicht.
Adobe Spry
Diese JavaScript Bibliothek unterstutzt den Webentwickler beim Umgang mit XML Dokumenten und basiert auf Googles AjaxXSLT. Das Prinzip des Frameworks basiert auf
speziellen Attributen, die in die HTML Elemente der Webseite eingefugt werden. Diese
dienen als Platzhalter fur die Daten. Ein JavaScript Objekt mit gleichen Namen wie der
Platzhalter bezieht ein XML Dokument vom Server. Mit einem XPath Ausdruck werden
die Daten innerhalb des Dokumentes speziziert, die anstelle des Platzhalter in die Webseite eingefugt werden. Weiterhin bietet die Bibliothek Unterstutzung fur Master- DetailView Verkettung und Verhaltensattribute.
Adobe hat Spry[71] unter der BSD Lizenz veroentlicht.
3.6.2 Mogliche Einteilung
Wie im letzten Abschnitt verdeutlicht, bauen die AJAX Frameworks auf einer breit
gefacherten Basis auf und sind somit schwer vergleichbar. In Anlehnung an das Buch
Ajax in Action[40] und der Webseite ajaxpatterns.org kann prinzipiell zwischen 2 Arten
von Frameworks unterschieden werden:
JavaScript Frameworks Sind Frameworks oder Bibliotheken, die Unterstutzung fur die
Clientprogrammierung bieten. Ein Vorteil dieser Bibliotheken liegt darin, das sie mit
jeder Server- Plattform und Infrastruktur zusammenarbeiten, wodurch keine speziellen serverseitigen Anpassungen notwendig sind. Weiterhin kann eine Unterteilung
anhand des Umfangs erfolgen:
13
XSLT ist die Abkurzung fur eXtensible Stylesheet Language Transformations.
26
Multi- purpose Beinhalten Unterstutzung fur unterschiedliche Verantwortlichkeiten, wie z.B. Widgets und Kommunikation. Ein Typischer Vertreter hierfur ist
der dojo Toolkit.
Specialized Sind auf ganz bestimmte Aspekte spezialisierte Frameworks. Hierzu
gehoren u.a. Widget- und Eektbibliotheken, Remote-, XML- und Loggingframeworks.
Applikationsframeworks Werden auch Hybride Frameworks genannt, weil sie die Serverund Clientseite umspannen. Dadurch ist sowohl auf der Serverseite, als auch auf der
Clientseite Programmieraufwand fur die Einbindung des Frameworks erforderlich.
Ein spaterer Austausch des genutzten Frameworks ware hierdurch aufwandig. Allerdings ubernehmen diese Frameworks den Kommunikationsmechanismus inklusive
Marshalling und Unmarshalling ubertragener Objekte. Diese Frameworks lassen sich
anhand der unterstutzten Plattformen weiter dierenzieren:
Multi- language Bieten Implementierungen fur mehrere Programmiersprachen auf
Serverseite an. Durch die Unterstutzung mehrere Serverplattformen leidet
haug die Integration in existierende Technologien der jeweiligen Plattformen.
Special Language Sind speziell fur eine Serverplattform entwickelt und haug
auch fur eine Webtechnologie dieser Plattform. Dadurch sind sie gut in diese
Technologie integriert und konnen auf relativ einfach Weise verwendet werden.
Die im Rahmen dieser Diplomarbeit betrachteten Frameworks sind nach der obigen Einteilung in Tabelle 3.1 dargestellt. Neben dem Funktionsumfang ist hier die Plattformabhangigkeit berucksichtigt. Dabei geben Applikationsframeworks haug eine konkrete
Architektur der Webanwendung vor.
Kriterium
JavaScriptFramework
Applikationsframeworks
zugeordnete Frameworks
Multi- purpose
dojo
Specialized
Rialto, Yahoo UI, Google AjaXSLT, Spry
Multi- language Rialto, Backbase
Special Language GWT, ZK, AjaxTags, DWR, Atlas
Tabelle 3.1: Einordnung der betrachteten AJAX Frameworks nach Gliederung in Abschnitt 3.6.2
3.6.3 Gegenuberstellung
Aufgrund der unterschiedlichen Ansatze und Zielsetzungen der Frameworks wird im folgenden versucht, diese nach Aspekten zu gliedern, die fur die Auswahl von AJAX Frameworks entscheidend sein konnen.
27
Um den Zweck eines AJAX Frameworks schneller zu erfassen, wird in Tabelle 3.2 eine
Einteilung in Framework[72], Toolkit[73] und Bibliothek[74] durchgefuhrt. Hierdurch kann
auf die Anwendbarkeit und den Funktionsaumfang geschlossen werden.
Kriterium
Framework
Toolkit
Bibliothek
zugeordnete Frameworks
ZK, Backbase, Atlas, DWR, Spry
GWT, Rialto, dojo
AjaxTags, Yahoo! UI, Google AjaXSLT
Tabelle 3.2: Einordnung der betrachteten AJAX Frameworks nach Framework, Toolkit
und Bibliothek
Wichtig fur die Nutzung eines AJAX Frameworks sind die Lizenzbedingungen. Daher
werden diese in Tabelle 3.3 betrachtet.
Kriterium
zugeordnete Frameworks
kommerziell
Backbase
BSD Lizenz
dojo, Yahoo UI, Google AjaXSLT, Spry
ATL Lizenz
dojo
Apache Lizenz
DWR, Rialto, AjaxTags
GPL
ZK
speziell / unbekannt GWT, Atlas
Tabelle 3.3: Einordnung der betrachteten AJAX Frameworks nach ihren Lizenzbestimmungen
Eine weitere Unterteilung in Tabelle 3.4 soll aufzeigen, inwieweit die hier betrachteten
Frameworks, die Entwicklung der Webanwendung unterstutzen. Diese basiert vor allem
auf dem Funktionsumfang der Frameworks, sowie den Funktionsbereich. Basisframeworks
bieten einen hohen Funktionsumfang und bieten weitreichende Unterstutzung fur verschiedene Aspekte. Dadurch kann eine bestimmte Architektur der Webanwendung vorgegeben sein. Frameworks mit einem abgegrenzten Funktionsumfang werden als zusatzliche
Frameworks eingeordnet. Dazu gehoren auch modulare Frameworks, dessen Teile sich eigenstandig nutzen lassen.
Kriterium
zugeordnete Frameworks
Basisframework
ZK, Backbase, Atlas, GWT, dojo, AjaxTags
zusatzliches Framework DWR, Spry, Rialto, dojo, Yahoo UI, Google AjaXSLT
Tabelle 3.4: Einordnung der betrachteten AJAX Frameworks nach dem Umfang der Unterstutzung des Entwicklers
Die nachste Unterteilung in Tabelle 3.5 bezieht sich auf die Kategorie der entwickelbaren
Webanwendungen (siehe Abschnitt 3.5). Diese wird haug vom verwendeten Framework
28
vorgegeben. Mit AjaxTags ist es zwar prinzipiell moglich, aber nicht sinnvoll Single Page
Applications zu entwickeln, da eine Unterstutzung fur die History- und Bookmarkfahigkeit
der Webanwendung fehlt.
Kriterium
serverzentriert
clientzentriert
Single Page Application
hybride Webanwendung
zugeordnete Frameworks
ZK, Atlas
GWT, Backbase, Atlas
ZK, GWT
AjaxTags
Tabelle 3.5: Einordnung der betrachteten AJAX Frameworks nach der Kategorie der entwickelbaren Webanwendung
3.7 Zusammenfassung
In diesem Abschnitt wurde gezeigt, das AJAX nicht gleich AJAX ist. Die vorhandenen
Ansatze, AJAX Funktionalitat in Webanwendungen zu integrieren, verfolgen unterschiedliche Ziele und sind unterschiedlich stark mit ihrer zugrundeliegenden Plattform verbunden.
Fur die Konzipierung einer AJAX- basierten Webanwendung mussen u.a. folgende Aspekte sorgfaltig abgewogen werden:
ˆ Weiternutzung bestehender Infrastruktur wie Serverkomponenten oder Daten einer
Datenbank
ˆ Plattform der Webanwendung (Java, .Net, etc.)
ˆ JavaScript Know- how des Entwicklungsteams
ˆ Client- oder Serverzentrierte AJAX Webanwendung
ˆ Beschrankung auf Webanwendung oder sind serverseitige Daten anderweitig nutzbar (z.B. SOAP- basierte Web Services)
Auch sollte durch die AJAX Popularitat nicht aus den Augen verloren werden, das der
Benutzer einer Webanwendung an den Page Reload gewohnt ist. Die prinzipielle Moglichkeit, mit AJAX Single Page Applications zu entwickeln ist verlockend. Dennoch verursacht
dies, in Abhangigkeit von dem genutzten Framework, Aufwand bei der Entwicklung, der
u.U. bei anderen Aspekten besser angebracht ist. Hier sei nicht nur die Funktionalitat
und Bedienbarkeit der Webanwendung erwahnt, sondern auch die Dokumentation.
29
4 Konzept einer clientzentrierten
Webanwendung
4.1 Bestimmung der AJAX Infrastruktur
4.1.1 Serverplattform
Bei der Umsetzung einer AJAX- basierten Webanwendung mussen verschiedene Randbedingungen festgelegt werden. Dazu gehort in erste Linie die Plattform fur die Server
Infrastruktur. Da diese nicht im Mittelpunkt der Arbeit steht, wird hier auf die Java Plattform gesetzt. Neben bereits vorhandenen Kenntnissen der Programmiersprache, existiert
auch eine Infrastuktur fur die MDSD, die als Basis genutzt werden kann.
4.1.2 AJAX Plattform
Bestimmung der Webanwendung
Der nachste Punkt ist die Wahl der AJAX Plattform. Hier muss festgelegt werden, ob
eine client- oder serverzentrierte Webanwendung entstehen soll, und ob diese als Single Page Application oder als hybride Webanwendung konzipiert wird. Worauf bereits in
Abschnitt 3.5 verwiesen wurde, ist eine hybride, clientzentrierte Webanwendung nicht
sinnvoll. Hybride Webanwendungen sind mittels der verfugbaren Webframeworks und ihrer AJAX Integration ohne Probleme realisierbar und ermoglichen einen einfachen und
schrittweisen U bergang zu AJAX Webanwendungen. Ein groerer Untersuchungsbedarf
besteht fur Single Page Applications. Deshalb soll sich hier auf diese konzentriert werden.
Single Page Applications spiegeln das Prinzip hinter AJAX am besten wieder: Durch die
Moglichkeit, Daten vom Server im Hintergrund zu beziehen, entfallt der Page Reload. Die
Konsequenzen im Kontext einer Webanwendung, sowie die Machbarkeit dieses Ansatzes,
sollen auf Basis der verfugbaren Technologien im Folgenden aufgezeigt werden.
Webframeworks fur serverzentrierte Webanwendungen haben nicht immer das Ziel einer
Single Page Application. Bestehende Frameworks, die mit AJAX Technologie erweitert
werden, zielen auf die komplette Generierung des benotigten JavaScript Codes ab. Andere
30
Frameworks wie ZK sind hingegen sehr speziell und gehen neue Wege, um Webanwendungen zu entwickeln. Basieren clientzentrierte Webanwendungen auf einer standardisierten
Kommunikation, sind sie unabhangig von der Serverplattform. Zusammen mit der Verlagerung der Prasentationslogik auf den Client, passen diese gut in das Konzept der
Service- orientierten Architektur[145] und sollen hier naher untersucht werden.
Interaktion
Die Portabilitat einer clientzentrierten Webanwendung hangt entscheidend von der Wahl
der Interaktion mit dem Server ab. Herkommliche Webanwendungen auf Basis der Java
Plattform nutzen den URL Querystring und die Servlet Technologie. Der URL Querystring
hat den Nachteil, das er nicht strukturiert ist. Die Servlet Technologie in Verbindung mit
einer Template- basierten Prasentationsschicht wie JSP oder Velocity[75] ist prinzipiell
auch geeignet, da mit Hilfe dieser Templates neben HTML auch XML oder JSON generiert werden kann. Der Nachteil ist lediglich der Programmieraufwand fur die Prasentationsschicht auf dem Server, da diese bei einer clientzentrierten Single Page Application
eigentlich nicht benotigt wird.
Hier stellen Kommunikationsframeworks, die auf dem RPC Pattern (siehe Abschnitt
3.1.2) basieren eine Vereinfachung dar. Diese ubernehmen den Konvertierungsaufwand
in das bevorzugte Datenformat, basieren auf einer standardisierten Kommunikation und
stellen eine wohldenierte Schnittstelle auf Clientseite zur Verfugung.
Das Pattern der RESTful Services (siehe Abschnitt 3.1.1) wird hier wegen der fehlenden
Unterstutzung nicht weiter betrachtet.
Datenformat
Wegen des wegfallenden Konvertierungsaufwands auf Clientseite wird als Datenformat
fur die U bertragung JSON favorisiert.
4.2 Architektur
Heutige Webanwendungen basieren meist auf der sogenannten 3- Tier- Architektur[76].
Dabei wird die Serverfunktionalitat in 3 logische Schichten aufgeteilt:
Persistenzschicht Ist fur die Bereitstellung und Verwaltung der Daten verantwortlich.
Business Logik Enthalt die domanenspezische Geschaftslogik der Webanwendung.
31
Prasentationsschicht Stellt die Benutzerschnittstelle zur Verfugung und ist fur die Reprasentation der Daten verantwortlich.
Fur die Entwicklung AJAX- basierter Webanwendungen werden Eingrie in die Prasentationsschicht notwendig. Wie bereits bei der Klassizierung von Webanwendungen in
Abschnitt 3.5 dargestellt, ist diese bei clientzentrierten Webanwendungen in den Client
verlagert. Da die Serverplattform nicht zentrales Thema der Diplomarbeit ist, wird hier
das Spring Framework eingesetzt. Dessen Architekturmodell ist gegenuber dem von Java
EE vereinfacht.
4.2.1 Spring Architekturmodell
Die Architektur einer Anwendung wird haug von den verwendeten Frameworks eingeschrankt bzw. in gewissem Mae vorgegeben. Die Architektur einer Webanwendung mit
dem Spring Framework wird in Abbildung 4.1 dargestellt.
Abbildung 4.1: Das Architekturmodell von Spring fur Webanwendungen aus [2]
Die Pfeile zwischen den einzelnen Schichten stellen die Zugrie dar. Die Applikationsschicht enthalt dabei die fachliche Logik der Anwendung. Diese wird meist auch als Domain Model bezeichnet. Die Service- Schicht stellt den Zugri auf die Business Klassen
bereit. Sie greift auf die Persistenzschicht zuruck um die Daten in einer Datenbank zu
speichern. Weiterhin stellt sie die Daten bereit, die in der Prasentationsschicht dargestellt werden sollen. Der Zugri auf diese Daten erfolgt dabei uber spezielle Controller,
welche die Anfragen des Clients bearbeiten. Der Controller wertet die Parameter der Anfrage aus, bezieht die notwendigen Daten von der Service- Schicht und gibt sie an die
32
Prasentationsschicht weiter. Hier werden diese dann in aufbereiteter Form an den Client
gesendet.
4.2.2 Angepasstes Architekturmodell
Das Spring Architekturmodell beinhaltet die Prasentationslogik auf dem Server. Deswegen sind fur clientzentrierte Webanwendungen noch kleine A nderungen notwendig. Neben
der Verlagerung der Prasentationsschicht vom Server auf den Client, wird eine Kommunikationsschicht eingefuhrt. Diese wird durch die Vielfalt der Interaktionsmoglichkeiten
von AJAX- basierten Webanwendungen notwendig, welche in Abschnitt 3 beschrieben
wurden. Das Architekturmodell fur clientzentrierte Webanwendungen ist in Abbildung
4.2 dargestellt.
Abbildung 4.2: Architekturmodell fur clientzentrierte Webanwendungen
Die einzelnen Schichten der Architektur werden in den folgenden Kapiteln in Bezug auf
die Videothek naher betrachtet.
4.3 Auswahl der Frameworks
Durch die groe Anzahl an verfugbaren AJAX Frameworks ist es sinnvoll, sich diese genauer zu betrachten, und bezogen auf die Anforderungen der Webanwendung zu bewerten.
33
So kann ein gutes Basisframework fur die bevorzugte Plattform gefunden werden. Nachdem im Abschnitt 4.1 die AJAX Infrastruktur fur das Videothekbeispiel bestimmt wurde,
erfolgt nun die Auswahl eines geeigneten Frameworks.
In Tabelle 3.4 sind die im Rahmen der Diplomarbeit betrachteten Frameworks herausgearbeitet, die sich als Basisframework eignen. Backbase ist kommerziell und somit fur
diese Diplomarbeit nicht von Interesse. Microsoft Atlas ist primar fur die .Net Plattform
entwickelt und eignet sich somit nicht als Basisframework. Durch die Festlegung einer
clientzentrierten Webanwendung, ist ZK ungeeignet. AjaxTags ist lediglich fur hybride
Webanwendungen geeignet. Durch die Plattformabhanigkeit von GWT wird der dojo
toolkit als Basis genutzt.
4.3.1 Dojo Toolkit
Nachdem im Abschnitt 3.6.1 ein U berblick uber den dojo Toolkit erfolgte, soll nun genauer
auf dessen Architektur eingegangen werden. Wie in Abbildung 4.3 dargestellt, ist dojo eine
Zusammenstellung von JavaScript Bibliotheken. Wie im Abschnitt 3.6.1 bereits erwahnt,
kann dojo mit Hilfe der build tools individuell zusammengestellt werden.
Abbildung 4.3: Aufbau des dojo Toolkits aus [3, Seite 8]
34
Die Grundlage bildet dabei das Package System, das die separate Nutzung der Bibliotheken sicherstellt. So mussen nur die Teile zum Webbrowser ubertragen werden, die in der
Webanwendung wirklich genutzt werden. Das Package System wird stets benotigt und
ist immer in der dojo Bibliothek vorhanden. Im Listing 4.1 soll die Nutzung des Package
Systems zum Nachladen weiterer Bibliotheken verdeutlicht werden.
1
2
3
4
5
<!
i n c l u d e dojo
>
<script
=" t e x t / j a v a s c r i p t "
</ s c r i p t >
<script
=" t e x t / j a v a s c r i p t ">
type
src
type
//
dojo
core
6
functionality
ready
7
dojo . r e q u i r e (
" d o j o . event . * " ) ;
8
//
event
now
,
dojo
9
10
dojo . r e q u i r e (
11
//
12
13
=" path / to / d o j o . j s ">
now
you
APIs
are
ready
to
to
use
use
" d o j o . widget . L a y o u t C o n t a i n e r " ) ;
can
use
the
LayoutContainer
widget
</ s c r i p t >
Listing 4.1: Beispiel zur Verwendung des dojo Package Systems in einer Webseite
Durch die Language- und Environment- specic Libraries werden dem Entwickler abstraktere APIs bereitgestellt. Diese verbergen die Inkompatibilitaten von Webbrowsern sowie
der verschiedenen JavaScript Derivate (siehe 2.2). Weiterhin bieten sie Hilfsfunktionen
und einfacher zu benutzende APIs fur das DOM und die CSS.
Mit den Application Support Libraries werden einzelne Aspkete einer Webanwendung
wie Drag and Drop, Animationen und Kommunikation zum Webserver unterstutzt. Der
Widget Toolkit bietet Zugri auf eine Vielzahl von Widgets. Mit seiner Hilfe lassen sich
auch eigene, wiederverwendbare Widgets erstellen.
In Abbildung 4.4 werden die einzelnen Schichten der dojo Architektur verdeutlicht.
Ein wichtiger Aspekt im Bootstrap von dojo ist der Parser. Mit Einbinden der dojo Bibliothek registriert er sich als Event- Listener beim HTML Dokument, wodurch er nach
kompletten Laden der Webseite aufgerufen wird. Er interpretiert den dojo- spezischen
Markup, der in der Webseite enthalten ist, und bindet ihn in die Webseite ein. Der dojospezische Markup kann dabei nicht nur HTML und XHTML, sondern auch SVG[77] und
VML[78] umfassen. Der Markup wird haug fur die Denition von Widgets genutzt.
Die einzelnen Konzepte und Bibliotheken von dojo, die bei dem Videotheksbeispiel Anwendung nden, werden in den folgenden Abschnitten naher erlautert. Einige Packages
setzen dabei eine spezielle Konguration voraus. Dazu wird ein Objekt namens djConfig
genutzt, welches vor dem Einbinden der dojo Bibliothek deniert werden muss. Listing
4.2 soll dies verdeutlichen.
35
Abbildung 4.4: Die Schichten der dojo Architektur aus [3, Seite 12]
1
2
3
4
5
6
7
8
9
10
11
<! d o j o
<script
config
object
>
= " t e x t / j a v a s c r i p t ">
var d j C o n f i g = f
isDebug
: true ,
debugContainerId
: " debugViewConsole " ,
preventBackButtonFix
: false
g;
</ s c r i p t >
type
<!
include
<script
</ s c r i p t >
type
dojo
library
after
= "text/ javascript "
config
src
object
>
= " path / to / d o j o . j s ">
Listing 4.2: Konguration von dojo
Eine gute Einfuhrung in dojo bietet die Prasentation IntroToDojo unter [3]. Die Prasentation DojoInDepth unter [79] fuhrt in weitergehende Konzepte von dojo ein. Das dojo
dot book unter [80] stellt eine Art How- To- Guide fur Webanwendungen mit dojo dar.
4.3.2 Direct Web Remoting
Der Kommunikationsmechanismus der Beispielwebanwendung wird mit den RPC umgesetzt. Der dojo Toolkit beinhaltet hierfur auch Bibliotheken, allerdings bietet sich durch
die Serverplattform Java das Framework DWR an. Es bietet gute Unterstutzung fur
verschiedene Java Webtechnologien:
ˆ Integration in verschiedene Frameworks wie Spring, Struts, WebWork, JSF
36
ˆ Integration mit dem in Spring vorhandenen Security Framework Acegi
DWR wird XML- basisert konguriert. Darin wird folgendes festgelegt:
ˆ Welche Objekte veroentlicht werden
ˆ Welche Klassen und Datentypen nach JavaScript konvertiert werden durfen
Durch die gute Unterstutzung des Springframeworks, konnen Objekte einfach durch Referenzierung der Spring Beans veroentlicht werden. Mit sogenannten Black- und Whitelisting konnen die veroentlichten Methoden der Objekte festgelegt werden. Blacklisting
sperrt den Zugri auf die Methoden, Whitelisting hingegen veroentlicht diese. Im Listing
4.3 ist die Veroentlichung eines Spring Beans verdeutlicht.
1
2
<! p r o v i d e
<c r e a t e
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
spring
=" s p r i n g "
=" s e s s i o n ">
bean
creator
3
4
the
scope
<param
javascript
="beanName"
name
value
=" U s e r S e r v i c e F a c a d e "
=" u s e r S e r v i c e F a c a d e "
<! e x p o r t o n l y t h e f o l l w i n g methods >
<! o n l y by name, t h e p a r a m e t e r s d o e s n ' t
<i n c l u d e
=" g e t A l l C a t e g o r i e s " >
<i n c l u d e
=" g e t A l l M e d i a " >
<i n c l u d e
=" g e t A l l P r o d u c t s " >
<i n c l u d e
=" getCategory " >
<i n c l u d e
=" getMedia " >
<i n c l u d e
=" getProduct " >
<i n c l u d e
=" g e t P r o d u c t s " >
<i n c l u d e
=" getMedias " >
<i n c l u d e
=" g e t C a t e g o r i e s " >
method
/
method
/
method
/
method
/
method
/
method
/
method
/
don ' t
export
the
note:
has
effect,
explicitly
no
with
following
name,
=" t o S t r i n g "
method
>
/
method
<e x c l u d e
</ c r e a t e >
matter
>
/
/
method
<!
<!
>
userServiceFacade
methods
because
not
>
methods
with
>
are
pattern
whitelisted
>
/
Listing 4.3: Bereitstellung eines Spring Beans als Remote Objekt in DWR
Weiterhin mussen DWR explizit die Klassen und Typen mitgeteilt werden, welche nach
JavaScript konvertiert werden sollen. Standardmaig werden nur die primitiven Datentypen, ihre Wrapper Klassen und die Datumsklassen (java.util.Date, java.sql.Date,
java.sql.Times und java.sql.Timestamp) konvertiert. Eigene Klassen sowie Arrays
von Objekten eigener Klassen mussen explizit fur die Konvertierung freigegeben werden.
Hierbei konnen bestimmte Attribute mit Black- und Whitelisting eingeschrankt werden,
wie im Listing 4.4 dargestellt.
37
1
2
3
4
5
6
7
8
< ! u s i n g DWRs j a v a b e a n c o n v e r t e r >
<c o n v e r t
="bean"
=" v i d e o l i b . s e r v e r . Product ">
<! a l l o w c o n v e r s i o n f r o m f o l l o w i n g a t t r i b u t e s >
<param
=" i n c l u d e "
=" p e r s i s t I d , name, d e s c r i p t i o n " >
<! b l a c k l i s t t h e f o l l o w i n g a t t r i b u t e >
<! n o t e : h a s no e f f e c t , b e c a u s e e x p l i c i t w h i t e l i s t i n g >
<param
=" e x c l u d e "
=" p e r s i s t V e r s i o n " >
</ c o n v e r t >
converter
match
name
value
name
value
/
/
Listing 4.4: Konguration von DWR zur Konvertierung bestimmter Java Typen nach
JavaScript
Die veroentlichten Objekte werden auf Clientseite als JavaScript Objekte bereitgestellt.
Dies wird mit einem Servlet realisiert, das auf die DWR Konguration zuruckgreift und
die erforderlichen JavaScript Dateien generiert.
DWR unterstutzt das Sicherheitskonzept von Java EE sowie das Acegi Security Framework. Fur jede Java EE Benutzerrolle wird eine separate Kongurationsdatei angelegt
sowie ein Servlet konguriert. Anhand der unterschiedlichen URL der Servlets kann die
Einteilung in Benutzerrollen erfolgen. Wie DWR mit Acegi genutzt werden kann, wird in
dem Tutorial unter [81] gezeigt.
Fur jedes veroentlichte Objekt wird auf Clientseite ein einfaches JavaScript Objekt
als Schnittstelle bereitgestellt. Bei Wechsel des Kommunikationsmechanismus kann dieses mit anderer Implementierung nachgebaut werden. Ein weiterer Weg, die Plattformabhangigkeit auf Clientseite zu begrenzen, ist die Verwendung des Business Delegate
Pattern[121]. Dabei nutzt nur ein Objekt diese JavaScript Schnittstellen, wodurch nur
an einem Objekt A nderungen bei Austausch des Kommunikationsmechanismus notwendig
werden.
4.4 Design einer Single Page Application
Durch den vollstandigen Verzicht auf Page Reloads wird die Startwebseite wahrend des
Benutzer- Workows sehr stark in ihrem Layout verandert, da sie alle moglichen Zustande
der Webanwendung reprasentieren muss. Fur die Beschreibung dieser Zustande gibt es
prinzipiell mehrere Wege:
ˆ Beschreibung der Startseite mittels Markup und Veranderung dieser durch dynamisches Hinzufugen und Entfernen von Seitenelementen mittels JavaScript
ˆ Nur unbedingt notwendige Elemente der Startseite mittels Markup beschreiben und
vollstandige dynamische Erzeugung der Seitenelemente mit JavaScript
38
ˆ Beschreibung der Webseite sowie deren einzelner Zustande mittels Markup
Der erste Ansatz spiegelt eine naive Herangehensweise wieder, der zweite ergibt sich
aus einer Fokussierung auf die dynamische Erzeugung und letzterer unterstutzt einen
deklarativen Ansatz.
Die dynamische Veranderung und Erzeugung der Struktur der Webseite ist durch den hohen debugging- Aufwand sehr entwicklungsintensiv. Daneben sind die einzelnen Zustande
der Webseite auch wenig transparent fur den Entwickler, wodurch die Gefahr von SideEekten und Memory- Leaks, z.B. durch nicht vollstandig entfernte Elemente, erhoht
wird.
Der deklarative Ansatz sollte hier bevorzugt werden. Der Entwickler kann vollig transparent das Layout der Webseite mit den zugehorigen Widget- Elementen gestalten. Die
einzelnen Elemente, die erst durch den Fortgang im Workow sichtbar werden, lassen
sich ebenfalls mittels Markup denieren und per CSS von der Darstellung ausschlieen.
Dadurch konnen die einzelnen Zustande der Webanwendung fast vollstandig beschrieben
werden. Nicht moglich ist lediglich die Beschreibung von Widget- Elementen, die sich
dynamisch in der Anzahl verandern, z.B. Widgets, die Eintrage einer Liste darstellen.
4.5 Inhalte von Webanwendungen
4.5.1 Statische und dynamische Inhalte
Webanwendungen bestehen aus verschiedenen Arten von Inhalten. Ganz allgemein kann
zwischen statischen und dynamischen Inhalten unterschieden werden. Zu den statischen
Inhalten gehort i.d.R. die Navigation, U berschriften und Beschreibungsfelder. Dynamische
Inhalte sind die eigentlichen Daten der Business Objekte, die von der Webseite dargestellt
werden sollen. Die Widget Elemente einer Webseite sollten diese Trennung ebenfalls
unterstutzen, indem statischer Inhalt per Markup angegeben werden kann. Dies fordert
die Transparenz der Webanwendung und eine klare Trennung.
4.5.2 Login- basierte Funktionalitat
Haug wird bei Webanwendungen ein Login bereitgestellt, durch welchen sich der Benutzer fur weitere Berechtigungen autorisieren kann. Hintergrund ist, dass die nutzbare
Funktionalitat der Webanwendung auf Benutzerrollen basiert. Hier bieten sich wieder
verschiedene Wege an:
ˆ Bereitstellung der nutzbaren Funktionalitat. Wird sich durch erfolgreichen Login fur
weitere Funktionen autorisiert, werden diese dynamisch der Webseite hinzugefugt.
39
ˆ Bereitstellung der gesamten Funktionalitat. Ist der Benutzer nicht autorisiert, wird
auf den Login verwiesen oder eine Fehlermeldung angezeigt.
ˆ Bereitstellung von mehreren Webanwendungen
Der Vorteil vom ersten Punkt ist die gute Bedienbarkeit der Webanwendung, da dem
Benutzer nur die Funktionalitat geboten wird, die er tatsachlich nutzen kann. Bei Aufruf
einer Funktionalitat wird i.d.R. das erwartete Ergebnis eintreten und keine Fehlermeldung
oder Umleitung zu einer Loginseite erfolgen. Jedoch kann dies auch als Nachteil gesehen
werden, da der Benutzer, sofern er noch nie autorisiert war, keine Kenntnisse von der
zusatzlichen Funktionalitat hat. Weil der Benutzer auch nie auf Autorisierung hingewiesen
wird, kann leicht der Eindruck entstehen, das dies keine Vorteile bringt.
Entscheidend sollte hier sein, wieviel Funktionalitat durch Autorisierung erlangt werden
kann und welche Zielgruppen mit der Webanwendung angesprochen werden sollen. Die
Integration der Administratorfunktionalitat in eine Shoppinganwendung ist weniger ratsam, da sich die Benutzerrollen Kaufer und Administrator sehr unterscheiden. Neben den
unterschiedlichen Workow von beiden, kann die Bereitstellung der Administratoranwendung im Internet ein Sicherheitsrisiko darstellen. In dem Fall bietet sich eine Trennung
auf Anwendungsebene an.
Wird bei einer Shoppinganwendung dem Benutzer ein Login angeboten, durch den er seine
Daten und Lieferadressen verwalten kann, ist es durchaus sinnvoll, diese Funktionalitat
standardmaig anzubieten. Allgemein ist die dynamische A nderung der Funktionalitat
weniger ratsam. Dadurch wird zusatzliche Logik auf Client- und Serverseite notwendig,
wodurch eine unnotige Kopplung verursacht wird.
4.6 Authentizierung
Die Authentizierung bedarf bei AJAX Webanwendungen einer besonderen Betrachtung.
Nach der Java EE Spezikation wird ein Benutzer nach erfolgreichem Login auf eine
Erfolgsseite, und bei nicht erfolgreichem Login auf eine Fehlerseite umgleitet. Da solche Seitenwechsel mit AJAX vermieden werden sollen, sind hierfur sind A nderungen am
Server notwendig, um die Weiterleitungen zu unterbinden. Diese sind im Tutorial unter [82] fur das Acegi Security System beschrieben. Das Tutorial zeigt auerdem, wie die
Authentizierung fur eine AJAX Webanwendung mit Acegi implementiert werden kann.
Bei AJAX Webanwendungen bietet sich die Formular- basierte Authentizierung an,
welche bereits bei herkommlichen Webanwendungen haug verwendet wurde. Durch
sie hat der Webdesigner die Moglichkeit, die Login- Seite individuell zu gestalten. Die
Authentizierung kann wie bei herkommlichen Webanwendungen genutzt werden, sollte allerdings mit AJAX Technologie zum Server gesandt werden. Nach der Java Servlet Spezikation[83, S. 93] muss das Feld fur den Benutzernamen j_username, und
40
das Feld fur das Passwort j_password genannt werden. Weiterhin muss als Aktion
j_security_check angegeben werden. Wird das Acegi Security System genutzt, muss
hier i.d.R. j_acegi_security_check angegeben werden.
4.7 History- und Bookmarkfahigkeit
Wie bereits in Abschnitt 2.3.3 dargestellt, verursacht die konstante URL bei AJAX Webanwendungen Probleme mit der Bedienbarkeit. Die History- und Bookmarkfahigkeit der
Webanwendung muss somit durch den Entwickler ermoglicht werden.
Konzeptionell kann hier zwischen History- und Bookmarkfahigkeit unterschieden werden.
Durch die Historyfahigkeit wird die Funktionalitat des Back- und Forward- Buttons sichergestellt. Die URL muss sich dabei nicht andern. Bookmarkfahig sind die Zustande
der Webanwendung allerdings erst, wenn sich die URL andert. Bei der Entwicklung sollte
dies berucksichtigt werden, da nicht unbedingt jeder Zustand der Webanwendung bookmarkfahig sein muss. Dazu gehoren z.B. die Webseiten, die bei einer Verkaufsanwendung
die Zahlungs- und Lieferformalitaten klaren. Daneben mussen auch nicht alle Veranderungen historyfahig sein. Werden lediglich Daten innerhalb eines Formulars aktualisiert,
so bedarf es normalerweise keines History- Eintrags. Dies ist jedoch sehr viel kontextsensitiver als die Bookmarkfahigkeit und sollte detailliert betrachtet werden.
Wie viele andere Frameworks auch, nutzt dojo hierfur den Anker der URL. Als Anker wird
der Teil einer URL nach dem Zeichen # bezeichnet. Wird der Anker einer URL geandert,
wird die Seite nicht neu geladen, da dieser in herkommlichen Webanwendungen fur den
Sprung an eine bestimmte Stelle innerhalb der Webseite genutzt wurde. Der Anker der
URL dient als eindeutiger Identikator fur den Zustand der Webanwendung.
In dem Package dojo.undo.browser bendet sich das History- und Bookmarksystem
von dojo. Um es zu benutzen, muss in der Konguration preventBackButtonFix:false
angegeben werden. Dadurch wird der Webseite ein verstecktes iframe1 hinzugefugt, welches zur korrekten Funktionsweise notwendig ist. Fur jeden history- und bookmarkfahigen
Zustand der Webanwendung muss ein State Objekt registriert werden, welches folgenden
Aufbau hat:
ˆ Ein optionales Attribut changeUrl, welches den Anker der URL enthalt. Wird dieses
auf den Wert "true" gesetzt, generiert dojo einen Identikator. Dieses Attribut ist
nur fur die Bookmarkfahigkeit notwendig.
ˆ Eine Funktion back() oder backButton() die aufgerufen wird, wenn durch drucken
des Back- Buttons in diesen Zustand gewechselt werden soll.
1
iframes sind eingebettete Frames und durfen anderen HTML Elementen enthalten sein. Mehr dazu
unter [84].
41
ˆ Analog eine Funktion forward() oder forwardButton(), wenn durch drucken des
Forward- Buttons in diesen Zustand gewechselt wird.
Alternativ kann anstelle der Funktionen auch eine Funktion handle(type) genutzt werden. Als Parameter wird entweder der String "forward" oder "back" ubergeben.
Mit der Anweisung dojo.undo.browser.setInitialState(state) muss der Startzustand einer Webanwendung festgelegt werden. Jeder weitere history- oder bookmarkfahige Zustand wird mit dojo.undo.browser.addToHistory(state) gesetzt.
Leider unterstutzt das History- und Bookmarkingsystem nicht alle Webbrowser. Eine
U bersicht dazu ndet sich im Wiki von dojo unter [85]. Darin ist neben der Funktionsweise auch der Hinweis enthalten, dass State Objekte mit dem Attribute changeurl
und ohne dieses, nicht gemeinsam in einer Webanwendung verwendet werden sollten.
Daraus ergibt sich die Konsequenz, das alle historyfahigen Zustande bookmarkfahig sein
mussen, wenn die Webanwendung bookmarkfahige Zustande bereitstellen soll. Um dies zu
verhindern, muss die Webanwendung zusatzliche Funktionalitat bereitstellen, die alle historyfahigen Zustande, die nicht bookmarkfahig sein sollen, auf bookmarkfahige Zustande
abbildet. Im einfachsten Falle kann hier naturlich auf die Startseite verwiesen werden,
allerdings besteht auch die Moglichkeit, diese auf den letzen bookmarkfahigen Zustand
des Workows abzubilden.
4.8 Das Widget System von dojo
Ein Widget ist ein sichtbares Element oder eine Menge von sichtbaren Elementen einer
Webseite. Es hat eine bestimmte Struktur, sowie ein deniertes Aussehen und Verhalten.
Beispiele sind HTML Elemente wie Button und Link. Ein Widget ist eine wiederverwendbare Komponente, da sie Daten einer festgelegten Datenstruktur darstellt.
Dojo besitzt ein modulares, Template- basiertes Widget System. Hauptziel von dojo ist
es, die Widgets per HTML- Markup denieren zu konnen und mittels CSS und JavaScript
benutzerfreundlicher zu gestalten. Die Erstellung eines Widgets durch eine JavaScript API
sollte moglich sein, jedoch nicht die einzige Moglichkeit. Dojo deniert ein Widget durch
die folgenden drei Aspekte:
HTML Eine HTML Datei enthalt die strukturelle Denition des Widgets. Diese ist keine
HTML konforme Webseite, sondern lediglich ein HTML Stub, der als Template fur
das Widget dient. Dieser HTML Stub darf lediglich ein Root Element besitzen. Es
durfen auch keine Widgets in dem Template verwendet werden, wie z.B. ein dojo
Button Widget.
CSS Eine CSS Datei, die das Layout und Aussehen der Elemente des HTML Stubs
beschreibt.
42
JavaScript Einige Zeilen JavaScript Code, die das Widget als JavaScript Objekt denieren, den aus dem Template generierten DOM Baum verwalten und es programmiertechnisch zuganglich machen. Die Nutzung einer separaten JavaScript Datei
vereinfacht die Wiederverwendbarkeit des Widgets.
Zwischen dem HTML Template und der JavaScript Denition des Widget Objektes gibt
es einige Zusammenhange. Dazu gehort spezieller Markup, der fur folgende Konzepte
des Widget Systems verwendet wird:
ˆ Properties
ˆ Placeholders
ˆ dojo Attach Points
ˆ dojo Attach Events
Nachfolgend soll jedes Konzept etwas detaillierter betrachtet werden.
4.8.1 Das Properties Konzept
Das Root- Element des HTML Templates spiegelt das JavaScript Widget Objekt wieder.
Hat das Widget Objekt Attribute, so konnen diese mit Attributen des Root Elementes
gesetzt werden. Dabei werden neben primitiven Datentypen auch Arrays und Funktionen
unterstutzt. Auf diese Weise konnen deklarativ die Attributwerte gesetzt werden. Weiterhin hat jedes JavaScript Objekt das spezielle Attribut domNode, welches den Zugri
auf den DOM Knoten des Root Elementes erleichtert.
Listing 4.5 zeigt einen Ausschnitt der JavaScript Denition eines Widgets. Die darin
enthaltenen Properties werden bei Nutzung des Widgets mit dem HTML Code aus Listing
4.6 gesetzt. Das Listing 4.7 zeigt die Werte der Properties, nachdem der dojo Parser diese
wahrend der Erstellung des Widgets gesetzt hat.
1
//
2
aNumber
3
4
5
property
definitions
in
widget
: 0,
aString
: "" ,
anArray
: [],
aFunction
: f u n c t i o n ( e v e n t ) fg ,
template
Listing 4.5: Denition der Widget Properties im JavaScript Template
43
1
<d o j o : T e s t W i d g e t
aNumber
2
aString
3
anArray
4
aFunction
5
</ d o j o : T e s t W i d g e t>
=
=
=
=
"42"
" h e l l o dojo "
"one ; two ; t h r e e "
" doSomething ( ) "
>
Listing 4.6: Setzen der Property Werte beim Einbinden des Widgets in eine XHTML Seite
1
//
2
aNumber
3
4
5
property
values
= 42
aString = "hello
dojo "
a n A r r a y = [ "one" , "two" , " t h r e e " ]
aFunction = doSomething
Listing 4.7: Werte der Properties, nachdem der Parser diese gesetzt hat
4.8.2 Das Konzept der Platzhalter
Im HTML Template des Widgets konnen Platzhalter verwendet werden, die beim einbinden des Widgets in die Webseite durch den Parser ersetzt werden. Diese Platzhalter
konnen Attribute des JavaScript Objektes direkt referenzieren. Es ist aber auch moglich,
mittels der Funktion postMixInProperties() ein separates Mapping fur die Platzhalter
anzugeben.
Im Listing 4.8 ist ein HTML Template eines Widgets mit zwei Platzhaltern deniert.
Dabei referenziert der Platzhalter ${this.content} ein Attribut des Widget Objektes.
Dadurch kann der dojo Parser den Platzhalter automatisch mit dem Wert des Attributes
ersetzen. Listing 4.9 zeigt, wie der Platzhalter ${title} ersetzt wird.
1
2
3
4
5
6
7
<d i v
=" TestWidget ">
<! u s i n g a p l a c e h o l d e r >
< d i v >$ f
g</ d i v >
<! p l a c e h o l d e r t h a t r e f e r e n c e s
class
t i t l e
property
< d i v >$ f
</ d i v >
from
the
widget
t h i s . content
object
g</ d i v >
a
>
Listing 4.8: Verwendung von Platzhaltern im HTML Template eines Widgets
44
1
//
2
postMixInProperties
replace
this .
3
5
6
7
strings
//
4
g,
g;
placeholders
=
replaces
t i t l e
f
in
widget
: function ( )
the
f
template
placeholder
: " hello placeholder"
title
Listing 4.9: Ersetzen der Platzhalter eines Widgets
4.8.3 Konzept der dojo Attach Points
Sollen Inhalte auf der Webseite aktualisiert werden, so muss auf die entsprechenden
Knoten im DOM Baum zugegrien werden. Besitzen diese Elemente keine eindeutige ID,
ist es meist umstandlich, eine Referenz auf den entsprechenden Knoten zu bekommen.
Dies vereinfacht dojo mit dem Konzept der dojo Attach Points. Wird einem Element aus
dem HTML Template das Attribut dojoAttachPoint zugewiesen, dann steht der DOM
Knoten dieses Elementes auf einer Variable des JavaScript Objektes zur Verfugung, die
als Namen den Wert des Attributes hat.
Eine spezielle Bedeutung dabei hat der Attributwert containerNode. Wird bei Nutzung
des Widgets dem HTML Element Inhalt zugewiesen, so wurde dieser verloren gehen, weil
das HTML Element durch das HTML Template ersetzt wird. Um dies zu verhindern,
kann dem Element im HTML Template, das den Inhalt aufnehmen soll, das Attribut
dojoAttachPoint="containerNode" zugewiesen werden. Der Parser weist dann den
angegeben Inhalt diesem Element zu.
Im Listing 4.10 ist die Verwendung von Attach Points in einem HTML Template beispielhaft dargestellt. Wird das Widget in eine Webseite, wie in Listing 4.11 dargestellt,
eingebunden, so ist dem Widget ein Inhalt zugewiesen. Durch die Denition eines dojo
Attach Points mit Namen containerNode, verwirft der Parser den Inhalt nicht, sondern
weist ihm diesem DOM Knoten zu. Abbildung 4.5 zeigt das Widget im Webbrowser,
bevor der Code in Listing 4.12 ausgefuhrt wird. Listing 4.12 zeigt den Zugri auf den
dojo Attach Point test mit JavaScript. Dabei wird dem DOM Knoten ein Text Knoten
mit dem Wert inserted with dojo attach points hinzugefugt. Das Resultat ist in
Abbildung 4.6 zu sehen.
4.8.4 Konzept von dojo Attach Event
A hnlich dem Konzept der dojo Attach Points, kann einem Element im HTML Template auch das Attribut dojoAttachEvent zugewiesen werden. So konnen den Events des
45
1
2
3
4
5
6
7
<d i v
class
<!
<d i v
<!
<d i v
</ d i v >
= " TestWidget ">
dojo
attach
point
dojoAttachPoint
special
dojo
for
= " t e s t ">
attach
dojoAttachPoint
accessing
point
that
dom
node
>
>
= " containerNode ">
Listing 4.10: Verwendung von dojo Attach Points im HTML Template eines Widgets
1
2
3
<d o j o : T e s t W i d g e t>
Hello
dojo
Attach
</ d o j o : T e s t W i d g e t>
Point
World .
Listing 4.11: Zuweisung von Inhalt bei Verwendung des Widgets
Dom Knotens auf einfache Weise Eventhandler zugewiesen werden. Die einzelnen Zuweisungen werden mit einem Semikolon getrennt. Eine Zuweisung besteht aus Eventname
und Namen der Eventhandler- Funktion. Beide werden durch einen Doppelpunkt voneinander getrennt. Sind Eventname und Eventhandler gleich, so genugt die Angabe des
Eventnamens ohne den folgenden Doppelpunkt.
Als Beispiel soll hier das Button Widget von dojo dienen. Listing 4.13 zeigt die Verwendung von dojo Attach Event im HTML Template des Button. Im JavaScript Widget
Objekt sind die zugewiesenen Eventhandler- Funktionen implementiert. Einen Ausschnitt
zeigt Listing 4.14.
Abbildung 4.5: Darstellung des Widgets 4.10 im Webbrowser vor Ausfuhrung der JavaScript Anweisung in Listing 4.12
46
1
2
//
this .
3
4
5
in
a
function
of
that
widget
. appendChild (
. createTextNode (
" i n s e r t e d with d o j o a t t a c h p o i n t s " )
test
document
);
Listing 4.12: JavaScript Anweisung fur den Zugri auf einen DOM Knoten mit dojo
Attach Points
Abbildung 4.6: Darstellung des Widgets 4.10 im Webbrowser nach Ausfuhrung der JavaScript Anweisung in Listing 4.12
1
dojoAttachEvent
2
=
"onMouseOver ; onMouseOut ; onMouseDown ;
onMouseUp ; o n C l i c k : b u t t o n C l i c k ; "
Listing 4.13: Beispiel zur Zuweisung von Events und Eventhandlern mit dojo Attach Event
1
//
2
onMouseOut
3
//
4
g,
event
handler
for
event
onMouseOut
for
event
onClick
: function ( event )f
implementation . . .
5
6
//
7
buttonClick
8
9
g,
event
//
handler
: function ( event )f
implementation . . .
Listing 4.14: Implementierung der Event- Handler im Widget Objekt
47
4.8.5 Wichtige Funktionen
Wahrend der Erstellung des Widgets werden durch den Parser verschiedene Funktionen
des Widget Objektes aufgerufen, die fur unterschiedliche Aspekte genutzt werden konnen.
Folgend sind die wichtigsten Funktionen in der Reihenfolge aufgelistet, wie sie vom Parser
aufgerufen werden:
postMixInProperties wird haug zum Ersetzen der Platzhalter im Template verwendet.
Auf DOM Knoten des Widgets kann hier noch nicht zugegrien werden.
llInTemplate wird genutzt, um das Template mit Inhalt zu fullen. Hier kann bereits auf
DOM Knoten des Widgets uber dojo Attach Points zugegrien werden.
postInitialize kann verwendet werden, um das Widget zu initialisieren.
postCreate wird aufgerufen, wenn das Widget fertig erstellt ist.
cleanUp kann zum Aufraumen verwendet werden, wenn das Widget Objekt geloscht
wird.
4.9 Anwendung des dojo Widget Systems
Wahrend grasche Desktop Anwendungen haug auf Standardwigets basieren, sind im
Gegensatz Webanwendungen meist ansprechender und individueller gestaltet. Bei kommerziellen Webanwendungen steht die Abhebung von der Konkurrenz sicherlich im Vordergrund. Daher liegt es nahe, fur die Inhalte, die eine Webanwendung prasentieren soll,
spezielle Widgets zu erstellen, da hier dem Webdesigner alle Moglichkeiten oen stehen. Bei Standardwidgets ist die HTML Struktur bereits vorgegeben, wodurch sich Einschrankungen bei der Gestaltung mit CSS ergeben. Allerdings sind Standardwidgets fur
viele Zwecke dennoch ausreichend, wie z.B. der Navigation. Benutzerdenierte Widgets
bieten sich vor allem fur die prasentierten Daten der Business Objekte an.
4.9.1 Inhalte von Widgets
Wie bereits in Abschnitt 4.5.1 beschrieben, konnen die Inhalte von Widgets in zwei Kategorien eingeteilt werden:
Statische Inhalte, die sich uber die Lebensdauer des Widgets hinweg nicht verandern.
Dies konnen z.B. U berschriften oder Beschriftungsfelder sein.
Dynamische Inhalte, die sich haug andern konnen. Dies betrit in der Regel die Daten
der Business Objekte, die dargestellt werden sollen.
48
Statischer Inhalt muss dem Widget nur bei der Erstellung zugewiesen werden, da sich
dieser wahrend der Lebenszeit nicht verandert. Hier bietet sich die deklarative Zuweisung
des Inhalts mit Markup an. Dies erhoht die Wiederverwendbarkeit des Widgets durch eine
klare Trennung von Inhalt und Funktion des Widgets. Weiterhin bietet sich das Konzept
der Platzhalter an. So werden bei Erstellung des Widgets die statischen Inhalte vom
Parser in das Widget eingebunden. Durch den statischen Charakter der Daten ist eine
A nderung und somit ein Zugri wahrend der Lebenszeit des Widgets nicht notwendig.
Durch die Veranderlichkeit der dynamischen Inhalte, muss auf diese wahrend der Lebenszeit des Widgets zugegrien werden. Hier ist das Konzept der Platzhalter ungeeignet, da
der Zugri auf dem DOM Knoten nur umstandlich uber den DOM Baum moglich ist.
Die Alternative, bei A nderung der Daten das Widget neu zu erstellen, ist Performance
intensiv. Daher bietet sich bei dynamischen Inhalten das Konzept der dojo Attach Points
an. Der Parser stellt automatisch die DOM Knoten als Attributwerte bereit, wodurch der
Inhalt mit einer Anweisung geandert werden kann. Die Wiederverwendung vorhandener
DOM Knoten wirkt sich auch positiv auf die Performance aus.
4.9.2 Data Binding
Die Verantwortung eines Widgets bezieht sich u.a. auf die Darstellung der Daten. Um
veranderliche Inhalte darzustellen, mussen diese in einer festgelegten, fur das Widget
lesbaren Form vorliegen. Solche Datenstrukturen werden als DTOs2 bezeichnet. Wird das
DTO eines Widgets geandert, wird automatisch auch die Anzeige aktualisiert. Besitzt
das Widget die Fahigkeit, Daten zu andern, so werden diese auch im DTO geandert.
Diese Synchronitat wird auch als Data Binding bezeichnet, weil ein DTO an das Widget
gebunden wird.
Im Falle von AJAX Webanwendungen ist neben dem Data Binding mit einem DTO auch
ein erweitertes Request Binding denkbar. In diesem Falle wird nicht nur das DTO an
das Widget gebunden, sondern zusatzlich auch noch, woher dieses zu beziehen ist. Dies
wurde die Kommunikation mit dem Server in das Widget verlagern. Bei DWR mussten
das JavaScript Objekt, die Methode sowie die notwendigen Parameter zusatzlich an das
Widget gebunden werden.
Solch eine Moglichkeit hat mehrere Konsequenzen. Durch die zusatzliche Funktionalitat
erhoht sich die Verantwortlichkeit des Widgets. Dies ist ganz im Sinne von Widget Komponenten mit einer geschlossenen Funktionalitat.
Nachteilig wirkt sich jedoch aus, dass die Widgets Request- spezisch werden. Ein Wechsel des Kommunikationsmechanismus wurde A nderungen an den Widgets verursachen.
2
DTO ist die Abkurzung von Data Transfer Object. Es ist ein allgemeines Pattern zum Datenaustausch.
Weitere Informationen gibt es in den Java EE Pattern Catalog unter [86]. Andere Bezeichnungen fur
Data Transfer Object ist Value Object oder Transfer Object.
49
Durch die Ausfuhrung der Requests zum Server, muss das Widget auch Funktionen zum
Errorhandling bieten. Da dies aus Grunden der Bedienbarkeit in der gesamten Webanwendung in einheitlicher Form erfolgen sollte, muss das Widget eine Schnittstelle besitzen,
mit der sich Errorhandler kongurieren lassen.
Aus diesen Grunden wird das Request Binding nicht weiter verfolgt, da es den Funktionsumfang eines Widgets unnotig aufblahen wurde. Mit der Beschrankung auf ein DTO
Binding sind die Widgets von dem Kommunikationsmechanismus entkoppelt. Die Bereitstellung der DTOs kann eine zentrale Kontrollerkomponente ubernehmen.
4.9.3 Widget Beziehungen
Eine Webseite besteht aus einer Vielzahl von sichtbaren Widgets. Widgets lassen sich
ganz allgemein in zwei Gruppen einteilen:
ˆ Layout Widgets, welche zur Seitenaufteilung und Positionierung anderer Widgets
genutzt werden.
ˆ Daten Widgets, die u.a. die Daten der Business Objekte darstellen.
Eine Webanwendung besitzt zur besseren Orientierung ein konsistentes Layout, wodurch
Layout Widgets i.d.R. nicht vom Zustand der Webanwendung abhangen. Daher sollen im
folgenden die Daten Widgets naher betrachtet werden.
Daten Widgets konnen mit anderen Daten Widgets in Beziehung stehen, so das der Inhalt
eines Widgets von einem anderen abhangt. Fur die Realisierung solcher Abhangigkeiten
bieten sich prinzipiell zwei Wege an:
ˆ Eine direkte Verkettung mittels Master- Detail- Widget. Dabei halt das MasterWidget eine Referenz auf das Detail- Widget und aktualisiert dessen Daten.
ˆ Verlagerung der Verkettung der einzelnen Widgets in einen zentralen Controller.
Dieser dient als Eventhandler und steuert abhangig vom Event alle Widgets der
Webanwendung. Dadurch sind die Widgets indirekt verknupft.
Beide Moglichkeiten sollen im folgenden naher betrachtet werden.
Master- Detail- View Verkettung
Ein typisches Beispiel fur ein Master- Detail- View ist die Navigation einer Webseite.
Die Navigationsleiste ist der Master, welcher abhangig von der Auswahl den Inhalt des
Detail- Views bestimmt. Vorteil einer solchen Losung ist die gekapselte Funktionalitat
der Widgets.
50
Nachteilig wirkt sich hier die Verknupfbarkeit der Widgets innerhalb einer Webanwendung aus. Heutige Webanwendungen enthalten haug eine horizontale und eine vertikale
Navigationsleiste sowie Sidebars. Neben diesen enthalt auch das Widget, in dem der eigentliche Inhalt der Webanwendung dargestellt wird, Verknupfungen zu anderen Widgets.
Bedingt durch diesen prinzipiellen Aufbau, gibt es haug mehrere Master- Widgets zu einem Detail- Widget. Abhangig vom Kontext, ist es dennoch haug so, dass das DetailWidget entscheidend fur den Zustand einer Webanwendung ist. Dadurch musste in einer
AJAX Webanwendung das Detail- Widget die Zustande der Webanwendung verwalten.
Da aber bei guter Trennung der Verantwortlichkeiten der Detail- View keine Kenntnis
vom Master- View besitzen sollte, gibt es keine Moglichkeit mehr, die Master- Widgets
abhangig vom Zustand der Webanwendung zu gestalten.
Zentrale Steuerung
Eine Alternative zum Master- Detail- View ist die Verkettung der Widgets uber einen zentralen Controller. Dabei werden Events an den Controller ubergeben, der dann abhangig
vom Event die anderen Widgets steuert. Master- Widgets gibt es bei dieser Architektur
in dem Sinne nicht mehr. Lediglich der Controller konnte als Master bezeichnet werden.
Durch die zentrale Steuerung der Events bietet sich der Controller auch dafur an, die
Zustande der Webanwendung zu verwalten.
Ein weiterer Vorteil ist, dass der zentrale Controller nicht alle Widgets, sondern nur alle
zustandsbasierten Widgets steuern muss. Dadurch konnen auch sogenannte CompositeWidgets genutzt werden. Composite- Widgets sind Widgets, die aus anderen Widgets
aufgebaut sind. Die gekapselten Widgets sind nicht vom Zustand der Webanwendung,
sondern vom Zustand des Eltern- Widgets abhangig. Daher muss der Controller lediglich
das Eltern- Widget steuern, nicht die darin enthaltenen.
Somit sind die Probleme bei der Master- Detail- View Verkettung umgangen. Als nachteilig konnte lediglich der erhohte Aufwand bei der Entwicklung der Architektur angesehen
werden.
Im Rahmen der Diplomarbeit soll die Zustandsverwaltung der Webanwendung mit einem
zentralen Controller weiter verfolgt werden. Dieser steuert alle zustandsbasierten Widgets, wobei die Moglichkeit von Composite- Widgets nicht ausgeschlossen werden soll.
Durch einen zentralen Controller wird die Verknupfung von Widgets untereinander auch
transparenter fur den Entwickler.
4.9.4 Accessibility
Bei der Entwicklung von Widget- Elementen sollten die Richtlinien uber den barrierefreien
Zugang zu Webanwendungen berucksichtigt werden. Neben dem Layout und Aussehen
51
des Widgets, sowie den Alternativen fur multimediale Inhalte, muss auch der Entwurf
der Benutzerschnittstelle Beachtung nden. Hierzu gehort die alternative Bedienung mit
Tastatur, welche in diesem Abschnitt naher betrachtet werden soll.
Haug werden die Tabulator- Taste und Tasten- Kurzel zur alternativen Steuerung mit
Tastatur verwendet. Bei Navigationen erweist sich aber auch die Steuerung mit den
Cursor- Tasten als sinnvoll. Im folgenden soll auf verschiedene Moglichkeiten eingeganen
werden.
Moglichkeiten mit HTML
HTML deniert fur die alternative Steuerung von Elementen, welche im Sinne von HTML
als Benutzerschnittstelle gelten, die Attribute accessKey und tabIndex. Als Benutzerschnittstelle gelten lediglich die Elemente, die den Fokus erhalten konnen, wie z.B. der
Link oder der Button. Mit accessKey kann eine Taste angegeben werden, die mit der
alt- Taste als Tastenkurzel verwendet werden kann, um dem Element den Fokus zuzuweisen. Das Attribut tabIndex dient zur Festlegung der Reihenfolge, in welcher Elemente
mit Hilfe der Tabulator- Taste fokussiert werden konnen. Es dient zur A nderung der
Standardreihenfolge, die vom Webbrowser automatisch festgelegt wird.
Besitzen HTML Elemente den Fokus, so konnen sie i.d.R. mit der Tastatur gesteuert
werden. Bei Gruppenelementen kann das gewunschte Element mit den Cursor- Tasten
gewahlt werden. Checkboxen konnen mit der Leertaste aktiviert bzw. deaktiviert werden.
Die Return- Taste dient zur Ausfuhrung der Aktion des Elementes.
Moglichkeiten mit JavaScript
Bei AJAX- basierten Webanwendungen werden Benutzerschnittstellen haug grasch
nachgebaut. Beim verwendeten dojo Toolkit ist das Button- Widget z.B. kein HTML
Button, sondern besteht aus Bildern mit einem Text. Hier kann auf die Tastaturevents
onkeypress, onkeydown und onkeyup zur Tastatursteuerung ausgewichen werden. Diese
konnen einer breiteren Palette von HTML- Elementen zugewiesen werden3 . Tritt ein
Event ein, so wird dieses nicht nur dem fokusierten Element ubergeben, sondern auch
den Elternelementen. Nachteilig wirkt sich hier allerdings aus, dass ein Element entweder
fokusierbar sein muss, oder fokusierbare Kindelemente besitzen muss, um Tastaturevents
zu beziehen.
Eine andere Alternative bietet das window- Objekt, welches Tastaturevents abfangen
kann. Dadurch ist es moglich Tastaturevents global abzufangen und zu behandeln, ohne
3
Eine U bersicht, welchen Elementen diese Attribute zugewiesen werden konnen, ndet sich unter [87].
Darin werden auch alle anderen Events beschrieben.
52
der vorherigen Fokussierung eines Elementes. Die Beschreibung von selfhtml dazu bendet sich unter [88]. Der Nachteil ist hier allerdings, dass das window- Objekt nicht
standardisiert ist (siehe Abschnitt 2.2), wodurch sich Webbrowser Inkompatibilitaten ergeben konnen.
Fur den dojo Toolkit ist ein Konzept fur globales Hotkey- und Fokus- Management bereits
in Planung. Naheres dazu ist unter [89] beschrieben.
Ein genereller Nachteil bei Events mit JavaScript sind die Webbrowser Inkompatibilitaten
bei dem ubergebenen Event- Objekt[90]. Dadurch wird die Bestimmung der zusatzlich
gedruckten Sondertasten erschwert. Zur Vermeidung von Konikten und zur Erhohung
der Transparenz sollten Tastaturkurzel deklarativ dem Widget zugewiesen werden.
4.9.5 Internationalisierung und Lokalisierung
Ein weiteres Konzept von Webanwendungen, welches bei der Entwicklung von Widgets
Berucksichtung nden muss, ist die Bereitstellung des Inhalts fur verschiedene Sprachen
und Lander. Neben der Zufriedenheit des Benutzers, welcher den Inhalt in seiner nativen
Sprache vorndet, ist ein weiterer Vorteil die Trennung von Quellcode und Beschreibungstexten. Die Internationalisierung einer Webanwendung umfasst dabei:
ˆ Bereitstellung einer U bersetzung der Texte
ˆ Spezielle Formatierungen, z.B. Zahlen, Wahrungen, Datums- und Zeitangaben
ˆ Berucksichtung von Sprachen, welche von Rechts nach Links gelesen werden
ˆ Berucksichtung bei der Validierung von Eingaben
Fur den dojo Toolkit bendet sich die Internationalisierung in Entwicklung. Aktuell ist
lediglich die Bereitstellung von U bersetzungen nicht mehr als experimentell deklariert.
Daher wird sich im folgenden naher mit der Bereitstellung und Nutzung lokalisierter
Ressourcen beschaftigt.
Bereitstellung lokalisiserter Ressourcen
Die U bersetzungen werden in separaten JavaScript Dateien auf dem Webserver hinterlegt. Diese beinhalten ein in JSON kodiertes JavaScript Objekt, das als Attribute die
Schlusselworter, und als Werte die U bersetzungen enthalt. Listing 4.15 zeigt die U bersetzungen der Jahreszeiten. Dabei sind die Werte nicht auf einen bestimmten Typ beschrankt. Neben Zeichenketten konnen auch Objekte angegeben werden. Diese lokalisierten Ressourcen werden in das dojo Package System eingebunden und konnen mit
dojo.requireLocalization("package", "filename") referenziert werden. Mit dieser Anweisung ladt dojo die geeignetsten Ressourcen vom Server.
53
1
2
//
(f
standard
3
spring
4
summer
5
f a l l
6
winter
7
g)
translations
:
:
:
:
"string",
"summer" ,
"autumn" ,
"winter"
Listing 4.15: Bereitstellung lokalisierter Ressourcen
Die <package>- Angabe bezeichnet dabei ein dojo Package, welches durch das dojo
Package System auf ein Verzeichnis abgebildet wird. In diesem Verzeichnis mussen die
lokalisierten Ressourcen in einer bestimmten Verzeichnisstruktur vorliegen. Diese ist in
Abbildung 4.7 dargestellt. Das Package- Verzeichnis muss einen Ordner nls enthalten,
welcher die lokalisierten Ressourcen beinhaltet, die mit <filename>.js benannt sind.
Abbildung 4.7: Aufbau der Verzeichnisstruktur zur Internationalisierung eines Widgets
Im Ordner nls stehen dabei die Standard- Ressourcen. Zur allgemeinen Verstandlichkeit
sollten die Standard- Ressourcen in Englisch gehalten sein. In Unterordnern, die nach
dem Locale 4 benannt sind, konnen spezialisiertere Ressourcen bereitgestellt werden. Diese Spezialisierungen mussen nicht den vollstandigen Inhalt besitzen, sondern beinhalten
nur den speziellen Inhalt fur den Locale. Listing 4.15 zeigt die Standardubersetzung der
Jahreszeiten. Fur amerikanisches Englisch kann eine spezialisiertere U bersetzung bereitgestellt werden, wie in Listing 4.16 dargestellt.
Zu beachten ist allerdings, dass dojo bei dem Locale den Strich als Separator benutzt
und alle Angaben in Kleinschreibung normalisiert. So werden deutsche Ressourcen z.B.
4
Der Locale ist eine kurze Angabe zur Bestimmung der Sprache und des Landes. Mehr Informationen
im Wikipedia Artikel unter [91].
54
1
2
3
4
//
(f
g)
translations
f a l l
for
en
us
: "fall"
Listing 4.16: Bereitstellung spezieller lokalisierter Ressourcen
im Ordner de bereitgestellt, solche fur amerikanisches Englisch im Ordner en-us.
Beim Erstellen der Ressourcen sollte auch das verwendete Encoding beachtet werden.
Hier bietet sich UTF-8[92] an.
Nutzung lokalisierter Ressourcen
Mit der Anweisung dojo.i18n.getLocalization("package", "filename") wird auf
die lokalisierten Ressourcen zugegrien. Die Anweisung gibt dabei ein JavaScript Objekt zuruck, welches die passendsten Ressourcen zum aktuellen Locale enthalt. Mit den
denierten Schlusselwortern kann auf die lokalisierten Daten zugegrien werden.
Die U berprufung, ob die Sprache von Rechts- nach Links gelesen wird, erfolgt mit der
Funktion dojo.i18n.isLTR(). Dies ist z.B. fur Menu- Widgets wichtig, welche in dem
Falle rechtsbundig ausgerichtet werden und nach links anstatt nach rechts aufklappen
mussen.
Um bei der Entwicklung die Lokalisierung zu testen, kann der Locale auf einfache Weise
mit dem Attribut locale des djConfig- Objektes5 geandert werden. Sollen mehrere Locales auf einer Seite verwendet werden, konnen diese mit dem Attribut extraLocale als
Array gesetzt werden. Diese konnen verwendet werden, indem der Locale als dritter Parameter der Funktionen dojo.requireLocalization und dojo.i18n.getLocalization
als String angegeben wird.
Funktionen zur Formatierung und Validierung von Zahlen, Wahrungen, sowie Datumsund Zeitangaben sind in Entwicklung. Auf die Validierung wird im nachsten Abschnitt
naher eingegangen.
Abschlussbemerkungen
Durch die verschiedenen Ressourcen werden mehrere Verbindungen zum Server notwendig, um alle geeigneten Ressourcen zu beziehen. Mit der Integration der Internationalisierung wurde das dojo Build System so erweitert, das es in der Lage ist, die verschiedenen
Ressourcen so zusammenzustellen, das lediglich nur noch eine Datei pro Locale vom
5
Siehe dazu Konguration von dojo im Abschnitt 4.3.1.
55
Server bezogen werden muss. Auch entfallt das Suchen nach den verschiedenen LocaleVarianten. Mehr Informationen dazu unter [93].
Ein kleines Tutorial, wie Widgets lokalisiert werden konnen, ist unter [94] zu nden. Der
U berblick fur die Internationalisierung bei dojo ndet sich unter [93]. Eine Auistung
von Aspekten, welche bei der Internationalisierung einer Anwendung Beachtung nden
sollten, gibt das Tutorial von Sun unter [95] wieder.
4.9.6 Validierung von Benutzereingaben
Eng mit der Internationalisierung und Lokalisierung ist die Validierung von Benutzereingaben verbunden. Herkommliche Webanwendungen validieren die Benutzereingaben haug
auf Serverseite. Das Webframework tapestry[96] besa ein eigenes clientseitiges Validierungsframework, welches durch das dojo Validation Framework ersetzt wurde.
Grundsatzlich ist es eine Design- Entscheidung, ob client- oder serverseitige Validierung
eingesetzt wird. Im Falle von AJAX Webanwendungen, besonders von Single Page Applications, liegt die Verwendung von clientseitiger Validierung nahe. Allerdings ist bei
AJAX Webanwendungen, speziell bei denen, die zur Kommunikation auf standardisierte
Schnittstellen setzen, die oene Server API zu nennen, welche entweder durch Sicherheitsmanahmen oder durch zusatzliche Validierung abgesichert sein sollte. Hier kann
nicht prinzipiell davon ausgegangen werden, dass alle Daten clientseitig erfolgreich validiert wurden.
Der beste Weg fur die Validierung von Benutzereingaben ist, die Validierung zu vermeiden.
Hierfur konnen in einigen Fallen spezielle grasche Widgets bereitgestellt werden. Bei der
Eingabe von z.B. Datumsangaben konnen grasche Kalender genutzt werden, wodurch
die Validierung des Datums uberussig wird.
Wird die Validierung notwendig, bietet dojo mehrere Wege an:
ˆ Funktionen zur manuellen Validierung von Eingaben
ˆ Verwendung von validierenden Eingabefeldern
ˆ Validierung von Formularen anhand eines Proles
Diese Moglichkeiten sollen im folgenden etwas naher betrachtet werden.
Manuelle Validierung
Dojo bietet mit dem Package dojo.validate.* eine Sammlung von Funktionen zur
Validierung an. So sind neben Validierungen fur Datums- und Zeitangaben, auch solche
56
fur Email- und Webadressen enthalten. Auch sind einige landesspezischen Validierungsfunktionen enthalten. Diese Validierungsfunktionen bilden die Basis fur die beiden anderen
Validierungsmoglichkeiten, die im folgenden weiter betrachtet werden.
Validierende Eingabefelder
Validierende Eingabefelder korrigieren Benutzereingaben oder zeigen Fehlermeldungen an,
wenn die Eingaben nicht einen bestimmten Muster entsprechen. Diese Eingabefelder benden sich im Package dojo.widget.validate. Beispiele hierfur sind Eingabefelder fur
IP Adressen und Postleitzahlen. Diese Eingabefelder benutzen die Validierungsfunktionen
aus dem Package dojo.validate.*. Werden diese Felder in einem Formular verwendet,
wird zur Zeit noch nicht automatisch das Absenden des Formulars verhindert, wenn diese
Eingabefelder Fehler enthalten. Dazu ist noch eigener JavaScript- Code notwendig. Mehr
dazu im dojo Wiki unter [97].
Validierung mit Prolen
Die nachste Moglichkeit bezieht sich auf HTML- Formulare mit Standardkomponenten.
Hier wird ein sogenanntes Prol genutzt, welches die Validierungsregeln fur die einzelnen
Komponenten des Formulars enthalt. Dieses Prol wird als JavaScript Objekt angegeben
und unterstutzt folgende Konzepte:
Filter verandern die Benutzereingaben und werden vor der Validierung angewandt. Sie
konnen z.B. zur Konvertierung in Klein- oder Groschreibung verwendet werden.
Notwendige Felder werden von optionalen Feldern getrennt. Bei Elementen, die eine
Mehrfachauswahl unterstutzen, wird angegeben wie viele Felder ausgewahlt sein
mussen.
Abhanigkeiten zwischen Feldern konnen angegeben werden. Wird ein Feld ausgefullt,
kann es erforderlich sein, dass ein weiteres Feld ausgefullt wird.
Bestatigungen sind eine besondere Art von Abhangigkeiten, wobei die beiden Felder den
gleichen Inhalt haben mussen.
 berprufungen. Hier werden fur die einzelnen Felder
Bedingungen sind die eigentlichen U
Funktionen angegeben, die einen Booleschen Wert zuruckliefern der angibt, ob die
U berprufung erfolgreich war. Dojo bietet mehrere Hilfsfunktionen hierfur bereits an,
es konnen aber auch eigene verwendet werden.
Mit der Funktion dojo.validate.check(<form>, <profile>) kann ein Prol auf ein
Formular angewandt werden. Dabei wird ein Objekt zuruckgeliefert, das Zugri auf die
57
Felder ermoglicht, die nicht erfolgreich validiert wurden. Auf den Webseiten von tapestry
unter [98] ist die Struktur des Prol- und Result Objektes gut erklart.
Einige Benutzereingaben konnen jedoch landes- oder sprachabhangig sein. Worauf bereits im Abschnitt 4.9.5 verwiesen wurde, sind lokalisierte Ressourcen nicht auf einen
bestimmten Werte- Typ beschrankt. Werden lokalisierte Validierungen notwendig, kann
die Funktion dojo.i18n.getLocalization(<package>, <filename>) auch genutzt
werden, um Prol- Objekte zur Validierung von Formularen zu beziehen.
4.10 Zusammenfassung
In diesem Abschnitt wurden verschiedene Moglichkeiten fur die Konzipierung einer clientzentrierten Webanwendung betrachtet und ausgewahlt. Dabei wurde aufgezeigt, dass
Programmierung nicht gleich Programmierung ist. Die deklarativen Ansatze bilden eine
Moglichkeit, die Implementierungs- spezischen Details sowie Eigenheiten einer Programmiersprache zu verbergen. In Bezug auf Webanwendungen ermoglichen sie die Trennung
zwischen Infrastruktur und Anwendung der Komponenten.
Allgemein ist eine konzentrierte Entwicklung von Widgets bei Webanwendungen, speziell AJAX- basierter, erkennbar. Auch der dojo Toolkit nutzt einen Widget- zentrierten
Ansatz fur die Entwicklung von Webanwendungen. Im Abschnitt 4.9 wurde speziell die
Verantwortlichkeit von Widgets naher untersucht. Dabei wurde gezeigt, dass die Anwendung allgemeiner Konzepte, wie z.B. die Master- Detail- Verkettung von WidgetElementen, bei clientzentrierten Webanwendungen problematisch ist.
Fur die Steuerung der Webanwendung wurde bereits in den Abschnitten 4.9.2 und 4.9.3
auf das Konzept eines zentralen Controllers hingewiesen. Dieses Konzept soll fur die
Umsetzung der Videothek genutzt werden. Es ermoglicht die Entkopplung der Steuerlogik von den einzelnen Widgets und einen zentralen Ansatz fur die History- und Bookmarkfahigkeit der Webanwendung.
Weiterhin wurde eine Abgrenzung der Arten von Widgets durchgefuhrt. Fur direkte Beziehungen zwischen Widgets wurden die sogenannten Composite Widgets naher speziziert. Eine mogliche Schachtelung von Widgets ist mit Container Widgets moglich.
Dabei entsteht lediglich eine indirekte und anonyme Beziehung zwischen den Widgets,
da das Eltern- Widget lediglich einen Bereich zur Verfugung stellt, in dem andere Widgets angezeigt werden konnen. Die besten Beispiele fur Container Widgets sind Layout
Widgets.
58
5 Aspekte der Modell- getriebenen
Softwareentwicklung
In den nachsten Abschnitten sollen einige wichtige Aspekte der Modell- getriebenen
Softwareentwicklung naher betrachtet werden. Eine Arbeitsgruppe um Prof. Dr. Georg
Beier[99] beschaftigt sich an der FH Zwickau[100] naher mit der MDSD und vergibt im
Rahmen dieser Diplomarbeiten. Daher erfolgt hier keine umfassende Beschreibung von
MDSD, sondern es wird sich auf die Aspekte beschrankt, die zum unbedingten Verstehen
notwendig sind. Der Leser soll am Beispiel der Videothek einen praktischen Einblick in die
Vorgehensweise mit der MDSD erlangen. Fur weiterfuhrende Informationen zur MDSD
sei hier auf die Diplomarbeit von Torsten Ronneberger[101] verwiesen.
5.1 Motivation
Bei der Softwareentwicklung wurden formale Designmodelle, wie z.B. ein UML Modell,
bisher nur zur besseren U bersicht der Softwarekomponenten eingesetzt. Aus einer Abbildung lassen sich Informationen wesentlich schneller erfassen, als durch den Quellcode
der Software. Daher dienen die Designmodelle meist nur als Dokumentation der Software. Die Konsistenz der Modelle zum Quellcode der Software muss manuell durch die
Entwickler sichergestellt werden, wodurch diese nicht immer gegeben ist.
Die Modell- getriebene Softwareentwicklung stellt die formalen Designmodelle in den Vordergrund. Durch Transformationen wird ein Modell in anderes Modell oder in Quellcode
umgesetzt. Dabei enthalt der Quellcode, wie bereits in Abschnitt 1.2 erwahnt, neben
Klassen- und Methoden- Deklarationen auch Implementierungsdetails. Dadurch ist das
Modell nicht mehr nur als Dokumentation zu betrachten, sondern wird zum Bestandteil
der Software. Die Konsistenz von Modell und Quellcode ist somit nach jeder vollstandigen
Transformation in Quellcode gegeben.
5.2 Modellierung
Um die formalen Modelle zu spezizieren wird haug UML eingesetzt. Dies ist jedoch
keine Voraussetzung. Es konnen auch textuell beschriebene Modelle verwendet werden.
59
Um aus Modellen implementierungsspezischen Code generieren zu konnen, muss die
Semantik eines Modells wohldeniert sein. Die Elemente, die in einem Modell genutzt
werden konnen, werden durch das verwendete Meta- Modell speziziert. Um den Elementen eine Semantik zu geben, muss das Meta- Modell dies unterstutzen. Wird dies
nicht unterstutzt, so muss das Meta- Modell erganzt oder ein Meta- Modell auf Basis
eines Meta- Meta- Modells selbst entwickelt werden. Im Rahmen dieser Diplomarbeit wird
sich auf die Modellierung mit der UML beschrankt.
5.2.1 Domain- spezische Modelle
Die UML bietet fur die Einfuhrung einer andwendungsfallspezischen Semantik den leichtgewichtigen Ansatz der UML Prole[102], der von den meisten UML Modellierungstools
unterstutzt wird. Dieser beinhaltet die Verwendung von Stereotypen[103] und Tagged
Values1 . Dabei dient der Tagged Value im Standard lediglich zur weiteren Spezizierung
des Stereotyps.
Zur Verdeutlichung ein kleines Beispiel. Soll eine Klasse persistent in einer Datenbank
gespeichert werden, so konnte diese mit einem Stereotyp <<persistent>> versehen werden. Da der Stereotyp <<persistent> Klassen zugewiesen werden soll, wird dieser von
dem Meta- Modell Element Klasse abgeleitet. Wird zur Persistenz z.B. das Hibernate
Framework eingesetzt, so konnte dieser persistenten Klasse der Tagged Value hibernate
zur naheren Spezizierung zugewiesen werden. Da dieser Tagged Value nur persistenten Klassen zugewiesen werden soll, kann dem Meta- Modell Element <<persistent>>
ein Tag framework zugewiesen werden. Dieser Tag wird im UML Tool mit dem Value
hibernate versehen. Dadurch ist der Tagged Value framework = hibernate entstanden.
Somit ist ein neues Meta- Modell Element <<persistent>> deniert, welches eine Semantik zum Ausdruck bringt. Dabei zeigt der Stereotyp die persistente Speicherung der
Klasse in einer Datenbank an. Der Tagged Value dient zur naheren Spezizierung, wie diese Speicherung geschehen soll. Die Verwendung solcher benutzerdenierter Meta- Modell
Elemente in einem Modell bewirkt die Spezizierung des Modells auf eine Anwendungsdomain. Das Modell wird damit Domain- spezisch und die Beschreibung mit Stereotypen
und Tagged Values als Domain- spezische Sprache2 bezeichnet.
1
2
Tagged Value bedeuted Eigenschaftswert.
Domain spezische Sprache ist die deutsche U bersetzung von Domain Specic Language, kurz DSL.
Siehe dazu auch Artikel bei der Wikipedia unter [104].
60
5.2.2 Anmerkung zur Verwendung von UML Prolen
Die breite Verwendung von Stereotypen kann in einem komplexen Meta- Modell resultieren. Um den Generierungsvorgang zu steuern, sind meist wenig Informationen notig,
die sich in einem Tagged Value hinterlegen lassen. Der dazu notwendige Stereotyp ware
somit nur Overhead. Zur einfacheren Anwendbarkeit wurde dem Basis Modell- Element
des verwendeten Meta- Modells der Tag mit Namen tags hinzugefugt. Dadurch besitzt
automatisch jedes Modell- Element diesen Tagged Value. Der Wert dieses Tagged Values
wurde zudem als Liste deniert. Dadurch konnen diesem Tagged Value mehrere Werte
zugewiesen werden. Wird in den folgenden Abschnitten auf Tag verwiesen, dann ist ein
Wert der Werteliste dieses speziellen Tagged Values gemeint.
5.3 Infrastruktur
5.3.1 Allgemeines zu openArchitectureWare
Fur die Modell- getriebene Umsetzung wird im praktischen Teil dieser Diplomarbeit das
MDSD/MDA Framework openArchitectureWare[105] eingesetzt. Es ermoglicht einen relativ einfachen Einstieg in das Thema. Dabei eignet sich openArchitectureWare sowohl
fur die Umsetzung der Aspekte der MDSD, als auch die der MDA3 .
Die MDA ist ein von der OMG4 verfolgter Standard zur generativen Entwicklung von
Softwaresystemen. Im Vordergrund der MDA steht dabei die Portabilitat und Interoperatbiliat von Softwaresystemen. Diese Aspekte sind bei der MDSD nicht die primaren
Ziele. Hier steht mehr die Umsetzung einer Domain in Quellcode fur eine Plattform im
Vordergrund. Fur eine ausfuhrlichere Unterscheidung und Abgrenzung zwischen MDA und
MDSD sei auf das Buch von Markus Volter und Thomas Stahl unter [108] verwiesen.
5.3.2 Der MDSD Entwicklungsprozess mit openArchitectureWare
Die MDSD Vorgehensweise zielt auf die Generierung von Quellcode ab. Allerdings sind
im Entwicklungsprozess der Modell- getriebenen Softwareentwicklung weitere wichtige
Aspekte zu beachten. Im folgenden ist der Prozess anhand einer einfachen Modell- zuCode Transformation mit openArchitectureWare grob skizziert.
Nach der Entwicklung der Domain- spezischen Sprache erfolgt die Modellierung des
Softwaresystems mit dieser. Bei der Modellierung konnen sich jedoch Fehler einschleichen.
3
4
MDA ist die Abkurzung fur Model Driven Archtitecture. Siehe dazu Artikel der Wikipedia unter [106].
Die Abkurzung OMG steht fur Object Management Group[107].
61
Daher ist es sinnvoll, das Modell zu validieren, bevor der Generator mit der Codegenerierung beginnt. OpenArchitectureWare beinhaltet hier die Validierungssprache check. Mit
einfachen Anweisungen konnen U berprufungen fur bestimmte Modell- Elemente angegeben werden. Dabei kann openArchitectureWare so konguriert werden, das bei Fehlern
der Vorgang abgebrochen wird und keine Code- Generierung erfolgt.
Ist die Validierung des Modells erfolgreich, beginnt der Code- Generator mit der Generierung der Infrastruktur. Hiefur mussen vom Entwickler Templates bereitgestellt werden,
die das Domain- spezische Modell in Quellcode umsetzen. In den Templates werden
Anweisungen angegeben, die das Modell analysieren, daraus Anweisungen der Ziel- Programmiersprache5 bilden und diese in eine Datei schreiben.
Der Code- Generierung folgt die manuelle Implementierung der Business Logik. Um den
Entwickler bei der Implementierung Hilfestellungen zu geben, beinhaltet openArchitectureWare das recipe Framework. Dieses arbeitet im Prinzip genauso wie die Validierungssprache check, jedoch auf Quellcode Ebene. Mit dem recipe Framework konnen so
Implementierungsdetails vorgeschrieben werden, z.B. dass zu einer bestimmten Klasse
eine abgleitete Klasse erstellt werden muss. Dieses Framework integriert sich auch gut
mit einer eigenen U bersicht in Eclipse.
Auf die einzelnen Aspekte des Entwicklungsprozesses wird im Kapitel 6 naher eingegangen. Diese werden dabei am Beispiel der Videothek verdeutlicht.
5
Programmiersprache ist hier im weiteren Sinne gemeint, da es mit openArchitectureWare moglich ist,
jede beliebige Art von textueller Ausgabe zu erzeugen.
62
6 Videothek als Beispiel einer
clientzentrierten Webanwendung im
Entwicklungsprozess mit MDSD
6.1 Konzipierung
Das in Kapitel 4 untersuchte Konzept einer clientzentrierten Single Page Application
soll hier am Beispiel einer Videothek umgesetzt werden. Dabei steht die Anwendbarkeit
der Modell- getriebenen Softwareentwicklung fur AJAX- basierte, clientzentrierte Webanwendungen im Vordergrund. Die Videothek soll kein fertiges, anwendbares Produkt
darstellen, sondern die Umsetzung wichtiger Konzepte verdeutlichen.
Hauptziel soll der Aufbau einer anwendbaren Infrastruktur fur AJAX- basierte, clientzentrierte Webanwendungen sein. Der clientseitige Teil der Infrastruktur soll mit relativ
geringem Aufwand mit anderen Serverplattformen zusammenarbeiten konnen.
 bersicht der verwendeten Tools
6.1.1 U
Im Folgenden sollen die fur die Videothek genutzten Tools und Frameworks aufgelistet
werden. Diese sind zur besseren U bersicht nach den Aspekt ihrer Verwendung gegliedert.
Der Vollstandigkeit halber seien hier auch alle bereits erwahnten Tools aufgelistet. Bis
auf das UML Tool Poseidon for UML sind alle eingesetzten Tools Open Source.
Modell- getriebene Softwareentwicklung
openArchitectureWare Basis fur die Modell- getriebene Softwareentwicklung ist das
Open Source Framework openArchitectureWare [105] (oAW). Fur dieses Framework liegt bereits eine Infrastruktur fur Version 3 vor, die als Basis genutzt wird.
Das Framework wird jedoch in der neueren Version 4 eingesetzt. Durch starke
A nderungen zwischen Version 3 und 4 musste vieles neu implementiert werden.
63
Poseidon for UML Zur Modellierung wird die Comunity Edition[109] von Poseidon for
UML[110] in Version 4.1 verwendet. Die mit Poseidon erstellten Modelle lassen sich
mit einen in openArchitectureWare integrierten Adapter nutzen.
Server Infrastruktur
Spring Framework Das Spring Framework [111] ist ein Mehrschichtiges Framework fur
Java EE Anwendungen. Es wird vorrangig zum Verknupfen der Serverkomponenten
eingesetzt.
Hibernate Das Hibernate Framework wird fur die Persistenzschicht eingesetzt. Es bildet Klassen in eine relationale Datenbank ab und besitzt eine Objetkt- orientierte
Abfragesprache[112].
HSQLDB Ist eine kompakte, einfach zu nutzende relationale Datenbank, in welcher
die persistenten Daten abgelegt werden. Diese wird von Hibernate standardmaig
unterstutzt.
Apache Tomcat Der Apache Tomcat [113] ist ein Web Container fur Java, der die Java
Servlet und Java Server Pages Spezikationen implementiert. Dieser wird in Version
5.5 eingesetzt. Er enthalt auerdem einen HTTP Server, welcher zur Entwicklung
ebenfalls eingesetzt wird.
AJAX Plattform
DWR wird als Kommunikationsframework zwischen Client und Server genutzt.
Dojo Toolkit Wird als allgemeiner Toolkit fur die Implementierung der Clientanwendung
verwendet.
Entwicklungsumgebung
Als Entwicklungsplattform fur die Videothek wird Eclipse [114] in Version 3.1 eingesetzt.
Eclipse ist durch den modularen Aufbau sehr gut mit Plugins erweiterbar. Die wichtigsten
sind im folgenden aufgezahlt:
JDT Die Java Development Tools [115] sind i.d.R. bereits in Eclipse enthalten und unterstutzen den Entwickler u.a. mit speziellen Editoren bei der Programmierung in
Java.
64
Ant Das Build- Werkzeug ANT [116] ist ebenfalls standardmaig in Eclipse enthalten.
Es wird fur die Generierung des Datenbank Schemas aus den Hibernate Mapping
Dateien, zum Starten und Stoppen der Datenbank HSQLDB sowie zum Packaging,
Deploying und Undeploying der Webanwendung verwendet.
openArchitectureWare Das Framework openArchitectureWare bietet eine gute Integration in Eclipse. Neben den Start des Generierungsvorgangs bieten die Plugins auch
spezielle Editoren zum Festlegen der Transformationsregeln.
aptana Aptana[117] ist eine IDE fur die Entwicklung dynamischer Webanwendungen. Sie
enthalt Editoren fur XML, HTML, CSS und JavaScript. Dabei bietet Aptana u.a.
fur HTML, CSS und JavaScript auch einen Code Assistenten an. Bei JavaScript
funktioniert dieser auch mit selbst geschriebenen JavaScript Objekten und Funktionen. Dadurch bieten diese Editoren mehr Funktionalitat als die des Eclipse Web
Tools Platform Project s[118]. Aptana hat noch den Beta Status und wurde in der
Version 0.2.4 eingesetzt.
6.2 Server Infrastruktur
Bei der Modell- getriebenen Softwareentwicklung wird das fachliche Modell der Anwendung in den Mittelpunkt gestellt und dient als Basis fur den Quellcode. Das fachliche
Modell dient weiterhin als Ausgangspunkt fur das Persistenz- und Prasentationsmodell.
Um Redundanz bei der Modellierung zu vermeiden, werden diese beiden Modelle aus dem
fachlichen Modell generiert.
6.2.1 Applikationsschicht
Das fachliche Modell der Videothek sei auf einige Klassen mit den wichtigsten Eigenschaften beschrankt. Diese sind im Klassendiagramm in Abbildung 6.1 dargestellt.
Die Klasse Media stellt dabei das zentrale Element der Videothek dar und bestimmt den
Medientyp des Produkts. Die Klasse Product beschreibt das Produkt lediglich, wodurch
die redundante Speicherung der Beschreibung bei Produkten entfallt, die auf mehreren Medien verfugbar sind. Zur Strukturierung der Produkte werden diese mit Hilfe der
Klasse Category in Kategorien eingeteilt. Jedes ausgeliehene Produkt bendet sich als
ShoppingCartItem im Warenkorb, der durch die Klasse ShoppingCart reprasentiert
wird. Jeder Warenkorb gehort einem Kunden.
65
Abbildung 6.1: Die Business Klassen der Videothek
6.2.2 Service- Schicht
Die Service- Schicht dient als Schnittstelle fur das fachliche Modell. Die Klassen dieser
Schicht wurden nach dem Session Facade Pattern entworfen. Dieses Pattern dient u.a.
als Vereinfachung des Business Modells und Abgrenzung von den anderen Schichten.
Mehr Informationen daruber benden sich unter [119].
In Abbildung 6.2 sind einige Klassen der Service- Schicht dargestellt.
Der Zugri auf die Persistenzschicht erfolgt mit sogenannten Data Access Objects. Auf
diese wird im Abschnitt 6.2.3 genauer eingegangen. Weiterhin werden den Controllern
keine Business Objekte bereitgestellt, sondern lediglich Daten Objekte nach dem Data
Transfer Object Pattern[86]. Dadurch gelingt eine gute Trennung des fachlichen Modells
von den beiden anderen Schichten.
Abgrenzung zur Controller Schicht
Der Datenaustausch mit der Controller Schicht wird mit dem Data Transfer Object
Pattern realisiert. Dieses beschreibt den Austausch der Business Daten nicht mit den
Business Objekt selbst, sondern mit einem Objekt, welches lediglich die Daten beinhaltet. Die Klassen der DataTransferObjects werden dabei als statische innere Klassen
umgesetzt. Durch diese Kapselung wird die Zugehorigkeit der DataTransferObjects
erkennbar und die Klassenanzahl bleibt uberschaubar.
66
Abbildung 6.2: Einige Service Klassen der Videothek
Die statischen inneren Klassen werden dabei automatisch aus dem Business Modell erzeugt. Jede Klasse, die DataTransferObjects bereitstellen muss, wird im Modell mit
dem Tag ui.this versehen. Dadurch generieren die Templates die inneren Klassen. Besitzt das Business Objekt Assoziationen, so konnen die Assoziationsenden mit dem Tag
ui.show versehen werden. So wird die Referenz auch in das DataTransferObject aufgenommen. Hier werden jedoch nur die Identikatoren der referenzierten Business Objekte
aufgenommen, und nicht die DataTransferObjects. Bei letzteren kann es bei bidirektionalen Assoziationen zu Problemen bei dem zur U bertragung verwendeten Datenformat
kommen.
6.2.3 Persistenzschicht
Die fachlichen Klassen, welche die Daten wiederspiegeln werden auch Java Beans oder
Entity Beans genannt. Die Daten dieser Objekte werden in Datenbanken gespeichert.
Hierzu werden die Klassen mit dem Tag persist.hibernate versehen, welches den
Templates zur Codegenerierung angibt, dass dies persistente Klassen sind.
67
Modellmodikationen
Um diese Klassen mit Hibernate in eine Datenbank abzubilden, sind meist Erganzungen notwendig. Es muss ein Attribut existieren, welches den Identikator des Objektes
der Datenbank enthalt (Primarschlussel). Durch dieses kann eindeutig auf ein Objekt
zugegrien werden. Weiterhin kann die Versionierung eines Objekts sich als nutzlich erweisen. Diese ist notwendig, um konkurrierende Veranderungen beim optimistic locking
in Multi User Umgebungen bei langen Transaktionen erkennen zu konnen. Siehe dazu die
Hibernate Dokumentation unter [120].
Diese beiden Attribute werden den Klassen durch Modellmodikationen hinzugefugt. Um
auf diese Attribute in anderen Templates eindeutig zugreifen zu konnen, werden diese
mit den Tags persist.id und persist.version versehen. Die Werte der Attribute
werden von Hibernate gesetzt. Fur die Identikation des Objekts wird ein synthetischer
Datenbankschlussel generiert. Nach der Modellmodikation werden fur die Klassen mit
dem Tag persist.hibernate auch die Hibernate Mapping Dateien generiert.
Abgrenzung zur Service Schicht
Der Zugri auf Objekte in der Datenbank erfolgt nach dem Data Access Object Pattern[4],
welches in Abbildung 6.3 dargestellt ist.
Abbildung 6.3: Das Data Access Object Pattern aus [4]
Auf das TransferObject aus wird aus Grunden der U bersichtlichkeit bei der Videothek
verzichtet. Das DataAccessObject wird dabei als Interface modelliert, welches fur die
jeweilig verwendete Persistenztechnologie implementiert wird. Weiterhin besteht mit Java
5 die Moglichkeit, Klassen mit Templates zu parametrisieren. So kann eine generische
Klasse DataAccess genutzt werden, wobei die persistente Klasse als Template Parameter
ubergeben wird. Da die Template Parameter bei Java 5 nur zur Compilezeit auswertbar
68
sind, mussen die generischen DataAccessObjects ein Attribut mit dem Klassentyp des
Template Parameters besitzen. Die fur die Videothek verwendete Realisierung des Data
Access Object Patterns ist in Abbildung 6.4 dargestellt.
Abbildung 6.4: Die Umsetzung des Data Access Object Patterns fur die Videothek
6.2.4 Controller- und Kommunikationsschicht
In dem Videotheksbeispiel wird fur die Kommunikation DWR eingesetzt. Dieses ubernimmt den kompletten Kommunikationsmechanismus und stellt auch den serverseitigen
Controller bereit. Der DWR Controller ist ein Servlet, welches die Anfragen der von DWR
generierten JavaScript Proxy Objekte entgegen nimmt und in einen lokalen Methodenaufruf eines Service Objekts umsetzt. Der Ruckgabewert dieser Methode wird zuruck an
den Client gesendet. Im Listing 6.1 ist die Konguration des DWR Servlets aus der Datei
web.xml verdeutlicht. Dabei wird der Parameter debug auf den Wert true gesetzt. Dies
ist fur die Entwicklung und den Test der Webanwendung nutzlich, da hier DWR eine
Testseite fur jedes veroentlichte Objekt bereitstellt.
1
2
3
4
5
6
7
8
<! dwr s e r v l e t s e r v e r s i d e p r o x y f o r r p c
<s e r v l e t>
<servlet name>
</ servlet name>
<s e r v l e t c l a s s>
<init param>
<param name>
</param name>
<param value>
</ param value>
</ init param>
dwr
>
invoker
uk . l t d . g e t a h e a d . dwr . DWRServlet
debug
true
69
</ s e r v l e t
c l a s s>
9
10
11
12
13
14
15
</ s e r v l e t >
< ! map f o l l o w i n g
<s e r v l e t m a p p i n g>
<servlet name>
<u r l p a t t e r n>
</ s e r v l e t m a p p i n g>
url ' s
dwr
/dwr/
to
dwr
invoker
servlet
</ servlet
*</ u r l p a t t e r n >
>
name>
Listing 6.1: Konguration des DWR Controller Servlets
DWR wird im Videotheksbeispiel so konguriert, dass es auf Spring Beans zuruckgreift.
Diese Spring Beans sind allerdings nicht direkt die Objekte der Service Schicht, sondern
sogenannte Proxies, welche zusatzlich noch die Transaktionssteuerung beinhalten. Im
Listing 4.3 auf Seite 37 wurde gezeigt, wie DWR auf Spring Beans zuruckgreifen kann.
Das Transaktionsmanagement ist mit einem abstrakten Proxy Bean deniert. Dies bietet
die Moglichkeit, die Transaktionssteuerung zentral an einem Objekt zu denieren und die
Proxy Objekte fur die jeweiligen Service Objekte davon abzuleiten. Listing 6.2 zeigt dabei
das abstrakte Bean, welches die Transaktionssteuerung beinhaltet. Im Listing 6.3 ist die
Denition des Transaktions- Proxies fur die UserServiceFacade verdeutlicht. Dabei ist
die UserServiceFacade als inneres Objekt deniert, um eine anderweitige Nutzung ohne
Transaktionsmanagement in der Spring Konguration zu unterbinden.
1
2
<! a b s t r a c t t r a n s a c t i o n p r o x y
<bean =" txProxyTemplate "
id
=" t r u e "
=" org . s p r i n g f r a m e w o r k . t r a n s a c t i o n . i n t e r c e p t o r .
T r a n s a c t i o n P r o x y F a c t o r y B e a n ">
3
abstract
4
class
5
6
7
8
9
10
11
12
13
14
15
16
17
18
>
<p r o p e r t y
<r e f
</ p r o p e r t y >
<p r o p e r t y
<p r o p s>
<prop
<prop
<prop
<prop
</ p r o p s>
</ p r o p e r t y >
</ bean>
=" t r a n s a c t i o n M a n a g e r ">
=" t r a n s a c t i o n M a n a g e r " />
name
local
=" t r a n s a c t i o n A t t r i b u t e s ">
name
=" s a v e * ">PROPAGATION REQUIRED</ prop>
="add * ">PROPAGATION REQUIRED</ prop>
k e y="remove * ">PROPAGATION REQUIRED</ prop >
k e y=" * ">PROPAGATION REQUIRED, r e a d O n l y </ prop >
key
key
Listing 6.2: Konguration eines abstrakten Proxy Objekts fur das Transaktionsmanagement als Spring Bean
1
2
<!
user
service
facade
txProxyTemplate
>
proxy
is
70
inherited
from
abstract
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<bean
= "userServiceFacade"
= " txProxyTemplate "
c l a s s = " org . s p r i n g f r a m e w o r k . t r a n s a c t i o n . i n t e r c e p t o r .
T r a n s a c t i o n P r o x y F a c t o r y B e a n ">
id
parent
<p r o p e r t y
<!
name
= " t a r g e t ">
userServiceFacade
use
without
as
inner
transaction
bean
to
mangement
prevent
>
it
from
<bean
=" v i d e o l i b . s e r v e r . U s e r S e r v i c e F a c a d e ">
<p r o p e r t y
= " categoryDao ">
<r e f
= " categoryDao " >
</ p r o p e r t y >
<p r o p e r t y
= "mediaDao">
<r e f
= "mediaDao" >
</ p r o p e r t y >
<p r o p e r t y
= " productDao ">
<r e f
= " productDao " >
</ p r o p e r t y >
</ bean>
</ p r o p e r t y >
</ bean>
class
name
local
/
name
local
/
name
local
/
Listing 6.3: Konguration eines Service Objekts als Spring Bean, welches das Transaktionsmanagement von einem anderen Spring Bean erbt
6.3 Client Infrastruktur
Die Client Infrastruktur besteht im wesentlichen aus 3 Aspekten:
ˆ Benutzerdenierte Widgets fur die Darstellung der Business Daten.
ˆ Ein zentraler Controller, der die Widgets steuert und die Zustande der Webanwendung verwaltet.
ˆ Eine Webseite, die das Layout der Webanwendung beschreibt. In dieser werden die
benutzerdenierten Widgets verwendet, um die Business Daten darzustellen.
Die benutzerdenierten Widgets sowie die Webseite sind Teil der Prasentationsschicht
des Clients. Der zentrale Controller gehort zur Controllerschicht. Diese beiden Schichten
werden im folgenden naher untersucht.
71
6.3.1 Controller- und Kommunikationsschicht
DWR stellt die veroentlichten Service Objekte auf Clientseite als JavaScript Objekte bereit, welche vom DWR Controller Servlet generiert werden. Im Listing 6.4 ist dargestellt,
wie diese Objekte in eine Webseite eingebunden werden.
1
2
3
4
5
6
7
8
<!
include
<script
DWR
>
= "text/ javascript "
= "/ v i d e o . l i b r a r y /dwr/ e n g i n e . j s ">
type
src
</ s c r i p t >
<!
include
<script
the
UserServiceFacade
Proxy
Object
>
= "text/ javascript "
= "/ v i d e o . l i b r a r y /dwr/ i n t e r f a c e / U s e r S e r v i c e F a c a d e . j s ">
type
src
</ s c r i p t >
Listing 6.4: Einbindung von DWR und der JavaScript Proxy Objekte in eine Webseite
Um die Architektur des Clients nicht unnotig mit dem Kommunikationsmechanismus von
DWR zu koppeln, wird das Business Delegate Pattern[121] eingesetzt, welches in Abbildung 6.5 dargestellt ist. Somit wird der Zugri auf die DWR- spezischen Objekte an
ein separates Objekt delegiert. Dadurch wird der Austausch des Kommunikationsmechanismus vereinfacht und die restliche Infrastruktur ist frei von kommunikationsspezischen
Code.
Abbildung 6.5: Verwendung des Business Delegate Patterns bei der Client Architektur
der Videothek
Business Delegate mit MDSD
Das JavaScript Proxy Objekt enthalt alle Methoden des Service Objekts auf Serverseite, die nicht durch Sicherheitseinschrankungen ausgeschlossen wurden. Die modellierten
Methoden des Service Objekts gehoren i.d.R. zu den veroentlichten, da diese explizit als
72
Schnittstelle entworfen wurden. Dadurch ist die Umsetzung mit MDSD relativ einfach,
allerdings bieten sich zwei Wege an:
ˆ Generierung des Business Delegate direkt aus dem Service Objekt. Die Generierung wird dabei uber einen Tagged Value des Service Objekts gesteuert.
ˆ Separate Modellierung des Business Delegate als eigenstandige Klasse.
Bei der ersten Variante wird lediglich ein Tagged Value an der Klasse des Service Objekts
benotigt. Einzig die Vermischung von clientseitigen Aspekten in ein serverseitiges Modell
kann als Nachteil gesehen werden. Die zweiten Variante trennt diese Aspekte besser, da
die Klasse des Business Delegate in einem separaten Modell fur die Client Architektur
hinterlegt werden kann. Da bei dieser Variante keine redundante Modellierung notwendig
ist, wird diese bei der Videothek eingesetzt.
In Abbildung 6.6 ist die Klasse des Business Delegate dargestellt. Das Attribut referenziert dabei die Klasse des Service Objekts, die in Abbildung 6.2 dargestellt wurde. Der
Stereotyp <<delegate>> des Attributs gibt dabei an, das die Methoden dieser Klasse in
die Klasse des Business Delegate ubernommen werden sollen. Auch wird dem Attribut
ein Startwert zugewiesen, welcher als Wert den Namen des JavaScript Proxy Objekts
von DWR hat. Durch den Tag delegate.dwr wird die Delegierung an ein DWR Objekt
festgelegt. Dadurch ist es moglich, neben den Funktionsdenitionen auch die Implementierung der Funktionen des Business Delegate Objekts zu generieren. Listing 6.5 zeigt
die Funktion getProduct, welche den Aufruf an die Funktion getProduct des DWR
Proxy Objektes delegiert.
1
, callbackFunc ) f
this . userServiceFacade . getProduct ( id , f
callback
: function ( returnValue ) f
callbackFunc . c a l l ( callbackObj ,
returnValue ) ;
getProduct
2
3
4
5
6
7
g,
g) ;
: function ( id ,
callbackObj
g
Listing 6.5: Generativ erzeugte Funktion eines Business Delegate Objekts
Weiteres Potential des Business Delegate
Das Business Delegate Objekt bietet weiterhin eine gute Basis fur zwei weitere nutzliche Funktionen AJAX- basierter Webanwendungen, welche hier erwahnt werden sollen,
jedoch nicht in der Videothek implementiert werden.
Dies ist zum einen die zentrale Moglichkeit fur clientseitiges Caching der Serveranfragen.
Die bereits vom Server bezogenen Objekte konnen in Listen oder Tabellen zwischengespeichert werden. Erst wenn die Suche in diesen erfolglos war, wird eine Serveranfrage
durchgefuhrt.
73
Abbildung 6.6: Modellierung eines Business Delegate der Videothek als eigenstandige
Klasse
Weiterhin kann mit wenigen A nderungen ein Mechanismus integriert werden, der die Daten der Webanwendung mit denen des Server synchron halt. Zwei dieser Mechanismen
wurden bereits in Abschnitt 2.3.2 erwahnt. Hierfur ist ein sogenanntes Attaching und
Detaching erforderlich, mit dem sich JavaScript Objekte bei dem Business Delegate
mit Serveranfragen verknupfen konnen. Das Business Delegate speichert fur jede Serveranfrage das Callback- Objekt sowie dessen Callback- Methode. Wird die Veranderung
eines Objekts auf dem Server festgestellt, so konnen die registrierten Callback- Methoden
der Callback- Objekte aufgerufen werden. Fur das Attaching konnen die bisherigen Methoden genutzt werden, jedoch ist die Speicherung der Callback- Objekte und Methoden
noch erforderlich. Zustatzlich mussen noch weitere Methoden fur das Detaching bereitgestellt werden, sowie die Implementierung des Mechanismus fur synchrone Daten. Eine
Moglichkeit mit DWR konnte das Reverse AJAX [122] Feature des sich in Entwicklung
bendenden DWR 2.0 sein. Zur Unterscheidung von Objekten bietet sich die Auswertung der von Hibernate durchgefuhrten Versionierung von Objekten an (siehe Abschnitt
6.2.3).
Applikations- Controller
Wie in Kapitel 4 speziziert, wird die Steuerung der Webanwendung in ein zentrales
Controller Objekt verlagert. Der Funktionsumfang ist dabei durch die folgenden Verantwortlichkeiten deniert:
ˆ Erzeugen der History- Eintrage fur den Webbrowser sowie Verandern der URL dem
Zustand der Webanwendung entsprechend.
ˆ Abbildung der URL beim Start der Webanwendung auf einen konkreten Zustand
der Webanwendung (Bookmarkfahigkeit).
74
ˆ Steuerung der Darstellung des Inhaltes der Webanwendung entsprechend dem aktuellen Zustand.
ˆ Auswertung der Benutzerevents, die fur den Zustand einer Webanwendung relevant
sind.
ˆ Abruf der Daten vom Webserver, die fur den Zustand der Webanwendung erforderlich sind und Bindung dieser an Widgets.
Die Benutzerevents verursachen eine A nderung der Zustandsbeschreibung der Webanwendung und diese wiederum eine A nderung der URL. Diese veranderte URL wird mit
dem in Abschnitt 4.7 naher betrachteten State Objekte beim dojo History System gesetzt. Als nachstes folgt die Abbildung der Zustandsbeschreibung der Webanwendung
auf die Widgets. Hierfur werden die benotigten Daten uber das Business Delegate vom
Webserver bezogen und an das Widget gebunden. Danach wird der Zustand auf die
Sichtbarkeit der einzelnen Widgets abgebildet.
Anmerkungen zum MDSD Ansatz des Controllers
Bei Webanwendungen ist oft von Zustanden die Rede, wenn konkrete Inhalte referenziert
werden. Daher liegt es nahe, den Controller mit einem State Chart zu modellieren. Im
folgenden werden einige Aspekte genannt, die dabei zu beachten sind.
Jeder Zustand der Webanwendung muss mit einer URL eindeutig beschreibbar sein. Jedes aktuell sichtbare Widget muss uber diese URL identizierbar sein. Ebenfalls mussen
benotigten Daten fur diese Widgets enthalten sein. Diese werden meist mit Identikatoren in der URL hinterlegt, durch welche diese vom Webserver bezogen werden konnen.
Eine Moglichkeit ist hier, die Widgets in der URL mit Namen zu benennen und ihnen
Werte zuzuweisen. Soll das Produkt Widget das Produkt mit der ID 42 anzeigen, so
konnte die URL beispielsweise den Teil product=42 enthalten.
Die Benutzerevents, die der Controller auswertet, verandern i.d.R. den Zustand der Webanwendung. Diese Events beschranken sich aber nicht auf ein Widget, sondern konnen
mehrere Widgets gleichzeitig verandern. Somit verliert sich die Moglichkeit, einzelne Widgets als Zustandsidentikator zu nutzen. Eine Alternative konnte die Kombination der
Widgets darstellen, da bestimmte Widget- Kombinationen den Zustand eindeutig festlegen. Benutzerevents treten jedoch haug in mehreren Zustanden der Webanwendung
auf. Bestes Beispiel ist hierfur eine statische Navigationsleiste. Werden diese WidgetKombinationen mit einfachen Zustanden im State Chart beschrieben, ergibt sich hier
eine sehr redundante Modellierung der Transitionen.
Weitere Aspekte mussen bei der Umsetzung des State Charts beachtet werden. Diese
mussen nicht modelliert werden, sondern konnen dem Modell durch Modikation hinzugefugt werden. Einerseits muss bedacht werden, dass jeder bookmarkfahige Zustand
75
eine direkte Transition vom Entry Point des Zustandsautomaten benotigt. Die Bookmarkfahigkeit von Zustanden konnte mit Tagged Values im Modell hinterlegt werden.
Aber auch die inverse Betrachtung ist moglich, dass die nicht bookmarkfahigen Zustande
mit Tagged Values versehen werden.
Weiterhin sind die Transitionen zwischen Zustanden im State Chart immer gerichtet. In
Bezug auf die Historyfahigkeit ist zu beachten, das beim Drucken auf den Back- Button
des Webbrowsers in den letzten Zustand der Webanwendung gewechselt werden soll.
Hierzu ist es notwendig, das zu jeder Transition zwischen Zustanden, die keine Entryund Exit Points darstellen, eine inverse Transition existieren muss. Diese kann ebenfalls
durch Modikation des Modells hinzugefugt werden.
Durch diese Aspekte war es im Umfang dieser Diplomarbeit nicht moglich, eine einfache,
handhabbare und skalierbare Modellierungsvorschrift herauszuarbeiten. Fur weiterfuhrende Informationen uber die Modellierung von Navigationen sei hier auf die Webseite von
Peter Dolog unter [123] verwiesen, wo sich einige Publikationen von Forschungsberichten
dazu nden.
6.3.2 Prasentationsschicht
Die Grundlage der Prasentationsschicht ist die Webseite, welche die eigentliche Webanwendung wiederspiegelt. Diese deniert den strukturellen Aufbau der Webanwendung mit
Hilfe von Widgets und referenziert die benotigten JavaScript und CSS Dateien. Der Inhalt
besteht zum Groteil aus dojo- spezischen XHTML Markup. Fur eine Modell- getriebene
Entwicklung dieser Datei ist die MDSD nicht geeignet. Sinnvolle Unterstutzung konnten
hier GUI Builder oder serverseitige, Template- basierte View- Technologien bieten, wie
z.B. eine JSP- Taglib, welche eine abstraktere API fur dojo Widgets besitzt.
Der zweite wesentliche Teil der Prasentationsschicht sind die benutzerdenierten Widgets, welche haug die Daten der Business Objekte darstellen. Im folgenden soll naher
untersucht werden, welche Teile der Infrastruktur fur dojo Widgets sich generativ erzeugen lassen. Dabei wird sich auf die Generierung der JavaScript Widget Objekte konzentriert. Die HTML- und CSS- Templates lassen sich prinzipiell auch generativ erzeugen,
sind jedoch nur zu Testzwecken oder als Grundlage fur die Arbeit der Webdesigner verwendbar.
MDSD Ansatz fur Widgets
Wie bereits in Abschnitt 4.9.2 beschrieben, bilden festgelegte Datenstrukturen das Modell
des Widgets, welches an dieses gebunden und dargestellt wird. Das Modell besteht dabei
aus den DataTransferObjects der Service Schicht, die von DWR in JSON Objekte
76
konvertiert werden. Daraus ergeben sich als Basis fur die Umsetzung der Widgets mit
MDSD verschiedene Moglichkeiten:
ˆ Die Widgets werden basierend auf den DTOs der Service Schicht generiert.
ˆ Eigenstandige Modellierung der Widgets als Klassen.
Die Generierung der Widgets basierend auf den DTOs ist der einfachste Weg. Dadurch
sind die Widgets aber sehr stark am Modell der DTOs orientiert. Die Moglichkeit, Daten
anderer DTOs zu nutzen ist nur umstandlich moglich, da solche Aspekte im Modell der
DTOs hinterlegt werden mussen. Da die DTOs aus dem Business Modell generiert werden, mussten die Informationen fur die Steuerung der Generierung der Widgets im Modell
der Business Schicht hinterlegt sein. Die Folge ware eine Vermischung von client- und
serverseitigen Aspekten im Modell der Business Schicht und die geringe Transparenz der
Modellierung der Widgets. Auch stellen die DTOs der Service Schicht die standardisierte
Schnittstelle der Applikation dar, die nicht mit speziellen Client- Anforderungen vermischt
werden sollte.
Die Modellierung der Widgets als eigenstandige Klassen ist exibler und transparenter.
Dies ermoglicht die Trennung von Client- und Server- Aspekten auf Modellebene.
Die Konzepte des dojo Widget Systems mit MDSD
Nach Festlegung der Art, wie die Widgets modelliert werden, erfolgt nun die Abbildung der
Konzepte des dojo Widget Systems auf das Modell. Dabei wird fur einige unter Abschnitt
4.8 und 4.9 genannten Aspekte eine Modellierungsvorschrift herausgearbeitet.
Soll das Widget statische Inhalte darstellen, werden diese als Attribute der Klasse modelliert und mit dem Stereotyp <<description>> versehen. Dadurch werden sie auf das
Konzept der Platzhalter von dojo abgebildet. Diese Platzhalter werden in der Funktion
postMixInProperties mit den Attributwerten ersetzt. Die Attributwerte k
onnen dabei
im Modell als Startwert des Attributes, deklarativ bei Verwendung des Widgets oder als
Parameter bei programmatischer Erstellung des Widgets gesetzt werden. Abbildung 6.7
zeigt ein Widget, welches einen Platzhalter namens title besitzt. Die generativ erzeugte
Funktion postMixInProperties des Widgets ist in Listing 6.6 dargestellt.
1
postMixInProperties
this .
2
3
5
6
7
*
/*
/
g,
g
= f
: this .
strings
t i t l e
4
: function ( )
t i t l e
,
PROTECTED REGION
ID
f
( Im7 . . . )
PROTECTED REGION END
*/
ENABLED START
*/
Listing 6.6: Generativ erzeugte Funktion postMixInProperties des Widgets aus Abbildung
6.7
77
Abbildung 6.7: Modellierung eines dojo Widgets als Klasse
Die dynamischen Daten, die vom Widget darstellt werden sollen, werden aus den DTOs
bezogen. Dabei wird jedes genutzte DTO ebenfalls als Attribut modelliert, aber mit den
Stereotyp <<dto>> versehen. Fur jedes DTO xyz werden die beiden Zugrismethoden
getXyz und setXyz generiert. Weiterhin wird eine Funktion updateXyz zur Aktualisierung der Darstellung bei A nderung eines DTOs generiert. Alle DTOs bilden dabei einen
Kontext, aus dem das Widget Daten beziehen und darstellen kann.
Um Daten aus diesem Kontext darzustellen, werden weitere Attribute modelliert, welche
mit dem Stereotyp <<field>> versehen sind. Diese werden auf das Konzept der dojo
Attach Points abgebildet. Der Attributname bezeichnet dabei den dojo Attach Point. Die
Daten, die dieser darstellen soll, werden im Modell mit dem Startwert des Attributes hinterlegt. Dabei wird ein Attribut eines mit dem Stereotyp <<dto>> versehenen Attributes
dieser Klasse referenziert. Abbildung 6.7 soll die Modellierung eines dojo Widgets verdeutlichen. In dieser ist zu erkennen, dass der Startwert category.name des Attributes
name auf das Attribut name des DTOs category verweist.
In der Funktion fillInTemplate werden die Daten der DTOs den dojo Attach Points
zugewiesen, indem die updateXyz Funktionen aufgerufen werden. Listing 6.7 zeigt die
generativ erzeugte Funktion fillInTemplate.
1
fillInTemplate
2
//
3
i f
5
7
8
g
*
/*
/
if
: function ( )
dto
is
( this . category )
//
4
6
check
update
f
set
f
fields
based
on
t h i s . updateCategoryDto ( ) ;
PROTECTED REGION
ID
( Im7 . . . )
PROTECTED REGION END
*/
78
that
dto
ENABLED START
*/
9
g,
Listing 6.7: Generativ erzeugte Funktion llInTemplate des Widgets aus Abbildung 6.7
Durch die implizite Voraussetzung der dojo Attach Points und die explizite Modellierung,
welcher Attributwert die notwendigen Daten enthalt, kann auch die Implementierung der
Funktion updateXyz generativ erzeugt werden. Diese zeigt Listing 6.8.
1
updateCategoryDto
2
//
clear
3
dojo
4
//
5
i f
//
i f
g
11
12
13
*
/*
/
10
g,
g
if
dto
is
f i l l
all
fields
check
( this . category )
7
8
based
on
that
dto
. dom . t e x t C o n t e n t ( t h i s . name , "" ) ;
6
9
f
: function ( )
fields
set
f
based
on
that
dto
( t h i s . name ) f
d o j o . dom . t e x t C o n t e n t ( t h i s . name ,
t h i s . c a t e g o r y . name ) ;
PROTECTED REGION
ID
( Im7 . . . )
PROTECTED REGION END
*/
ENABLED START
*/
Listing 6.8: Generativ erzeugte Funktion zur Aktualisierung der Darstellung des DTOs
aus Abbildung 6.7
Werden Attribute ohne Stereotyp modelliert, so werden diese als ganz normale Attribute
des Widget Objekts umgesetzt.
Beziehungen zwischen Widgets
Wie bereits in Abschnitt 4.9.3 beschrieben, wird hier keine Master- Detail- Verkettung
von Widgets betrachtet. Dadurch ist die Realisierung von Beziehungen zwischen Widgets
auf zwei Arten beschrankt:
Container Widgets bestehen aus mehreren Widgets, wobei die gekapselten Widgets
nicht zustandsabhanig sind oder vom zentralen Controller gesteuert werden.
Composite Widgets bestehen ebenso aus mehreren Widgets, wobei der Zustand der
gekapselten Widgets lediglich vom Eltern- Widget abhangt. Die Kind- Widgets
werden nicht vom zentralen Controller gesteuert, sondern beziehen ihre Daten vom
Eltern- Widget.
Fur Container Widgets muss lediglich das Attribut isContainer modelliert und mit dem
Startwert true versehen werden, damit der dojo Parser diese als Container Widgets
erkennt. In dem HTML Template muss wie in Abschnitt 4.8.3 beschrieben der dojo
79
Attach Point containerNode einem Element zugewiesen werden. Der dojo Parser fugt
dann die deklarativ angegebenen Kind- Widgets automatisch dem dojo Attach Point
hinzu. Dadurch wird eine unnotige Kopplung zwischen den Widgets vermieden und sie
bleiben getrennt einsetzbar.
Bei Composite Widgets kann mit Hilfe der MDSD wieder eine Infrastruktur generiert werden. Die Beziehung zu den gekapselten Widgets werden mit Hilfe von Assoziationen modelliert, wobei die navigierbaren Assoziationsenden mit dem Stereotyp <<childwidget>>
versehen sind. Die Rollennamen werden zu Attributen des Eltern- Widgets, die die Widget
Objekte der gekapselten Widgets speichern. Abhangig von der Multiplizitat der Beziehung
wird hierfur ein Objekt oder ein Array verwendet. Die gekapselten Widgets werden dem
dojo Attach Point hinzugefugt, der mit dem Tagged Value dojoAttachPoint am Assoziationsende angegeben wurde. Die DTOs der Kind- Widgets mussen vom Eltern- Widget
gesetzt werden. Dies erfolgt mit dem Tagged Value binding am Assoziationsende, welcher als Wert den Namen des DTOs des Eltern- Widgets hat.
Abbildung 6.8 soll die Modellierung von Composite Widgets verdeutlichen. Nicht dargestellt werden dabei der Stereotyp <<childwidget>> sowie die beiden Tagged Values
dojoAttachPoint = dapProduct und binding = products am Assoziationsende mit
dem Rollennamen productList.
Abbildung 6.8: Modellierung eines Composite Widgets
Eine kleine A nderung ergibt sich bei der Umsetzung der updateProducts Funktion fur das
DTO products des Widgets ProductListViewWidget. Hier muss die jeweilige Anzahl an
Objekten des Widgets ProductItemViewWidget programmatisch erstellt werden. Listing
6.9 zeigt die Umsetzung bei gekapselten Widgets.
1
updateProductsDto
2
//
3
i f
4
5
clear
child
: function ( )
widgets
( this . productList )
for
( var i = 0 ; i
//
delete
f
<
f
based
widget
this .
on
that
dto
productList
object
80
. length ;
i ++
)
f
6
this .
7
g
8
//
9
dojo
10
g
11
//
12
i f
f i l l
remove
//
14
for
widget
f i l l
( var
15
//
16
var
17
18
19
20
21
22
);
23
//
all
i
29
g,
if
=
dto
f
child
0
/
g
hold
//
g
t h e DOM
;
i
is
set
widgets
<
child
based
on
that
dto
this . products . length ;
i ++
)
f
widget
= dojo . widget . createWidget (
" ProductItemViewWidget " , f
product
: this . products [ i ]
/ * PROTECTED REGION I D ( . . . )
25
g
from
w
this .
28
children
create
24
27
all
[ i ] . destroy () ;
. dom . r e m o v e C h i l d r e n ( t h i s . d a p P r o d u c t ) ;
( this . products )
13
26
productList
*
PROTECTED REGION END
child
widget
productList
add
child
object
. p u s h (w) ;
widget
to
in
ENABLED START
*/
*/
array
t h e DOM
t h i s . d a p P r o d u c t . a p p e n d C h i l d ( w . domNode ) ;
Listing 6.9: Generativ erzeugte Funktion zur Aktualisierung des DTOs gekapselter Widgets
Benutzeraktionen und Eventhandler
Fur Benutzeraktionen werden in Webanwendungen meist Buttons und Links genutzt. Bei
Links wird dabei eine JavaScript Funktion als Event- Handler angegeben, da sonst ein
Page Reload durchgefuhrt wird. Wie bereits in Abschnitt 4.8 erwahnt, enthalt das HTML
Template von Widgets nur Elemente fur den strukturellen Aufbau. Andere Widgets wie
z.B. Buttons konnen darin nicht verwendet werden. Um diese Nutzen zu konnen, bieten
sich drei Moglichkeiten an:
ˆ Deklarative Beschreibung in der Webseite auerhalb des Widgets
ˆ Deklarative Beschreibung in der Webseite als Kind- Element des Widgets
ˆ Programmatische Erstellung
Bei der ersten Moglichkeit konnen Probleme mit der Positionierung der Aktions- Elemente
mit CSS auftreten, da diese Bestandteil des Widgets sind, aber durch die Denition
81
auerhalb des Widgets nicht als Kind- Element im DOM abgelegt werden. Diese Probleme
sind bei der zweiten Moglichkeit umgangen. Bei der Darstellung von Listen, die in der
Lange variieren, ist die zweite Moglichkeit fur Widgets, welche die Eintrage der Liste
darstellen, nicht machbar, da diese Widgets selbst dynamisch erstellt werden mussen. Fur
diesen Fall bleibt nur die dritte Moglichkeit. Allerdings ist die programmatische Erstellung
wenig transparent fur den Webdesigner, weshalb diese nur verwendet werden sollte, wenn
die zweite Moglichkeit ausscheidet.
Die Funktionen fur das Event- Handling benotigen i.d.R. Daten von dem Widget, welches
das Aktionselement enthalt. Durch den Zugri von auen auf diese Daten entsteht haug
eine hohe Kopplung. Besser ist hier, den Event- Handler als Funktion in das Widget zu
verlagern. Hier ist ein einfacher Zugri auf die Daten des Widgets moglich. Beschreibt
die Aktion einen Zustandswechsel der Webanwendung, wird in dem Event- Handler ein
Event mit den benotigten Daten des Widgets erstellt und an den zentralen Controller
ubergeben.
Bei Links konnen die Event- Handler den Aktions- Elementen relativ einfach zugewiesen
werden. Dem Wert des Attributes href konnen mit dem Prax javascript: beliebige
JavaScript Anweisungen zugewiesen werden. Wird aber z.B. das dojo Button Widget verwendet, kann dem Attribut onClick nur eine Funktion zugewiesen werden. Bei programmatischer Erstellung des Buttons ist dies einfach moglich, da das Widget, welches den
Button erstellt, die Event- Handler Funktion implementiert und dadurch einfach die Funktion zuweisen kann. Wird der Button deklarativ erstellt, so muss erst eine Referenz auf das
Widget Objekt bezogen werden, bevor die Funktion zugewiesen werden kann. Dadurch
ist es notwendig, dem Widget einen Identikator zuzuweisen. Listing 6.10 verdeutlicht die
Zuweisung der Event- Handler Funktion doSomething des Widgets productListView
zu dem Attribut onClick des Buttons.
1
2
<! d e c l a r a t i v e
<d o j o : b u t t o n
3
onClick
4
show
5
6
7
8
9
created
>
button
=" d o j o . widget . b y I d ( ' p r o d u c t L i s t V i e w ' ) . doSomething ( ) ">
something
</ d o j o : b u t t o n >
<! d e c l a r a t i v e c r e a t e d w i d g e t
<d o j o : P r o d u c t L i s t V i e w W i d g e t
with
event
handler
function
widgetId = "productListView"
= " p r o d u c t s from c a t e g o r y ">
</ d o j o : P r o d u c t L i s t V i e w W i d g e t >
>
t i t l e
Listing 6.10: Zuweisung der Event- Handler Funktion eines Widgets zu einem deklarativ
erzeugten Button- Widget
Die MDSD kann die programmatische Erstellung wieder etwas vereinfachen. Dazu wird
das Aktions- Widget als Attribut mit dem Stereotyp <<action>> modelliert. Dieses Widget wird nach Erstellung und auf diesem gespeichert. Der modellierte Startwert des Attributes wird als Beschriftung des Buttons oder als Linktext verwendet. Das Aktions- Wid-
82
get wird dem dojo Attach Point zugefugt, der mit dem Tagged Value dojoAttachPoint
angegeben wurde. Die modellierten Widgets werden in der Funktion fillInTemplate erstellt und dem dojo Attach Point hinzugefugt. Listing 6.11 zeigt den generativ erzeugten
Code fur ein Aktions- Widget.
1
//
create
2
var
3
//
4
5
6
this
,
needed
for
event
handler
call
button
t h i s . s h o w P r o d u c t = d o j o . w i d g e t . c r e a t e W i d g e t ( " Button " ,
caption
: "show p r o d u c t " ,
onClick
: function ( event ) f
//
8
10
g) ;
11
//
12
= this ;
create
7
9
closure
g
add
' this '
this
button
references
the
button
. showProductHandler ( event ) ;
to
dojo
attach
f
object
point
t h i s . s h o w . a p p e n d C h i l d ( t h i s . s h o w P r o d u c t . domNode ) ;
Listing 6.11: Generativ erzeugter Code fur ein Aktions- Widget
Event- Handler werden als Methoden in UML modelliert und als Funktion des Widgets
umgesetzt. Soll die Funktion als Event- Handler fur ein modelliertes Aktions- Widget
dienen, so kann das mit <<action>> versehene Attribut als Verandertes Attribut 1 bei
der Methode gesetzt werden. Bei einem dojo Button wird diese Funktion automatisch
der Eigenschaft onClick zugewiesen, wie Listing 6.11 verdeutlicht.
6.4 Weitere Aspekte im Entwicklungsprozess mit MDSD
In beiden letzten Abschnitten 6.2 und 6.3 wurde speziell auf die Modellierung und Umsetzung in Quellcode eingegangen. Die Beschreibung weiterer Aspekte wie Modell- Validierungen und Unterstutzung des Entwicklers bei der Implementierung soll hier erfolgen.
Diese sind nicht notwendig, stellen jedoch Konzepte dar, welche den Entwicklungsprozess
handhabbarer machen.
6.4.1 Modell- Validierungen
Wie bereits in Abschnitt 5.3.2 erwahnt, werden Modell- Validierungen in openArchitectureWare durch die check validation language unterstutzt. Bei der Videothek sind ModellValidierungen u.a. bei der Modellierung der Widget Klassen sinnvoll. Wie in Abbildung
1
Diese Angabe dient normalerweise der Beschreibung, dass es sich bei der Methode um eine Zugrismethode des angegebenen Attributes handelt.
83
6.3.2 auf Seite 77 verdeutlicht, wird in den Startwerten der Attribute, die mit dem Stereotyp <<field>> angegeben sind, auf Attribute mit dem Stereotyp <<dto>> verwiesen.
Dies ist keine standardisierte Modellierungsvorschrift im Sinne von UML und somit nicht
von einem UML Tool uberprufbar. Solche benutzerdenierten Modellierungsvorschriften
konnen mit der Syntax von check auf korrekte Anwendung hin validiert werden. In Listing 6.12 ist ein Beispielcode abgebildet, der das Vorhandensein des mit dem Stereotyp
<<dto>> versehenen Attributes uberpruft.
1
2
c o n t e x t W i d g e t ERROR " f i e l d i n widget ' " + t h i s . Name +
" ' r e f e r s to a DTO t h a t i s not a member" :
3
4
5
6
7
8
. typeSelect ( Field ) . forAll ( f j
A t t r i b u t e . t y p e S e l e c t ( Dto ) . e x i s t s ( d t o j
d t o . Type . A t t r i b u t e . e x i s t s ( a t t r i b j
f . I n i t V a l u e . m a t c h e s ( d t o . Name + " nn . nn w+" ) ) ) )
Attribute
;
Listing 6.12: Validierungsregel zur U berprufung der referenzierten DTOs bei Widget Klassen
Dabei wird nach dem Schlusselwort context der Typ des Modell- Elementes angegeben,
fur den die Validierungsregel gilt. Im Beispiel werden alle mit dem Stereotyp <<widget>>
annotierten Modell- Elemente mit dieser Regel validiert. Das Schlusselwort ERROR impliziert einen Fehler in der Modellierung. Alternativ kann auch das Schlusselwort WARNING
verwendet werden. Abhangig von der Konguration wird bei Fehlern im Modell kein Code
generiert. Der folgende Text ist die Beschreibung des Fehlers oder der Warnung fur die
Ausgabe bzw. die Log- Datei. Zwischen dem Doppelpunkt und dem Semikolon steht die
Validierungsregel, welche den Wert true liefert, wenn die Validierung erfolgreich ist.
Die Regel uberpruft alle mit <<field>> annotierten Attribute, ob der Startwert mit dem
Namen eines mit <<dto>> annotierten Attributes, gefolgt von einem Punkt und mindestens einem Buchstaben beginnt. Dieses Beispiel dient lediglich zur Feststellung, ob die
referenzierten DTOs existieren. Im Listing 6.13 wird uberpruft, ob das referenzierte Attribut des DTOs existiert. Diese U berprufung ist genauer, und impliziert diese aus Listing
6.12. Die Unterscheidung ist durch die spezischere Fehlermeldung dennoch sinnvoll.
1
2
c o n t e x t W i d g e t ERROR " f i e l d i n widget ' " + t h i s . Name +
" ' r e f e r s to an A t t r i b u t e from a DTO t h a t doesn ' t e x i s t " :
3
4
Attribute
6
7
8
. typeSelect ( Field ) . forAll ( f j
. t y p e S e l e c t ( Dto ) . e x i s t s ( d t o j
d t o . Type . A t t r i b u t e . e x i s t s ( a t t r i b j
f . I n i t V a l u e == d t o . Name + " . " +
Attribute
5
;
attrib
. Name ) ) )
Listing 6.13: Validierungsregel zur U berprufung der referenzierten Attribute von DTOs
bei Widget Klassen
84
Werden die beiden Validierungsregeln auf die Klasse in Abbildung 6.9 angewandt, wird
die Ausgabe in Listing 6.14 vom Framework erzeugt. Fur weitere Informationen uber die
Sprache check sei hier auf dessen Referenz unter [124] verwiesen.
Abbildung 6.9: Beispiel einer modellierten Widget Klasse mit Fehlern
1
7841
2
3
4
5
6
ERROR
refers
7841
ERROR
refers
WorkflowRunner
to
a
DTO
that
is
WorkflowRunner
to
an
[<<W i d g e t >>
Attribute
TestWidget
field
in
not
member
a
field
]
from
a
in
DTO
" TestWidget "
[<<W i d g e t >> T e s t W i d g e t ]
widget
widget
that
" TestWidget "
doesn ' t
exist
Listing 6.14: Fehlermeldungen durch Anwendung der beiden Validierungsregeln in Listing
6.12 und 6.13 auf Abbildung 6.9
6.4.2 Entwicklungsunterstutzung bei der Implementierung
Durch die MDSD kann in den seltensten Fallen der Code vollstandig generiert werden. Die
Hibernate Mapping Dateien sowie das Business Delegate fur DWR sind solche Ausnahmen. Der generierte Code stellt haug eine Infrastruktur bereit, die fertig implementiert
werden muss. Dabei kann es sein, das die generierte Infrastruktur eine bestimmt Implementierung vorschreibt.
Als Beispiel seien hier die HTML- und CSS Templates des dojo Widget Systems genannt.
Diese beiden mussen existieren und speziell an das HTML Template werden gewisse Anforderungen gestellt. So werden die mit dem Stereotyp <<field>> annotierten Attribute,
wie bereits in Abschnitt 6.3.2 beschrieben, auf dojo Attach Points abgebildet. Der Name
des Attributes gibt dabei den Wert eines dojo Attach Points an. Diese U berprufungen, ob
85
die verwendeten dojo Attach Points im HTML Template existieren, sind mit dem recipe
Framework moglich.
Das Framework integriert sich gut als U bersicht in Eclipse. In dieser werden alle U berprufungen mit einem Identikator gelistet der angibt, ob die U berprufung erfolgreich war.
In Abbildung 6.10 ist das Ergebnis der U berprufung dargestellt, ob zu jeder Widget Klasse
ein HTML- und CSS- Template existiert. Wie in der Abbildung rechts unten zu sehen
ist, kann dem Entwickler auch Hilfestellung fur die weitere Implementierung gegeben
werden.
Abbildung 6.10: Beispielubersicht des recipe Frameworks nach ausgefuhrten U berprufungen
Durch die Integrierung der U berprufungen in Eclipse sind diese recht aufwandig zu kongurieren. Von openArchitectureWare werden bereits Klassen fur Standard- U berprufungen
bereitgestellt, die genutzt werden konnen. Ein Beispiel hierfur ist die U berprufung, ob eine
Klasse von einer anderen abgeleitet ist. In dem obigen Falle wurde eine Klasse fur die
U berprufung selbst erstellt. Weiterhin muss eine Basisklasse von openArchitecureWare
implementiert werden, welche alle U berprufungen beinhaltet. Diese serialisiert die U berprufungen direkt nach der Code Generierung in eine Datei. Diese Datei wird von einem
Eclipse Plugin ausgewertet, welches auch die Ergebnisse der U berprufung anzeigt. Hier
ist die Konguration etwas umstandlich, da das Eclipse Plugin die selbst erstellte Klasse
zur U berprufung im Class Path nden muss. Da wiederum jedes Eclipse Plugin seinen
eigenen Class Loader besitzt, wird hier ein separates Plugin erstellt, welches das openArchitectureWare Plugin erweitert. Weitere Informationen benden sich in der Referenz zu
dem recipe Framework unter [125].
6.5 Die entstandene Demo- Applikation
In diesem Kapitel wurde die Modellierung von Server- und Client Infrastruktur der DemoApplikation betrachtet, sowie auf einige Aspekte der Umsetzung in Code eingegangen.
86
Aus dem Modell wurden Infrastruktur- Komponenten generiert, fertig implementiert und
fur die Videothek verwendet, welche in diesem Abschnitt kurz vorgestellt werden soll.
Die daraus entstandene Demo- Webanwendung ist in Abbildung 6.11 dargestellt. Es wurde ein ublicher struktureller Aufbau mit Kopf- und Fuzeile, linker Navigation und rechter
Sidebar gewahlt. In der linken Navigation werden alle Kategorien mit den dazugehorigen
Produkten als Baumansicht dargestellt. Der Hauptbereich in der Mitte wird fur die detailliertere Darstellung von Daten verwendet. In Abbildung 6.11 werden dort alle Produkte
der ausgewahlten Kategorie dargestellt.
Abbildung 6.11: Darstellung aller Produkte einer Kategorie in der Videothek
Die Baumansicht auf der rechten Seite bezieht erst dynamisch bei Klick auf eine Kategorie die entsprechenden Produkte vom Webserver. In der Mitte werde die Produkte
mit Hilfe eines Composite- Widgets dargestellt, welches in Abschnitt 6.3.2 als Beispiel
modelliert wurde. Abbildung 6.8 zeigt das Modell dieses Composite- Widgets. Mit Hilfe der in Abschnitt 6.3.2 herausgearbeiteten Modellierungsvorschrift, konnte das ElternWidget vollstandig generativ erzeugt werden. Bei den Kind- Widgets sind lediglich die
Event- Handler fur den Button show product manuell zu implementieren.
Bei Klick auf den Button oder einem Produkt in der Baumansicht, wird das entsprechende
Produkt im Hauptbereich der Webseite angezeigt. Abbildung 6.12 zeigt die Darstellung
eines Produkts in der Demo- Anwendung. Die Darstellung eines Produktes erfolgt ebenso
mit einen Composite- Widget. Im oberen Teil werden die Daten des Produktes dargestellt.
Es folgen dann alle Medien, auf denen das Produkt verfugbar ist. Die Kategorien, in denen
das Produkt eingeordnet ist, werden im unteren Teil dargestellt.
87
Abbildung 6.12: Darstellung eines Produktes in der Videothek
Fur weitere Informationen uber die Implementierung der Demo- Applikation sei hier auf
den Quellcode verwiesen.
6.6 Zusammenfassung
In diesem Teil der Diplomarbeit wurde sich mit der Modell- getriebenen Umsetzung des in
Kapitel 4 ausgearbeiteten Konzeptes einer clientzentrierten Webanwendung beschaftigt.
Dabei wurde versucht, die wesentlichsten Aspekte zu berucksichtigt, um eine mogliche
Basis fur die Modell- getriebene Vorgehensweise herauszuarbeiten.
Im Vordergrund dieses Kapitels stand eine praktische Einfuhrung in den Entwicklungsprozess einer AJAX Webanwendung mit MDSD, um einerseits die Anwendbarkeit und
andererseits das Potential von MDSD zu verdeutlichen. Dabei wurden die theoretischen
Betrachtungen bewusst kurz gehalten, ebenso die Kongurationsdetails von openArchitectureWare. Die allgemeinen Konzepte von MDSD, wie Modell- Validierungen und die
U berprufung der Implementierung der generierten Infrastruktur, wurden am Beispiel gezeigt. Weiterhin wurde dabei in Abschnitt 6.4.2 auf die aufwandige Konguration des
recipe Frameworks hingewiesen. Dies soll verdeutlichen, dass zu einem Entwicklungsprozess mit MDSD nicht nur ein Code Generator, sondern eine Sammlung von gut zusam-
88
menarbeitenden Tools notwendig ist. Diese wird auch oft als Tool Chain bezeichnet. Das
Framework openArchitectureWare bietet einen leichten Einstieg in die MDSD, jedoch ist
fur den produktiven Einsatz eine durchdachte Infrastruktur notwendig.
Wesentlich ist die Steuerung des Generierungsvorgangs mit Stereotypen und Tagged
Values. Abhangig von diesen wird unterschiedlicher Code erzeugt. Fur das dojo Widget
System wurde in Abschnitt 6.3.2 eine mogliche Modellierungvorschrift herausgearbeitet.
Dies stellt eine Art von Domain- spezischen Modellen dar.
Die Vorteile der MDSD sind am Beispiel der Hibernate Mapping Dateien am deutlichsten erkennbar. Diese werden vollstandig aus dem Modell generiert. Der Entwickler muss
die formale Spezikation der Hibernate Mapping Dateien nicht mehr auf jede persistente
Klasse einzeln anwenden. Er erstellt lediglich eine einzige Implementierung der Spezikation fur den genutzten Code Generator, welcher dann in der Lage ist, diese auf jede Klasse
anzuwenden. Dadurch wird ein wesentlicher Zeit- und Qualiatsvorteil erzielt. Mogliche
Fehler in den Mapping Dateien mussen nicht mehr in jeder Klasse, sondern konnen an
einer zentralen Stelle behoben werden - dem Template zur Generierung der Mapping Dateien. Durch die Wiederverwendbarkeit dieses Templates in anderen Projekten wird ein
wesentlicher Vorteil gegenuber der herkommlichen Softwareentwicklung erzielt.
Als weiteres Beispiel wurde die Infrastruktur fur dojo Widgets generativ umgesetzt. Hier
konnte durch eine geeignete Modellierungsvorschrift ein Groteil der Implementierung
generiert werden.
89
7 Abschlussbemerkungen
7.1 Bewertung und Entwicklungstendenzen bei AJAX
Frameworks
In dieser Arbeit wurde versucht, den aktuell haug verwendeten Begri AJAX etwas
naher zu denieren. Dabei wurde in Abschnitt 2.3.1 auf einige Moglichkeiten fur AJAXbasierte Webanwendungen eingegangen, mit denen sich Webanwendungen sehr viel benutzerfreundlicher gestalten lassen. Doch neben diesen vielversprechenden Moglichkeiten
wurde auch auf die Hindernisse mit AJAX verwiesen. Einige davon sind die History- und
Bookmarkfahigkeit (Abschnitt 2.3.3), barierrefreie Webanwendungen (Abschnitt 2.4) und
die notwendigen und noch fehlenden Webstandards (Abschnitt 2.2). Aktuelle AJAX Frameworks und Toolkits bieten bereits Losungsmoglichkeiten fur diese Hindernisse an, die
in den meisten aktuellen Webbrowsern funktionieren.
Durch die nahere Betrachtung verschiedener AJAX Plattformen konnte eine Kategorisierung fur AJAX- basierte Webanwendungen herausgearbeitet werden. Es folgte eine U bersicht uber vorhandene AJAX Frameworks. Hier wurde die Unbestimmtheit des Begris
AJAX deutlich, da AJAX nur auf der Nutzung eines JavaScript Objekts beruht. Dadurch
ermoglicht sich eine sehr breit gefacherte Nutzung von AJAX, die sich in der Anzahl und
Verschiedenheit der verfugbaren AJAX Frameworks und Toolkits niederschlagt. Durch
diese Entwicklungsvielfalt sind sie leider nicht mehr uberschaubar. Fur eine grobe Einteilung der Frameworks wurden in Abschnitt 3.6.2 mogliche Ansatze herausgearbeitet. Weiterfuhrende Aspekte zur Auswahl eines Frameworks wurden in Abschnitt 3.7 aufgefuhrt.
Dazu gehoren die genauere Spezizierung der AJAX Plattform der geplanten Webanwendung, sowie das Know- how der Entwickler. Auf der Webseite ajaxpatterns.org wurde mit
dem Aufbau einer Vergleichs- Matrix begonnen. Diese ist unter [126] zu nden.
Bei der Entwicklung von neueren AJAX Frameworks deutet sich ein neuer Ansatz an,
indem diese andere als Basis voraussetzen. Dies sind i.d.R. clientseitige Toolkits wie dojo
oder Yahoo UI, die neben Cross Browser Support auch nutzliche Bibliotheken bieten. Das
Apache Incubator[127] Projekt XAP 1 [128] stellt eine Infrastruktur fur Webanwendungen
bereit, welche die clientseitigen Toolkits nutzt, um die Inhalte der Webseite im Webbrowser darzustellen. Dabei verfolgt XAP einen XML- basierten Ansatz, der durch einen
1
XAP steht fur Extensible AJAX Plattform.
90
Adapter2 auf einen angebundenen Toolkit abgebildet wird. XAP ist von der Serverplattform unabhangig.
Einen ahnlichen Ansatz verfolgt das von Sun's AJAX Architekt Greg Murray vorgestellte
Projekt jMaki [129]. Es ist eine Tag Library fur Java Server Pages (JSP[61]) bzw. eine Komponente fur die Java Server Faces (JSF[130]) Technologie. Es ist ein WrapperFramework um clientseitige Toolkits wie dojo und Yahoo UI. Dadurch wird die Nutzung clientseitiger Toolkits durch eine serverseitig integrierte, Template- basierte View
Technologie ermoglicht. Fur Entwickler herkommlicher Webanwendungen ermoglicht sich
dadurch ein einfacher Weg zu AJAX- basierten Webanwendungen.
Allgemein ist die Tendenz zu deklarativen Ansatzen erkennbar. Diese bieten neben der
hoheren Transparenz und Fehlerfreiheit auch eine geeignete Moglichkeit fur Softwareentwickler, welche keine weitergehenden JavaScript Kenntnisse besitzen. Da die Nutzung von
JavaScript durch die W3C Richtlinien fur barierrefreie Webanwendungen nicht empfohlen
wird, werden zukunftig alternative Technologien notwendig. Einen U berblick hierfur bietet
die Dynamic Accessibile Web Content Roadmap[131] des W3Cs. Weiterhin arbeitet die
Web Application Formats Working Group [132] des W3C bereits an einer Spezikation
zur deklarativen Beschreibung von Webanwendungen. Diese sollte auf vorhandenen Formaten wie z.B. XUL von der Mozilla Foundation[133] oder XAML3 von Microsoft[138]
basieren. Wie in Abschnitt 3.6.1 beschrieben, nutzt das AJAX Framework ZK auch XUL
Komponenten.
Durch diese stetige Entwicklung neuer Technologien, werden auch die Rendering Engines
der Webbrowser leistungsfahiger und komplexer, wodurch sie sich auch fur den Einsatz
auerhalb von Webbrowsern eignen. Die Rendering Engine Gecko der Mozilla Foundation wird z.B. auch in der Linux Distribution Symphony OS[139] verwendet, um den
Desktop darzustellen. Weitere Informationen dazu benden sich in der News Meldung
von Golem[140] unter [141] und der Wikipedia unter [142].
Bei AJAX- basierten Webanwendungen wird wesentlich mehr Logik im Webbrowser ausgefuhrt als bei herkommichen Webanwendungen. Dies verandert auch die Sichtweise des
Webbrowsers als Anwendung. Der Webbrowser wird bei herkommlichen Webanwendungen meist nur zur Darstellung der Webseiten vom Webserver genutzt, wodurch er in
die Kategorie der Thin Clients[143] einzuordnen ist. Der wesentliche Teil der Verarbeitungslogik ist auf dem Webserver hinterlegt. Bei AJAX hingegen wird clientseitige Logik
notwending, um das XmlHttpRequest Objekt nutzen zu konnen. Im Falle von clientzentrierten Webanwendungen verlagert sich die Prasentationslogik vollstandig in den Client.
2
3
Bei XAP werden die Adapter Bridges genannt.
XAML ist die Abkurzung fur eXtensible Application Markup Language. Es ist eine XML- basierte
Sprache, die zur Beschreibung von graschen Oberachen in Windows Vista[134] genutzt wird. Diese
ist Teil der Windows Presentation Foundation[135], die wiederum Bestandteil des .Net Frameworks
3.0 [136] ist. Mehr Informationen daruber im Wikipedia Artikel unter [137].
91
Dadurch stellt der Webbrowser nicht mehr nur Webseiten dar, sondern stellt eine Laufzeitumgebung fur AJAX- basierte Webanwendungen bereit. Dies bewirkt die Einordnung
des Webbrowsers als Fat Client[144], da er neben der Ein- und Ausgabe auch Verarbeitungslogik besitzt.
Die Entwicklung AJAX- basierter Webanwendungen geht eindeutig in die Richtung von
Single Page Applications. Hybride Webanwendungen konnen lediglich einen Teil des Potentials von AJAX nutzen. Wie in Abschnitt 4.9 gezeigt, werden von dojo wesentliche
Konzepte von Webanwendungen, wie Internationalisierung und Validierung unterstutzt.
Durch Sun und IBM stehen auch Unternehmen mit einer groen Marktmacht hinter diesem Toolkit. Inwieweit zukunftige Webanwendungen client- oder serverzentriert sein werden, bleibt abzuwarten. Clientzentrierte werden sich allerdings nur durchsetzen, wenn die
Programmierung in JavaScript nicht mehr notwendig ist. Jedoch wird die Unterscheidung
zwischen client- und serverzentrierten Webanwendungen mit zunehmender Integration
von AJAX in bestehende Webframeworks immer schwieriger.
Die Entwicklung clientzentrierter Webanwendungen wird aber erst richtig interessant,
wenn das XmlHttpRequest Objekt den Zugri auf Services anderer Domains ermoglicht.
Dies wurde gut in das Konzept der Service- orientierten Architektur (SOA[145]) passen.
Das W3C beschaftigt sich bereits mit sogenannten Cross Site Extensions des XmlHttpRequest Objekts[146]. Hierdurch konnte das Potential von AJAX weiter gesteigert werden,
allerdings birgt dies auch Risiken, wie der Artikel der Wikipedia unter [147] zeigt. Weiterhin sind clientzentrierte Webanwendungen im Sinne der Service- orientierten Architektur
nur fur Webanwendungen interessant, wo die serverseitige Infrastruktur anderweitig verwendbar ist.
Das Videotheksbeispiel wurde Service- orientiert ausgelegt. Fur den Kommunikationsmechanismus wurde jedoch DWR genutzt. Der Einsatz von SOAP ware durch den Overhead
der U bertragung und der fehlenden Moglichkeit, clientseitig auf Services anderer Domains
zuzugreifen, nicht sinnvoll.
7.2 Einsatz von MDSD bei der Entwicklung von AJAX
Webanwendungen
Die Basis fur die Entwicklung einer AJAX Webanwendung stellt die Festlegung der AJAX
Infrastruktur (siehe 4.1), des verwendeten Architekturmodells (siehe 4.2.2) sowie der genutzten Frameworks (siehe 4.3) dar. Jede Schicht des Architekturmodells besitzt dabei
eine festgelegte Verantwortlichkeit, die mit speziellen Software- Komponenten realisiert
wird. In Abschnitt 6.2 wurde auf die Modellierung und Umsetzung der Server Komponenten eingegangen. Da diese nicht im Mittelpunkt der Diplomarbeit stehen, wurde die
Betrachtung kurz gehalten. Wichtig fur clientzentrierte AJAX Webanwendungen ist die
Schnittstelle zu den Server- Komponenten. Im Abschnitt 6.3 folgte die Betrachtung der
92
Client Infrastruktur. Durch die Herausarbeitung einer geeigneten Modellierungsvorschrift
fur Widgets konnten diese bis auf die Implementierung der Event- Handler von AktionsWidgets generativ erzeugt werden. Bei der Codegenerierung fur spezielle Frameworks,
wie das dojo Widget System, besteht das Problem der Modellierung der fur die jeweiligen
Aspekte des Frameworks notwendigen Daten. Die Verwendung der UML ist durch den
universellen Aspekt nicht immer geeignet, die Daten im Modell zu hinterlegen. Spezielle,
fur die Domain geeignete, Meta- Modelle erlauben eine transparentere Modellierung.
Wesentlich fur den Einsatz der MDSD ist dabei die Unterscheidung zwischen der Entwicklung von Softwarekomponenten und der Verwendung dieser. Auf Serverseite wurden die
generativ erzeugten und fertig implementierten Softwarekomponenten verwendet, indem
sie mit dem Spring Framework untereinander verknupft wurden. Zu den InfrastrukturKomponenten auf Clientseite gehorten die benutzerdenierten Widgets, ein zentraler
Controller zur Steuerung der Webanwendung sowie eine Komponente zur Entkopplung
des Kommunikationsmechanismus von der Client Infrastruktur. Diese Komponenten wurden teilweise vollstandig generativ erzeugt. Bei der Implementierung der Komponenten
wurden diese miteinander verknupft und in der Webseite verwendet. Bei der Verwendung
der Komponenten konnte auf Server- und Clientseite kein wesentlicher Vorteil mit der
MDSD erzielt werden.
Daher ist die MDSD primar zur Generierung einer Infrastruktur geeignet. Entscheidend fur
den Einsatz der MDSD ist die zugrundeliegende Architektur der Software. Die serverseitige Architektur einer Webanwendung ist wohldeniert und somit sehr gut fur den Einsatz
der Modell- getriebenen Softwareentwicklung geeignet. Die Infrastruktur des Clients ist
dagegen aktuell noch sehr unbestimmt. Durch den allgemeinen Trend der Vermeidung
von JavaScript Programmierung, ist diese sehr vom verwendeten Framework abhangig.
Dadurch kann bei Wechsel des Frameworks eine groere Anpassungen an der MDSD
Infrastruktur notwendig werden.
Die im Rahmen dieser Diplomarbeit eingesetzten Frameworks eigneten sich gut fur die
Entwicklung mit MDSD. DWR stellte auf Clientseite eine Schnittstelle bereit, die mit
Hilfe eines Business Delegate von den Client Komponenten entkoppelt wurde. Durch die
festgelegte Schnittstelle von DWR lies sich das Business Delegate mit wenig Aufwand
vollstandig generativ erzeugen. Die Konzepte des dojo Widget Systems waren dabei umfassender. Hierfur wurde eine geeignete Modellierungsvorschrift fur die UML herausgearbeitet, wodurch sich der wesentliche Teil der Infrastruktur generieren lies. Durch die
Verwendung der MDSD fur das in Abschnitt 4 herausgearbeitete Konzept einer clientzentrierten AJAX Webanwendung konnte ein Teil der notwendigen JavaScript Programmierung generativ erzeugt werden. Somit folgt die Nutzung der MDSD dem allgemeinen
Trend der Vermeidung von JavaScript Programmierung.
Die MDSD ist prinzipiell fur wiederkehrende Aufgaben geeignet. An verschiedenen Stellen
wiederkehrender oder ahnlicher Quellcode in der Implementierung ist ein Indiz fur die Anwendbarkeit der MDSD. Dies kann als Grundlage fur die Entwicklung einer Modellierungs-
93
vorschrift bzw. eines Meta- Modells herangezogen werden. Durch die Wiederverwendung
der MDSD Infrastruktur rendiert sich der erhohte Zeitaufwand fur die Entwicklung geeigneter Meta- Modelle oder Modellierungsvorschriften. Wiederverwendung ist hier aber
nicht beschrankt auf Projektebene zu sehen. Wie am Beispiel des dojo Widget Systems
verdeutlicht, wird die MDSD Infrastruktur bereits innerhalb eines Projekts fur jedes Widget wiederverwendet.
7.3 Ausblick
Wie bereits in Abschnitt 7.2 angemerkt, wurden bei Verwendung der Softwarekomponenten auf Server- und Clientseite manueller Code notwendig. Um diesen Teil zu automatisieren besitzen hier grasche Editoren nach dem WYSIWYG[148] Prinzip groes Potential,
welche die Softwarekomponenten per Drag- and- Drop verknupfen. Mit VE[149] konnen
z.B. grasche Oberachen basierend auf Swing[150] fur die Java Plattform entworfen
werden. Solch ein Konzept ist auch auf der Basis von Widgets eines AJAX Frameworks
denkbar.
In Abschnitt 6.3.1 wurde bereits angemerkt, dass es im Rahmen dieser Diplomarbeit nicht
moglich war eine Modellierungsvorschrift fur State Charts zu entwickeln, mit welcher
die Infrastruktur zur Steuerung der Webanwendung generativ erzeugt werden kann. Die
deswegen notwendige manuelle Implementierung der Steuerung war der grote Teil der
Clientlogik, die implementiert werden musste. Durch die Herausarbeitung eines geeigneten
Meta- Modells oder einer Modellierungsvorschrift fur die UML konnte die Steuerung der
Webanwendung teilweise generativ erzeugt werden.
Ein weiterer Aspekt ist der Ausbau der Modellierungsvorschrift fur Widgets. Im Rahmen
dieser Diplomarbeit wurde gezeigt, dass die generative Entwicklung von benutzerdenierten Widgets moglich ist. Die herausgearbeitete Modellierungsvorschrift stellt allerdings
nur eine Basis dar. Notwendig sind hier neben Formular- Widgets mit der notwendigen Validierung (siehe 4.9.6) auch die Internationalisierung der statischen Inhalte (siehe 4.9.5).
Weiterhin ist eine Unterstutzung der Konzepte fur barrierefreie Widgets (siehe 4.9.4)
sinnvoll.
94
Literaturverzeichnis
[1] Client-centric vs. server-centric programming in ASP.NET
http:blogs.msdn.com/federaldev/archive/2006/05/22/604367.aspx.
\Atlas".
[2] Seth Ladd, Darren Davison, Steven Devijver, Colin Yates: Expert Spring MVC and
Web Flow. APress, 2006.
[3] Russell, Alex: dojo - An Introduction. http://alex.dojotoolkit.org/06/
AjaxExperience/IntroToDojo.pdf.
[4] Core J2EE Patterns - Data Access Object. http://java.sun.com/blueprints/
corej2eepatterns/Patterns/DataAccessObject.html.
[5] 134 Ajax Frameworks and Counting. http://ajaxian.com/archives/134-ajax frameworks-and-counting.
[6] Wikipedia Homepage. http://www.wikipedia.org//.
[7] Document Object Model Homepage. http://www.w3.org/DOM/.
[8] Community, Wikipedia: Programmierschnittstelle. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Programmierschnittstelle.
[9] Community, Wikipedia: Dynamic HTML. From Wikipedia, the free encyclopedia,
2006. http://en.wikipedia.org/wiki/Dynamic HTML.
[10] Community, Wikipedia: JavaScript. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/JavaScript.
[11] ECMA International Homepage. http://www.ecma-international.org/.
[12] Community, Wikipedia: ECMAScript. From Wikipedia, the free encyclopedia, 2006.
http://en.wikipedia.org/wiki/ECMAScript.
[13] Community, Wikipedia: JScript. From Wikipedia, the free encyclopedia, 2006.
http://en.wikipedia.org/wiki/JScript.
[14] SELFHTML Homepage. http://de.selfhtml.org/.
[15] JavaScript und Webstandards. http://aktuell.de.selfhtml.org/weblog/javascriptstandards.
[16] World Wide Web Consortium Homepage. http://www.w3.org/.
95
[17] Rich Web Clients Activity Statement.
Activity.html.
[18] The
XMLHttpRequest
Object.
WD-XMLHttpRequest-20060619/.
http://www.w3.org/2006/rwc/
http://www.w3.org/TR/2006/
[19] Window Object 1.0. http://www.w3.org/TR/Window/.
[20] Webseite der WHATWG. http://www.whatwg.org/.
[21] Web Applications 1.0 Working Draft der WHATWG. http://www.whatwg.org/
specs/web-apps/current-work/.
[22] Google Suggest Webseite. http://labs.google.com/suggest.
[23] ajaxpatterns.org Homepage. http://ajaxpatterns.org.
[24] Periodic Refresh. http://ajaxpatterns.org/Periodic Refresh.
[25] HTTP Streaming. http://ajaxpatterns.org/HTTP Streaming.
[26] Community, Wikipedia: Ajax (Programmierung). Wikipedia, die freie Enzyklopadie,
2006. http://de.wikipedia.org/wiki/Ajax (Programmierung).
[27] Web Accessibility Initiative Homepage. http://www.w3.org/WAI/.
[28] Community, Wikipedia: Section 508 Amendment to the Rehabilitation Act of 1973.
From Wikipedia, the free encyclopedia, 2006.
http://en.wikipedia.org/wiki/Section 508.
[29] Community, Wikipedia: Barrierefreies Internet. Wikipedia, die freie Enzyklopadie,
2006. http://de.wikipedia.org/wiki/Accessibility.
[30] Mobile Top Level Domain Homepage. http://pc.mtld.mobi/.
[31] Homepage der Internet Corporation For Assigned Names and Numbers.
http://www.icann.org/.
[32] dotmobi Switch On! Web Browsing Guide. http://pc.mtld.mobi/documents/
dotmobi-Switch-On!-Web-Browsing-Guide.html.
[33] Community, Wikipedia: Web 2.0. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Web 2.0.
[34] RESTful Service. http://ajaxpatterns.org/RESTful Service.
[35] Community, Wikipedia: Representational State Transfer.
From Wikipedia, the free encyclopedia, 2006.
http://en.wikipedia.org/wiki/
Representational State Transfer.
[36] Community, Wikipedia: CRUD. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/CRUD.
96
[37] AjaxCaller Testin' Demo. http://ajaxify.com/run/testAjaxCaller/.
[38] RPC Service. http://ajaxpatterns.org/RPC Service.
[39] Community, Wikipedia: Stellvertreter (Entwurfsmuster). Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Stellvertreter (Entwurfsmuster).
[40] Dave Crane, Eric Pascarello, Darren James: Ajax in Action. Manning Publications
Co., 2006.
[41] Simple AJAX Toolkit. http://www.modernmethod.com/sajax/.
[42] JSON-RPC. http://json-rpc.org/.
[43] Direct Web Remoting Homepage. http://getahead.ltd.uk/dwr/.
[44] Selfhtml - Eigenschaft innerHTML. http://de.selfhtml.org/javascript/objekte/
all.htm#inner html.
[45] Javascript
XML
Frameworks.
Javascript XML Frameworks.
http://ajaxpatterns.org/
[46] Google AJAXSLT. http://goog-ajaxslt.sourceforge.net/.
[47] JSON Homepage. http://www.json.org/.
[48] Sun Microsystems Homepage. http://www.sun.com/.
[49] Community, Wikipedia: Single page application. From Wikipedia, the free encyclopedia, 2006. http://en.wikipedia.org/wiki/Single Page Application.

[50] AJAX Framework Ubersicht
. http://ajaxpatterns.org/Frameworks.
[51] Heise News Homepage. http://www.heise.de/.
[52] ajaxian Homepage. http://ajaxian.com/.
[53] Google Web Toolkit Homepage. http://code.google.com/webtoolkit/.
[54] Google Web Toolkit Terms and Conditions. http://code.google.com/webtoolkit/
terms.html.
[55] ZK Ajax Web Framework Homepage. http://zk1.sourceforge.net/.
[56] Community, Wikipedia: User Interface Markup Language. From Wikipedia, the free
encyclopedia, 2006. http://en.wikipedia.org/wiki/UIML.
[57] Community, Wikipedia: User interface markup language.
From Wikipedia, the free encyclopedia, 2006.
http://en.wikipedia.org/wiki/
User interface markup language.
[58] Community, Wikipedia: ZK User Interface Markup Language. From Wikipedia, the
free encyclopedia, 2006. http://en.wikipedia.org/wiki/ZUML.
97
[59] Community, Wikipedia: Gecko (Rendering Engine). Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Gecko (Rendering Engine).
[60] Community, Wikipedia: XML User Interface Language. From Wikipedia, the free
encyclopedia, 2006. http://en.wikipedia.org/wiki/XUL.
[61] Community, Wikipedia: JavaServer Pages - JSP 2.0. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/JavaServer Pages#JSP 2.0.
[62] Backbase Homepage. http://www.backbase.com.
[63] Microsoft Atlas Homepage. http://atlas.asp.net/.
[64] Atlas XML Script. http://www.nikhilk.net/AtlasXMLScript.aspx.
[65] Ajax JSP Tag Library Homepage. http://ajaxtags.sourceforge.net/.
[66] Display tag library Homepage. http://displaytag.sourceforge.net/.
[67] Rich Internet Application Toolkit Homepage.
servers.com/.
http://rialto.application-
[68] Acegi Security System Homepage. http://www.acegisecurity.org/.
[69] dojo JavaScript Toolkit Homepage. http://dojotoolkit.org/.
[70] Yahoo! User Interface Library Homepage. http://developer.yahoo.com/yui/.
[71] Adobe Spry Framework for Ajax Homepage.
technologies/spry/.
http://labs.adobe.com/
[72] Community, Wikipedia: Framework. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Framework.
[73] Community, Wikipedia: Toolkit. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Toolkit.
[74] Community, Wikipedia: Programmbibliothek. Wikipedia, die freie Enzyklopadie,
2006. http://de.wikipedia.org/wiki/Programmbibliothek.
[75] Velocity Homepage. http://jakarta.apache.org/velocity/.
[76] Community, Wikipedia: Dreischichtige Architektur. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Three-Tier-Architektur.
[77] Community, Wikipedia: Scalable Vector Graphics. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Svg.
[78] Community, Wikipedia: Vector Markup Language. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Vector Markup Language.
98
[79] Russell, Alex: Dojo In Depth. http://alex.dojotoolkit.org/06/AjaxExperience/
DojoInDepth.pdf.
[80] Dojo Dot Book. http://manual.dojotoolkit.org/WikiHome/DojoDotBook/.
[81] DWR
and
Acegi.
http://iremia.univ-reunion.fr/intranet/wiki/
Wiki.jsp?page=DWRandAcegi.
[82] Ajax based login using Acegi.
sjivan?entry=ajax based login using aceci.
http://www.jroller.com/page/
[83] JavaTM Servlet Specication. http://www.joshrehman.com/servlet-spec/2.4/.
[84] Eingebettete Frames. http://de.selfhtml.org/html/frames/eingebettete.htm.
[85] Using dojo.undo.browser.
DojoDotBook/Book0.
http://manual.dojotoolkit.org/WikiHome/
[86] Core J2EE Patterns - Transfer Object.
http://java.sun.com/blueprints/
corej2eepatterns/Patterns/TransferObject.html.
[87] Event-Handler. http://de.selfhtml.org/javascript/sprache/eventhandler.htm.
[88] Window
Objekt.
window.htm#capture events.
[89] Global Hotkey and Focus
GlobalHotkeyAndFocusManager.
http://de.selfhtml.org/javascript/objekte/
Manager.
http://dojo.jot.com/
[90] SELFHTML event. http://de.selfhtml.org/javascript/objekte/event.htm.
[91] Community, Wikipedia: Locale. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Locale.
[92] Community, Wikipedia: UTF-8. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/UTF8.
[93] Internationalization Overview. http://dojo.jot.com/InternationalizationOverview.
[94] How To Localize Widgets. http://dojo.jot.com/HowToLocalizeWidgets.
[95] The
Java
Tutorials:
Internationalization,
Lesson:
http://java.sun.com/docs/books/tutorial/i18n/intro/index.html.
Introduction.
[96] Tapestry Homepage. http://tapestry.apache.org/.
[97] Validation. http://manual.dojotoolkit.org/WikiHome/DojoDotBook/Book43.
[98] Formular- basierte Validierung mit Tapestry.
tapestry4.1/javascript/form.html.
http://tapestry.apache.org/
[99] Beier, Prof. Dr. Georg. Homepage: http://wwwstud.fh-zwickau.de/~geobe/.
99
[100] Homepage der Westsachsischen Hochschule Zwickau (FH).
zwickau.de/.
http://www.fh-
[101] Ronneberger, Torsten: Untersuchungen zur Integration aspektorientierter Methotik
in ein MDA Framework, 2006.
[102] Community, Wikipedia: Prol (UML). Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Prol (UML).
[103] Community, Wikipedia: Stereotyp (UML). Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Stereotyp (UML).
[104] Community, Wikipedia: Domanenspezische Programmiersprache.
Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/
Domanenspezische Programmiersprache.
[105] openArchitectureWare Homepage.
http://www.eclipse.org/gmt/oaw/.
http://www.openarchitectureware.org/,
[106] Community, Wikipedia: Model Driven Architecture. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Model Driven Architecture.
[107] Object Management Group (OMG) Homepage. http://www.omg.org/.
[108] Thomas Stahl, Markus Volter:
dpunkt.verlag GmbH, 2005.
Softwareentwicklung.
Modellgetriebene
[109] Poseidon
For
UML
Community
http://www.gentleware.com/ce.0.html.
Edition
Homepage.
[110] Poseidon For UML Homepage. http://www.gentleware.com/.
[111] Spring Framework. http://www.springframework.org/.
[112] HQL: The Hibernate Query Language. http://www.hibernate.org/hib docs/v3/
reference/en/html single/#queryhql.
[113] Apache Tomcat Homepage. http://tomcat.apache.org/.
[114] Eclipse Homepage. http://www.eclipse.org/.
[115] Eclipse Java Development
http://www.eclipse.org/jdt/.
Tools
(JDT)
Subproject
Homepage.
[116] Apache ANT Project Homepage. http://ant.apache.org/.
[117] Aptana Homepage. http://www.aptana.com/.
[118] Eclipse
Web
Tools
Platform
http://www.eclipse.org/webtools/.
100
(WTP)
Project
Homepage.
[119] Core J2EE Patterns - Session Facade.
http://java.sun.com/blueprints/
corej2eepatterns/Patterns/SessionFacade.html.
[120] Optimistic concurrency control in Hibernate.
http://www.hibernate.org/
hib docs/v3/reference/en/html single/#transactions-optimistic.
[121] Core J2EE Patterns - Business Delegate. http://java.sun.com/blueprints/
corej2eepatterns/Patterns/BusinessDelegate.html.
[122] DWR version 2.0 milestone 2 Homepage.
http://getahead.ltd.uk/dwr/
changelog/dwr20m2.
[123] The UML State Machines Based Navigation Modelling for Hypermedia.
http://www.l3s.de/ dolog/uml/.
[124] openArchitectureWare check Framework Referenz.
gmt/oaw/doc/4.0/r30 checkReference.pdf.
[125] openArchitectureWare recipe Framework Referenz.
gmt/oaw/doc/4.0/r40 recipeReference.pdf.
[126] AJAX Framework Comparison Matrix.
Frameworks Matrix.
http://www.eclipse.org/
http://www.eclipse.org/
http://ajaxpatterns.org/
[127] Apache Incubator Project Homepage. http://incubator.apache.org/.
[128] Extensible
Application
http://incubator.apache.org/xap/.
Platform
(XAP)
Homepage.
[129] Project jMaki Homepage. https://ajax.dev.java.net/.
[130] Community, Wikipedia: JavaServer Faces. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/JavaServer Faces.
[131] Dynamic Accessible Web Content Roadmap.
PF/roadmap/.
[132] Web Application Formats
2006/appformats/.
http://www.w3.org/WAI/
Working Group Homepage.
http://www.w3.org/
[133] Homepage der Mozilla Foundation. http://www.mozilla.org/.
[134] Community, Wikipedia: Microsoft Windows Vista. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Microsoft Windows Vista.
[135] Community, Wikipedia: Windows Presentation Foundation.
Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/
Windows Presentation Foundation.
[136] Community, Wikipedia: .NET Framework 3.0. Wikipedia, die freie Enzyklopadie,
2006. http://de.wikipedia.org/wiki/.NET Framework 3.0.
101
[137] Community, Wikipedia: eXtensible Application Markup Language. Wikipedia, die
freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/XAML.
[138] Microsoft Homepage. http://www.microsoft.com/.
[139] SymphonyOS Homepage. http://www.symphonyos.com/.
[140] golem.de Homepage. http://www.golem.de/.
[141] Symphony:
Linux-Distribution
mit
http://www.golem.de/0505/37987.html.
ungewohlichem
Desktop.
[142] Community, Wikipedia: Symphony OS. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Symphony OS.
[143] Community, Wikipedia: Thin Client. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Thin Client.
[144] Community, Wikipedia: Fat-Client. Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Fat-Client.
[145] Community, Wikipedia: Serviceorientierte Architektur. Wikipedia, die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/Serviceorientierte Architektur.
[146] Proposal for cross-site extensions to XMLHttpRequest.
Archives/Public/public-webapi/2006Apr/0214.html.
http://lists.w3.org/
[147] Community, Wikipedia: Cross-Site Scripting. Wikipedia, die freie Enzyklopadie,
2006. http://de.wikipedia.org/wiki/Cross-Site Scripting.
[148] Community, Wikipedia: What You See Is What You Get (WYSIWYG). Wikipedia,
die freie Enzyklopadie, 2006. http://de.wikipedia.org/wiki/WYSIWYG.
[149] Visual Editor Project Homepage. http://www.eclipse.org/vep/.
[150] Community, Wikipedia: Swing (Java). Wikipedia, die freie Enzyklopadie, 2006.
http://de.wikipedia.org/wiki/Swing (Java).
102
Thesen
AJAX ist ein Modebegri, der zur Beschreibung von Webanwendungen genutzt wird,
aber keine konkrete Denition dieser gibt.
AJAX kann die Bedienbarkeit einer Webanwendung erheblich steigern.
Fur AJAX- basierte Webanwendungen sind A nderungen im Entwicklungsprozess von Webanwendungen notwendig.
AJAX besitzt das Potential fur Single Page Applications.
Clientzentrierte Single Page Applications passen gut in das Konzept der Service- orientierten Architektur.
Die MDSD eignet sich zur Entwicklung clientzentrierte Webanwendungen.
Die Basis der MDSD stellt ein ausgearbeitetes Konzept der Webanwendung dar.
An verschiedenen Stellen wiederkehrender Quellcode ist ein Indiz fur die Anwendbarkeit
der MDSD.
Mit einer geeigneten Modellierungsvorschrift kann ein Groteil der Implementierung einer
Softwareinfrastruktur generiert werden.
Ein wesentlicher Bestandteil im MDSD Entwicklungsprozess ist die Validierung Domainspezischer Modelle.
Ein skalierbarer MDSD Entwicklungsprozess erfordert eine integrierte Tool- Chain.
Eidesstattliche Erklarung
Hiermit versichere ich, die vorliegende Arbeit selbststandig und unter ausschlielicher
Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben.
Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Prufungsbehorde
vorgelegt und auch nicht veroentlicht.
Zwickau, 27. September 2006
Tobias Haubold