Wikipedia

Ajax (Programmierung)

Konzept der asynchronen Datenübertragung zwischen Browser und Server
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 6. November 2005 um 01:34 Uhr durch Schlurcher (Diskussion | Beiträge) (Entfernung der Vorlage:Langlink Siehe auch Löschdiskussion). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Ajax [ˈeɪdʒæks] ist ein Akronym für die Wortfolge Asynchronous Javascript and XML. Mit diesem Akronym wird ein Konzept der Datenübertragung zwischen einem Server und dem Browser beschrieben, welches es ermöglicht, dass die HTML-Seite nicht mit jeder HTTP-Protokoll-Anfrage komplett neu geladen werden muss. Das eigentliche Novum besteht in der Tatsache, dass nur gewisse Teile einer HTML-Seite sukzessive bei Bedarf nachgeladen werden.

Wer den Begriff Ajax in diesem technologischen Kontext erfunden hat, ist nicht mehr eindeutig nachvollziehbar. Sicher ist jedoch, dass ihn Jesse James Garrett, ein Mitarbeiter der Agentur Adaptive Path, in seinem Essay Ajax: A New Approach to Web Applications maßgeblich geprägt hat. Grundsätzlich waren die technologischen Grundlagen und die Vorgehensweise aber bereits vorher bekannt, und wurde generell mit dem Begriff XMLHttpRequest beschrieben. Wenn man so will, hat Garret also den Brand Ajax erschaffen, um so diverse Software-Technologien unter einem Begriff zu subsumieren.

Technologisch betrachtet, handelt es sich bei Ajax um keine Neuerung. Vielmehr repräsentiert Ajax eine Synthese aus bereits bestehenden Technologien, mittels derer interaktive, Desktop-ähnliche Web-Anwendungen realisiert werden können. Diese vermitteln so den Eindruck, als ob das Problem der zustandlosen Web-Anwendung behoben wurde. Um eine Ajax-Anwendung realisieren zu können, werden die nachfolgenden Webtechniken benötigt:

Das Model einer traditionellen Web-Anwendung (links) im direkten Vergleich mit einer Ajax Web-Anwendung (rechts). Sämtliche Anwendungsdaten werden auf dem Server in einer Datenbank- und/oder einem Legacy-System abgespeichert.
  • HTML (oder XHTML) und CSS um das Aussehen einer Web-Seite beeinflussen zu können.
  • Das Document Object Model, welches mittels JavaScript verändert werden kann, um so Inhalte dynamisch anzeigen bzw. verändern zu können.
  • Datenaustausch und -manipulation wird mittels XML und XSLT getätigt.
  • Das XMLHttpRequest-Objekt, um Daten auf asynchroner Basis mit dem Web-Server austauschen zu können. (In diesem Kontext wird vornehmlich XML als Trägermedium der einzelnen Daten benutzt. Es ist jedoch auch denkbar, formatiertes HTML, einen ASCII-Text, JSON oder gar EBML zu verwenden).
  • Sowie JavaScript als zentrale Schnittstelle zu den einzelnen Komponenten.


Geschichte

Die Idee und die damit verbundenen Technologien, welche dem Ajax-Konzept zugrunde liegt, gibt es in vergleichbarer Form schon seit etwa 1998. Die erste Komponente, die es ermöglichte Client-seitig eine HTTP-Anforderung auszulösen, wurde durch das Outlook Web Access Team erstellt. Diese Komponente ist Teil des Microsoft Exchange Servers und wurde auch alsbald als Bestandteil des Internet Explorer 4.0 ausgeliefert [1]. Manche Beobachter stufen Outlook Web Access als ersten erfolgreichen Vertreter des Ajax-Konzepts ein. Später folgten Anwendungen wie Oddposts Webmail-Produkt. Im Jahr 2005 war der Begriff Ajax zunehmend durch einige wegweisende Ereignisse in den Medien präsent. Zum einen benutzte Google das asynchrone Kommunikations-Paradigma in einigen bekannten, interaktiven Anwendungen wie beispielsweise Google Groups, Google Maps, Google Suggest und nicht zuletzt Gmail. Zudem wurde der Begriff Ajax als solcher, wie bereits erwähnt, von Garrett geprägt. Der zugehörige Artikel hat im Ajax-Umfeld inzwischen einen gewissen Bekanntheitsgrad erlangt. Letztlich hat sich die Ajax-Unterstützung der Gecko-Engine in einem Maß entwickelt, welche es ermöglicht die Ajax-Technologie in vielfältiger Weise einzusetzen.

