Aus Alt mach Neu mit AJAX: Instant Messaging und Presence
Posted by Olaf Bergmann Fri, 21 Oct 2005 02:31:00 GMT
Anfang Oktober fand in San Francisco zum zweiten Mal die internationale Konferenz zum Web 2.0 statt. Wie bei Konferenzen zu aktuellen Modethemen üblich, waren unter den Ausstellern auch viele neu gegründete Unternehmen, die den Markt mit frischen Ansätzen bereichern. Beispiele für Startups, die auf AJAX-Technologie auf der Clientseite webbasierter Anwendungen setzen, sind Meebo und Zimbra. Beide Unternehmen haben sich im weitesten Sinne auf Messaging-Anwendungen mit Web-Interface spezialisiert, ein Feld, das auch Google Talk besetzen möchte.
Mit Instant Messaging (IM) wird ein Modethema der vergangenen Jahre aufgegriffen und ajaxifiziert. Ein wesentliches Merkmal von klassischen IM-Anwendungen ist der eingebaute Presence-Dienst, der Auskunft über die Verfügbarkeit von eingetragenen Nutzern erteilt. Für jeden Kontakt im Adreßbuch der IM-Anwendung (oft Roster oder Buddy-List genannt) kann man sofort sehen, ob diejenige Person gerade erreichbar ist oder nicht gestört werden möchte.
Klassische IM-Protokolle wie Jabber/XMPP oder SIMPLE unterscheiden sich von webbasierten Ansätzen durch ihre push-basierte Architektur; da jeder Teilnehmer einen eigenen Serverprozeß aufsetzt, können Nachrichten bei Bedarf an den betreffenden Teilnehmer gesendet werden. In einer Client/Server-Architektur hingegen müssen die Clients regelmäßig Anfragen stellen, um neue Informationen zu erhalten.
Dies ist auch der Ansatz, der im AJAX-Buch angedeutet
wird. Mit dem Ajax.PeriodicalUpdater aus der Bibliothek
Prototype lässt sich eine Buddy-List sehr einfach
aktualisieren. Alternativ ließe sich auch der PeriodicalExecuter
dafür einsetzen, allerdings lässt sich dieser nicht so ohne weiteres
stoppen, wenn er erst einmal läuft – der Browser wird dann sehr
schnell zum Speicherfresser.
Auf den ersten Blick erscheint das Polling gegenüber den push-basierten Lösungen nicht sehr attraktiv. Doch die Ende-zu-Ende-Kommunikation hat einen großen Nachteil: Sie harmoniert nicht gut mit Middleboxes, also Geräten, die sich zwischen Sender und Empfänger einer Kommunikationsbeziehung befinden und den normalen Protokollablauf beeinflussen können. Die bekanntesten Vertreter dieser Art sind NATs und Firewalls. Beide haben ihre Berechtigung, machen eine reibungslose Kommunikation aber sehr schwer. Das Ergebnis sind Keep-Alive-Mechanismen und Verrenkungen wie STUN, um von außerhalb erreichbar zu sein.
Webbasierte Anwendungen können dieses Problem getrost vernachlässigen: Sobald Web-Traffic durch die Firewall gelassen wird, was selbst in den meisten Unternehmen heutzutage übliche Praxis ist, kann die bidirektionale Kommunikation über TCP beginnen. Bereits vor einigen Jahren haben Web-Services diese asymmetrische Kommunkationsbeziehung genutzt, um Schwierigkeiten mit Firewalls und NATs zu umgehen. Und das ist auch der Grund, warum SOAP fast ausschließlich über HTTP transportiert wird…
Keine Frage, Polling über HTTP gibt es schon lange und wird es immer
geben. Das XMLHttpRequest-Objekt wird diesen Aspekt aber wieder
stärker in den Vordergrund rücken. Mit welchen Lasten muss ein
Server-Betreiber nun plötzlich rechnen? Wie viele Filedeskriptoren
sind gleichzeitig offen zu halten? Welche Bandbreite erfordern die
Antworten? Wie unterscheidet man das erwünschte Polling von einer
DOS-Attacke?
