Reiche Kunden

Inhaltsverzeichnis

HTML hat den Siegeszug angetreten. Der ursprünglicher Einsatzbereich der Hypertext Markup Language - die Präsentation vernetzter Dokumente - wurde mittlerweile stark erweitert, bis hin zur interaktiven Präsentation von Multimedia-Inhalten oder den grafischen Benutzerschnittstellen (GUI) von Web-Applikationen. Rich Clients bereichern Web-Auftritte durch visuelle Effekte [1, 2] und können zusätzlich die Interaktionsmöglichkeiten verbessern.

Web-Applikationen erfreuen sich großer Beliebtheit, weil sie sich leicht verteilen lassen. Der Browser ist generisch, das heißt, unabhängig von der Applikation, die er anzeigt. Das macht ihn vom Konzept her schlank. Zudem hat der Entwickler so gut wie keinen Verteilungsaufwand. Die jeweils aktuelle Version der Web-Anwendungen steht jedem Benutzer sofort zur Verfügung, und er kann von fast überall aus darauf zugreifen.

Trotz aller Verbesserungen bei der automatischen Verteilung und Aktualisierung von Desktop-Applikationen bleibt diese wichtige Eigenschaft der Web-Anwendungen unerreicht. Selbst innerhalb von Unternehmen ist sie mittlerweile so wichtig, dass Entwickler auch für diesen an sich geschlossenen Bereich und darin sogar für Benutzergruppen Applikationen mit der Thin-Client-Architektur bauen.

Grenzen der Thin-Client-Architektur

Leider ist die Freude nicht ungetrübt. Schlanke HTML-Applikationen stoßen gerade bei Anwendungen für Experten an architekturbedingte Grenzen. Wer häufig mit Web-Anwendungen arbeitet, stellt höhere Anforderungen an die Interaktionsmöglichkeiten. Um diesen Bedarf zu erfüllen, benötigen Programmierer leistungsfähige Steuerungselemente und durchbrechen oft unbewusst durch applikationsspezifischen Code auf dem Client die Thin-Client-Architektur.

Javascript, Applets, Macromedias Flex, ActiveX et cetera verwenden zwar jeweils eine applikationsunabhängige Ausführungsmaschine, senden aber zur Laufzeit programmspezifischen Code zum Client, der ihn lokal ausführt (Code Shipping). Damit klassifiziert sich dieser Ansatz als leistungsfähig, aber schwergewichtig (Rich Fat Client).

Ergänzungskandidaten, um Thin Clients mit mehr Funktionen zu versehen, sind von Desktop-Applikationen bekannte Widgets wie Menüleisten mit Untermenüs, Werkzeugleisten, modale Dialoge oder Baumdarstellungen. Gleiches gilt für das Interaktionsverhalten. Schnelle und einfache Benutzbarkeit verlangt unter anderem nach Unterstützung für Tastaturkürzel, Kontextmenüs oder einer Drag&Drop-Funktion.

HTML-Applikationen unterstützen zwei Arten der Interaktion: das Verfolgen von Links und das Ausfüllen von Formularen. Der Benutzer bleibt in beiden Fällen an das serielle Anfrage-Antwort-Konzept gebunden, das jedoch für intensive Datenerfassung oder die direkte Modellierung komplexer Sachverhalte nicht ausreichend ist. Im ersten Fall will der Benutzer seine Eingaben asynchron absetzen, im zweiten den Effekt seiner Manipulation ohne Verzögerung sehen, etwa bei einer Tabellenkalkulation.

Unterschiede bestehen auch in den Interaktionsmöglichkeiten der einzelnen Widgets. HTML kann eine Tabelle zwar darstellen, wenn es aber darum geht, einzelne Zeilen/Spalten/Zellen zu selektieren und auf der Selektion zu operieren, ist ein Mehrwert-Widget leichter zu bedienen.

Ein weiteres Indiz für den Bedarf an solchen Softwarebausteinen ist die zunehmende Verbreitung von Fat Clients, die lokal installiert sind und ihre Daten etwa per Web Services beziehen. Beispiele dafür sind die Verbreitung der RSS Reader (RDF Site Summary) und die Entwicklung der Rich Client Platform (RCP) in Eclipse.

Einfache Konzepte sind gefragt