Vergleich mit herkömmlichen Web-Anwendungen

Datei:Ajax-prozessfluss-traditionell.png
Der Prozessfluss einer traditionellen Web-Anwendung.

Ajax-Anwendungen erwecken den Eindruck, als ob sie gänzlich auf dem Computer des Anwenders ausgeführt werden. Der Prozessfluss einer traditionellen Web-Anwendung wird hingegen durch die zustandslose Natur des HTTP-Protokolls fortwährend unterbrochen. Dies lässt schnell erkennen, dass eine traditionelle Web-Anwendung auf mehrere Bereiche verteilt wurde.

„Jede Benutzeraktion, die für gewöhnlich eine HTTP-Anfrage erzeugen würde, erzeugt nun einen JavaScript-Aufruf, der an die Ajax-Engine delegiert wird [...]“, so beschreibt es Garrett in seinem Essay. „Jede Antwort auf eine Aktion des Nutzers, die keine Verbindung zum Server erfordert, – wie beispielsweise das Validieren von Daten, das Verändern von Daten, welche sich im Speicher befinden und sogar das Navigieren zwischen einzelnen Elementen der Web-Seite – all dies kann von der Ajax-Engine bewältigt werden. Benötigt die Ajax-Engine Daten vom Server, um eine bestimmte Aktion erfolgreich durchführen zu können – es kann sich hierbei beispielsweise um das Übertragen von Daten, die verarbeitet werden müssen, um das Nachladen einzelner Bausteine der Benutzeroberfläche oder um das Laden neuer Daten handeln –, führt diese eine asynchrone Anfrage, für gewöhnlich in Form eines XML-Dokuments, an den Server durch. Dabei wurde jedoch die Interaktion des Benutzers mit der Anwendung, wie dies bei gewöhnliche Web-Anwendungen der Fall ist, nicht unterbrochen [...]“.

Traditionell übermitteln Web-Anwendungen im Grunde Formulare, die zuvor vom Benutzer ausgefüllt wurden, an einen Webserver. Der Webserver antwortet, indem er dem Browser des Nutzers eine neue Webseite schickt. Aufgrund der Tatsache, dass der Webserver bei jeder Anfrage seitens des Nutzers eine neue Webseite erzeugen und übermitteln muss, erscheint die Anwendung dem Benutzer insgesamt als träge und wenig intuitiv, vergleicht man diese mit einer gewöhnlichen Desktop-Anwendung.

Ajax-Anwendungen hingegen sind in der Lage Anfragen an den Server zu schicken, um mit diesen nur die Daten anzufordern, die tatsächlich benötigt werden. Für gewöhnlich geschieht dies über den Aufruf eines SOAP Web Services oder eines vergleichbaren XML-basierten Web-Service-Dialekts. Der Client, also der Webbrowser, verarbeitet die Antwort des Servers nicht direkt, sondern schleust diese durch den JavaScript-Prozess der Ajax-Engine. Im Ergebnis erhält man so eine Benutzeroberfläche, die sehr viel zügiger auf Benutzereingaben reagiert. Ein Grund für dieses veränderte Verhalten ist die Tatsache, dass wesentlich weniger Daten zwischen Webbrowser und Webserver ausgetauscht werden müssen. Zudem wird die Webserverlast reduziert, da schon viele Verarbeitungsschritte Client-seitigt getätigt werden können.

