Es gab Zeiten, da wurden komplexe Softwaresysteme in der Regel über grün-schwarze Terminals bedient. Diese waren in ihren Darstellungs- und Interaktionsfähigkeiten doch recht eingeschränkt - somit feierten ab Ende der 80er Jahre des vorigen Jahrhunderts grafische Benutzeroberflächen ihren Siegeszug: schick aussehend und "interaktiver". Die Programmierung wurde durch Umgebungen à la Visual Basic oder Delphi (und anderen!) vereinfacht - und wenn man schon einmal die Oberfläche entwickelte, dann wurden große Teile der Anwendungslogik gleich direkt druntergehängt. Aus dem "Thin Client"-Konzept der Host-Umgebungen wurde das "Fat Client"-Konzept Desktop-basierter Anwendungen.

Die Gegenwart
Es scheint, als wiederhole sich die Geschichte mal wieder – wenn auch mit anderen Buzzwords und etwas anderen Rahmenbedingungen: Heute sind es die klassischen HTML-Seiten, die dem Benutzer nicht das wiedergeben, was er von einer modernen Benutzerschnittstelle erwartet. Und heute sind es Ajax-basierte Seiten, die schick und interaktiv sind. Die "Freigabe", innerhalb des Frontends entwickeln zu können, führt zu einer enormen Freisetzung von Kreativität in der UI-Entwicklung! Ketzerisch gesagt: So wie man in den 90er Jahren mit Visual Basic vor irgendeiner ODBC-Datenbank entwickelte, so begint man heute, mit JavaScript vor irgendwelchen SOAP-Schnittstellen zu programmieren.

Die Renaissance des Fat Client?
Also eines Clients, der nicht nur für die Optik, das User Interface zuständig ist, sondern sehr viel Anwendungslogik mitbringt? – Ich fürchte: ja. Oder besser gesagt: Getrieben durch den Ajax-UI-Hype werden viele Systeme entstehen, in denen der Client viel zu "fat" sein wird – weil es zu einfach ist, unterhalb der Oberfläche noch hier und da ein paar Javasript-Routinen einzubauen, die dann Logik ausführen, die im Client eigentlich nichts zu suchen hat.

Nehmen wir das Beispiel der Erfassung einer Bestellung: Es wäre doch schön und "interaktiv", wenn direkt bei der Eingabe von Bestellpositionen der Gesamtpreis der Bestellung immer gleich mitberechnet wird. - Also: Mit ein wenig JavaScript und einem SOAP Call zum Server holt man sich den Artikelstamm mit Preisdaten in den Browser, führt eine Multiplikation mit der Bestellmenge aus und rechnet den Preis aller Bestellpositionen zusammmen. Na ja, da gibt es noch kundenspezifische Rabatte ab einer bestimmten Bestellhöhe: Also auch den Kundenstamm per SOAP Call holen und reinrechnen. Und nun noch Fracht- und Lieferzuschläge reinrechnen. Und, und, und ...

... und ganz schnell wurde aus einem "interaktiven Frontend" ein komplexes, in JavaScript codiertes Anwendungsprogramm, das im Browser abläuft! - Und alle aus den 90er Jahren bekannten Probleme holen uns ein: konkurrierende Anwendungslogik zwischen dem Client und dem Server sowie ein heftiger Datenaustausch zwischen Client (Browser) und Server mit einer schwer zu kontrollierenden Lauffähigkeit unter WAN-Bedingungen, in denen die Latenzzeit eines Roundtrips nicht im Millisekundenbereich liegt.

Die Architektur im Zentrum

• Anbieter von Ajax Control Libraries überlassen die Architekturdefinition komplett dem nutzenden Entwickler. Motto: Baue Dein UI mithilfe der zur Verfügung gestellten Controls und binde Server-seitige Logik über SOAP Calls ein – that’s it!
• Andere Anbieter binden ihre Controls direkt an eine Server-seitige Verarbeitung: Eine Seite, die über Ajax Controls zusammengebaut wird, hat ihre Server-seitige Repräsentation, z.B. in Form einer Java-Klasse, die quasi das "Nettoabbild" der Benutzeroberfläche repräsentiert: ein Feld in der Seite wird repräsentiert durch ein Property in der Java Klasse, ein Button auf der Seite durch eine Methode in der Klasse etc. Zwischen der Browser-Seitenverarbeitung und der Server-Anwendungsverarbeitung gibt es eine geblockte Kommunikation, d.h., die Seite sammelt Datenänderungen durch Benutzereingaben auf und schickt diese zu bestimmten Synchronisationszeitpunkten zu ihrer Server-seitigen Repräsentation, in der dann die eigentlich Verarbeitung abläuft. – Durch diese Art der Trennung zwischen Browser und Server, verbleibt die Anwendungslogik komplett auf der Server-Seite, der Browser-Client dient alleine dem Zweck der optischen Aufbereitung und der Eingabeverarbeitung.

Welchen Weg Sie auch immer einschlagen mögen: bei aller Ajax-Euphorie empfiehlt sich ein kurzes Innehalten, ansonsten sind auch Sie Teil einer neuen, ungewollten "Fat Client"-Generation.

Björn Müller leitet bei der Software AG den Bereich "XMLi User Interfaces", der u.a. eine AJAX-basierte Frontend-Lösung für interaktive Unternehmensanwendungen verantwortet. Mit seiner Firma Casabac (heute Teil der Software AG) war Björn Müller einer der frühen AJAX-Pioniere in Deutschland.