Webframeworks – eine Kategorisierung

Action-based vs. Component-based

Ein Webframework kann entweder Action-based (oft auch Request-based genannt) oder Component-based sein (Abb. 3). Bei Action-based Webframeworks wird in dem API ersichtlich, dass eine HTML-Anfrage geparst und eine HTML-Antwort erzeugt werden soll. Jede Anfrage eines Nutzers ist eine eigene Aktion. Für jede Aktion wird genau ein Objekt definiert, das Anfragen entgegennimmt und verarbeitet. Der Ablauf ist dadurch sehr linear, als Einstiegspunkt für Interaktionen wird ein Servlet oder eine Aktion mit allgemeinen Attributen (z. B. URLs, Formulare etc.) genutzt. Vorteile dieses Konzepts sind die relativ simple Entwicklung, die Möglichkeit des einfachen Testens im Webbrowser sowie einfaches Verwalten von Lesezeichen, da jede Aktion einen URL darstellt. Demgegenüber steht der Nachteil, dass die Konfiguration schon bei relativ kleinen Seiten unübersichtlich wird, da jede Aktion ein eigenes Objekt besitzt und deshalb auch ein eigenes Mapping notwendig ist. Somit muss trotz einfacher Seitenstruktur sehr viel Konfiguration verwaltet werden.

Bei Component-based Webframeworks abstrahiert das API im Gegensatz zur Action-based-Variante vom Anfrage-/Antwortkonzept und behandelt die Webanwendung als Sammlung von Komponenten mit jeweils eigener Darstellung und eigenen Aktionen. Die Anfrage wird nicht an die Aktion, sondern an die Komponente geleitet, dort verarbeitet und in der Oberfläche angezeigt. Es entsteht kein linearer Ablauf. Zusammengehörende Typen von Informationen (z. B. Login, Logout, GetAccount) werden in Gruppen gesammelt (z. B. AccountController). Somit kann ein Objekt für mehrere Aktionen verantwortlich sein.

Ein großer Vorteil ist der schnelle Einstieg für Entwickler ohne Erfahrung in der Webentwicklung, da das API Java-Desktopanwendungen (z. B. Swing) ähnelt. Dies ermöglicht auch die einfachere Erstellung von eigenen Komponenten und deren Wiederverwendung. Des Weiteren ist die Konfiguration übersichtlich, da nicht für jede Aktion ein eigener Controller notwendig ist. Den Vorteilen steht der Nachteil gegenüber, dass der Entwickler auch die oft komplexe Abstraktion des Webframeworks verstehen muss, um die Features ausnutzen und Fehler nachverfolgen zu können.

Die Entscheidung für ein Action-based oder Component-based Webframework hängt also vom Workflow der Webanwendung ab. Während Komponenten sehr gut einsetzbar sind, wenn Wiederverwendung und komplexe Abläufe eine große Rolle spielen (z. B. bei einer großen Webanwendung einer Bank mit vielen ähnlichen Masken), eignet sich das Anfrage-/Antwortkonzept besonders für lineare Abläufe, z. B. für einen einfachen Onlinefragebogen.

Abb. 3: Vergleich des Action-based- und Component-based-Konzepts
Client-centric vs. Server-centric

Wichtig ist des Weiteren die Unterscheidung zwischen dem clientzentrischen und dem serverzentrischen Ansatz (Abb. 4). Beim clientzentrischen Ansatz wird die gesamte Oberfläche und Steuerungslogik beim Start auf den Client geladen. Dies ist insbesondere bei Anwendungen sinnvoll, die über einen längeren Zeitraum benutzt werden, da so in der Summe weniger Daten zwischen Client und Server ausgetauscht werden. Beispielsweise startet der Mitarbeiter in einer Bank die Anwendung zur Verwaltung von Kundendaten morgens und arbeitet den ganzen Tag mit derselben Oberfläche. Diese muss nicht jedes Mal neu geladen werden, wenn eine neue Seite aufgerufen wird, sondern ist sofort verfügbar. Beim Wechsel zu einem anderen Kunden müssen statt der gesamten HTML-Oberfläche nur noch die Kundendaten (z. B. im XML-Format) vom Server übertragen werden.

Beim serverzentrischen Ansatz hingegen wird die Darstellung der Oberfläche auf dem Server (z. B. durch den Aufruf einer Java-Methode) erstellt, an den Client übertragen und dann dort dargestellt (z. B. eine HTML-Seite, die Kundendaten enthält). In der oben genannten Bankanwendung müsste somit bei jedem Seitenwechsel (z. B. zur Auswahl eines anderen Kunden) neben den Kundendaten auch die HTML-Oberfläche jedes Mal erneut vom Server übertragen werden, wodurch die Ladezeiten spürbar länger werden. Der serverzentrische Ansatz ist sinnvoll, wenn die Steuerungslogik aus Sicherheitsgründen oder wegen sehr leistungsschwachen Clients nicht vom Server ausgelagert werden soll. Ein weiterer Anwendungsfall ist der Einsatz von Clients ohne Browser, da hier die technische Implementierung auf Clientseite nicht bekannt sein muss. Dies ermöglicht z. B. den Einsatz auf Mobiltelefonen ohne Browser, die nur Java ME unterstützen.

Weitere wichtige Begriffe aus dem Umfeld von Webanwendungen werden im Kasten „Kriterien unabhängig von der Auswahl eines Webframeworks“ beschrieben. Sie haben keinen direkten Einfluss auf die Auswahl eines Webframeworks, da ihre Eigenschaften nicht nur die Oberfläche, sondern die gesamte Anwendung betreffen.

