HTML and CSS Reference
In-Depth Information
4.1 Architektur?
Die Entwicklung einer JavaScript-basierten RIA stellt die Webanwendungsentwicklung vor neue
Anforderungen. Bekannte Ansätze verlieren ihre Gültigkeit, alte Entwurfsmuster werden wieder
eingesetzt. In der klassischen Request-Response-basierten Webanwendungsentwicklung sind ver-
schiedene Lösungsansätze für das Problem der Seitennavigation entwickelt worden, ein Problem
das RIAs so nicht kennen. Andererseits dürfen sich RIA-Anwendungen ebenso wie Rich-Clients
mit dem Problem des Datentransfers zwischen Client und Server auseinandersetzen, ein Problem,
das wiederum Technologien, die serverseitig arbeiten, geschickt gelöst haben: Mit ORM-Tools, ver-
schiedenen Frameworks, Lazy Loading, einer handvoll Best Practices, Tooling und Industrieunter-
stützung haben sich sehenswerte Lösungsansätze etabliert. Die meisten Ansätze betreiben allerdings
keine Ursachenbekämpfung; die Komplexität des Gesamtsystems steigt bei jedem hinzugefügten
Framework. Der Betrieb, die Fehlersuche und die Wartung von Webanwendungen sind keine trivia-
len Tätigkeiten. Gerade die starken Technologiebrüche in der Laufzeitumgebung und in der Entwick-
lung sind in Bezug auf Effizienz und qualitätssichernde Maßnahmen aus dem Kapitel Software-En-
gineering absolut kontraproduktiv. Auch das Versprechen, das Problem durch noch bessere Tools in
den Griff zu bekommen, ist nicht eingelöst geworden.
Wie bei jeder Softwareentwicklung spielen die Erweiterungs- und Wartungskosten eine wesentliche
Rolle im Lebenszyklus einer Webanwendung. Gesucht sind Methoden und Vorgehensweisen, die im
Vorfeld zu besserer Softwarequalität führen, und Architekturmuster, die eine nachhaltige Wartung
und Pflege der Webanwendungen begünstigen. Webanwendungen haben nicht selten die Anforde-
rung, mit steigender Last entsprechend skalieren zu müssen. Technologien sollten das nicht verhin-
dern. Sobald es sich nicht um eine Prototyp- oder eine Intranetanwendung für eine überschaubare
Menge an Endanwendern handelt, sollte man sich kritisch mit dem Problem der Last und der Ska-
lierbarkeit auseinandersetzen. Dabei müsste berücksichtigt werden, wie hoch der serverseitige Auf-
wand pro Sitzung ist. Während JSP und Servlets eine leichtgewichtige Laufzeitumgebung mit spei-
cherpersistenten Servlets zur Verfügung stellen, tauchen die ersten Skalierungsprobleme schließlich
mit weiteren einzusetzenden Technologien beziehungsweise Frameworks auf. Einerseits ist die Ein-
führung von Komponentenmodellen in der Webentwicklung erstrebenswert, andererseits fordert die
Transformation des Request-Response-Zyklus in ein ereignisbasiertes Modell auf dem Server ihren
Tribut: einen mit der Anzahl der Teilnehmer steil steigenden Ressourcenverbrauch und eine relativ
hohe Latenz. Modulare und komponentenbasierte Entwicklung hat in der Vergangenheit auch dazu
geführt, dass im Browser benötigte CSS- und JavaScript-Ressourcen entsprechend der Komponen-
tenstrukturierung auf viele kleine Dateien verteilt wurden. So bringt nicht selten jede UI-Komponen-
te ihre eigenen CSS- und JavaScript-Ressourcen mit ins Boot. Das Ergebnis ist eine HTML-Seite,
die viele Requests durch den HTTP Connection Bottleneck schicken muss.