Neben diesem augenfälligen Bedarf an komplexen Benutzerschnittstellen und dem Siegeszug der schlanken Architekturen gibt es eine weniger offensichtliche Eigenschaft der Rich-Thin-Client-Architekturen: das einheitliche Programmiermodell. Entwickler von Web-Applikationen müssen sich heute mit einer Vielzahl von Sprachen, Techniken und Paradigmen auseinander setzen. Angenehmer - und wirtschaftlicher - ist es, sich zumindest für die Benutzerschnittstelle auf ein einfaches, klares Konzept verlassen zu können.

Der erste Schritt zu dessen Verwirklichung ist ein generischer, also applikationsunabhängiger Client, der in der Lage ist, alle Mehrwert-Widgets anzuzeigen und zu steuern. Weil sämtliche applikationsspezifische Logik auf dem Server residiert, muss der Client die Beschreibung der Widgets von dort holen.

Eins der ersten veröffentlichten Entwurfsmuster für die Softwareentwicklung ist das Half-Object Plus Protocol (HOPP). Es erlaubt die Verteilung eines Objekts in zwei Prozessräume, indem es das Objekt in zwei Halb-Objekte trennt, die miteinander kommunizieren [3]. Bei der Realisierung eines Rich Thin Clients kann die Umsetzung dieses Pattern so aussehen, dass ein serverseitiges Programm ein Anzeigeobjekt - etwa einen Button - erstellt und manipuliert, während der Client die Darstellung übernimmt.

Abbildung 1 verdeutlicht das Prinzip der Halb-Objekte in der Rich-Thin-Client-Architektur am Beispiel eines Button: Der applikationsspezifische Code (1) liegt auf dem Server in der Applikationsschicht. Er spricht die API der serverseitigen Hälfte des Buttons (2) an, die in der Infrastrukturschicht des Servers realisiert ist und dafür sorgt, dass sein Zustand an den Client übermittelt wird (3) - im Beispiel unter anderem die Tatsache, dass der Server über Klick-Aktionen Mitteilung erhalten soll.

Die Infrastruktur des Client erzeugt die andere Hälfte des Buttons, hier als Swing JButton (4), setzt dessen Zustand, merkt sich den Notifikationswunsch und stellt den Button dar. Klickt der Benutzer auf den Button (4), findet ein Server-Roundtrip zur Behandlung dieses Ereignisses statt: Der Client registriert den Klick (5) und schickt einen Request zum Server (6), der ihn an die Applikation weiterleitet, die die zugehörige Funktion ausführt (7). Analog zum Anfang (2-3-8) schickt der Server den neuen Zustand an den Client, der ihn aktualisiert darstellt.

Dieser Ansatz weist folgende Besonderheiten auf:

• Es liegt kein anwendungsspezifischer Code in der Applikationsschicht des Clients.
• Die Anwendung überträgt nur das Minimum der notwendigen Zustandsinformation, nicht wie bei HTML stets die vollständige Seite.

Was für einen Button funktioniert, lässt sich für beliebige andere Widgets einsetzen: Formularfelder, Slider, Frames, Windows, Dialoge, Fortschrittsbalken, Tabellen, Bäume und Layout-Komponenten.

Das heißt, der Entwickler kann auf dem Server eine umfangreiche Widget-Bibliothek nutzen und braucht sich nicht um die Verteilung zum Client zu kümmern. Im Gegensatz zu Display Engines wie X11 oder Microsofts Terminal Server muss eine auf HOPP basierende Anwendung nicht jede Mausbewegung übers Netz schicken. Die Datenübertragung findet nur dann statt, wenn es nötig ist: zum initialen Aufbau und bei der Auslösung eines registrierten Events.

Anders als Fat Clients überträgt ein solcher Rich Client keinen applikationsspezifischen Code und übermittelt nur die unbedingt erforderlichen Daten - beispielsweise den angezeigten Ausschnitt einer großen Tabelle. Letzteres können Fat Clients unter anderem dann nicht tun, wenn die Tabelle sortierbar ist. Wer die Sortierlogik auf den Client verteilt, muss alle Daten dorthin übermitteln. Ohne applikationsabhängige Logik auf dem Client entfällt zudem das von Fat Clients bekannte Problem, die Client- und Serverversionen kompatibel halten zu müssen.

Programmierer können Technik wählen