Abb. 4: Vergleich des clientzentrischen und serverzentrischen Ansatzes
Kriterien unabhängig von der Auswahl eines Webframeworks

Die folgenden Kriterien betreffen die gesamte Anwendung und nicht nur die Auswahl des Webframeworks zur Realisierung der Oberfläche.

Plattformunabhängigkeit

Plattformunabhängigkeit bedeutet, dass die Applikation unabgängig von folgenden Faktoren ausgeführt werden kann:

  • Betriebssystem (z. B. Windows, Linux, Unix, Mac OS X)
  • Application-Server (z. B. WebSphere, JBoss)/Webcontainer (z. B. Tomcat, Jetty)
  • Webbrowser (z. B. Internet Explorer, Firefox, Safari, Chrome)
  • Datenbank (z. B. DB2, MySQL, „NoSQL“)
  • Programmiersprache (z. B. Java, Groovy, Scala)
Mehrkanalfähigkeit

Eine Webanwendung ist mehrkanalfähig, wenn sie über mehrere Kommunikationswege ausgeführt werden kann. Dabei ist ein großer Teil des entwickelten Codes für alle Kanäle nutzbar. Folgende Ziele werden erreicht:

  • Reduzierung der Entwicklungskosten
  • Schnellere Auslieferung von neuen Funktionen und/oder Kanälen
  • Bessere, einheitlichere Benutzbarkeit der unterschiedlichen Kanäle

Zu unterscheiden sind zwei Arten der Mehrkanalfähigkeit, die unabhängig voneinander in unterschiedlichen Kontexten betrachtet werden. Mehrkanalfähige Consumer-Anwendungen ermöglichen die Benutzung auf diversen Endgeräten wie Desktop, Laptop, Smartphone oder TV. Auf allen Endgeräten wird dieselbe Funktionalität angeboten. Die Darstellung und Benutzung ist ähnlich. Dabei treten in der Praxis allerdings einige Probleme auf, z. B. enorm unterschiedliche Displaygrößen, verschiedene Eingabemethoden oder die ausschließliche Unterstützung weniger Multimediaformate.

Bei Enterprise-Anwendungen bedeutet Mehrkanalfähigkeit die Wiederverwendung von Komponenten in verschiedenen Prozessen. Für jeden Kanal kann dann ein eigener Prozessablauf spezifiziert werden. Für diese Komponenten gelten besonders hohe Anforderungen an die Unabhängigkeit und Integrierbarkeit in verschiedene Prozesse.

Offlinefähigkeit

Offlinefähigkeit ermöglicht einer Webanwendung, auch ohne Internetverbindung funktionsfähig zu sein. Zur Realisierung sind zwei Möglichkeiten gegeben, die unabhängig von einem konkreten Webframework eingesetzt werden können.

JavaScript-Caching kann verwendet werden, sofern Daten nur kurzfristig auf Clientseite gespeichert werden müssen. Dabei werden die Daten im Arbeitsspeicher zwischengespeichert – nach einem Browserneustart oder Absturz des Systems sind die Daten daher verloren. In der Oberfläche können neue Daten auch eingegeben werden, wenn keine Internetverbindung vorhanden ist. Die Daten werden später mit dem Server synchronisiert, beispielsweise durch einen Button-Klick. Diese Lösung benötigt eher geringen Aufwand und wird durch JavaScript-Bibliotheken realisiert, z. B. durch jCache [3]. Ein möglicher Anwendungsfall sind Einstellungstests von Bewerbern, die Aufgaben über eine Weboberfläche bearbeiten.

Im Enterprise-Umfeld ist die JavaScript-Caching-Lösung allerdings oft nicht ausreichend. Gears (früher Google Gears) ermöglicht als Browser-Plug-in die Offlineverwendung von Webanwendungen. Dadurch können Daten bei fehlender Internetverbindung auch auf Clientseite persistiert werden. In Zukunft soll allerdings laut Google auf HTML5 gesetzt werden, deswegen wurde die Weiterentwicklung von Gears eingestellt. Der Support endet allerdings nicht, da bereits viele Webanwendungen Gears produktiv einsetzen [4]. HTML5 ist in den meisten Browsern noch nicht oder nur teilweise implementiert.

Architekturänderungen zur Realisierung von Offlinefähigkeit

Die Realisierung von Offlinefähigkeit erfordert ein Umdenken bei der Architektur, da neue Fragen entstehen, die bei klassischen „Online“-Webanwendungen nicht auftreten:

  • Welche Funktionalitäten sollen auch offline verfügbar sein?
  • Wie soll die Datenschicht auf Clientseite isoliert werden (z. B. durch eine lokale Datenbank)?
  • Soll das Wechseln zwischen Online- und Offlinemodus manuell oder automatisch erfolgen?
  • Wie und wann werden die Daten synchronisiert (z. B. manuell oder im Hintergrund)?

Ausführliche Erläuterungen zu diesen Fragestellungen sind unter [5] zu finden.

Frameworktypen

Webanwendungen existieren je nach Einsatzgebiet in verschiedenen Größen und beanspruchen dementsprechend auch unterschiedlichen Zeitaufwand zur Realisierung (Abb. 5). Für jede dieser Arten von Webanwendung gibt es geeignete Webframeworks. Je nach Frameworktyp unterscheiden sich sowohl die Entwicklung der Webanwendung als auch die Benutzung durch den Endanwender. Im Folgenden werden die unterschiedlichen Typen vorgestellt.

Abb. 5: Kategorisierung von Webframeworks
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.