Abschließend sei noch auf eine Webseite als Ajax-Beispiel hingewiesen, die es erlaubt, Fotografien zu verwalten. Möchte der Benutzer beispielsweise einem Foto eine Beschreibung oder einen Titel hinzufügen, so müsste bei einem traditionellen Programmieransatz die gesamte Seite, einschließlich der Bilder, neu generiert werden. Mit der Ajax-Technologie wird beispielsweise DHTML verwendet, um nur tatsächlich den Bereich der Webseite zu erneuern, der auch verändert wurde. Dies ist ein reelles Beispiel, das veranschaulicht, wie es innerhalb der Flickr-Anwendung möglich ist, Titel einzelner Bilder zu verändern.

Datei:Ajax-prozessfluss-ajax.png
Der Prozessfluss einer Anwendung, wie er sich bei Ajax darstellt.

Die Ajax-Plattform

Ajax-Anwendungen können in Webbrowsern, welche die zuvor genannten Techniken unterstützen, ausgeführt werden. Die Ajax-Anwendung die in einem Webbrowser ausgeführt wird, bezeichnet man als Client-Plattform.

Die eigentliche Programmlogik oder der Prozessfluss der Anwendung ist auf einem Server hinterlegt. Dies geschieht in Form von EJBs, .NET-Komponenten oder aber in Form von Skript-Komponenten wie sie beispielsweise von der Skriptsprache Ruby zur Verfügung gestellt werden. Das Ajax-Konzept selbst erfordert keine spezifische Technik, mittels derer die Server-seitige Programmlogik umgesetzt werden muss. Sowohl der Server, als auch die Anwendungslogik wird im Ajax-Kontext als Server-Plattform bezeichnet.

Vor-/Nachteile und Kritik

Der größte Vorteil der Ajax-Technologie ist die Tatsache, dass Daten verändert werden können, ohne dass die komplette Webseite vom Webbrowser neu erzeugt werden muss. Dies erlaubt es Web-Anwendungen, auf Benutzereingaben schneller zu reagieren. Zudem wird vermieden, dass redundante Daten, die sich unter Umständen nicht geändert haben, fortwährend über das Internet übertragen werden müssen. Da die Ajax-Technologien frei zugänglich sind, werden sie unabhängig vom Betriebssystem von den Webbrowsern unterstützt, die auch JavaScript unterstützen. Dies setzt voraus, dass die JavaScript-Unterstützung nicht deaktiviert wurde. Vergleichbare Techniken, wie etwa Macromedias Shockwave oder Flash, sind immer noch mit dem Nachteil behaftet, dass sie ein Browser-Plugin benötigen und nicht immer für alle Plattformen verfügbar sind.

