Ajax im Einsatz: geschäftskritische Schnittstelle

Inhaltsverzeichnis

Zusammengesetzt aus den Anfangsbuchstaben des englischen "Asynchronous Javascript and XML", beschreibt Ajax ein Designkonzept, das die Interaktion zwischen Webclients und Servern auf neuartige Weise regelt. Im Gegensatz zu klassischen Webanwendungen, die die komplette Aufbereitung der Darstellung im Server erledigen, ermöglicht Ajax ein selektives Nachladen notwendiger Daten im Hintergrund. Im Ergebnis führt dies zu interaktiven und desktopähnlichen Webanwendungen, die den Nutzern mehr Komfort bieten sollen (siehe Ajax-Hintergrund).

Für Unternehmen ist der Ajax-Ansatz vor allem deshalb interessant, weil sie ihre Infrastruktur nicht sonderlich anpassen müssen. Im Gegensatz zu bisher bekannten Rich-Clients (Flash/Flex/Java) wird für die Ausführung der Client-Komponente keinerlei Plug-in oder Runtime im Browser benötigt.

In Firmen arbeiten teilweise Tausende von Mitarbeitern tagtäglich mit Webseiten und Anwendungen. Deren Oberflächen sind teilweise recht komplex oder weisen sogar sonderbare Prozessflüsse oder Bedienkonzepte auf. Und dabei gilt immer nur ein Grundsatz: Was nicht funktioniert, kostet genauso Geld wie verlorene oder falsche Ergebnisse. Und hier geht es im einfachen Fall nur um die Zeit der Mitarbeiter.

Software im Unternehmenseinsatz

Man stelle sich vor, dass nur 1000 Mitarbeiter fünf Minuten lang versuchen, ihren Urlaubsantrag auszufüllen, weil die dazugehörige Anwendung zu langsam reagiert oder Fehler enthält. Schnell gehen dem Betrieb zwei Wochen und mehr an Arbeitszeit verloren. Was im Kleinen fast nicht messbar ist, wird im Großen schnell zu einer kritischen Masse.

Was Unternehmensanwendungen darüber hinaus deutlich von den üblichen im Web unterscheidet, ist die Tatsache, dass es sich zumeist um vertrauliche Daten handelt. Angefangen bei Personaldaten bis hin zu produktionsrelevanten Informationen über neue Entwicklungen ist hier nahezu jede Schattierung und Abstufung denkbar.

Kundensicht statt Technik-Euphorie

Wenn Unternehmen Interesse an einer neuen Technik zeigen, blicken sie mit kritischen Augen darauf. Wer bewerten will, ob und wie ein neuer Ansatz im Kontext kritischer Softwareprodukten funktioniert, ist gut beraten, sich von der durchweg euphorischen Entwicklerseite auf die der Kunden ziehen zu lassen und zu versuchen, rational die Chancen zu bewerten. Ein komplettes Vorgehensmodell dafür soll an dieser Stelle nicht aufgezeigt werden. Anhand von Ajax lassen sich aber exemplarisch ein paar Punkte darstellen, die in Ansätzen eine Bewertung beziehungsweise Eignung nachvollziehbar machen.

Ein guter Einstieg in eine solche Betrachtung ist meist der Blick auf die vorhandene Infrastruktur. Dazu zählen eingesetzte Plattformen, Server und Umgebungen genauso wie der Blick auf die verfügbaren Clients. Nicht selten stolpert man in diesem Zusammenhang über Dinge, für die bisher keine Ajax-Implementierung existiert. Beispielhaft seien hier SAP-Techniken wie HTMLB oder WebDynpro angeführt. Bei den Clients kann man ebenso Überraschungen erleben. Einerseits zeichnen sich zentral gesteuerte Unternehmen durch heterogene Komponenten aus. Das bewahrt die Software aber nicht vor der Falle, dass teilweise nicht die neuesten Versionen von Internet Explorer, Firefox und Co. installiert sind. Hier ist es angeraten, genauer zu prüfen, für welche Versionsnummern das gewünschte Framework Unterstützung bietet.

Blickt man in Anwendungsbereiche wie Kiosksysteme oder Handhelds und Mobiles, mutiert die schöne, einheitliche Unternehmensinfrastruktur schnell zum Alptraum jeglichen Ajax-Frameworks. Ein umfassender Einsatz von Javascript auf den Clients überfordert ältere oder hardwareseitig schwächer ausgestattete Geräte schnell. Man sollte grundsätzlich im Hinterkopf behalten, dass Internetbrowser keine Hochgeschwindkeits-Javascript-Ausführungsumgebungen darstellen. Ebenfalls nicht unwichtig ist, dass sich durch das veränderte Anwendungsverhalten die Last auf den Servern deutlich verändert. Im Gegensatz zur gelegentlichen und seitenweisen Übermittlung von Clientanfragen löst eine Ajax-Anwendung häufiger viele kleinere Anfragen an den Server aus. Ein Servermechanismus, der sich bisher als hilfreich erwiesen hat (Request-zu-Thread-Zuordnung), sorgt dadurch bei umfangreicher Ajax-Verwendung für einen bis um den Faktor vier höheren Ressourcenbedarf. Will man das verhindern, muss man Vorkehrungen bei der serverseitigen Programmierung treffen.

Ist schließlich die erste Hürde genommen und hat man einen geeigneten Ansatz für die Infrastruktur gefunden, stellt sich schnell die Frage nach den Vorgaben rund um Softwarearchitektur und -entwicklung. Hier gilt besonderes Augenmerk der Schichtentrennung und Komponentenbildung sowie der Modellierung von Ajax-Funktionen. Mit dem Schritt in Richung der Rich Clients wächst die Verlockung, fachliche Funktionen auf dem Client und nicht mehr auf dem Server abzubilden. Gibt man ihr zu schnell nach, schafft man sich in den Projekten nahezu beliebig große Stolpersteine. Diese resultieren zumeist aus den Besonderheiten der clientseitigen Programmiersprache Javascript.