Webframeworks – eine Kategorisierung

Fat Client

Fat Clients besitzen die klassische Optik von Java-Anwendungen und verwenden Textfelder, Buttons, Checkboxen usw. Neben der Oberfläche wird auch die eigentliche Verarbeitung der Geschäftslogik auf dem Client vollzogen, nur die Daten werden auf dem Server gespeichert. Fat Clients werden beispielsweise mit Swing oder Eclipse RCP realisiert – und nicht mit Webframeworks. Der Begriff dient daher in diesem Artikel nur zur Abgrenzung.

Klassische Webanwendung

Eine klassische Webanwendung besitzt in der Regel eine Multi-Page-Struktur sowie die von Beginn der Internetära an bekannte HTML-Oberfläche. Die Anwendung wird serverzentrisch realisiert. Die gesamte Geschäftslogik wird über Anfrage-/Antwortkommunikation durch den Server verarbeitet, wobei die Webanwendung nur die Oberfläche (d. h. das vom Server empfangene HTML) darstellt. Elementare, vom Desktop bekannte Features wie Drag and Drop oder der Zugriff auf die Festplatte und Betriebssystemfunktionen fehlen in klassischen Webanwendungen. Die Konsequenz ist mangelnde Benutzerfreundlichkeit. Immerhin muss durch den Einsatz von grundsätzlichen Ajax-Funktionen nur noch der aktualisierte Bereich der Seite neu geladen werden. Die gute Benutzbarkeit einer Desktopanwendung wird dadurch allerdings nicht erreicht. Klassische Webanwendungen benötigen kein Plug-in und laufen in jedem Browser. Allerdings entstehen insbesondere beim Einsatz von Ajax oft Kompatibilitätsprobleme zwischen verschiedenen Browsern.

Rich Internet Applications (RIA)

Bei einer RIA läuft die Oberfläche vollständig auf dem Client ab. Durch die Verwendung des clientzentrischen Konzepts wird bei diesem Frameworktyp stärker zwischen Oberflächendarstellung und Daten getrennt. Eine RIA hat eine Single-Page-Struktur und verfügt über viele Eigenschaften von Desktopanwendungen wie Offlinefähigkeit, Drag and Drop oder Festplattenzugriff. Zudem ermöglichen RIAs die Realisierung von hohen Anforderungen an die Oberfläche, beispielsweise durch Animationen, Effekte oder Multimediafeatures. Daher wird statt Java auch eine neue Skriptsprache zur Entwicklung benötigt. Die Webanwendung ist meistens nicht mehr als solche zu erkennen und kann in der Regel auch außerhalb des Browsers gestartet werden. Aufgrund dieser revolutionären Darstellung entstehen aber auch einige Nachteile für Entwickler und Anwender:

  • Die gesamte Webanwendung muss beim ersten Start sowie bei jeder neuen Version vollständig heruntergeladen werden.
  • Auf dem Client muss ein Plug-in des jeweiligen Webframeworks installiert sein, wodurch als Nebeneffekt auch Kompatibilitätsprobleme zwischen verschiedenen Browsern eliminiert werden.
  • Plattformneutralität geht verloren, falls das Plug-in nicht für alle gewünschten Systeme verfügbar ist.
  • Typische Browserfeatures wie Lesezeichen oder Vorwärts-/Rückwärtsnavigation fehlen oft.
  • Der (Java-)Entwickler muss eine neue Programmiersprache lernen.
Rich Client

Der Rich Client vermischt die Eigenschaften der beiden bereits genannten Architekturtypen. Die Oberfläche wird beim Start immer noch großteils oder vollständig auf den Client geladen, die Optik aber entspricht der einer klassischen Webanwendung. Das Ziel ist daher im Gegensatz zu RIAs nicht die Neuausrichtung der Oberflächendarstellung von Webanwendungen, sondern die Verbesserung bei der Nutzung der bereits verbreiteten und akzeptierten Darstellung. Die Oberfläche wird entweder clientzentrisch oder serverzentrisch realisiert und besitzt meist eine Single-Page-Struktur. Auf Clientseite wird im Gegensatz zu RIAs kein Plug-in benötigt, auch das Lernen einer speziellen Skriptsprache ist nicht notwendig. Dennoch können einige RIA-Features wie Drag and Drop mittlerweile relativ einfach mit Ajax-Komponenten realisiert werden.

CRUD-Client

