Evaluierung von AJAX-basierten Frameworks für das Web 2.0

Inhaltsverzeichnis

ZUSAMMENFASSUNG

INHALTSVERZEICHNIS

ABBILDUNGSVERZEICHNIS

TABELLENVERZEICHNIS

LISTINGS

ABKÜRZUNGSVERZEICHNIS

1. EINLEITUNG

1.1. AJAX - eine kurze Einführung
1.2. Zielsetzung der Arbeit
1.3. Aktueller Stand

2. GRUNDLEGENDE BETRACHTUNGEN
2.1. Geschichtlicher Ursprung von AJAX
2.2. Begriffsklärung
2.2.1. MVC
2.2.2. Remote Scripting
2.2.3. RIA
2.2.4. Widget
2.2.5. Wrapper
2.2.6. Stub
2.3. Definition der Anwendungsdomäne
2.3.1. Web Remoting
2.3.2. DOM-Manipulation
2.3.3. Widgets
2.3.4. Visuelle Effekte
2.3.5. Browseranwendungen
2.4. Beispiel-Szenarien
2.4.1. „Hello World“ example
2.4.2. Adresskartei
2.4.3. AJAX-Bildergalerie
2.5. Was ist AJAX?

3. AJAX FRAMEWORKS
3.1. Der Begriff „framework“
3.2. Abgrenzung zu Funktionsbibliotheken
3.3. Anforderungen an ein framework
3.4. Klassifikation
3.5. Überblick

4. BESCHREIBUNG DER EVALUIERUNG
4.1. Allgemeiner Überblick
4.2. Testauswahl
4.3. Beschreibung der Durchführung
4.4. Testumgebung
4.5. Kriterien
4.6. Bewertungsmaßstab

5. DURCHFÜHRUNG DER EVALUIERUNG
5.1. Clientframeworks
5.1.1. Javascript-basierte Bibliotheken (Basisframeworks)
5.1.1.1. ACE
5.1.1.2. AjaxToolbox
5.1.1.3. Bajax
5.1.1.4. HTMLHttpRequest
5.1.1.5. Lokris
5.1.1.6. MAJAX
5.1.1.7. Prototype
5.1.2. Javascript-basierte Effektbibliotheken (Applicationframeworks)
5.1.2.1. Adobe Spry
5.1.2.2. DOJO
5.1.2.3. jQuery
5.1.2.4. MochiKit
5.1.2.5. Mootools
5.1.2.6. Yahoo User Interface library
5.1.3. Basis- und Applikationsframeworks erweiternde frameworks
5.1.3.1. Freja
5.1.3.2. OpenRico
5.1.3.3. Script.aculo.us
5.2. Serverframeworks
5.2.1. PHP
5.2.1.1. AJAXAgent
5.2.1.2. Flexible AJAX
5.2.1.3. My-BIC
5.2.1.4. Sajax
5.2.1.5. tinyAjax
5.2.1.6. XAJAX
5.2.2. Perl
5.2.2.1. Catalyst
5.2.2.2. CGI::AJAX
5.2.3. Python
5.2.3.1. CherryPy
5.2.3.2. Nevow
5.2.4. Java
5.2.4.1. DWR
5.2.4.2. Google Web Toolkit
5.2.4.3. JSON-RPC-Java
5.2.5. DotNet
5.2.5.1. AJAX.NET
5.2.5.2. Anthem.Net
5.2.5.3. ASP.NET AJAX (Codename 'Atlas')
5.2.5.4. ComfortASP.NET
5.2.5.5. Visual WebGUI

6. RESULTATE
6.1. Übersicht
6.2. Fehlerbetrachtung
6.3. Testergebnisse
6.4. Bewertung der frameworks
6.4.1. Basisframeworks
6.4.2. Applicationframeworks
6.4.3. Basis- oder Applicationframeworks erweiternde Frameworks
6.4.4. Serverframeworks PHP
6.4.5. Serverframeworks Perl
6.4.6. Serverframeworks Python
6.4.7. Serverframeworks Java
6.4.8. Serverframeworks DotNet
6.5. Diskussion

7. AUSBLICK
7.1. Frameworkentwicklungen
7.2. Die Zukunft von AJAX

LITERATURVERZEICHNIS

INDEX

A. ANHANG A-3

A.1. Grafische Darstellung der Messwerte A-3

A.2. Übersicht über AJAX frameworks A-7

A.3. Testbögen A-15

Abbildungsverzeichnis

Abbildung 1: Standardbeispiel für neue Trends im Web 2.0: Google Suggest - Das Auto Completing ist in AJAX frameworks mit wenigen Anweisungen realisierbar

