Ajax ist nicht die einzige Möglichkeit, sogenannte «Rich Web Applications» zu entwickeln. Die gängigste Alternative zur Entwicklung hochinteraktiver Anwendungen im Web-Browser ist die Flash-Technologie von Adobe, und mit User-Interface-Standards wie XAML und XUL lassen sich ebenfalls ansprechende Oberflächen erstellen. Für Entwicklungen, die in mehr oder weniger allen Browsern anstandslos laufen und nach dem Motto «Zero Footprint» völlig auf Plug-ins oder andere clientseitige Zusatzsoftware verzichten sollen, kommt man um Ajax aber nicht herum.
Einfach, aber kompliziert
Das Prinzip von «Asynchronous Javascript and XML», wofür die Abkürzung Ajax eigentlich steht, klingt einfach: Damit nicht bei jeder Änderung an den angezeigten Daten und Kontrollelementen die gesamte Webseite neu geladen werden muss, nutzt der Ajax-Programmierer eine geschickte Technologiemischung aus HTTP-Kommunikation, JavaScript, DHTML und einem Datenaustauschformat. Dazu greift die Webseite auf eine in JavaScript formulierte, clientseitige «Ajax-Engine» zurück, die für das Absetzen der passenden HTTP-Requests, die Verarbeitung der vom Server zurückgelieferten Daten und ihrer Weiterleitung an die passenden DHTML-Objekte auf der Seite sorgt.
Auf der elementarsten Ebene benötigt der Ajax-Programmierer somit Kenntnisse einer erklecklichen Anzahl unterschiedlicher Techniken:
- Ein Mechanismus zur asynchronen Kommunikation zwischen Browser und Webserver: Das XMLHttpRequest-Objekt.
- Eine vom Browser unterstützte Sprache für Aufbau und Analyse der Meldungen zum und vom Webserver und für passende Eingriffe in den DOM-Baum des Browser: JavaScript.
- Eine Markup-Sprache zur Festlegung der Grundstruktur der Seite: DHTML.
- Ein Datenformat für die Meldungen, die zwischen Browser und Server ausgetauscht werden: Im strengen Sinn der Abkürzung Ajax wird dazu XML eingesetzt, zunehmend kommt aber das einfacher verständliche Format JSON (JavaScript Object Notation) in Mode.
Allein die Kombination der verschiedenen Technologien und Protokolle macht deutlich, dass Ajax im Detail sehr rasch ziemlich kompliziert werden kann. Es ist wie generell bei der Programmierung: Das Idiotenbeispiel «Hello World» ist schnell verstanden und ebenso schnell umgesetzt, hinter einer nutzbringenden Real-World-Anwendung steckt aber einiges mehr an Know-how und Entwicklungsaufwand.
Ein Webdesigner, der ein bisschen JavaScript beherrscht und per DHTML einfache Effekte gestalten kann, ist mit der Ajax-Programmierung völlig überfordert, und auch der gestandene Webentwickler beschäftigt sich lieber mit der Funktionalität seiner Anwendung als mit den Low-Level-Details von HTTP, XML und DOM. Dies gilt umso mehr, als bei Webanwendungen auch die nach wie vor uneinheitliche Implementation der verschiedenen Browser punkto DOM, JavaScript und Rendering der HTML-Elemente berücksichtigt werden muss.
Populäre Ajax-Frameworks
Frameworks, Toolkits
und Libraries
Vor allem die Open-Source-Szene, aber auch eine Reihe kommerzieller Softwareanbieter unterstützen die Entwicklung Browser-basierter Anwendungen mit attraktiver Benutzerschnittstelle durch sogenannte Ajax-Frameworks, die dem Programmierer die Knochenarbeit abnehmen sollen. Unter ajaxpatterns.org findet sich eine Liste, die aktuell über 150 Frameworks aufzählt. Rund ein Viertel der Teilnehmer hat bei einer kürzlichen Umfrage zum Thema auf surveymonkey.com zwar angegeben, auf die Unterstützung durch Frameworks und vorgefertigte User-Interface-Widgets zu verzichten – dessen ungeachtet werden Ajax-Framework aber immer beliebter. Dies zeigt sich auch darin, dass Internetgrössen wie Google und Yahoo ihre eigenentwickelten Ajax-Tools seit einiger Zeit dem Publikum zur Verfügung stellen.
Kategorien und Aspekte
Ein interessanter Abriss über Ajax-Frameworks, den Gary Horen Ende 2006 auf der Entwicklerwebsite von Bea Systems publiziert hat, teilt den Dschungel der verfügbaren Frameworks anhand von vier Achsen funktional und architektonisch ein. Horen beleuchtet im Detail zwar nur Frameworks, die sich für den Einsatz in einer Java-Serverumgebung eignen, die Erkenntnisse gelten aber generell:
- Open Source versus kommerziell: Die wenigen kommerziell vertriebenen Produkte sind, darin sind sich auch andere Experten einig, oft kompletter und reifer – einige Hersteller haben mit der Entwicklung ihrer Produkte bereits begonnen, bevor der Begriff Ajax aufkam. Aus diesem Grund sind Produkte wie Backbase, Bindows und die Jackbe NQ Suite auch breiter angelegt als manche Open-Source-Frameworks, die oft in einem Bereich hervorragend, in anderen Funktionen aber nur spartanisch ausgestattet sind.
Auch die Dokumentation ist bei kommerziellen Tools im allgemeinen umfassender: Viele Open-Source-Projekte – und dies gilt nicht nur für Ajax-Frameworks – haben erhebliche Mühe, ihre an sich hervorragende Software auch standesgemäss zu dokumentieren. Der Support, für einen Hersteller kostenpflichtiger Software zumindest theoretisch ein absolutes Muss, hängt bei den Open-Source-Frameworks mit dem Engagement der Entwickler, mehr noch aber mit der Popularität des Projekts zusammen: Je grösser die Benutzergemeinde, desto rascher und fundierter die Unterstützung in Foren, Chats und Fachbüchern.
Ein Spezialfall, der künftig aber vermehrt auftreten dürfte, ist General Interface von Tibco: Das Produkt wurde als kommerzielles Produkt geboren, ist heute aber wahlweise auch kostenlos unter der GPL erhältlich.
- Umfassendes Framework versus Einzelkomponenten: Die Bezeichnung «Ajax-Framework» richtet sich punkto Funktionsumfang nicht nach einem allgemeinverbindlichen Standard. Während einige Frameworks gerade mal den direkten Umgang mit dem XMLHttpRequest-Objekt vereinfachen oder ein API für eine ganz bestimmte Funktionalität zur Verfügung stellen, handelt es sich bei anderen in erster Linie um Sammlungen von interaktiven User-Interface-Elementen oder «Widgets», die sich mehr oder weniger per Copy/Paste in den Code einer Webseite einbauen lassen.
Andere Frameworks bieten zusätzlich ausgeklügelte Kommunikations- und Sicherheitsmechanismen als Grundlage für unternehmenstaugliche Webapplikationen, und vor allem die kommerziellen Angebote warten mit einer kompletten Entwicklungsumgebung samt grafischem Seiteneditor und Debugger auf.
In unserer Übersichtstabelle haben wir versucht, die Angebote in die drei Kategorien «Libraries» (Widget-Sammlungen, allenfalls mit elementarer Kommunikations-Infrastruktur), «Frameworks» (komplette Frameworks mit umfassender Unterstützung für infrastrukturelle Aspekte) und «IDE» (komplette Entwicklungsumgebungen) einzuteilen.
Bei der Wahl des geeigneten Frameworks sollte man das Einsatzszenario mitberücksichtigen: Bestehende Applikationen lassen sich leicht mit einigen Widgets aus einer Library anreichern. Umfassende Frameworks eignen sich mehr für völlig neue Entwicklungen, bei denen keine Rücksicht auf eventuell schon bestehende, mit dem Framework nicht kompatible JavaScript- und DHTML-Konstrukte nötig ist.
- Deklarativ versus prozedural: Je nach Framework erfolgt die Gestaltung der Benutzerschnittstelle mit unterschiedlichen Mitteln. Die meisten Frameworks sind wie das populäre JavaScript-Toolkit Dojo oder das C++-Framework WT prozedural orientiert. Sie stellen ein API für eine bestimmte Programmierumgebung zur Verfügung, auf dessen Basis der Entwickler Code erstellt, der die durch den Benutzer generierten Events verarbeitet. Deklarative Frameworks wie ICEfaces, das als Ergänzung zum Java-Standard-Framework JSF konzipiert ist, arbeiten dagegen mit einer eigenen Sprache, die das Layout der Oberfläche und die Beziehungen zwischen den Elementen beschreibt. Um die Details des Event-Handling kümmert sich das Framework.
- Clientzentriert versus serverzentriert: Die ersten Ajax-Frameworks haben sich ausschliesslich auf die Clientseite konzentriert, wo sie die asynchrone Kommunikation mit dem Server und mit unterschiedlicher Ausprägung das Layout der Seite unterstützten: Libraries wie DWR und Prototype regelten vor allem den Informationsaustausch mit dem Server; das Layout der Seite wurde konventionell per DHTML und JavaScript definiert. Eigentliche Frameworks im Stil von Dojo, OpenRico und Jackbe NQ Suite nutzen für die Gestaltung der Seitenstruktur einen deklarativen XML-Dialekt. Sämtliche Widget-Libraries und eine ganze Reihe kompletter Frameworks arbeiten nach wie vor clientzentriert und verlangen dem Anwendungsentwickler entsprechend fundierte JavaScript- und DHTML-Kenntnisse ab.
Serverzentrierte Frameworks ermöglichen die Entwicklung interaktiver Webanwendungen ohne Web-Know-how: Die gesamte Programmierung erfolgt in der Serverumgebung der Wahl, die durch einen serverseitigen Teil des Frameworks ergänzt wird. Am gängigsten sind Frameworks für Java, .Net und PHP; es gibt aber auch Lösungen für ColdFusion, Lotus Notes sowie für exotische Umgebungen wie Lisp, Smalltalk oder die Datenbank 4D.
Ein Musterbeispiel für ein rein serverzentriertes Framework ist das
Google Web Toolkit: Die gesamte Anwendung wird in Java programmiert, ein Compiler übersetzt den Java-Code danach in DHTML und JavaScript. Serverzentriert arbeiten auch diejenigen Ajax-Frameworks, die auf Java-Servertechnologien wie JSF aufsetzen, darunter Echo2, ICEfaces und die JSF-Ausgabe von Backbase.
Die meisten übrigen Frameworks mit einer Serverkomponente arbeiten mit einem hybriden Ansatz: Zwar wird der Hauptteil der Anwendung mit der Sprache der jeweiligen Serverumgebung erstellt, an einzelnen Stellen muss der Programmierer aber trotzdem auf JavaScript und DHTML zurückgreifen.
Obwohl alle Libraries, Widget-Sammlungen und Frameworks dem gleichen Ziel dienen – eine attraktive, browserbasierte Anwendung mit starker Interaktivität –, unterscheiden sich die Vorgehensweise und die Anforderungen an den Entwickler stark. Die Wahl einer Entwicklungsumgebung ist zudem immer auch Geschmackssache. Einmal mehr gilt deshalb: Nur mit einer eingehender Evaluation, am besten verbunden mit Praxistests, findet man das für den aktuellen Zweck optimale Ajax-Framework.
Unsere Marktübersicht zählt neben den populärsten serverunabhängigen Client-Side-Toolkits die wichtigsten serverzentrierten Frameworks für Java, .Net, PHP und ColdFusion auf. Dazu kommen einige besonders interessante Exoten wie das deutsche Produkt Winlike, das sich als «Window Manager» für Webapplikationen versteht und im Browser beliebig viele überlappende und minimierbare Fenster im klassischen GUI-Stil anzeigt.
Ajax-Frameworks im Überblick
Was soll ein Framework sonst noch können?
Ajax-Frameworks erfüllen zwei Hauptfunktionen: Sie befreien den Programmierer von den Details der Kommunikation zwischen Browser und Server und stellen vorgefertigte User-Interface-Elemente wie Listen, Tabellen und Datumseingabefelder zur Verfügung. Für Jim Plush, Senior PHP/Ajax Developer bei Panasonic, ist dies aber unter Umständen nicht genug. Er hat mit My-BIC ein eigenes Framework entwickelt, das zehn seiner Meinung nach wichtige, in anderen Frameworks oft vernachlässigte Aspekte abdeckt. Fünf der zehn Anforderungen, die Plush auf seiner Website www.litfuel.net/plush an Ajax-Frameworks stellt:
- Synchronisation der Requests/Responses: Wenn Request A für die Beantwortung drei Sekunden braucht, der unmittelbar danach abgesetzte Request aber nur eine, treffen die Antworten vom Server in der falschen Reihenfolge ein. Für Plush muss «jedes anständige Framework entweder eine Submission Queue oder eine andere Form von Abgleich zwischen Requests und Responses bereitstellen.»
- Keine Verbindung: Webserver und Netzwerkverbindungen fallen öfter aus als man denkt. Wie verhält sich die Ajax-Anwendung, wenn der Server nicht mehr antwortet? Ein gutes Framework fängt solche Probleme ab und informiert den User elegant über die Downtime-Situation.
- Abbruch von Requests: Es sollte möglich sein, jeden Request individuell mit einem Timeout zu versehen. Falls der Server für die Antwort zu lange braucht, kann das Framework so die hängigen Anfragen automatisch und elegant abbrechen.
- Auf XML folgt JSON: «Ajax» impliziert eigentlich, dass die Daten im XML-Format ausgetauscht werden. JSON ist aber schneller, braucht weniger Ressourcen und ist einfacher im Umgang. Plush findet, dass ein modernes Framework unbedingt auch JSON von Haus aus unterstützen.
- Debugging: Trotz browsernahen Debugging-Tools wie Firebug sollte ein Framework auch einen eigenen Debugger mitbringen, mit dem sich die angefallenen Requests und Responses verfolgen lassen.
(ubi)
