AJAX und Comet Steffen Platte sp@x-berg.de Abstract: Häufig erfordern Benutzeraktionen auf einer Webseite nur die Änderung eines kleinen Teiles des Dokumentes. Klassische Webanwendungen erfordern jedoch, dass der Web-Server ein komplettes Dokument generiert und überträgt. Diese Verschwendung von Ressourcen führt zu einer trägen Webanwendung mit schlechter Benutzbarkeit. AJAX und Comet sind zwei Technologien, die es erlauben, einzelne Daten asynchron vom Server zu erhalten. Moderne Webanwendungen erreichen durch Verwendung dieser Technologie eine höhere Reaktivität und somit verbesserte Benutzbarkeit. 1 Einführung Im vergangenen Jahrzehnt bestanden Webseiten hauptsächlich aus statischen Inhalten. Nach jeder Benutzerinteraktion wurde eine Anfrage an den Web-Server gesendet, der daraufhin ein neues Dokument generierte und auslieferte. Der Browser wurde lediglich zur Darstellung des anzuzeigenden Dokuments benutzt. Diese Vorgehensweise führt zu hohen Wartezeiten zwischen einzelnen Benutzeraktionen mit der Webseite und somit einer schlechten Benutzbarkeit der Webseite. Im Laufe der 1990er Jahre wichen einige Webseiten von diesem sogenannten multi page interface -basierten Design (s. [MD07], Kap. 1) ab. Bei diesem älteren Modell führt eine Benutzeraktion auf der Webseite zur Generierung eines neuen Dokumentes. Dieser Prozess wiederholt sich immer wieder. Während dieser Ansatz leicht zu implementieren ist, schränkt er die Benutzerfreundlichkeit der Webseite durch viele Wartezeiten ein. Um diese Einschränkung zu umgehen, entstanden neue Webseiten, die nun ein neues single page interface Modell benutzen. Anstatt die gesamte Seite neu zu laden, werden nur die Teile verändert, die auf Grund der vorausgegangenen Benutzeraktion veraltet sind. Nur die dazu notwendigen Daten werden vom Web-Server abgerufen. Im Zuge dieses Wandels entstanden komplexe Webanwendungen, die in Bezug auf Bedienbarkeit und Reaktivität den nativen Desktopanwendungen ebenbürtig sind. Als einige Beispiele unter einer Vielzahl von Angeboten seien hier Google Docs 1 zur Textverarbeitung, Meebo 2 für Instant Messaging und der E-Mail-Dienst Gmail 3 genannt. Diese Dienste bieten einen für den Alltagsgebrauch ausreichenden Funktionsumfang. Da sie auf einem Web- Server laufen, haben sie eine Reihe von Vorteilen gegenüber ihren nativen Pendants auf dem Desktop. So sind diese Anwendungen von jedem Computer aus verfügbar, der mit dem Internet verbunden ist und einen Browser installiert hat. Weitere Software muss nicht installiert sein und auch die verwendete Plattform ist unerheblich. Viele dieser Webanwendungen bieten Mechanismen, die das gemeinsame Arbeiten an verschiedenen Arten von Dokumenten unterstützen. Für dieses Aufgabenfeld ist eine hohe Reaktivität der Webanwendung wichtig, um die Benutzer über neue Ereignisse so schnell wie möglich informieren zu können. Diese Seminararbeit stellt Prinzipien und Techniken zum Erhöhen der Reaktivität von Webanwendungen vor. Dies sind zum einen AJAX, mit dem sich Daten asynchron vom Web-Server abfragen lassen, ohne ein komplettes Dokument generieren zu müssen. Zum anderen Comet, was als Oberbegriff für eine Reihe von Techniken steht, die das Senden von Nachrichten vom Web-Server zum Client in Echtzeit erlauben. Die 1 http://docs.google.com/ 2 http://www.meebo.com/ 3 http://mail.google.com/
verschiedenen Ansätze der Implementierung werden beschrieben und miteinander verglichen. Im Rahmen dieser Seminararbeit entstanden konkrete Code-Beispiele, die den praktischen Einsatz und Nutzen verdeutlichen. 2 AJAX Dieses Kapitel befasst sich mit dem derzeit passierenden Wandel von klassischen multi page interface Webseiten hin zu single page interface Webanwendungen, die AJAX benutzen. Diese Umstellung ist für viele Webseiten vorteilhaft, da sie so eine höhere Reaktivität erreichen und somit die Benutzbarkeit verbessern. Im Folgenden wird zunächst das klassische Modell von Webseiten beschrieben. Anschließend wird die Funktionsweise von modernen AJAX-Webanwendungen erläutert. 2.1 Klassische Webseiten Klassische Webanwendungen, an die sich die Benutzer während des vergangenen Jahrzehnts gewöhnt haben, funktionieren nach dem folgenden Schema, dessen zeitlichen Ablauf Abbildung 2 verdeutlicht. Die beteiligten Entitäten zeigt Abbildung 1. Benutzeraktionen in der Oberfläche von Webseiten führen zu HTTP- Anfragen, die an den Web-Server gesendet werden. Der Web-Server reagiert darauf, indem er die übergebenen Parameter auswertet und basierend darauf die gewünschte Aktion durchführt. Dabei kann es sich etwa um Datenbankzugriffe handeln. Dies führt häufig zu Änderungen des Applikationsmodells auf Serverseite. Nachdem der Web-Server die Verarbeitung der Daten abgeschlossen hat, generiert er ein neues HTML-Dokument, das er sodann per HTTP an den Browser des Benutzers ausliefert. Der Benutzer kann nun das Ergebnis betrachten und wird daraufhin eine weitere Aktion ausführen, die den beschriebenen Prozess erneut auslöst. Diese Vorgehensweise für Webanwendungen stammt aus den frühen Zeiten des World Wide Webs. Aus einer technischen Sichtweise ist dieser gewählte Ansatz nachvollziehbar, denn er lässt sich verhältnismäßig leicht implementieren. Für den Benutzer führt dieser klassische Ansatz allerdings nicht zu einer komfortabel benutzbaren Anwendung. Jede seiner Interaktionen führt zu einer Anfrage an den Web- Server, die den Benutzer warten lässt, bis die neue Seite generiert und übertragen ist. Wann immer die Webanwendung Daten vom Web-Server benötigt, muss der Benutzer warten. Die Reaktivität solcher Webanwendungen ist somit weitaus schlechter als die von nativen Desktopanwendungen. Abbildung 1: Entitäten klassischer Webanwendungen (aus [JJG]) Abbildung 2: Zeitlicher Ablauf klassischer Webanwendungen (aus [JJG]) Durch den Einsatz von AJAX ist es möglich, die Reaktivität und damit die Benutzbarkeit der Webanwendung zu verbessern. Der nächste Abschnitt befasst sich daher mit AJAX.
2.2 Webanwendung mit AJAX Die Abkürzung AJAX steht für Asynchronous JavaScript and XML. Geprägt und bekannt gemacht wurde der Begriff durch Jesse James Garrett in [JJG]. Das AJAX zu Grunde liegende Konzept war allerdings schon viel länger bekannt. Das asynchrone Laden von Inhalten war erstmals möglich durch Java-Applets und Flash- Plugins. 1996 führte Microsoft für den Internet Explorer das <iframe>-tag ein, mit dem diese Aktion ohne das Installieren eines Plugins durchgeführt werden konnte. Im Jahr 1999 veröffentlichte Microsoft eine ActiveX- Komponente mit dem Namen XMLHTTP, die daraufhin von Mozilla, Safari, Opera und weiteren Browsern als natives Objekt mit dem Namen XMLHttpRequest (XHR) übernommen wurde. (vgl. [WAJen]) Zwischen klassischen Webseiten im multi page interface Design und modernen AJAX-Anwendungen im single page interface Design besteht ein fundamentaler Unterschied. Bei AJAX-Anwendungen kann das Datenmodell der Anwendung teilweise auf den Browser des Benutzers ausgelagert werden. Zu Beginn einer Sitzung (vgl. Abb. 3) wird zunächst die Webanwendung mit Teilen des Datenmodells als JavaScript-Quelltext übertragen. Diese einmalige Initialisierung verlangt das Versenden größerer Datenmengen als es hierzu bei klassischen Webanwendungen nötig wäre. Im Laufe der Sitzung kann der Browser des Benutzers im Hintergrund (asynchron) Anfragen an den Web-Server stellen, um veraltete Inhalte im aktuell dargestellten Dokument zu aktualisieren. Der Web- Server übermittelt nur die benötigten Daten, die der Browser in das Abbildung 3: Modell moderner AJAX-Anwendungen (aus [CPJ06]) Dokument einpflegt. Dadurch ist es nicht nötig, dass der Browser ein komplettes, neues Dokument laden muss der Benutzer kann während der gesamten Sitzung auf derselben Seite bleiben. Da der Web-Server immer nur die zur Aktualisierung notwendige Daten ausliefert, verringert dies den Netzwerkverkehr im Vergleich zu klassischen Webanwendungen. Außerdem hat der Browser nun Kenntnis über Teile des Datenmodells und den Zustand der Webanwendung. Dadurch kann er gewisse Berechnungen sogar lokal durchführen, ohne dass hierfür eine Anfrage an den Webserver gesendet werden muss. Durch diesen zweiten Aspekt verringert sich der Netzwerkverkehr weiter. Bei klassischen Webseiten werden bei jeder Anfrage komplette, aus HTML- und CSS-Code bestehende, Dokumente übertragen, die das Netzwerkaufkommen von AJAX-Anfragen um ein Vielfaches übersteigen. Der vorab genannte Nachteil einer höheren Datenmenge, die während der Initialisierung übertragen werden muss, kann so im Laufe der Sitzung kompensiert werden. Der zeitliche Ablauf von AJAX-Webanwendungen wird in Abbildung 4 verdeutlicht. Hinzugekommen ist hier die Ajax engine, die auf Grund von Benutzerinteraktionen Daten aus dem Datenmodell im Browser serialisiert und diese im Hintergrund als AJAX-Anfrage an den Web-Server sendet. Der Benutzer kann derweil weiter das aktuelle Dokument betrachten und mit ihm interagieren. Hat der Web-Server die Anfrage beantwortet, so verarbeitet die Ajax engine diese und führt die notwendigen Änderungen am aktuellen Dokument durch, so dass der Benutzer die neuen Inhalte betrachten kann.
Abbildung 4: Zeitlicher Ablauf von AJAX-Webanwendungen (aus [JJG]) Im folgenden Beispiel wird zunächst ein XHR-Objekt erzeugt und anschließend eine Anfrage an den Web- Server gesendet. Das Ergebnis der Anfrage wird in einem Dialogfenster präsentiert. var xmlhttp = null; try { // Mozilla, Opera, Safari sowie Internet Explorer (ab v7) xmlhttp = new XMLHttpRequest(); catch(e) { try { // MS Internet Explorer (ab v6) xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); catch(e) { try { // MS Internet Explorer (ab v5) xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); catch(e) { xmlhttp = null; if (xmlhttp) { xmlhttp.open('get', 'beispiel.xml', true); xmlhttp.onreadystatechange = function () { if (xmlhttp.readystate == 4) { alert(xmlhttp.responsetext); ; xmlhttp.send(null);
3 Comet Die Bezeichnung Comet (manchmal auch Reverse AJAX genannt) dient als Oberbegriff für eine Reihe von Technologien, die es zum Ziel haben, die Latenz bei der Auslieferung von Nachrichten der Webanwendung an den Client zu reduzieren. Geprägt wurde dieser Begriff durch Alex Russell in [AR]. AJAX erhöht die Reaktivität der Benutzeroberfläche für einen einzelnen Benutzer. Moderne Webanwendungen erlauben es jedoch, dass eine Vielzahl von Benutzern miteinander kommuniziert und Daten austauscht. Das hat zur Folge, dass diese anderen Benutzer ebenfalls den Zustand des Models auf dem Web-Server ändern können. Für dieses Anwendungsgebiet (ein Beispiel ist Google Wave 4 ) ist es wünschenswert, dass derartige Änderungen so schnell wie möglich dem oder den betreffenden Benutzern mitgeteilt werden. Comet ermöglicht die Interaktion zwischen Browser und Webanwendung in Echtzeit über eine HTTP-Verbindung. Wann immer ein neues Ereignis auf der Seite des Abbildung 5: Netzwerk-Aktivität mit Comet (aus [AR]) Web-Servers auftritt, kann dieses direkt an den Browser geschickt und dort dem Benutzer angezeigt werden. Im Gegensatz zu einer AJAXbasierten Lösung, wo nur als eine Reaktion auf eine Benutzereingabe neue Ereignisse ausgeliefert werden können, kann Comet dies zu jeder Zeit tun. Dazu wird eine ausgezeichnete und zu Beginn der Sitzung initialisierte Verbindung benutzt. Den soeben beschriebenen Ablauf von Nachrichten verdeutlicht die Abbildung 5. Eine rein AJAX-basierte Lösung würde es erfordern, dass der Benutzer kontinuierlich Aktionen durchführt, die in Anfragen an den Web-Server resultieren, um über neue Ereignisse informiert werden zu können. Dies ist aus Gründen der Benutzbarkeit nicht wünschenswert. Ein anderer Ansatz wäre, regelmäßig den Web-Server nach neuen Ereignissen zu fragen, das sogenannte polling. Dieser Ansatz erzeugt unnötige Last auf dem Server, da nicht immer neue Nachrichten vorliegen werden. Durch Einsatz von Comet ist es dem Server möglich, Daten an den Client zu schicken ( push ), wann immer sie auftreten. Bei der Implementierung von Comet war es nötig, Grenzen und Hindernisse, die durch das HTTP- Protokoll vorgegeben sind, zu umgehen. So war es bei der Spezifikation von HTTP nicht vorgesehen, dass das Protokoll zum Aufbauen von lang-dauernden Verbindungen benutzt werden soll. Im Folgenden werden zwei Ansätze (AJAX Long Polling und BOSH) zur Umsetzung von Comet beschrieben. Mit ihnen ist es möglich, Webanwendungen zu implementieren, die die Kommunikation und Zusammenarbeit von vielen Benutzern in Echtzeit ermöglichen. 3.1 AJAX Long Polling Beim sogenannten AJAX Long Polling (auch: Asynchronous Polling ) handelt es sich um eine Mischung aus Push- und Pull-Paradigma. Einzige Voraussetzung dafür ist die Unterstützung von AJAX durch den Browser. Mittels AJAX baut der Client eine Verbindung zum Server auf, die für eine bestimmte Zeit, etwa 45 Sekunden, offen gehalten wird. Tritt während dieser Zeitspanne kein neues Ereignis auf Serverseite auf, das an den Client zu schicken wäre, wird die Verbindung auf Grund eines Timeouts beendet. Daraufhin baut der Client sofort eine neue asynchrone Verbindung zum Server auf. Tritt ein Ereignis auf Serverseite auf, sendet der Server 4 Google Wave: http://wave.google.com/
eine entsprechende Nachricht an den Client und schließt die Verbindung. Dies veranlasst den Client, sie sofort wieder neu aufzubauen. (vgl. [BMD07]) Eine andere Implementationsvariante versendet beim Auftreten von Ereignissen auf dem Server unvollständige HTTP-Antworten und hält die Verbindung so lange wie möglich weiter offen. Bei dieser Variante werden Verbindungen länger gehalten, aber es können Probleme mit Proxy-Servern auftreten (s. unten). Durch das sofortige erneute Verbinden bei einem Verbindungsabbau ist sichergestellt, dass immer eine Verbindung zwischen Client und Server besteht, über die der Server neue Ereignisse veröffentlichen kann. In [BMD07] wird eine rein Polling-basierte Webanwendung, die in einem auf 15 Sekunden festgelegten Intervall den Web-Server nach neuen Ereignissen fragt, verglichen mit einer Push-basierten, die AJAX Long Polling verwendet. Letztere verwendet serverseitig Jetty 5 als Applikationsserver und dessen Cometd-Library. In Testläufen wurden unter anderem die Triptime neuer Ereignisse gemessen. Das ist die Zeit, die ein neues Ereignis vom Entstehen auf dem Server bis zum Eintreffen beim Client benötigt. Außerdem wurde ausgewertet, wie viele überflüssige Nachrichten verursacht wurden. Diese entstehen, wenn bei einem klassischen Poll kein neues Ereignis auf dem Server vorhanden war oder wenn bei einem AJAX Long Poll ein Timeout auftritt. Die Abbildungen 6 und 7 zeigen die Auswertungen der Testläufe. Auf der x-achse ist die Anzahl der gleichzeitig mit dem Server verbundenen Clients aufgetragen. Die farbigen Balken stehen für die Intervalle, in denen neue Ereignisse erzeugt wurden. Pro Anzahl von Clients wurden Ereignisse in 5 verschiedenen Intervallen erzeugt. Während der Testläufe wurden genau zehn zu veröffentlichende Ereignisse auf dem Server erzeugt. Abbildung 6 zeigt, wie drastisch sich die Latenz durch Verwendung der Push-Technologie reduziert. Die Triptime nimmt mit höherer Anzahl von Clients zu, was auf die steigende CPU-Last des Servers zurückzuführen ist. In Abbildung 7 wird die Ineffizienz von reinem Polling deutlich. Wird alle 50 Sekunden ein Ereignis auf dem Server erzeugt, so werden insgesamt fast 35 Nachrichten an den Client geschickt, um die insgesamt 10 erzeugten Ereignisse zu veröffentlichen. Etwa zwei Drittel der versendeten Nachrichten war also überflüssig. Die Push-basierte Lösung benötigt hingegen im Maximum kaum mehr als 10 Nachrichten. Allerdings traten bei zu hoher Last auf dem Server Nachrichtenverluste auf. Abbildung 6: Publish Triptime (aus [BMD07]) Abbildung 7: Anzahl Nachrichten (aus [BMD07]) 5 http://jetty.codehaus.org/jetty/
Ein Problem bei der Implementation von AJAX Long Polling kann auftreten, wenn sich Proxy-Server zwischen Client und Web-Server befinden. Diese sind häufig so konfiguriert, dass sie erst warten, bis eine komplette Anfrage vom Web-Server empfangen wurde und leiten diesen erst dann weiter zum Client. Dieses Verhalten führt bei AJAX Long Polling Anfragen dazu, dass Nachrichten nicht mehr in Echtzeit beim Client ankommen, weil sie durch den Proxy-Server aufgehalten werden. Im nächsten Abschnitt wird mit BOSH ein Verfahren beschrieben, welches das soeben beschriebene Problem des Proxy-Bypassings lösen kann. 3.2 BOSH BOSH steht für Bidirectional-streams Over Synchronous HTTP, war ehemals bekannt als HTTP-Binding und wurde im Rahmen des XMPP-Protokolls entworfen (s. [XEP]). Neben Client und Server gibt es in der BOSH-Architektur einen Connection Manager (CM), der die serverseitige Implementation des BOSH-Protokolls darstellt und logisch vom eigentlichen Server getrennt ist. Er übersetzt transparent zwischen dem HTTP-Protokoll des Clients und dem Protokoll, das der Server verwendet. Der Client sendet per AJAX eine Anfrage an den CM, der solange nicht auf diese Antwortet, bis neue Ereignisse vorliegen. Beim Auftreten neuer Ereignisse überträgt der CM diese sofort über die bestehende Anfrage und beendet die Verbindung. Damit entsteht eine, im Sinne des HTTP-Protokolls komplette, Anfrage, die Proxy- Server direkt weitersenden. Hat der Client etwas empfangen und wurde folglich die bestehende Verbindung beendet, so muss der Client sofort eine neue Verbindung zum CM aufbauen. Es soll immer eine Verbindung zum CM gehalten werden. Möchte der Client eine Anfrage an den Server stellen, während parallel dazu bereits eine Verbindung offen ist, wird eine zweite Verbindung aufgebaut. Der Server antwortet auf die Anfrage des Clients allerdings auf der ersten Verbindung, auch wenn es keine Daten zu senden gibt. Daraufhin wird die erste Verbindung stets geschlossen. Die jetzt noch offene zweite Verbindung steht dem Server ab jetzt zur Verfügung, falls er auf Grund neuer Ereignisse Daten an den Client schicken muss. Das heißt, dass die Rollen der zwei Verbindungen mit jeder Anfrage des Clients wechseln. Dadurch, dass bei jeder Datenübertragung in einer der beiden Richtungen eine HTTP-Anfrage abgeschlossen wird, tritt das bei AJAX Long Polling beschriebene Problem mit Proxy-Servern nicht auf. 4 Zusammenfassung 4.1 Kritische Würdigung Der folgende Abschnitt soll Vor- und Nachteile der präsentierten Techniken AJAX und Comet zusammenstellen (vgl. [WAJ]). Es wurde gezeigt, dass die Reakivität von Webanwendungen durch den Einsatz dieser Techniken stark erhöht werden kann. Dabei ist jedoch zu beachten, dass diese modernen Webanwendungen aufwändiger zu implementieren sind als klassische Webseiten. Man muss auf neue Fehlerarten reagieren können. Dieser Nachteil wird gemildert durch JavaScript-Bibliotheken wie etwa jquery 6, die bewährte und getestete Lösungen für häufige Probleme bereitstellen. Damit muss der Entwickler nicht mehr auf spezielle Eigenheiten der JavaScript-Implementationen in verschiedenen Browsern eingehen. AJAX und Comet sind in jedem aktuellen Browser verfügbar, der JavaScript aktiviert hat. Es bedarf keiner zusätzlichen Installation eines Plugins. Trotzdem ist es wichtig, dass Webentwickler dafür sorgen, dass ihre Webanwendung auch bei ausgeschaltetem JavaScript benutzbar ist. Durch den Einsatz von AJAX ergeben sich neue Anforderungen an die Benutzeroberfläche. Wie beschrieben, kann der Benutzer während seiner gesamten Sitzung dasselbe Dokument gezeigt bekommen, das mittels AJAX aktualisiert wird. Dadurch ist die Zurück -Schaltfläche des Browser nicht mehr ohne Weiteres in der gewohnten 6 http://jquery.com/
Weise verwendbar. Außerdem können Lesezeichen nicht mehr auf bestimmte Zustände der Webanwendung verweisen. Für dieses Problem existieren bereits Lösungen, etwa das Projekt reallysimplehistory 7. Eine weitere Anforderung besteht darin, dass der Benutzer in einer geeigneten Form darüber Rückmeldung erhalten muss, dass gerade eine AJAX-Anfrage im Hintergrund läuft, deren Ergebnis abgewartet werden sollte. Außerdem muss die unvermeidbare Latenz einer Netzwerkverbindung berücksichtigt werden. Wie die Benchmarks im vorherigen Kapitel gezeigt haben, kann der Netzwerkverkehr mit Comet verringert werden. Gleichzeitig können neue Ereignisse in Echtzeit an den Client übermittelt werden. Bei einer sehr hohen Anzahl an gleichzeitigen Benutzern einer Webanwendung muss der Web-Server viele parallele Verbindungen verwalten, was eine hohe Last verursacht. Hierbei ist auf eine skalierbare Architektur der Webanwendung zu achten, in der die Last auf mehrere Server verteilt werden kann. 4.2 Einordnung in das Software Engineering Eine grundlegende Anforderung an Software ist, dass sie gut bedienbar sein muss. Klassische Webseiten haben auf Grund der vielen Wartezeiten für den Benutzer eine schlechte Bedienbarkeit. Durch die Entwicklung der Technologien AJAX und Comet wurde die Reaktivität von Webanwendungen und somit ihre Benutzbarkeit stark verbessert. Dabei stellt Comet eine Best Practice dar. Das gegebene Problem, nämlich Ereignisse auf dem Web-Server in Echtzeit an den Browser schicken zu können, musste unter Berücksichtigung der Beschränkungen durch das HTTP-Protokoll gelöst werden. Hierfür wurden verschiedene Lösungen probiert, die evolutionär gewachsen sind und verbessert wurden. Daraus entstanden Spezifikationen wie etwa für BOSH, die nun standardisiert werden sollen. Ähnliches gilt für andere Technologien zur möglichen Implementation von Comet, wie das Bayeux-Protokoll 8 oder WebSockets 9. Häufig auftretende Probleme, wie etwa das Erzeugen eines XHR-Objektes wurden in JavaScript-Bibliotheken gekapselt, die zentral gepflegt werden. Im Rahmen dieser Bibliotheken entstanden getestete Lösungen, von der eine Vielzahl von Webanwendungen profitieren können. 4.3 Zusammenfassung Innerhalb dieser Seminararbeit wurde zunächst gezeigt, dass klassische Webanwendungen lange Wartezeiten verursachen, die daraus resultieren, dass durch den Web-Server stets komplette Dokumente generiert und ausgeliefert werden müssen. Dies führt zu einer schlechten Benutzbarkeit der Webanwendung. Mittels AJAX können einzelne Daten im Hintergrund vom Web-Server abgefragt werden. Diese Daten können dann in die aktuell angezeigte Seite eingepflegt werden und veraltete Bereiche der Seite aktualisieren. Durch die Verwendung von Comet kann der Web-Server aufgetretene Ereignisse in Echtzeit an den Browser schicken. Die präsentierten Benchmarks haben zusätzlich ergeben, dass die Anzahl unnötig versendeter Nachrichten verringert wird. AJAX und Comet verbessern somit die Reaktivität und damit die Benutzbarkeit von Webanwendungen. Beide sind technisch ausgereifte und bewährte Technologien. Das Konzept hinter AJAX ist bereits älter als ein Jahrzehnt. In der Zukunft geht es darum, das volle Potential hinter diesen Technologien zu erkennen und auszuschöpfen. Daher ist mit der Entwicklung weiterer Webanwendungen zu rechnen, die diese Technologien verwenden. 7 http://code.google.com/p/reallysimplehistory/ 8 http://svn.cometd.com/trunk/bayeux/bayeux.html 9 http://dev.w3.org/html5/websockets/
Literaturverzeichnis [AR] Alex Russell: Comet: Low Latency Data for the Browser, WWW: http://alex.dojotoolkit.org/2006/03/cometlow-latency-data-for-the-browser/, letzter Zugriff: 13.04.2010. [BMD07] Engin Bozdag, Ali Mesbah, Arie van Deursen: A Comparison of Push and Pull Techniques for AJAX, WSE '07: Proceedings of the 2007 9th IEEE International Workshop on Web Site Evolution, 2007. [CPJ06] Dave Crane, Eric Pascarello, Darren James: Ajax in Action, Manning Publications, 2006. [JJG] Jesse James Garrett: Ajax: A New Approach to Web Applications, WWW: http://www.adaptivepath.com/ideas/essays/archives/000385.php, letzter Zugriff: 13.04.2010. [MD07] Ali Mesbah, Arie van Deursen: An Architectural Style for Ajax, wicsa, pp.9, Sixth Working IEEE/IFIP Conference on Software Architecture (WICSA'07), 2007. [WAJ] Wikipedia: Ajax, WWW: http://de.wikipedia.org/wiki/ajax_%28programmierung%29, letzter Zugriff: 14.04.2010. [WAJen] Wikipedia: Ajax, WWW: http://en.wikipedia.org/wiki/ajax_%28programming%29, letzter Zugriff: 04.05.2010. [XEP] Ian Paterson, Dave Smith, Peter Saint-Andre, Jack Moffitt: XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH), XMPP Standards Foundation, WWW: http://xmpp.org/extensions/xep-0124.html, letzter Zugriff: 14.04.2010.