Die Rich-Client-Architektur erlaubt eine Vielzahl denkbarer Implementierungen mit unterschiedlichen Techniken. Der Programmierer muss sich entscheiden, welche API er serverseitig für die Widgets haben möchte, welche Techniken er dort für die Implementierung der Geschäftslogik nutzen will und welche auf dem Client die Darstellung realisieren sollen. Weitere Unterschiede bestehen in der Wahl des Übertragungsprotokolls. Eine Implementierung mit Ruby auf dem Server und GTK auf dem Client ist genauso denkbar wie eine reine Java-Lösung mit serverseitigem J2EE und clientseitigem Swing.

Gerade für die Realisierung des applikationsunabhängigen Clients gibt es viele Optionen. Wegen der transparenten Verteilung bieten sich sowohl Applets, Macromedias Flash-Plug-in, Javascript- oder ActiveX-Programme als auch .Net-Anwendungen als native Standalone-Lösung an.

Wichtiger Unterschied zu den Fat Clients: Der zur lokalen Ausführung zum Client übertragene Code ist für alle Applikationen gleich. Bei der Auswahl der eingesetzten Technik muss man bei jeder dieser Optionen ihre speziellen Randbedingungen bezüglich der Verfügbarkeit auf verschiedenen Plattformen, des Funktionsumfanges und nicht zuletzt der Sicherheit beachten.

Java-basierte Rich-Client-Plattformen
AltioLive	www.altio.com
AppProjector	www.asperon.com
Canoos ULC	www.canoo.com/ulc/
Droplets	www.droplets.com
RSWT	rswt.sourceforge.net
Thinlets	www.thinlet.com

Vorteile für die agile Softwareentwicklung

Zwar ist die Implementierung aller Halbobjekte und des Übertragungsprotokolls nicht besonders kompliziert, bedeutet aber eine erhebliche Fleißarbeit. Schwierig sind vor allem die für den Anwendungsentwickler transparenten Optimierungen zur Reduktion der Bandbreite und der Latenzzeiten. Die gute Nachricht ist, dass andere diese Arbeit bereits geleistet haben und verschiedene Varianten verfügbar sind. Der Kasten unten links führt einige Java-basierte Produkte auf, die sich unterschiedlich stark als Rich Thin Client qualifizieren. Einige von ihnen bieten Unterstützung für das Testen, Debugging, die interaktive GUI-Programmierung und unterschiedliche Deployment-Szenarien. Hilfe bei der Entwicklung leisten auch diverse Beispiele und vorgefertigte Teil-Lösungen.

Für die Anhänger agiler Softwareentwicklung bringt die Rich-Thin-Client-Architektur einen zusätzlichen Vorteil. Agile Entwicklung erfordert die Möglichkeit, den Benutzer häufig mit neuen Versionen der Software bedienen zu können. Rich Thin Clients erlauben eine beliebig häufige Verteilung neuer Versionen ohne Abstriche hinsichtlich der Benutzerfreundlichkeit.

Dierk König
ist XP-Coach bei der Canoo Engineering AG, Basel.

Literatur

[1] Kai König; Aus dem Hut; Macromedias Flex: J2EE-basierte Flash-Entwicklung; iX 3/04, S. 60

[2] Kai König, Regina Müller; Zuschlag über Doppelklick; Entwicklung von Webkomponenten mit Flash Remoting; iX 5/03, S. 124

[3] Gérard Meszaros; Pattern: Half-object+Protocol; in James O. Coplien, Douglas C. Schmidt; Pattern Languages of Program Design; Addison-Wesley, Reading 1995; ISBN: 0201607344; S. 129

Mehr Infos

iX-TRACT

• Web-Applikationen sind stark verbreitet, vor allem weil sie sich leicht verteilen lassen.
• Während reine HTML-Seiten im Hinblick auf die Benutzerschnittstelle kaum Komfort bieten, haben viele andere Lösungen den Nachteil, dass applikationsspezifischer Code auf dem Client liegt.
• Das Konzept der Rich Thin Clients dagegen sieht vor, dass der Server nur notwendige Zustandsinformationen an den Client überträgt.
• Eine Thin-Client-Architektur ist plattformunabhängig, flexibel und erlaubt den Einsatz unterschiedlicher Techniken.

Zwei weitere Artikel zu Rich Thin Clients mit Eclipse sowie einem Java-Framework finden Sie in der aktuellen Printausgabe. (ka)