Klassisches Outfit
Neue Techniken landen nicht zwingend sofort in unternehmenskritischen Anwendungen. Ajax ist jedoch zu verlockend, um lange außen vor zu bleiben. Es ist allerdings noch weit von einer stabilen Technik für Unternehmensanwendungen entfernt.
- Markus Eisele
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 den Kasten „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.
Stolperstein Entwicklungswerkzeuge
Ohne werten zu wollen, kann die Programmierung in der aktuell verbreiteten Version 1.5 nicht gerade als optimal bezeichnet werden. Zumal es in Sachen Werkzeugunterstützung für die Entwickler schlecht aussieht. Angefangen bei mäßigen Entwicklungsumgebungen (Dreamweaver, Eclipse-Plug-ins) bis hin zur Werkzeugschlacht, die man beim Debugging von Javascript-Teilen auf sich nehmen muss. Vom HTTP-Sniffer bis zum speziellen Browser-Plug-in können da schnell mal mehr als drei verschiedene Dinge zum Einsatz kommen, um Fehler zu finden. Ist die Entwicklung so weit erfolgreich verlaufen, bleibt die Frage nach der Softwarequalität - ein entscheidendes Kriterium für Betrieb und Wartbarkeit von Anwendungen im Unternehmen.
Begibt man sich auf Internet-Suche, findet man durchaus Pattern- beziehungsweise Best-Practises-Ansätze für die Entwicklung mit Ajax und Javascript. Für Unternehmen, die im Rahmen ihres Entwicklungsprozesses Softwaremetriken, Nightly Builds oder ähnliches im Einsatz haben, ist Javascript-Entwicklung aber nicht messbar. Hier bleibt nur der direkte Blick in den Code. Ein müßiges Geschäft, das die Abnahme von Projekten deutlich verzögern kann.
Über ein ähnliches Problem stolpert man, wenn man über Tests im Ajax-Umfeld nachdenkt. Entwicklertests sind noch die kleinste Hürde, denn hier gibt es verschiedene Ansätze (etwa JSUnit). Wenn es um Last-, Performance- oder automatisierte Oberflächentests geht, kommt man schnell an die Grenzen der kommerziell im Einsatz befindlichen Werkzeuge. Das Capture & Replay-Aufzeichnen von Ajax-Anwendungen ist keinesfalls trivial und gelingt in Gänze leider nicht immer. Das liegt vor allem an der Tatsache, dass die etablierten Werkzeuge lediglich die tatsächlich an den Server gesendeten Requests aufzeichnen und wieder abspielen können. Was sich in der Ajax-Anwendung selber tut, bleibt diesen Werkzeugen verborgen. Hier muss man sich auf die Suche nach verfügbaren Alternativen begeben und den Abnahmetest entsprechend neu gestalten.
Ein letzter Punkt in dieser losen Folge von Herausforderungen sei das Thema Systemmanagement. Dahinter verstecken sich allerlei Techniken und Werkzeuge zur Überwachung von Anwendungen im Betrieb. Dazu gehört Performanceanalyse genauso wie Fehlerüberwachung und Verfügbarkeitsprüfung. Standardmäßig bieten die entsprechenden Werkzeuge Adapter für Plattformen und Produkte. Browser-Plug-ins finden sich darunter nicht. Geht es daher darum, eine gewichtige Ajax-Anwendung im Betrieb zu überwachen, muss ein Workaround her. Ob man die Fehler beziehungsweise Performance-Indikatoren per Servlet auf den Server schreibt oder andere Wege geht, bleibt jedem selbst überlassen. Bisher berücksichtigen weder die Systemmanagement-Produkte noch die verfügbaren Ajax-Implementierungen eine solche Anforderung.
Schnittstellendesign versus Benutzbarkeit
Wenn man schießlich die technischen Schwierigkeiten so weit im Griff hat, kann man sich dem Bereich widmen, der Ajax ursprünglich auf den Plan gebracht hat. User Interface Design und Usability sind schließlich die eigentlichen Treiber moderner Anwendungen. Auch hier gibt es Punkte, auf die man bei der Umsetzung einer Ajax-Anwendung achten muss. Vor allem, wenn ein Ajax-Ansatz für die Navigation innerhalb der Anwendung Verwendung findet, ist bedenkenswert, dass sich Javascript mit dem Konzept der Browser History und der Bookmarks nicht verträgt. Sollen Anwender von einem der beiden oder gar von beiden Konzepten Gebrauch machen können, muss man hier etwas tun. Ein Glück, dass viele verfügbare Frameworks solcherlei Stolpersteine schon behoben haben.
Viel schwieriger sind andere Aspekte, an die sich die Anwender bei Webanwendungen gewöhnt haben. Dazu gehört vor allem das Ausdrucken von Bildschirminhalten. Durch Ajax wird das papierlose Büro wieder zu einer Wunschvorstellung. Die Frameworks nehmen einem hier selten die Arbeit ab. Eine selbstgebaute Lösung ist deshalb erforderlich. Der bei Weitem schwierigste Teil verbirgt sich aber sicherlich in der Unmenge denkbarer Funktionen und Darstellungsformen, die einem das hintergründige Neuladen von Inhalten eröffnen. Schnell ist man hier dabei, neue Benutzerkonzepte zu entwickeln. Seitenteile erscheinen unvermittelt, wo man sie nicht erwartet, der Browser bewegt die Seite wild durch die Gegend oder ähnlich Schlimmes. Dass die Anwender mit solchen Funktionen nicht zurecht kommen, kann man sich gut vorstellen.
Grundsätzlich gilt deshalb der Leitspruch: Asynchron und im Hintergrund bedeutet nicht automatisch unsichtbar. Anwender sind Rückmeldungen von den Systemen gewohnt und haben ein Recht darauf zu wissen, dass in ihrem Sinne gerade gearbeitet wird. Schon ein kleiner „Bitte warten“-Balken wirkt da Wunder und ist schnell programmiert. Außerdem sollte man nicht unbedingt der Versuchung erliegen, den gesamten Bestand fertiger Widgets aus einem oder gar mehreren Frameworks in einer Anwendung einzusetzen. Weniger ist zumeist mehr. Nutzer kommen mit aufgeräumten und übersichtlichen Anwendungen viel besser zurecht als mit überladenen Wunderwerken. Spannend bleibt schließlich die Entwicklung barrierefreier Webapplikationen: Was auf klassischen Webseiten schon ein Riesenstolperstein ist, verschlimmert sich bei der konsequenten Verwendung von Javascript und Ajax. Bisher sind leider keinerlei standardisierte Ansätze in Sicht. Will man entsprechende Lösungen bereitstellen, müssen Entwickler weitgehend in die bestehenden Frameworks eingreifen.
Potenzieller Einsatz von Frameworks
Was mit Ajax im Kontext von Unternehmen zu beachten ist, ergibt, wie gesehen, eine beachtliche Liste. Da stellt sich die Frage, was man guten Gewissens mit diesbezüglichen Frameworks erreichen kann. Grundsätzlich ist die Verwendung etablierter Standards beziehungsweise eine stabile Produktintegration ein gangbarer Weg. Bei Enterprise Java (JEE) wird man hier im Umfeld der Java Server Faces (JSF) fündig. Microsoft verfolgt mit der .Net-Plattform unter dem Stichwort ASP.Net Ajax (früher Atlas genannt) eine ähnliche, komponentenorientierte Strategie. Vielfach findet sich außerdem in oberflächenlastigen Produkten (Portal, CMS et cetera) diverser Hersteller schon eine Ajax-Implementierung. Sind diese Wege keine Alternative, sollte man auf alle Fälle auf die serverseitige Generierung der Oberflächen und Ajax-Funktionen zurückgreifen.
Welches der vielen verfügbaren Frameworks zum Einsatz kommt, hängt von den konkreten Anforderungen ab. Vielleicht sollte man sich hier an einer breiten Unterstützung in der Entwickler-Community oder an bekannten Namen orientieren. Derzeit ist noch nicht abzusehen, ob und wie sich das Angebot konsolidieren wird. Den letzten möglichen Weg stellt die Verwendung integrierter Frameworks dar, die kommerziell wie als Open Source verfügbar sind. Hier seien beispielhaft die Rich Ajax Plattform von Eclipse und die Produktreihe Crossvision der Software AG genannt. Bei beiden unterliegt man in Bezug auf die einsetzbaren Widgets deutlichen Einschränkungen. Will man hier einen Webstyleguide für ein Unternehmen unterbringen, versteckt sich darin weiterer Aufwand. Nicht nur innerhalb, sondern vor allem abseits der vorgeschlagenen Wege ist es allgemein dringend anzuraten, sich an die schon verfügbaren Patterns und Best Practices zu halten. Ein guter Anfang sind bekannte Ajax-Webseiten oder die Java-Blueprints von Sun.
Fazit
Auch künftig dürfte der Wunsch zur verbesserten Nutzerinteraktion im Webumfeld wichtig für Innovationen bei Oberflächentechniken bleiben. Dabei stellt Ajax sicherlich noch nicht das Ende der Entwicklung dar. Standardisierungsgremien überlegen weiterhin, wie die Zukunft des Webs aussehen könnte. Beim W3C heißen die „Verdächtigen“ XHTML 2, XFrames und XForms - von RDF ganz abgesehen. Ebenfalls profitieren kann Ajax vom anhaltenden Trend zu einer serviceorientierten Architektur (SOA). Als ideale Ergänzung zu bisher eher oberflächenlosen Diensten unterschiedlicher Güte kann man vor allem im Umfeld der SOA-Infrastrukturprodukte von einer zunehmenden Unterstützung ausgehen.
Mit zunehmender Verbreitung und Akzeptanz dürfte außerdem die Menge der Entwicklungswerkzeuge wachsen. Und mit mehr Erfahrung in Projekten ist mit deutlich besseren Methoden zur Qualitätssicherung zu rechnen. Schließlich haben Entwickler es aber selbst in der Hand, was aus Ajax in Zukunft wird. Es gab in der Vergangenheit schon einige teilweise brillante Ansätze zur Verbesserung der Nutzbarkeit von Webanwendungen (Flash, Java Applets, Webstart et cetera), die zwar technisch nicht direkt mit Ajax vergleichbar sind, aber genau dort scheitern, wo Entwickler nicht in der Lage sind, nutzerzentriertes Anwendungsdesign umzusetzen.
Markus Eisele
arbeitet im Bereich Software-Technologie im Center of Competence IT-Architecture der msg systems ag in München.
Literatur
[1] Stefan Mintert; Webentwicklung; Zwei Helden; Ajax: die nächste Generation der Web-Anwendungen; iX 11/2005, S. 56
[2] Christoph Leisegang, Stefan Mintert, Bastian Spanneberg; Web 2.0; Äpfel und Birnen; Fünf clientseitige Ajax-Frameworks; iX 8/2006, S. 54
[3] Christoph Leisegang, Stefan Mintert, Bastian Spanneberg; Web 2.0; Die Nullnummern; Fünf serverseitige Ajax-Frameworks; iX 9/2006, S. 66
iX-TRACT
- Wer im Unternehmen Webanwendungen betreibt, kann sie durch Einbeziehung von Ajax und Javascript erheblich komfortabler gestalten.
- Zu überwindende Stolpersteine reichen jedoch von der Browser History über Testmöglichkeiten bis zu Druckoptionen.
- Vorhandene Frameworks bieten zwar Unterstützung, aber nicht die Lösung aller Schwierigkeiten.