Wie bereits angedeutet wird für Ajax zwar kein Plugin benötigt, dennoch muss die Unterstützung für JavaScript vom Benutzer in dessen Webbrowser aktiviert sein. Wie es auch bei DHTML-Anwendungen zur Praxis geworden ist, muss auch eine Ajax-basierte Anwendung rigoros getestet werden, um so die Eigenarten der diversen Webbrowser entsprechend behandeln zu können. Im Laufe der Zeit hat sich die Ajax-Technologie weiter entwickelt, was dazu führte, dass für diese nun diverse Programmbibliotheken zur Verfügung stehen. Diese können zu einer fehlerfreien und einfacheren Anwendungsprogrammierung beitragen. Es wurden ebenfalls Techniken entwickelt, die es ermöglichen, Anwendungen zu entwerfen, die einer Desktop-Anwendung nahe kommen. Zudem bieten diese die Möglichkeit, auch Benutzer, die einen Webbrowser ohne JavaScript-Unterstützung einsetzen, in geeigneter Weise zu bedienen. Einer der häufigsten Vorwürfe gegen die Ajax-Technologie, ist die Tatsache, dass es schwer möglich ist, die Funktionalität des Zurück-Buttons des Browsers zu gewährleisten (siehe: Jakob Nielsens 1999 Top-10 New Mistakes of Web Design). Es besteht die Gefahr, dass das Drücken des Zurück-Buttons nicht den vorherigen Zustand der Anwendung wiederherstellt, da Browser für gewöhnlich nur statische Seiten in ihrer Historie abspeichern. Das Unterscheiden zwischen einer statischen Seite, die gänzlich in den Cache des Browsers geladen wurde, und einer Seite, die auf dynamische Weise verändert wurde, mag kniffelig sein. Grundsätzlich erwartet ein Benutzer, dass ein Drücken des Zurück-Buttons die zuletzt getätigte Aktion revidiert. Bei Ajax ist dies nicht immer der Fall. Software-Entwickler haben verschiedenste Lösungen erfunden, um diesem Problem zu begegnen. Die meisten Lösungen basieren auf so genannten Iframes, ein weiteres HTML-Element. Das Iframe-Element ist für den Nutzer nicht sichtbar und wird benutzt, um die Browser-Historie des Nutzers auf diesem Umweg zu befüllen (Google Maps z.B. führt eine Suche in einem nicht sichtbaren Iframe-Element durch und befüllt mit den daraus resultierenden Ergebnissen das Ajax-Element der sichtbaren Webseite). Das Dojo-Toolkit erlaubt es, die einzelnen Ajax-Anforderungen mittels so genannter Callbacks zu verfolgen. Die Callbacks werden immer dann ausgelöst, wenn der Nutzer den Zurück-Button des Browsers betätigt. Über diesen Umweg ist es möglich, den vorherigen Zustand der Anwendung wiederherzustellen.