Abbildung 2: AJAX als "buzzword" in der "tag cloud" des Web 2.0 (Quelle: http://www.openjacob.org)

Abbildung 3: traditioneller Ablauf bei der Anforderung von Daten von einem Webserver: Die gesamte Website wird neu geladen, im Beispiel: eine Bilderauswahl unter http://www.flickr.com

Abbildung 4: Die gleiche Anfrage wie in Abb. 2 mittels AJAX, während die AJAX Engine auf das Eintreffen der HTTP Response wartet, kann der Nutzer die ursprüngliche Seite uneingeschränkt weiter benutzen

Abbildung 5: Mit AJAX verschwinden allmählich die Grenzen zwischen Desktop- und Webanwendungen, Bsp.: http://www.bindows.net

Abbildung 6: Schematische Einordnung von AJAX frameworks

Abbildung 7: Grafische Darstellung der Anzahl der Suchergebnisse von www.google.de bei der Suche nach der Kombination +ajax +{frameworkname}, Durchführung: 31.01.2007

Abbildung 8: Bewertung der getesteten frameworks im Schulnotensystem

Abbildung 9: Traffic bei Erstaufruf in kB in Boxplot-Darstellung

Abbildung 10: Ladezeit je Anwendungsszenario in s in Boxplot-Darstellung

Abbildung 11: Ladezeitvergleich basierend auf den einzelnen Anwendungsszenarien A3

Abbildung 12: Zeit zum Ausführen eines asynchronen Requests je framework in s A-4

Abbildung 13: übertragene Datenmenge bei Seitenerstaufruf je framework je Anwendungsbeispiel in kB. A-5

Abbildung 14: Messwertübersicht für die Abbildungen 11-13 A-6

Tabellenverzeichnis

Tabelle 1: Bestandteile von AJAX

Tabelle 2: Einordnung von AJAX frameworks nach Kategorien

Tabelle 3: Klassifikation im Internet verfügbarer frameworks nach Sprachplattform

Tabelle 4: Übersicht über Anzahl der getesteten frameworks

Tabelle 5: Kriterienkatalog für Evaluierung

Tabelle 6: Meistgenutzte AJAX Toolkits im Vergleich (Quelle: [Ore06])

Tabelle 7: Bedeutung wesentlicher IT-Technologien und der Zeitraum bis deren voraussichtliche

Durchsetzung (Quelle: Computerzeitung/Gartner)

Listings

Listing 1: "Hello World" - klassische Realisierung mit PHP

Listing 2: Das "Hello World" Beispiel als AJAX-Realisation

Listing 3: Das "Hello World"-Beispiel in einer verbesserten AJAX-Variante

Listing 4: Eine mögliche Implementierung des Beispiels 2 mittels PHP

Listing 5: Das Adresskarteibeispiel basierend auf AJAX

Listing 6: Beispiel 3 in einer klassischen Realisierung mit PHP

Listing 7: Eine einfache, AJAX-basierte Bildergalerie

Listing 8: Beispiel 1 aus Kapitel 2.3.1 mit der ahah.js

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Zusammenfassung

„Remote Scripting“-Anwendungen erleben seit einigen Jahren einen regelrechten Anfrageboom. Während aus usability-Sicht bisher eine strikte Unterscheidung zwischen Desktop-Anwendungen und Webapplikationen herrschte, finden sich seit einiger Zeit zunehmend Angebote im World Wide Web, die diese strikte Trennung verwischen lassen. Interaktive Nutzerdialoge, nebenläufige Pro- zessabarbeitung und visuelle Unterstützungsmittel wie Drag & Drop- Effekte halten auf Webseiten Einzug, die dem Nutzer bisher nur aus eigenständigen Softwareprodukten in einer spezifischen Betriebssystemumgebung bekannt waren. Viele dieser neuen Anwendungs- und Interaktionsmög- lichkeiten im weltweiten Datennetz werden inzwischen unter dem Oberbegriff Web 2.0 zusammengefasst. Für den Nutzer bringt dieser neue Entwicklungstrend viele Vorteile: Anspre- chende, intuitive Nutzerführungen ohne die Notwendigkeit, eine ganze Internetseite bei jedem Interaktionsschritt neu zu laden und ohne bemerkbaren zeitlichen Overhead.

Was für den Nutzer Erleichterung bringen soll, bedeutet häufig für einen Programmierer zunächst Mehraufwand. Eine Technik zur Realisierung solcher so genannten Rich Internet Applications, die sich in den letzten beiden Jahren immer mehr in den Vordergrund gedrängt hat, wird unter der Bezeichnung AJAX zusammengefasst. Einen einheitlichen Standard gibt es dabei nicht, sodass fast täglich neue AJAX-basierte frameworks veröffentlicht werden, die dem Programmierer (we- nigstens einen Teil der) Komplexität der Programmflusssteuerung abnehmen sollen. Aufgabe der Studienarbeit soll es daher sein, das inzwischen unüberschaubar gewordene Angebot an AJAX frameworks zu systematisieren und einen Überblick über Vor- und Nachteile ausgewählter Pro- grammbibliotheken zu geben. Dafür ist ein Kriterienkatalog zu erarbeiten, der eine Bewertung der verschiedenen frameworks nach unterschiedlichen Gesichtspunkten ermöglicht. Besonderer Schwerpunkt ist dabei auf Kriterien aus Programmierersicht (Sprachunabhängigkeit, Overhead, Implementierungsmöglichkeiten,…) und Anwendersicht (Plattformanforderungen, Einarbeitungszeit, Ergebnisqualität, …) zu legen. Auf den Kriterienkatalog ist anschließend eine Auswahl an bereits existierenden, frei verfügbaren AJAX frameworks anzuwenden, die als zukünftig relevant einge- schätzt werden. Die Ergebnisse sind abschließend in einer Gesamtübersicht zu präsentieren, die eine objektive Empfehlung für Nutzer darstellen soll, die vor der Wahl stehen, welche AJAX Pro- grammbibliothek sie zukünftig einsetzen sollten.

1. Einleitung

1.1. AJAX - eine kurze Einführung

Bereits im antiken Griechenland verband man mit dem Namen AJAX vor allem eins: Macht, Schönheit und Größe. Die Rede ist hier von Ajax dem Großen, Sohn des Königs von Salamis, der in Homers Illiade in der Schlacht um Troja als Mutigster aller Griechen im Zweikampf dem Trojaner Hektor gegenüber stand. Der Kampf dauerte einen ganzen Tag, doch keiner der beiden Helden konnte ihn für sich entscheiden, weswegen beide letztendlich den Kampf mit Respekt gegenüber dem Anderen beendeten. [Fid07] Jahrhunderte lang wurde der Mythos weitergetragen, doch ausgerechnet im Jahr 2005 tauchte der Name AJAX in einem vollkommen neuen Zusammenhang wieder auf: Wie ein griechischer Held „eroberte“ der Begriff binnen kurzer Zeit die Welt des Internets und selbst zwei Jahre später kann noch niemand einen Orakelspruch sprechen, wohin der Weg von AJAX im „Web 2.0“ in nächster Zeit führen wird. [Hos07]

AJAX - dies ist zu Beginn des 21. Jahrhunderts eine Art Modewort („buzzword“), mit dessen Techniken es möglich sein soll, die Bedienung des klassischen World Wide Web zu revolutionie- ren¹ oder zumindest zu vereinfachen und das Nutzungskonzept einer Webseite stärker auf die Bedürfnisse der Nutzer auszulegen. Interessant dabei ist, dass sich hinter AJAX kein vollkommen neues Programmierkonzept oder sogar eine eigene neue Sprache verbirgt, sondern zunächst nur ein Akronym für „Asynchronous Javascript And XML“. Den sprichwörtlichen Stein ins Rollen ge- bracht hat dabei ein inzwischen vielfach zitierter Aufsatz von dem Amerikaner Jesse James Garrett unter dem Titel „Ajax: A New Approach to Web Applications“ im Februar 2005 [Gar05]. Seitdem hat sich einiges im Web getan: In den darauf folgenden Monaten entstanden Angebote im Internet, die Mitte der Neunziger Jahre noch kaum vorstellbar waren.² Diese Entwicklung setzte in einer Zeit ein, der mit der steigenden Verbreitung von so genannten Wikis und Blogs bereits ein weiterer Trend vorausgegangen war. Inhalte, die aktiv von Nutzern erstellt wurden, rückten immer mehr in den Mittelpunkt des Interesses - der Nutzer selbst verbunden mit möglichst einfach und intuitiv zu bedienenden Benutzeroberflächen wurde zunehmend wichtiger.

Die Techniken dafür gab es bereits vorher; so wurde zum Beispiel eine Vielzahl von Content Management Systemen entwickelt, mit der auch ein Nutzer ohne Programmierkenntnisse schnell Inhalte im Web publizieren konnte und die entsprechenden Seiten dynamisch im Hintergrund generiert und als HTML-Seiten ausgeliefert wurden. Doch im Gegensatz dazu wirkten Internetseiten, die im Hintergrund auf Techniken wie AJAX, XML und Webser- vices aufsetzten, plötzlich wesentlich lebendiger und „reicher“ an Funktionali- täten.

Abbildung 1: Standardbeispiel für neue Trends im Web 2.0: Google Suggest - Das Auto Completing ist in AJAX frameworks mit wenigen Anweisungen realisierbar

Abbildung in dieser Leseprobe nicht enthalten

Im Herbst 2004 beschäftigte sich in San Francisco eine Konferenz unter dem Titel „Web 2.0“ mit dieser Entwicklung. Community-Orientierung, erhöhte Benutzerfreundlichkeit, eine intuitive Bedie- nung und das allmähliche Verwischen von Dienstgrenzen durch Kombination bestehender Techniken und Inhalte („Mashup“) wurden auf der Konferenz als wesentliche Aspekte identifiziert, sowie weitere Schlüsselprinzipien für die kommenden Jahre benannt. Dale Dougherty - ein Mitor- ganisator der Konferenz vom O’Reilly Verlag - stellte eine Reihe von Vergleichen an, in welchem Veränderungsprozess sich das Internet aktuell befinden würde, und welche altbekannten Services in Zukunft durch neuen Technologien ersetzt werden würden. Der Name der Konferenz steht seit- dem als Schlagwort für diesen gesamten Veränderungsprozess. „Web 2.0 ist heute, Web 1.0 war gestern“ wird beispielsweise auf der Website von Helge Städtler unter dem Titel „Tachometer der Webentwicklung“ [Sta07] getitelt³.

Rückblickend kann wohl festgestellt werden, dass AJAX als Programmierkonzept an dieser Ent- wicklung einen maßgeblichen Anteil hat und weiterhin haben wird. Die Grenzen zwischen Web- Applikationen und Desktop-Anwendungen scheinen allmählich zu verschwinden. Plötzlich entde- cken Web-Designer wieder „Drag and Drop“-Effekte sowie weitere Animationsarten für sich, Websitebesuchern werden Hilfeassistenten angeboten und reine textuelle Informationen werden grafisch ansprechend aufbereitet und sind von Nutzerseite aus jederzeit anpassbar.

Zu erwähnen ist dabei, dass diese Sonderfunktionen nicht mehr Ressourcen benötigen als die althergebrachten Websiteinhalte der letzten Jahre. Eher im Gegenteil kann gesagt werden, dass auf AJAX-basierten Internetseiten ein völlig neues „look-and-feel“ entsteht. Websiteinhalte schei- nen spürbar schneller zu laden, jeder Mausklick ruft anscheinend eine unmittelbare Aktion hervor, und das gesamte Timingverhalten von Webanwendungen scheint sich unter Einsatz dieser neuen Technik zu verbessern, da ein wesentlicher Anteil aller Operationen nun auf Clientseite verlagert wird.

Der Mehraufwand für diese Reihe von Vorteilen ist zunächst auf Programmiererseite zu suchen, denn gegenüber traditionellen Programmieransätzen auf Serverseite (ASP, PHP, Perl, Python und andere) ist nun ein wesentlich komplexerer Programmablauf zu realisieren, der sowohl auf Server- als auch auf Clientseite stattfindet und ebenso eine wechselseitige Kommunikation zwischen die- sen einschließt. Nicht nur die eindeutige Abarbeitung von Programmcode verwischt unter dem Konzept von AJAX, auch die Vielfalt der eingesetzten Sprachen stellt eine Herausforderung für die Entwickler von AJAX-basierten Webapplikationen dar. Während es vor Jahren genügte, Spezial- kenntnisse in PHP oder Perl zu besitzen und das Layout der Internetseite einem Grafiker überlassen blieb, der mithilfe von Cascading Style Sheets die einzelnen Elemente einer Seite op- tisch ansprechend anordnete, verzahnen sich bei modernen Internetseiten diese Techniken immer mehr. Einzelne Skriptsprachen sind nicht mehr alleinstehend, sondern agieren zunehmend mitein- ander: So werden die Stärken von Javascript, XHTML / DOM, CSS, XML und Sprachen wie PHP, DotNet, Java sowie Datenbankanfragesprachen wie MySQL immer häufiger kombiniert, um noch ansprechendere Internetauftritte zu realisieren.

Diese Entwicklung mag aus Benutzersicht erfreulich sein, birgt auf Entwicklerseite aber mehrere Gefahren. Während seit Jahren stetig versucht wurde, Softwareentwicklung mithilfe von Standardi- sierungen, integrierten Softwareentwicklungsumgebungen (IDEs) und „Best Practise“- Empfehlungen in geregelte Bahnen zu lenken, besteht durch die Vermischung verschiedener Sprachen und Programmierkonzepte die Gefahr, die Bestrebungen ungewollt wieder umzukehren. Webseitenentwickler haben immer mehr Wahlmöglichkeiten, unter dem Einsatz welcher Techniken sie ein konkretes Problem lösen. Wird keine konsequente Umsetzung gefunden, entsteht schnell ein Mischcode, der schwer zu warten ist.

Eine weitere Gefahr ist, dass Webanwendungen aufgrund begrenzter Entwicklungsressourcen häufig nur für bestimmte Anwendungsfälle und Browserfamilien entwickelt werden. Auch wenn heutige moderne Browser größtenteils Webstandards mit dem gleichen Endverhalten umsetzen, so ist für einen Programmierer dennoch ein relativ hoher Aufwand mit vielen Fallunterscheidungen und Work-arounds nötig, um sowohl aktuelle Internetbrowser wie Internet Explorer, Mozilla/Firefox, Safari und Opera, als auch ältere Versionen dieser Programme zu unterstützen und alle Informati- onen einer Webseite identisch (oder zumindest in gleicher Art und Weise benutzbar) in diesen darzustellen.

Das skizzierte Problemszenario ist seit langem in der Softwareentwicklung bekannt und beschränkt sich nicht nur auf die Entwicklung von Webapplikationen. Um einen Programmierer bei seiner Ar- beit zu unterstützen und ihm die Behandlung ständig wiederkehrender Problemszenarien zu vereinfachen, finden sich für nahezu jede Sprache eine Reihe von frameworks in Form von Pro- grammbibliotheken. Dazu verbergen frameworks in unterschiedlichem Maße die zugrunde liegende Komplexität und abstrahieren von den technischen Realisierungen. Auch nach der rasanten Verbreitung von AJAX im Jahr 2005 wurden weltweit - ob nun von Privatpersonen oder größeren Unternehmen, ob kommerziell oder open-source - verschiedenste frameworks konzipiert, entwi- ckelt und anderen Nutzern bereitgestellt. Knapp zwei Jahre später ist die Vielfalt dieser frameworks so groß geworden, dass es einem Einsteiger nur noch schwer möglich ist, einen Gesamtüberblick zu bekommen und herauszufinden, welche frameworks für welche Zwecke am Besten geeignet sind. Darüber hinaus ist es inzwischen schon nicht leicht, überhaupt zu unterscheiden, welche von den angebotenen AJAX-Programmbibliotheken wirklich AJAX-Komponenten mit erweiterten Funk- tionalitäten enthalten und welche sich unter Umständen nur so nennen, aber keinen Mehrwert bringen. Ebenso wenig ist häufig nicht genau erkennbar, inwieweit angebotene AJAX frameworks bereits einen stabilen Entwicklungsstand erreicht haben und ob sie auch in Zukunft unter der gro- ßen Konkurrenz weiter Bestand haben und unterstützt werden, oder ob in wenigen Monaten im schlechtesten Fall ein komplettes Reengineering des damit realisierten Projektes nötig werden könnte.

1.2. Zielsetzung der Arbeit

Ziel der vorliegenden Studienarbeit ist es, einen Überblick über bestehende AJAX frameworks zu geben und diese nach unterschiedlichen Kriterien zu bewerten. Datengrundlage dazu ist eine im Oktober 2006 durchgeführte Recherche, in der zunächst zum 31.10.2006 insgesamt 231 frame- works identifiziert wurden, die einen Bezug zu der Thematik „Asynchronous JavaScript and XML“ erkennen ließen. Schwerpunktmäßig wurden rein Javascript-basierte Funktionssammlun- gen, sowie frameworks basierend auf PHP, Perl, Python, DotNet und Java untersucht. Daneben existieren weitere frameworks für andere Sprachen, wobei hier exemplarisch Flash und Coldfusion genannt seien. Da Flash als Technologie bereits vor Jahren eine ähnliche Motivation wie AJAX verfolgte und die Thematik AJAX unter Flash eine eigene Studienarbeit füllen könnte, werden diese frameworks in der weiteren Betrachtung ausgeklammert. Das Gleiche gelte an dieser Stelle für Javascript-basierte frameworks mit einer reinen Spezialisierung auf Debugging und Logging, da diese aus Webseitenbesuchersicht ebenfalls keine Relevanz unter dem Schlagwort „Web 2.0“ auf- weisen. Aus dem genannten Grund reduzierte sich die Zahl der aktuell verfügbaren framework um 22 auf insgesamt 209 Programmbibliotheken.

In einem zweiten Untersuchungsschritt konnte festgestellt werden, dass 18 der verbliebenen fra- meworks zwar überdurchschnittlich oft in Verbindung mit dem Begriff AJAX genannt wurden, selbst aber keine erkennbaren AJAX-ähnlichen Funktionalitäten implementierten. Die Projektwebsites von 6 weiteren frameworks, die auf mehreren anderen Internetseiten empfohlen wurden, waren sogar in mehreren Stichproben über einen Zeitraum von zwei Wochen generell nicht zu erreichen und ihr Entwicklungsstand erschien eingestellt. Insgesamt blieben deshalb als Datengrundlage für diese Studienarbeit 185 AJAX frameworks. Deren genaue Klassifikation wird im Kapitel 3.4 näher beschrieben. Eine Übersicht mit generellen Informationen zu allen AJAX frameworks ist im Anhang 1 zu finden. Die Übersicht erhebt aufgrund der derzeitigen sehr dynamischen Entwicklung in diesem Bereich dabei keinen Anspruch auf Vollständigkeit.

Die Studienarbeit besteht aus insgesamt sieben Teilen. Nach einer kurzen Einführung in die Thematik im vorliegenden Kapitel 1 beschäftigt sich Kapitel 2 zunächst mit einigen Grundlagen von AJAX, die für das spätere Verständnis der framework - Evaluation nötig sind. Die Ziele und Einsatzgebiete stehen dabei im Mittelpunkt und es wird versucht die Frage zu klären, was AJAX selbst eigentlich ist. Anhand von Fallbeispielen wird die Einsatzweise von AJAX geklärt, welche später als Grundlage für die Evaluierung der verschiedenen frameworks dienen. Kapitel 3 klärt darauf aufbauend zunächst grundlegende Begriffe im Zusammenhang mit AJAX frameworks und gibt einen Überblick über das breite Spektrum an AJAX frameworks.

1.3. Aktueller Stand

In Kapitel 4 wird anschließend der Kriterienkatalog definiert, welcher der Durchführung der Evalua- tion und der Bewertung der AJAX frameworks zugrunde liegt und legt die Kriterien offen, unter welchen Gesichtspunkten die Auswahl an frameworks getroffen wurde, die von den knapp 200 Vertretern repräsentativ evaluiert wurden. Kapitel 5 stellt den experimentellen Teil der Studienar- beit dar, in dem kategorisiert nach den zugrunde liegenden Skriptsprachen einzelne frameworks untersucht und deren Vor- und Nachteile beschrieben werden. Daran anschließend gibt Kapitel 6 eine Übersicht über die gewonnenen Ergebnisse aus der Evaluierung und versucht, eine objektive Bewertung der getesteten frameworks abzugeben. Empfehlungen über gute und weniger gute frameworks für bestimmte Einsatzgebiete werden getroffen und deren Potential in Verbindung mit anderen Techniken diskutiert. Kapitel 7 schließlich versucht als Abschluss der Studienarbeit einen Ausblick auf die Zukunft von AJAX sowie AJAX frameworks anhand aktuell verfügbarer Fakten und Prognosen zu geben.

Paradox an der Thematik „AJAX“ ist, dass sich hinter diesem Schlagwort im Grunde genommen keine neuen Technologien verbergen - Javascript, HTML und XML sind seit langem bekannt und wurden dementsprechend schon in einer Vielzahl wissenschaftlicher Arbeiten analysiert und vor wenigen Jahren auch standardisiert. Neu erscheint zwar zunächst der Ansatz der Asynchronität, aber auch dafür gab es die nötigen Techniken bereits 1998⁴. Warum erst zu Beginn des Jahres 2005 ein sprunghaftes Interesse an dieser Thematik aufkam, soll in Kapitel 2 geklärt werden. Die bedeutendste wissenschaftliche Arbeit zu dem Thema prägte Jesse James Garrett mit dem Titel „Ajax: A New Approach to Web Applications“ im Februar 2005 [Gar05]. Obwohl der Begriff „AJAX“ letztendlich ein Marketingbegriff für die Beschreibung von etwas bereits Bekanntem war, kam es in den Medien zu einem regelrechten Hype. Allein in dem Internet-Versandhaus ama- zon.com fanden sich im Februar 2006 knapp 200 verschiedene Buchtitel, die sich mit der Thematik AJAX beschäftigen, als Suchbegriff unter www.google.com waren es sogar geschätzte 92.900.000 Ergebnisse.⁵ Zumeist beschäftigen sich diese Artikel mit einer Einführung in das Thema AJAX, vorwiegend für Programmierneulinge in diesem Gebiet, oder sind Gegenstand von threads in ver- schiedenen Diskussionsforen.

Im Gegensatz dazu oder vielleicht gerade deswegen finden sich nur sehr wenige weitere wissen- schaftliche Abhandlungen oder Veröffentlichungen, die sich mit der Thematik „Asynchronous Javascript“ oder sogar mit AJAX frameworks auseinandersetzen. Viele davon wurden erst inner- halb der letzten Monate im englischsprachigen Raum verfasst. Wissenschaftlich fundierte, deutschsprachige Artikel sind selten und finden sich zumeist als Veröffentlichung in speziellen Ma- gazinen (entwickler.press). Exemplarisch sei hierfür das AJAXspecial vom Software & Support Verlag genannt.

Daneben erfolgt aktuell ein regelmäßiger Wissensaustausch auf verschiedensten Konferenzen zum Thema AJAX weltweit. Neben der Ursprungsveranstaltung „Web 2.0“ jedes Jahr im Oktober in San Francisco sei hier vor allem die „w-jax 2006“ in München und „Ajax in Action“ im Februar 2007 in Frankfurt genannt.

Obwohl Quellen im Internet wegen der kurzen Lebensdauer und der schwer einzuschätzenden Relevanz in der Regel kritisch zu sehen sind, sei abschließend an dieser Stelle auch die Seite www.ajaxpatterns.org erwähnt, die erstmals den Versuch startete, eine lückenlose Übersicht über bestehende AJAX frameworks zu geben.

Es finden sich eine Reihe weiterer derartiger Übersichten im weltweiten Datennetz, doch repräsentieren diese jeweils nur einen Bruchteil der tatsächlich angebotenen Programmbibliotheken oder beschäftigen sich tiefergehend mit einer bestimmten Art von AJAX frameworks wie zum Beispiel der ASP.Net-framework-Vergleich von Zeiss [Zei07] zeigt.

Abbildung 2: AJAX als "buzzword" in der "tag cloud" des Web 2.0 (Quelle: http://www.openjacob.org)

2. Grundlegende Betrachtungen

2.1. Geschichtlicher Ursprung von AJAX

Im Folgenden soll kurz diskutiert werden, was die Ursprünge von AJAX sind und warum sich dieser Ansatz erst in den letzten Jahren durchsetzen konnte. Die aktuelle Diskussion um das Thema AJAX ist dabei der vorläufige Höhepunkt einer Entwicklung, deren Wurzeln bis in die Achtziger Jahre zurückreichen. Zu dieser Zeit bestand das Hauptinteresse darin, in einer zweistufigen (two- tier-, Client-Server-) Architektur verschiedenste Daten mehreren Nutzern gleichzeitig zur Verfügung zu stellen. Während die gesamte Darstellungslogik in einzelnen Komponenten einer Software rein auf Clientseite implementiert wurde, wurden die Daten selbst von einem Server bereitgestellt.

Diese strikte Trennung veränderte sich ab dem Zeitpunkt, wo HTTP und HTML es jedermann er- möglichten, Informationen im Internet zu suchen und auf eigenen Internetseiten zu veröffentlichen. Diese Informationen waren zu Beginn meist nur statische Inhalte, die von einem Server als elekt- ronischer Text bereitgestellt und auf eine Anfrage hin zu einem Client geschickt wurden, welcher diese Informationen schließlich in einem Internetbrowser darstellte. Einer der ersten Internetbrow- ser dieser Zeit war unter anderem der im Februar 1992 an der University of Illinois / Urbana Champaign (USA) entwickelte Mosaic Browser, dem weitere Entwicklungsprodukte wie beispiels- weise 1994 in den USA der Netscape Navigator, in Norwegen der Opera Browser, oder 1995 der Internet Explorer folgten. Auch wenn es zu Beginn reichte, von einem Server statische Informatio- nen ausliefern zu lassen welche von Clients angefordert wurden, stiegen allmählich die Erwartungen der Internetnutzer. Das Internet war nicht mehr nur ein Netz zum wissenschaftlichen Austausch, sondern stellte inzwischen auch immer mehr private und kommerzielle Angebote zur Verfügung. Die Nutzer verglichen zunehmend die Möglichkeiten, die ihnen das reine Hypertext- Konzept von HTML anbot mit den Möglichkeiten von Desktopanwendungen, und als Konsequenz wurde schnell nach Erweiterungen und Alternativen gesucht, Internetinhalte in einem ersten Schritt dynamisch verändern und in einem weiteren Schritt grafisch ansprechender aufbereiten zu können.

Die Firma Sun Microsystems stellte dazu im Mai 1995 erstmals die Entwicklung der Programmiersprache Java der Öffentlichkeit vor, deren Applet-Konzept nun interaktive Anwendungen auf einer Webseite ermöglichten. Durch eine Kooperation mit Netscape und einer reibungslosen Browserunterstützung im zu der Zeit weit verbreiteten Netscape Navigator wurde Java schnell zu einer bedeutenden Technik. Trotz der Erfolge von Java Applets bestanden jedoch zwei wesentliche Probleme: Zum Einen liefen applets nur in Internetbrowsern, die eine Java Virtual Machine in einer korrespondierenden Version bereitstellten, für die das applet entworfen wurde.

Zum Anderen waren die Internetanbindungen häufig noch dial-up-Verbindungen, sodass der Download von Code von komplexen Java applets durchaus länger dauern konnte, als manche Nutzer bereit waren zu warten. Aus diesem Grund wurde weiter nach Alternativen gesucht und schnell entstand die Idee, dass es möglich sein müsste, direkt auf dem Server dynamisch Code generieren zu können und durch diesen letztendlich statische Seiteninhalte an Clients auszuliefern.

Eine erste Lösung, die es ermöglichte, Webseiten ein dynamischeres Verhalten zu verleihen, war das Common Gateway Interface (CGI) . Dies ermöglichte es, Skripte auf dem Server zu erstellen, die bei einer Anfrage direkt als Programm ausgeführt werden können. In die Kritik geriet CGI, da aus Sicherheitssicht Bedenken erhoben wurden, dass beliebiger Code direkt auf dem Webserver ausgeführt werden könnte. Sun erkannte diese Entwicklung und führte 1996 das Servlet-Konzept ein - Java-Code, der nun direkt auf einem Applikationsserver ausgeführt werden konnte und das Wartungsproblem löste, welches bei applets in verschiedenen Browsern bestand. Gleichzeitig er- kannte man nun bei servlets, dass eine stärkere Trennung zwischen der Verarbeitung der dynamischen Inhalte und der Darstellung dieser Inhalte in den Skripts nötig sei - und erweitere dies zu Java Server Pages (JSP) . Ein ähnliches Konzept entwickelte Microsoft parallel zuvor unter der Bezeichnung Active Server Pages (ASP) . Auch weitere Skriptsprachen wie PHP entstanden in diesem Zeitraum.

Zur gleichen Zeit wurde von Brendan Eich für die Netscape Communication Corporation eine wei- tere dynamisch typisierte Sprache entwickelt, die letztendlich JavaScript genannt wurde und Programmierern ohne weitere Kenntnisse in Java ermöglichen sollte, einer Webseite eine dynami- sches Verhalten zu verleihen. Aus dieser Entwicklung heraus entstand auch die Idee, eine Webseite mit ihren Tags als Objekt anzusehen, die zueinander in Beziehung stehen und dyna- misch modifiziert werden können, was später zum Document Object Model (DOM) weiterentwickelt wurde.

Die Firma Microsoft konnte als zunehmender Konkurrent diese Entwicklungen nicht ignorieren und entwickelte zunächst eine eigene Skriptsprache mit einem ähnlichen Funktionsumfang wie JavaSc- ript, welche JScript genannt wurde. Stückweise begann damit eine Entwicklung, die heute unter dem Begriff „Browserkrieg“ bekannt ist. Entwickler mussten mit verschiedensten Inkompatibilitäten kämpfen und durch die unterschiedliche Darstellung in verschiedenen Browsertypen entstand schnell der Ruf nach einer Standardisierung, welche letztendlich durch die European Computer Manufacturers Association erfolgte, die die Basisfunktionalitäten von Javascript als ECMAScript definierten.

Diese Entwicklung kann als der Beginn des Strebens nach einer Browserdominanz angesehen werden. Während der Netscape Navigator bis 1996 der führende Webbrowser war, gelang es Microsoft ab dem Internet Explorer 3.0 erstmals, Nutzer zu einem Umstieg zu bewegen. Der Höhe- punkt des Browserkrieges wird mit dem Jahr 1998 angegeben, wo immer neuere proprietäre Formate durch die Browserhersteller eingeführt wurden, um einerseits neue Nutzer, andererseits einen Vorsprung gegenüber anderen Konkurrenten zu gewinnen. Eine Entwicklung aus dieser Zeit war in den Browsern der vierten Generation unter anderem DHTML - eigentlich ein Marketingbeg- riff, der bereits bekannte Technologien umfasste, und nicht vom W3C standardisiert ist, aber jetzt erst populär wurde. Mit DHTML war es nun möglich, Inhalte und die Struktur einer Internetseite „on the fly“ zu verändern, auch wenn bedingt durch den Browserkrieg Inkompatibilitäten die Entwick- lung erschwerten.

Obwohl mit DHTML zwischenzeitlich sehr aufwändige Seiten entstanden, konnte sich die Idee dahinter zunächst nur bedingt durchsetzen. Die Gründe dafür sind vielschichtig. Das Hauptargu- ment bezog sich auf Javascript selbst. Die abweichenden Implementierungen und Interpretationen in verschiedenen Browsern wurden immer wieder angeführt, auch dass Javascript jederzeit von Benutzern aus Sicherheitsgründen ausgeschaltet werden konnte. Zwischenzeitlich aufkommende Sicherheitsrisiken wurden in den Medien hochgespielt und auch der erhöhte Entwicklungsaufwand von Javascript mit wenig Debuggingmöglichkeiten war immer ein Argument, so wenig Javascript wie möglich auf eigenen Webseiten einzusetzen. So kam es, dass Javascript als Teilkonzept von DHTML letztendlich als eine Art „Spielzeug für Programmierer“ abgetan wurde und sich lange Zeit auf das serverseitige Erstellen von dynamischen Inhalten konzentriert wurde.

Dennoch bestand weiterhin das Problem, dass Nutzer auf Internetseiten zunehmend die intuitive Bedienung vermissten, die sie aus anderen Softwarebereichen gewöhnt waren. Man fand sich damit ab, dass die Navigation in Webseiten meist nur in Form von Textlinks ablief, die Frage be- stand jedoch trotzdem, wie man Nutzern bessere Interaktionsmöglichkeiten anbieten könnte. Die Firma FutureWave stellte dazu bereits 1996 einen Ansatz namens Future Splash Animator vor, der auf einer javabasierten Animationswiedergabesoftware aufsetzte und später an Macromedia ver- kauft und in Flash umbenannt wurde. Trotz dass mit dieser Technologie bis dahin noch nicht da gewesene Effekte auf Webseiten Einzug hielten, hatte Flash ähnliche Probleme wie Java zu Be- ginn: nämlich dass es nicht universell einsetzbar war und auf jedem Client eine spezielle Abspielsoftware benötigte.

Bis ins Jahr 2001 stellte sich immer stärker heraus, dass in der Entwicklung von Webseiten immer weniger das Layout als vielmehr die Inhalte im Mittelpunkt standen. Immer aufwändigere Content- Management-Systeme wurden entwickelt, die dem Nutzer einen Teil der Arbeit abnahmen, das dynamische Verhalten von Internetseiten selbst programmieren zu müssen. Vielmehr wurden Sei- teninhalte nur noch definiert, in Datenbanken zwischengespeichert und beispielsweise mithilfe von templates dynamisches zu kompletten Seiten zusammengesetzt. DHTML-Effekte wurden dazu nicht benötigt und wurden im Zweifelsfalle eher mit Flash umgesetzt, da dort erheblich weniger bis teilweise gar kein Programmieraufwand nötig war, um ansprechende Effekte zu erzeugen.

In der folgenden Zeit beschränkten sich die Entwicklungen vorwiegend auf Standardisierungen und festgelegte Schnittstellen, wodurch der Programmieraufwand wesentlich reduziert werden sollte. Nachdem sich viele Unternehmen um das Jahr 2000 herum mangels Erfolgen aus dem Web zu- rückzogen und sich der Internet Explorer gegenüber dem Netscape Navigator als meistgenutzter Browser durchsetzte, setzte auch ein Umdenken bei den Browserherstellern ein. Trotz dass sich die aktuell auf dem Markt befindlichen Browser an einigen Punkten im Verhalten und der Imple- mentierung von Funktionen unterschieden, wurden dennoch vermehrt Standards einheitlich umgesetzt. Das Ergebnis dieser knapp 20 Jahre dauernden Entwicklung ist nun, dass Internetsei- ten von heute mit denen von einst kaum zu vergleichen sind. Trotz dass sich (X)HTML als elementauszeichnende Sprache über die Jahre hinweg fest etabliert und gehalten hat, ist ein im- menser Funktionsumfang hinzugekommen, der Programmierern und Webdesignern heutzutage für die Entwicklung von Internetauftritten zur Verfügung steht.

Die entscheidende Frage ist nun, wo in dieser Entwicklung der Begriff AJAX einzuordnen ist. Mit dem Aufkommen neuer Angebote wie GoogleMaps stiegen sprunghaft wieder die Service- Erwartungen der Nutzer auf Webseiten. Die Präsentation dynamisch generierter Informationen wurde zunehmend von Besuchern schlichtweg erwartet, daher fielen immer mehr neue Konzepte auf, die die Benutzung oder den Umgang mit Webseiteninhalten vereinfachten. Garrett als Mitar- beiter der Firma Adaptive Path fasste diese Beobachtung 2005 in seinem vielfach beachteten Aufsatz zusammen [Gar05]. Der Name AJAX war geboren und innerhalb eines Jahres begann ein regelrechter Boom um diese Technik. Alte Entwicklungen wie DHTML und Javascript wurden wie- der entdeckt und wieder verstärkt auf Internetseiten eingesetzt. Selbst das einizig neu erscheinende Konzept von AJAX - das asynchrone Nachladen von einzelnen Seiteninhalten im Hintergrund - ist bei weitem nicht neu, sondern wurde erstmals im Jahr 1998 von Microsoft im Internet Explorer 5.0 als Hilfsobjekt implementiert und unter anderem unter einer Anwendung mit dem Namen „Outlook Web Access“ genutzt, um unbemerkt HTTP Requests im Hintergrund an einen Server senden zu können, um Informationen ohne Neuladen der gesamten Seite nachladen zu können. Nur wurde dieser Ansatz zu seiner Zeit von keinem anderen Internetbrowser unterstützt.

Abschließend bleibt die Frage zu klären, warum der endgültige Durchbruch von Javascript als Ba- sistechnologie von AJAX erst 10 Jahre nach deren Entwicklung gelungen scheint. Gelin nennt dazu in [Gel06] zwei wesentliche Gründe: Als erstes werden in diesem Artikel die beschränkten Einsatzmöglichkeiten von DHTML im lange Zeit genutzten Netscape 4 Browser genannt, weswe- gen ständig Fallunterscheidungen bei Browserabfragen getroffen werden mussten. Die Ausführung von DHTML war zu seiner Zeit oft langsam und fehleranfällig und führte oft zu Abstürzen. Erst mit der Entwicklung verbesserter Internetbrowser und einer gesteigerten Ausführungsgeschwindigkeit von Javascript wurde DHTML für Webentwickler wieder interessant. Der zweite Grund seien die hohen Sicherheitsbedenken gegenüber dem XMLHttpRequest-Objekt gewesen, da in der An- fangszeit die Gefahr bestand, dass Unbefugte über ActiveX-Komponenten beliebige Dateien von lokalen Festplatten auslesen konnten und erst nach und nach auch Gecko-basierte Browser ein XMLHttpRequest-Objekt implementierten. Mit dem Fortschreiten aktueller Servertechnologien und verbesserter Hardware wurde nun schnell offensichtlich, dass mit asynchronen Anfragen an Web- server ein wesentlicher Mehrwert zu erreichen war, was die Ausführungsgeschwindigkeit und das subjektive Nutzungsverhalten angeht. Genau in dieser Zeit gab der Begriff AJAX der Entwicklung einen Namen - und wurde von vielen Webdesignern mit Freude aufgenommen und umgesetzt.

2.2. Begriffsklärung

2.2.1. MVC

MVC ist ein Akronym für die Bezeichnung Model-View-Controller und repräsentiert ein Architektur- konzept in der Softwaretechnologie. Erstmals wurde ein MVC-ähnliches Vorgehen 1997 durch den Norweger Trygve Reenskaug in der Sprache Smalltalk aufgezeigt. Die Idee hinter MVC ist die Trennung der Anwendungslogik in einen Daten (Model) -, Präsentations (View)- und Steuerungsteil (Controller). Statt Anwendungen als homogene Einheiten zu konzeptionieren, die später nur schwer wartbar oder Teile davon nur schwer durch andere Implementierungen austauschbar sind, soll die Auftrennung in einer MVC-Architektur ein flexibleres Programmdesign und spätere Erweite- rungen unkompliziert ermöglichen. Komplexität soll dadurch reduziert werden. Die Model- Komponente definiere dabei die internen Datenstrukturen (mit entsprechenden Zugriffsmethoden) eines Programms, wobei keine Einschränkungen in der Repräsentation der Daten getroffen wer- den. Der Teil eines Programms, der mit View umschrieben wird, stelle eine Art frontend dar, welches die Daten dem Nutzer visuell darstellt und die Control-Komponente übernehme in einer MVC-Architektur die Koordinierung und Steuerung des Programmablaufs, sowie die Verwaltung der einzelnen Views.

2.2.2. Remote Scripting

Das Interesse an AJAX entstand vor allem aufgrund einer Funktionalität, die sich Remote Scripting nennt. Dies umfasst die Möglichkeit, einzelne Skripte auf Clientseite in einem Browser laufen zu lassen, die während der Ausführung Informationen mit einem Server austauschen, neue Funktio- nen auf einem Server aufrufen können und zurückgelieferte Ergebnisse weiterverarbeiten können, ohne dass aktuelle Statusinformationen der Seite verloren gehen. Die Erstellung von Webanwen- dungen basierend auf Remote Scripting umfasst daher die Entwicklung von Clientskripts und Serverskripts, die beide im Kontext einer einzelnen Webseite logisch vereint werden. Während Skripts auf Clientseite vorwiegend für die Darstellung und Realisierung eines User Interfaces ein- gesetzt werden, und so durch schnelle Antwortzeiten für Nutzer sehr lebendig wirken können, werden Serverscripts vorwiegend zur Realisierung von business logic im backend-Bereich genutzt (wodurch wiederum die Komplexität von clientseitigen Skripts erheblich reduziert werden kann)

Vor dem Aufkommen der XMLHttpRequest-Idee bestand das Problem, dass zu einem definierten Zeitpunkt Client- und Serverskripts nicht gleichzeitig ausgeführt werden konnten in dem Sinne, dass ein Serverskript zwar dynamische Inhalte an einen Webbrowser ausliefern konnte, bei einer Nutzerinteraktion jedoch ein neuer request an das Skript auf dem Server geschickt wurde, der die gesamte Seite erneut an den Browser schickte obwohl mitunter nur ein kleiner Teil der Webseite tatsächlich modifiziert wurde. Allein die Zeit zur Kommunikation mit dem Server erzeugte teilweise einen merklichen Overhead.

2.2.3. RIA

Webanwendungen, also Applikationen, die ohne Notwendigkeit einer Installation direkt auf Inter- netseiten aufgerufen und genutzt werden können, werden im Zuge der Web 2.0 - Debatte oftmals als Rich Internet Applications bezeichnet. Ein wesentliches Merkmal von RIAs ist, dass sich diese Anwendungen nicht mehr wie traditionelle Internetseiten verhalten, sondern vom Nutzungsverhal- ten kaum noch von gängigen Desktopanwendungen unterscheiden, das heißt, einem Nutzer stehen gleiche Interaktionsmöglichkeiten wie Menus, Schaltflächen, Fenster und Nutzerdialoge zur Verfügung wie er sie bereits seit Jahren von kommerziellen Softwareprodukten kennt. Zusätzlich kommunizieren RIAs im Hintergrund häufig mit anderen Datenbanken oder Webservices, können ohne Datenverlust sogar temporär auch offline eingesetzt werden. Im Zusammenspiel der neuen Techniken entsteht ein neues Nutzungsgefühl, welches oftmals als „reichhaltig“ umschrieben wird (das heißt eine Vielzahl von Funktionen bei einer minimalen Antwortzeit bietet) und sich von der hierarchischen Hypertextnavigation vergangener Jahre unterscheidet.

2.2.4. Widget

Widget ist ein Kunstwort aus dem Bereich der Softwaretechnik, welches aus den Teilen window und gadget zusammengesetzt ist, also alle Arten von Geräten („Fensterkontrollelemente“) zur In- teraktion umfasst, insbesondere alle graphischen Module, die auf Click-Events reagieren und manipuliert werden können (Schaltflächen, Trees, Registerkarten, … ). Dazu können widgets ent- sprechende Funktionen zugewiesen werden. WIdgets können eigenständig genutzt und in bestehende Internetseiten eingebunden werden um damit qualitativ hochwertige, intuitiv bedienba- re GUIs zu schaffen.

2.2.5. Wrapper

Der Begriff „wrapper“ ist ein Entwurfsmuster aus dem Bereich der Softwaretechnologie, in dem definiert wird, wie zwei Komponenten mit unterschiedlichen Schnittstellen oder anderen Inkompatibilitäten gemeinsam zusammenarbeiten können.

2.2.6. Stub

Stubs sind in der Softwareentwicklung einzelne Programmrümpfe, die stellvertretend für eine kon- krete Implementierung einer Programmkomponente stehen. Dies kann der Fall sein, wenn die eigentliche Softwarekomponente noch nicht fertig entwickelt ist, oder sich im Gegensatz dazu die eigentliche Programmkomponente auf einem anderen Rechner befindet, über ein Pseudoobjekt jedoch wie eine lokale Ressource angesprochen werden kann, um Komplexität zu verbergen.

2.3. Definition der Anwendungsdomäne

In diesem Abschnitt sollen grundlegende Prinzipien vorgestellt werden, deren Behandlung bei AJAX im Mittelpunkt stehen. Bezug nehmend auf eine Vorstellung unter [Pat06] sei dazu im Folgenden auf Web Remoting, Ausführung auf Clientseite, Widgets, visuelle Effekte und Browseranwendungen eingegangen.

2.3.1. Web Remoting

Was AJAX in vergangener Zeit so erfolgreich hat werden lassen, ist mutmaßlicherweise das A im Namen, welches die Möglichkeit repräsentiert, jederzeit asynchrone Anfragen an einen Server zu schicken, um von diesem spezifische Daten anzufordern. Während dieser Zeit steht die Applikation nicht zwangsweise still, um auf das Eintreffen der Serverantwort zu warten, sondern kann in der Regel ohne Einschränkungen weiter bedient werden, was die eigentliche Anfrage an den Server im Hintergrund transparent werden lässt.

Abbildung 3: traditioneller Ablauf bei der Anforderung von Daten von einem Webserver: Die gesamte Website wird neu gela- den, im Beispiel: eine Bilderauswahl unter http://www.flickr.com

Abbildung in dieser Leseprobe nicht enthalten

Javascript wird also um Funktionen erweitert, die genutzt werden können, um zur Ausführungszeit direkt HTTP-Anfragen an einen Webserver stellen zu können. Internetbrowser der neuesten Gene- ration implementieren dazu ein Javascript-Objekt namens XMLHttpRequest, dessen Methoden nach einer Instantiierung genutzt werden können. Im Microsoft Internet Explorer Version 6 geschah dies noch über ein eigenes ActiveX-Objekt.

Das Ziel ist dabei in erster Linie, das Neuladen kompletter Internetseiten zu vermeiden im Falle, dass sich eigentlich nur einzelne Seitenbereiche verändern. Objektiv betrachtet war dieser Ansatz bereits seinerseits mit frames realisierbar, doch geht der AJAX-Ansatz über die Idee von frames weit hinaus. So können die asynchron angefragten Daten direkt in Javascript weiterverarbeitet und letztendlich dank des Dynamic Object Models an beliebiger, nicht vorher explizit per Tag ausge- zeichneter Stelle in ein HTML-Dokument hineingeladen werden. Darüber hinaus ist nicht nur das Abfragen von Daten von einem Webserver möglich, sondern ebenso das Senden von Daten an einen Webserver, was diese Technik universell einsetzbar werden lässt. Mit Daten, die von der AJAX Engine gesendet und empfangen werden können, ist dabei keine Einschränkung getroffen worden: Sowohl XML, ein spezielles Serialisierungsformat namens JSON als auch reiner Text können beliebig übertragen werden. Besonders XML ist für eine Kommunikation mit Webservern interessant, die bestimmte Dienste anbieten, weswegen an dieser Stelle auf die Thematik Webser- vices verwiesen sei.

Abbildung 4: Die gleiche Anfrage wie in Abb. 2 mittels AJAX, während die AJAX Engine auf das Eintreffen der HTTP Res- ponse wartet, kann der Nutzer die ursprüngliche Seite uneingeschränkt weiter benutzen

Abbildung in dieser Leseprobe nicht enthalten

2.3.2. DOM-Manipulation

Ein weiteres Grundprinzip von AJAX ist es, jede mögliche Operation von Server- auf Clientseite zu verlagern. Während es bedingt durch den steigenden Einsatz von Serverskriptsprachen zuneh- mend dazu kam, dass alle Daten an einen Webserver gesendet wurden, der die Validierung dieser Daten übernahm und anschließend entsprechende Berechnungen durchführte, soll dies in der AJAX-Philosophie zunehmend auf Clientseite im Webbrowser stattfinden. Beispielsweise kann die Überprüfung von eingegebenen Formulardaten direkt auf Clientseite mittels Javascript erfolgen, wodurch eine sofortige Rückmeldung noch während der Eingabe an den Nutzer gewährleistet wer- den kann - was wiederum direkt dem AJAX-Ansatz entspricht, Ladezeiten zu minimieren und neue interaktive Interaktionsmöglichkeiten zu schaffen. In Kombination mit bestehenden und lange be- reits bekannten Techniken von DHTML besitzt der Programmierer alle Möglichkeiten, ein HTML- Dokument direkt auf Clientseite über das DOM dynamisch zu verändern.

2.3.3. Widgets

Kein unmittelbarer Bestandteil, aber im Rahmen von AJAX als innovative Technik für das Web 2.0 mit verbreitet hat sich der zunehmende Einsatz von kleinen Bedienassistenten, die dem Nutzer Informationen interaktiv und grafisch aufbereitet zur weiteren Verarbeitung präsentieren. Exempla- risch seien an dieser Stelle Infofenster, Baumstrukturen, Navigationstabs oder sortierbare Tabellenelemente genannt, die in Desktopanwendungen schon lange bekannt sind. Da deren Pro- grammierung auf Webseiten bis vor kurzem relativ aufwändig war, fand man solche „Widgets“ bisher höchstens als Spielereien vor. Durch die zunehmende Verbreitung von AJAX und entsprechender frameworks werden nun in speziellen Applikationsframeworks immer häufiger fer- tige Funktionen bereit gestellt, mit denen relativ einfach Daten entsprechend aufbereitet und dargestellt werden können - und dies in erprobten Implementierungen, die in der Mehrzahl aller gängigen Internetbrowser das gleiche fehlerfreie Ergebnis liefern sollten. In diesem Sinne knüpft der Hype um die AJAX-Technologie an Methoden des Software-Engineerings an, die von Desk- topapplikationen schon längst bekannt sind: Programmierer werden stärker ermutigt, bereits bestehende, zuverlässige Lösungen zu nutzen, als in mühevoller Arbeit immer wieder von Neuem eine eigene Problemlösung implementieren zu müssen.

2.3.4. Visuelle Effekte

Das Gleiche, was bereits in 2.3.3 über die Wiederentdeckung von Bedienassistenten gesagt wurde, gilt ebenso für sonstige Animationen und Effekte. Nachdem 1998 mit dynamischem HTML (DHTML) in den Browsern die Möglichkeiten geschaffen wurden, beliebige grafische Effekte auf Webseiten mittels Javascript zum Einsatz kommen zu lassen, fanden sich seitdem nur wenige sinnvolle Anwendungen auf Internetseiten im Netz. Immer wieder wurde gewarnt, nicht zu viele von diesen Effekten einzusetzen, da diese den Nutzer abschrecken könnten, wenn sie übermäßig oft eingesetzt würden. Darüber hinaus stand mit Adobe (früher Macromedia) Flash eine professionelle Alternative bereit, grafisch aufwändige Seiten konsistent zu entwickeln.

Durch die aktuellen Entwicklungen rund um das Thema AJAX und die Möglichkeit, direkt auf Clientseite mit Daten von einem Webserver umzugehen, stieg nun auch wieder das Interesse an erweiterten Layoutmöglichkeiten mit den Bordmitteln der Internetbrowser. Drag and Drop - Effekte wurden wieder entdeckt, die ohne ein zusätzliches Plugin intuitiv benutzbar sind.⁶ Da auch diese Effekte inzwischen gebündelt in Applikationsframeworks bereitgestellt werden (man sich so nicht für jeden neuen Effekt erst auf die Suche nach einer passenden Funktionsbibliothek machen muss) und eine einfache API bieten, ist auch der Einsatz dieser Möglichkeiten in den letzten Monaten beachtlich gestiegen.

2.3.5. Browseranwendungen

Überhaupt ist es durch die Idee hinter AJAX zu einer Reihe neuer Anwendungsangebote im Internet gekommen, die bis vor kurzem in dieser Form nicht vorstellbar oder zumindest schwer realisierbar waren. Neben interaktiven Terminplanern finden sich inzwischen leicht zu bedienende Fotoalben bis hin zu ganzen Textverarbeitungs- und Tabellenkalkulationsprogrammen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Mit AJAX verschwinden allmählich die Grenzen zwischen Desktop- und Webanwendungen, Bsp.: http://www.bindows.net

Die Grenze zwischen klassischen Desktopanwendungen und Webapplikationen scheint durch die Entwicklungen, die mit der Verbreitung von AJAX eingesetzt haben, mehr und mehr zu verwischen. Ein gutes Beispiel dafür, was mithilfe von AJAX frameworks (die die zugrunde liegende Komplexi- tät abstrahieren und einfache Möglichkeiten zur Erstellung von Webanwendungen bereitstellen) heute bereits möglich ist, zeigt unter anderem die Seite www.bindows.net [Bin06].

2.4. Beispiel-Szenarien

Bevor in Kapitel 3 näher auf AJAX frameworks eingegangen wird, sollen im Folgenden zunächst drei Beispielanwendungen verdeutlichen, wie AJAX zur Lösung bestehender Problemszenarien genutzt werden kann und wo bei der Programmierung möglicherweise Probleme auftreten können. Diese Beispiele sollen schließlich im experimentellen Teil als Grundlage genutzt werden, um Kriterien für die Evaluierung verschiedener frameworks definieren zu können.

2.4.1. „Hello World“ example

Als erstes Beispiel soll die klassische „Hello World“ - Ausgabe in einer modifizierten Variante dienen, welche die Stärken und Schwächen von AJAX hervorheben soll.

Beschreibung: Die aufgerufene HTML-Datei enthält einen Hyperlink mit der Beschriftung „La- den“ sowie zwei ausgezeichnete Ebenen mit den Identifikatoren div1 und div2. Nach Klick auf den Link „Laden“ soll in die Ebene div1 der Inhalt einer Datei hello1.txt hineingeladen werden und gleichzeitig in die Ebene div2 der Inhalt der Datei hello2.txt. Die Dateien hello1.txt und hello2.txt befinden sich beide im gleichen Dateisystem relativ zu der eigentlichen HTML-Datei, die aufgeru- fen wurde. hello1.txt enthalte den Schriftzug „Hallo Welt1“ und hello2.txt den Schriftzug „Hallo Welt2“. Zielsetzung:

- Verdeutlichen des Einsatzes von AJAX
- Fallunterscheidung für verschiedene Browser
- Behandlung paralleler HTTP-Requests

Ein möglicher klassischer Lösungsansatz könnte so aussehen, dass der Inhalt der HTML-Datei dynamisch mithilfe einer Skriptsprache wie beispielsweise PHP erstellt wird. Listing 1 zeigt eine mögliche Realisierungsvariante.

Abbildung in dieser Leseprobe nicht enthalten

Listing 1: "Hello World" - klassische Realisierung mit PHP

2.4. Beispiel-Szenarien

Um das Beispiel nun mithilfe einer asynchronen Anfrage zu realisieren, ist die gesamte Logik auf Clientseite zu verlagern und mittels JavaScript und dem XMLHttpRequest-Objekt zu realisieren, wie beispielsweise Listing 2 zeigt:

Abbildung in dieser Leseprobe nicht enthalten

Listing 2: Das "Hello World" Beispiel als AJAX-Realisation⁷

Evaluierung von AJAX-basierten frameworks für das Web 2.0

2. Grundlegende Betrachtungen

Was die genaue Bedeutung der Befehle und Argumente zur Initialisierung des AJAX-Requests angeht (Listing 2, Zeilen 05-08 und 11-13), sei an dieser Stelle auf die jeweilige Fachliteratur ver- wiesen.

Unter Annahme einer fehlerfreien Testumgebung funktioniert Listing 2 unter folgenden zwei Einschränkungen:

- als Internetbrowser auf Clientseite wurde der Mozilla Browser, Firefox, Safari ab Version 1.3, Opera ab Version 7.6 oder der Internet Explorer ab Version7.0 verwendet

- Nach Klick auf den Link „Laden“ enthält sowohl die Ebene div1 als auch die Ebene div2 den gleichen Text, in der Regel „Hello World2“

Benutzt man beispielsweise den Internet Explorer 6.0, so bietet dieser zwar ebenfalls einen AJAX- Support, der jedoch in Form einer ActiveX-Komponente namens „Microsoft.XMLHTTP“ zur Verfü- gung steht, was eine Fallunterscheidung nötig macht, in welchem Browser die jeweilige HTML- Datei nun tatsächlich verarbeitet wird. Weiterhin würden die Nutzer anderer Browser benachteiligt werden, welche keine AJAX-Unterstützung bereitstellen. Statt einer Fehlermeldung wäre es mög- lich, dass eine Alternativlösung bereitgestellt wird, die unter Verwendung von iframes die Abfrage einer Ressource auf einem Webserver realisiert und so das AJAX verhalten nachahmt und vor dem Nutzer verbirgt („fallback-Lösung“)

Das zweite Problem entsteht dadurch, dass zwar für jede Anfrage eine eigene Instanz des XMLHttpRequest-Objekts erzeugt und der Variable request zugewiesen wird, diese jedoch eine lokale Variable in der gleichen Javascript-Funktion für beide Aufrufe darstellt und die Referenz auf die erste Instanz in der Variablen request sofort beim zweiten Aufruf der httpRequest()-Funktion überschrieben wird.

Daneben existieren weitere Fallstricke, die nicht sofort offensichtlich sind. Wird beispielsweise ein dynamisch generierter Dateiinhalt vom Webserver angefordert, so wird laut HTTP-Spezifikation ohne weitere Vorkehrungen bei GET-Anfragen der empfangene Dateiinhalt in einem Cache zwi- schengespeichert. Wird die Datei später ein zweites Mal angefordert, so wird der Inhalt unter Umständen direkt aus dem lokalen Browsercache geladen, ungeachtet dessen ob sich der dyna- mische Inhalt auf Serverseite vielleicht geändert hat. Der Internet Explorer implementiert dieses Verhalten korrekt, was jedoch ohne Beachtung dieser Cachingeffekte zu schwer zu findenden Problemen führen kann. Eine mögliche Lösung wäre beispielsweise, Requests nur per POST zu versenden, was nicht immer möglich ist, oder in jedem GET-Request einen eindeutigen Parame- terwert im Query String der URL zu ergänzen.

Abbildung in dieser Leseprobe nicht enthalten

Listing 3: Das "Hello World"-Beispiel in einer verbesserten AJAX-Variante

2.4.2. Adresskartei

Anwendungsbeispiel 2 sei ein Standardbeispiel, welches bei vielen framework-tutorials als Einführungsbeispiel realisiert wird: Eine webbasierte Adresskartei.

Beschreibung: Es ist eine Webanwendung zu realisieren, die das Eintragen von Adressdaten in und das Abfragen von Kontaktdaten aus einer Adressdatenbank ermöglicht. Die Webseite dafür bestehe aus insgesamt drei Bereichen. Eine Ebene mit der ID eingabe enthalte ein Formular, des- sen eingegebene Daten nach Absenden dieses Formulars in die Adressendatenbank übernommen werden sollen. Die zweite Ebene mit der ID namen enthalte eine Übersicht der Namen aller bereits in der Datenbank eingetragenen Kontakte. Die dritte Ebene mit der ID info enthalte schließlich nach Auswahl eines Kontaktes dessen vollständige Adressübersicht aus der Datenbank. Alle Ad- ressdaten werden in einer MySQL-Datenbank gespeichert. Eine entsprechende ausführbare Datei auf dem Webserver (im Quelltextbeispiel zugriff.php genannt) im gleichen Verzeichnis auf dem Server stelle dazu die nötigen Funktionen bereit, um per POST übertragene Formulardaten in die Datenbank zu übernehmen (Definition beispielsweise durch zugriff.php?cmd=insert).und eine Liste aller Vor- und Zunamen der in der Datenbank enthaltenen Kontakte bereitzustellen (zugriff.php?cmd=namen). Um die XML-Unterstützung in AJAX testen zu können, werden die voll- ständigen Adressdaten eines einzelnen Kontaktes im XML-Format bereitgestellt (daten.xml.php mit Parameter ?contact=[contactid]).

Zielsetzung:

- Datenübermittlung via POST
- Umgang mit Formularen
- Aufruf einer Funktion auf einem Webserver
- Umgang mit XML-Daten
- Behandlung von Zeichensätzen

Des Weiteren soll dieses Beispiel später Möglichkeiten einer Erweiterung der Nutzerfreundlichkeit durch AJAX frameworks bieten, sodass beispielsweise die Ebene namen durch ein Eingabefeld mit einer Autocomplete-Funktion ersetzt werden könnte, die Formulardaten während der Eingabe automatisch validiert werden oder die Ebenen insgesamt beispielsweise als Registerkarten voneinander getrennt werden können.

Listing 4 zeigt die klassische Realisierung des gestellten Problemfalls mittels PHP. Die Variable $db sei ein Platzhalter für die konkrete Datenbankbezeichnung und die Funktion mysqldata() abstrahiere von den konkreten Anfrageoperartionen. Ebenfalls seien Funktionen zur Herstellung der Datenbankverbindung und zum Parsen der XML-Daten nicht aufgeführt.

Abbildung in dieser Leseprobe nicht enthalten

Listing 4: Eine mögliche Implementierung des Beispiels 2 mittels PHP

Um dieses Beispiel zu „ajaxifizieren“ ist es nötig, die AJAX-Hilfsfunktionen aus Listing 2 zu erweitern, damit auch Daten via POST gesendet werden können. Des Weiteren steht nun das „X“ aus AJAX im Mittelpunkt, wie XML-Daten behandelt und eingebunden werden. Listing 5 zeigt eine beispielhafte Implementierung.

Abbildung in dieser Leseprobe nicht enthalten

Listing 5: Das Adresskarteibeispiel basierend auf AJAX

2.4. Beispiel-Szenarien

2.4.3. AJAX-Bildergalerie

Das dritte Beispiel soll als Grundlage dazu dienen zu zeigen, was mit AJAX frameworks für unterschiedliche Effekte realisiert werden können und wo diese sinnvoll dosiert einsetzbar sind.

Beschreibung: Es ist eine einfache Bildergalerie zu realisieren. Die entsprechende HTML-Datei besteht dazu aus drei Bereichen. Die erste Ebene mit der ID thumbs enthalte dazu drei Vorschaubilder (thumbnails), die in einem entsprechenden Verzeichnis auf dem Webserver liegen und exemplarischdie Dateinamen tpic1.jpg, tpic2.jpg und tpic3.jpg haben. Eine zweite Ebene mit der Bezeichnung bild enthalte jeweils das korrespondierende Bild pic1.jpg, pic2.jpg oder pic3.jpg in Normalansicht, welches durch den Nutzer im Vorschaubereich ausgewählt wurde. Darunter existiert eine dritte Ebene mit der ID kommentar, welche vom Webserver dem Bild zugeordnete Kommentare abruft und entsprechend anzeigt. (Diese können auf verschiedenste Wege bereitgestellt werden, im Beispielquellcode als Tabelle in einer MySQL-Datenbank, welche analog zum Beispiel 2 über ein Skript auf dem Server abgefragt wird)

Zielsetzung:

- Es ist nach Animationen und Effekten zu suchen, die diese Bildergalerie für den Benutzer interessant und intuitiv bedienbar erscheinen lassen. Vorstellbar sind Fade-In-Effekte (zum Beispiel Yellow-Fade-Techniken), aber auch Drag and Drop-Effekte oder eine alternative Bilderauswahl mithilfe geeigneter Widgets.

Die grundlegende Realisierung der Funktionalität sollte keine neuen Probleme oder Anforderungen im Vergleich zu den Beispielszenarien 1 und 2 aus den vorhergegangenen beiden Unterkapiteln darstellen und ist in den Listings 6 und 7 aufgezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Listing 6: Beispiel 3 in einer klassischen Realisierung mit PHP

[...]

---

¹ Etwas vereinfacht betrachtet hat sich das zugrunde liegende Konzept des WWW seit 1989 mit der Einführung der Hyper- Text Markup Language am CERN nicht mehr wesentlich geändert.

² An dieser Stelle wird in Publikationen und Artikeln häufig auf bekannte Beispiele wie GoogleMaps (http://maps.google.com), GoogleSuggest (http://labs.google.com/suggest/) oder beispielsweise Flickr (http://www.flickr.com) verwiesen.

³ Dass sich aufgrund derartiger Slogans und Schlagwörter schnell ein nur schwer zu kontrollierender Hype entwickeln kann, bei dem mit zunehmendem Fortschreiten Begrifflichkeiten und ursprüngliche Konzepte immer stärker verwässern, wird am Beispiel Web 2.0, AJAX und Mashup schnell deutlich. So verwundert es nicht, dass bereits im Jahr 2006 erste Spekulatio- nen wie „Überholt das Web 3.0 gar das Web 2.0“ [Bas06] in einigen Weblogs zu finden waren, welche zumeist ohne wissenschaftlichen Hintergrund von Unternehmen und anderen selbst ernannten Experten zu Marketingzwecken genutzt wurden. Professur Verteilte und Selbstorganisierende Rechnersysteme

⁴ Siehe Kapitel 2.1

⁵ Gesucht wurde am 08.02.07 nach der Wortkombination „+ajax +xml“ Professur Verteilte und Selbstorganisierende Rechnersysteme

⁶ Als Beispiel seien hierfür die Konfigurationsmöglichkeiten auf der personalisierten Startseite von http://www.google.de genannt

⁷ Sonstige, für die korrekte Funktionalität irrelevante Anweisungen wie Meta- oder Stylesheet-Angaben werden in den abgedruckten Beispielquelltexten nicht abgebildet. Ebenso liege der Fokus zunächst nicht auf Best Practise - Empfehlungen, welche Vor- und Nachteile beispielsweise der Aufruf von Javascript-Funktionen über „href=’javascript:foo()’“ oder als „onclick=’foo()’“ - event bietet, sowie mögliche Modifikationen der Quelltexte hinsichtlich Fallback-Möglichkeiten um die Funktionalität der Internetseite zu gewährleisten, falls bspw. Javascript deaktiviert sein sollte.