CRUD ist das Akronym für „Create, Read, Update and Delete“. CRUD-Clients ermöglichen in erster Linie das Anzeigen, Suchen und Bearbeiten von Datensätzen und sind daher sehr gut zur Verwaltung von Daten geeignet. Die Optik entspricht dabei einer klassischen Webanwendung. Typische Browserfeatures wie Lesezeichen oder Vorwärts- und Rückwärtsnavigation sind zumeist von Grund auf in einer Multi-Page-Struktur verfügbar. Im Gegensatz zu den zuvor beschriebenen Frameworktypen wird mit diesen Webframeworks nicht nur die Oberfläche erschaffen, sondern die gesamte Anwendung (d. h. die übliche Drei-Schichten-Architektur mit Oberfläche, Geschäftslogik und Datenhaltung) auf einmal realisiert. Die Webanwendung ist dabei serverzentrisch. CRUD-Frameworks besitzen folgende Eigenschaften, wodurch sehr schnell Ergebnisse erzielt werden können:

  • Convention over Configuration: Konfiguration ist nur notwendig, falls die Default-Konfiguration nicht ausreichend ist.
  • Code-Generation: Durch die Erstellung des Models für die Persistierung in der Datenbank werden auch Anwendungslogik und Oberfläche für dieses Model sofort mit erzeugt.
  • Objekt-UI-Mapping: Für Attribute des Models wird automatisch in der Oberfläche die passende Darstellung angezeigt, z. B. für den Datentyp java.util.Date ein Kalender-Widget.
  • Moderne Sprache: Oft basieren Frameworks für CRUD-Clients auf „modernen“, auf JVM basierenden Programmiersprachen, um hohe Effektivität zu erreichen und die Menge des Quellcodes zu reduzieren.

Zusätzlich zu den vorgestellten Frameworktypen werden manchmal auch Portale eingesetzt (Kasten: „Portal“).

Portal

Ein Portal kann zusätzlich zu einem Webframework eingesetzt werden. Unabhängig vom ausgewählten Produkt entsteht dadurch ein erheblicher Mehraufwand und höhere Komplexität. Portale stellen Informationen verschiedener Anwendungen (Standardsoftware, Individualsysteme, Webseiten, externe Systeme) auf eine einheitliche Art dar und werden eingesetzt, um Informationen, Personen und Prozesse über organisatorische Grenzen hinweg in Unternehmen zu integrieren. Portale werden auf einem Portalserver deployt. Neben Webframeworks zur Entwicklung der eigentlichen Oberflächen von Anwendungen wird eine Portalsoftware benötigt. Dabei konkurrieren sowohl kommerzielle Produkte wie IBM-WebSphere-Portal und Open-Source-Produkte wie Liferay-Portal um die Kunden.

Portlets

Portlets sind der De-facto-Standard für die Realisierung eines Portals und sind in den JSRs 168 und 286 spezifiziert. Sie definieren beliebig kombinierbare Komponenten einer Benutzeroberfläche, die von dem Portalserver angezeigt und verwaltet werden. Jede Anwendung, die im Portal dargestellt werden soll, wird in ein Portlet integriert. Die Portlets können auch untereinander Informationen austauschen und dadurch auf Zustände anderer Anwendungen entsprechend reagieren. Detaillierte Informationen zum Portlet-Standard gibt es unter [6].

Vorteile eines Portals

Wegen des erheblichen Mehraufwands beim Einsatz eines Portals im Gegensatz zur Entwicklung von einzelnen Webanwendungen ist die Einführung insbesondere bei großen Anwendungslandschaften sinnvoll. Dies bietet folgende Vorteile:

  • Integration: Die Funktionen und Daten von Anwendungen können in andere Komponenten integriert werden.
  • Zusammenarbeit: Eine Aktion in einer Anwendung kann Änderungen des Zustands von anderen Anwendungen hervorrufen.
  • Single-Sign-on: Ein Benutzer muss sich nur einmal anmelden und kann dann alle integrierten Anwendungen, für die er die Zugriffsrechte besitzt, verwenden.
  • Personalisierung: Die Darstellung der Oberfläche kann durch den Benutzer oder das System individuell angepasst werden. Der Benutzer kann das Look and Feel seinen persönlichen Wünschen anpassen, beispielsweise bezüglich Inhalt, Struktur oder grafischer Darstellung. Das System kann basierend auf Metadaten den am besten zum Benutzer passenden Inhalt, z. B. passende Newsmeldungen oder die am häufigsten genutzten Anwendungen, anzeigen.
Technologietyp

Die verschiedenen Webframeworks unterscheiden sich in den eingesetzten Technologien, mit denen Webanwendungen realisiert werden:

  • Java: Die Programmierung erfolgt nahezu ausschließlich in Java. Die Oberfläche (HTML und JavaScript) wird automatisch erzeugt, Konfiguration mit XML ist nur minimal oder gar nicht notwendig.
  • Mixed Language: Die Programmierung erfolgt durch Java und HTML, die Konfiguration durch XML. JavaScript wird z. B. durch frameworkeigene Elemente (z. B. Tag Libraries) automatisch erzeugt.
  • „Moderne“ JVM-Sprache: Die Programmierung erfolgt mit einer „no-Java“-Programmiersprache wie Groovy oder Scala, die in Java-Bytecode übersetzt wird. Dadurch ist der Zugriff auf die Java-Bibliotheken ohne Umwege möglich.
  • Skriptsprache: Die Programmierung erfolgt vollständig in einer Skriptsprache, die explizit für die Erstellung von RIAs entwickelt wurde. Dadurch wird u. a. das bidirektionale Binding zwischen Client und Server stark vereinfacht. Zugriff auf die Java-Bibliotheken ist meist nur über Umwege möglich.
Kommentare

Schreibe einen Kommentar

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