Ein durchaus ähnlich gelagertes Problem ist die Tatsache, dass es bei Webseiten, die dynamisch aktualisiert werden, beinahe unmöglich ist, ein Bookmark auf einen ganz bestimmten Zustand einer Web-Anwendung zu setzen. Auch für dieses Problem wurden zwischenzeitlich Lösungen entwickelt. Meistens wird in diesem Zusammenhang der Anker in der gegenwärtigen URL verwendet, der nach der Raute (#) steht. Auf diese Weise ist es möglich, den Prozessfluss einer Anwendung zu verfolgen. Zudem wird es dem Benutzer so ermöglicht, über den genannten URL-Teil einen bestimmten Anwendungszustand wiederherzustellen. Viele Webbrowser ermöglichen es, den Anker durch JavaScript dynamisch zu aktualisieren. Dies ermöglicht es einer Ajax-Anwendung, den Inhalt der dargestellten Webseite parallel zur Verarbeitung zu aktualisieren. Diese Lösungsansätze beheben auch einige der Probleme, die durch den nicht funktionierenden Zurück-Buttons entstehen.

Die Netzwerk-Latenzzeit – oder das zeitliche Intervall zwischen einer HTTP-Anfrage des Browsers und der zugehörigen Server-Antwort – muss bei der Entwicklung einer Ajax-Anwendung berücksichtigt werden. Ohne ein klar ersichtliches Feedback für den Benutzer ([2]), vorausschauendes Laden einzelner Anwendungsdaten ([3]) und einem korrekten Umgang mit dem XMLHttpRequest-Objekt ([4]), kann sich einem Benutzer der Eindruck aufdrängen, dass die gesamte Anwendung nur zähflüssig auf dessen Aktionen reagiert. Für gewöhnlich ist dies ein Umstand, der sich dem Benutzer nur schwer erschließt ([5]). Aus diesem Grund ist es wichtig, so genannte visuelle Feedbacks, wie beispielsweise das Symbol einer Sanduhr, zu verwenden, um den Benutzer darauf aufmerksam zu machen, dass momentan gewisse Hintergrundaktivitäten stattfinden oder Daten bzw. Inhalte geladen werden.

Unabhängig von den technischen Schwierigkeiten von Ajax gab es in der Vergangenheit immer wieder Kritik daran, dass das Unternehmen Adaptive Path, welches den Begriff Ajax ursprünglich geprägt hat, oder andere Unternehmen den Begriff als Marketing-Vehikel benutzen, obwohl die Grundlagen von Ajax auch in der Vergangenheit weitestgehend bekannt waren.

Barrierefreies Internet

Soll die Ajax-Technologie eingesetzt werden, so stellt dies eine Herausforderung dar, wenn die Web-Anwendung den WAI-Regeln folgen soll. Software-Entwickler müssen aus diesem Grund Alternativen anbieten, wenn eine Webseite beispielsweise auch für blinde Nutzer mit einem Screenreader zugänglich sein soll. Dies ist notwendig, da die Mehrzahl aller Ajax-Anwendungen für herkömmliche grafische Webbrowser entworfen wurden.

Aktuell stehen verschiedene Möglichkeiten zur Verfügung, um eine Ajax-Anwendung einer Suchmaschine zugänglich zu machen. Die einzelnen Ansätze variieren im Grad der Indizierung, die erreicht werden kann, und der Art, wie dies erreicht wird. Für einige Webseiten, wie beispielsweise die eines Studiengangs einer Universität, ist es notwendig, dass jeder einzelne Bereich durch eine Suchmaschine erfasst werden kann. Eine Seite jedoch, die einen Webmail-Service zur Verfügung stellt, wird dies nicht erforderlich machen. Nachfolgend sind einige Strategien genannt, die es ermöglichen einen Webauftritt durch eine Suchmaschine indizieren zu lassen:

  • Lightweight Indexing: An der eigentlichen Webseite werden keine strukturellen Änderungen vorgenommen. Es werden jedoch bereits existierende Elemente, wie beispielsweise Meta-Tags oder Überschriften-Elemente für die Indizierung verwendet.
  • Extra Link Strategy: Zusätzliche Links werden auf der Webseite platziert, denen Suchroboter folgen können um so den gesamten Webauftritt indizieren zu können. Die zusätzlichen Links müssen nicht sichtbar sein, da sie nur für den Suchroboter einer Suchmaschine gedacht sind.
  • Secondary Site Strategy: Eine zweite Webseite wird entworfen. Diese ist für eine Suchmaschine voll zugänglich.

Webbrowser die Ajax-tauglich sind

Literatur

  • Jesse James Garrett: Ajax: A New Approach to Web Applications. Adaptive Path LLC, 18. Februar 2005, [6] (englisch) (Der Essay, welcher den Namen geprägt hat in engl. Sprache)
  • Louis Rosenfeld, Peter Morville: Information Architecture for the World Wide Web. 2. Auflage. O'REILLY, August 2002, ISBN 0596000359 (Sehr gute Lektüre, die auch die Probleme behandelt, die beim Einsatz der Ajax-Technologie auftreten können)
  • Jennifer Fleming: Web Navigation. O'Reilly, Mai 1999, ISBN 1565923510
  • Olaf Bergmann, Carsten Bormann: AJAX - Frische Ansätze für das Web-Design 1. Auflage. SPC TEIA Lehrbuch Verlag, Oktober 2005, ISBN 3935539266
  • Stuart Langridge: DHTML Utopia. SitePoint, 30. Juni 2005, ISBN 0957921896 ( Webseite d. Buches (englisch))
  • Ryan Asleson, Nathaniel T. Schutta, Nate T. Schutta: Foundations of Ajax. Apress, 17. Oktober 2005 ISBN 1590595823 (Webseite d. Buches (englisch))
  • Dave Crane, Eric Pascarello: Ajax in Action. Manning Publications, November 2005, ISBN 1932394613 (noch nicht erschienen, einzelne Kapitel als Online-Version (englisch))

Technische Quellen

Bibliotheken

Anwendungsbeispiele

Siehe auch
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Ajax_(Programmierung)&oldid=10574115“