Vom Kometen getroffen

Webentwicklung mit Comet
Kommentare

So in etwa fühlt sich wohl jeder Webserver, der aufgrund von ständigen Anfragen seitens AJAX-Applikationen nach neuen Daten gefragt wird, obwohl die besagten Daten sich noch gar nicht verändert haben. Comet beschreibt eine Art Datenübertragung, die vom Server eingeleitet wird, im Gegensatz zu einer regelmäßigen Anfrage durch den Client.

Das Konzept des Web 2.0 weitet sich auf immer mehr Bereiche des Inter- und Intranets aus. Täglich erblicken neue AJAX-Applikationen das Licht der Welt, manche davon brauchbar, manche etwas realitätsfern. Doch einige dieser Applikationen stechen durch ein neues Konzept hervor, das bisher nur als „HTTP Streaming“ bekannt war und sich eher im Hintergrund gehalten hatte. Alex Russell, Projektleiter des Dojo Toolkits, hat aufgrund der fehlenden Diskussionsgrundlage den Begriff „Comet“ geprägt, um der Technologie einen Namen zu geben und ihr mehr Aufmerksamkeit zukommen zu lassen. Ein neues Buzzword war geboren.

Was steckt hinter Comet?

Comet soll keinesfalls ein Ersatz für AJAX sein. Vielmehr ist Comet ein Mechanismus, um AJAX um Funktionalität zu erweitern. Comet zeichnet sich dadurch aus, dass die Applikation nicht ständig, wie beispielsweise bei Realtime-Applikationen wie Chats, den Server nach neuen Daten fragen muss (Polling), sondern eine einmal aufgebaute HTTP-Verbindung aufrecht hält und es damit  möglich ist, Daten vom Server zum Client zu „schieben“ (Push). Durch diese ereignisgetriebene (Event-driven) Arbeitsweise kann der Server stark entlastet werden, da nicht jeder Client in kurzen Zeitabständen den Status der zu verarbeitenden Daten abfragen muss. Da HTTP generell zustandslos ist, also jeder Request einzeln und getrennt von anderen behandelt wird, muss dies durch eine dauerhafte Verbindung (Long-lived HTTP connection) umgangen werden. Diese wird zu Beginn eines Prozesses gestartet (nicht unbedingt zu Beginn der Applikation) und entweder für eine bestimmte Zeit oder über den kompletten Lebenszyklus der Applikation hinweg verwendet. Ein weiterer Vorteil, den Comet und AJAX gemeinsam haben, zeigt sich darin, dass man clientseitig keine zusätzlichen Plug-ins braucht, um sich diese Techniken zunutze zu machen. Somit ist man in der Lage, normale asynchrone HTTP-Verbindungen zu nutzen, die den meisten Browsern keine Probleme bereiten.

Abb. 1: Comet-Modell einer Webanwendung
Comet in der Praxis

Wie schon erwähnt, ist Comet keine neue Entwicklung, sondern vielmehr eine Methodik, die schon seit längerem Einzug in die Entwicklung vom Webapplikationen gefunden hat. Durch die Namensgebung wurde das Problem konkretisiert und sorgt seither für mehr Diskussionsstoff, was genau der Zielsetzung des ursprünglichen Namensgebers Alex Russell entspricht. In Bereichen, in denen es darauf ankommt, die Daten zeitnah an den Client zu verteilen, sobald diese in irgendeiner Form verändert wurden, kommt genau diese Technik ins Spiel. So sind beispielsweise Applikationen wie Chats, Instant Messenger und Applikationen rund um Börse und Wertpapierhandel nur einige Beispiele, bei denen man diese Form von Datenübertragung zum Einsatz bringen sollte. Es geht darum, nur das an Daten zu übertragen, was von Bedeutung ist. Beispielapplikationen, die Comet bereits jetzt einsetzen, sind zum Beispiel der Chat über Gtalk innerhalb von Gmail oder der webbasierte Instant Messenger Meebo. Weitere Einsatzmöglichkeiten wären kollaboratives Schreiben in Echtzeit (beispielsweise in einem Wiki) oder auch die nächste Generation der Auktionsplattformen (um immer über den aktuellen Preis einer Ware im Bilde zu sein).

Polling vs. Push

Es stellt sich nunmehr die Frage: „Soll ich nun alle meine AJAX-Anwendungen auf Comet umstellen?“ Natürlich nicht. Es gilt abzuwägen, ob, wann und woher man die Daten bezieht. Außerdem gibt es noch viele andere Aspekte, die zu beachten sind. Der Vorteil von Comet ist natürlich die Antwortzeit der Anwendung auf neue Daten. Diese Aktualisierung beruht, wie schon erwähnt, nicht auf dem Polling-Intervall, sondern wird sofort durch ein serverseitiges Event ausgelöst. Auch der Overhead bei Comet ist bei weitem nicht so hoch wie bei gebräuchlichen AJAX-Anwendungen. Durch das Benutzen ein und derselben HTTP-Verbindung fällt der zusätzliche Aufbau und das Schließen der einzelnen Verbindungen vom Polling weg. Leider bringt Comet auch einige Nachteile mit sich, die man nicht außer Acht lassen sollte. So wird das Debuggen solcher Anwendungen durch die Architektur von Comet erschwert, da man sich hier nicht auf festgelegte Intervalle verlassen kann. Auch das Testen solcher Anwendungen erfordert durch die ereignisgetriebe Natur von Comet einiges an Mehraufwand als bei „altbewährten“ AJAX-Applikationen. Durch den Umstand, dass wir in unserer Comet-Applikation eine kontinuierliche Verbindung zum Server hergestellt haben, ist es nunmehr unmöglich, gleichzeitig Daten über diese Verbindung hochzuladen. Um dies zu realisieren, muss der Client parallel eine zweite Verbindung zum Server aufbauen, was bei steigender Benutzerzahl zu erheblichen Problemen führen kann.

Es unterliegt auch immer dem Zweck der Aktion, wann man zur AJAX-eigenen Methode des Pollings oder der Comet-Variante greifen sollte. Will man beispielsweise wirklich eine Anwendung alle 10 Minuten auf den neuesten Stand bringen, ist es natürlich unnötig, über diesen Zeitraum eine, in diesem Fall ungenutzte, Verbindung zum Server offen zu halten. Bei einem solchen Einsatz von HTTP-Verbindungen innerhalb unserer Anwendungen ist das Polling auf jeden Fall die bessere Alternative. Auch sollten Comet-basierte Anwendungen nicht auf jedem x-beliebigen Server eingesetzt werden. Die Betonung liegt auf sollte – funktionieren würde es, jedoch würde sich der Server sehr schnell darüber beschweren.

Skalierbarkeit

Wie verhält sich der Server, wenn mehrere Hundert Benutzer mit jeweils einer, teilweise sogar zwei HTTP-Verbindungen arbeiten? Die meisten der heutzutage eingesetzten Server kommen bei solchen Anforderungen schnell ins Schwanken. Zwar gibt es spezialisierte Serverlösungen (unter anderem im Finanzbereich), jedoch sind diese für die meisten Entwickler entweder nicht wirklich brauchbar oder nicht finanzierbar. Auf Betriebssystemebene sind Events im Bereich des I/O-Subsystems heutzutage Alltag, jedoch nicht im Kontext von Servern. Um dem Abhilfe zu schaffen, gibt es Twisted aus der Python-Welt, Jetty für Java und auch die Entwickler der Apache Software Foundation arbeiten daran, ein Multi-Processing Module namens event für den Apache HTTP Server 2.2 bereitzustellen. Auch seitens des J2EE Application Server Glassfish gibt es erste Schritte in Richtung Comet: Grizzly, ein HTTP Listener basierend auf Javas NIO-Technologie. Allerdings gibt es immer zwei Seiten: den Server und den Client. Per Spezifikation darf ein Client zwar nur zwei Verbindungen zu je einem Server öffnen, jedoch macht der Mozilla Firefox hier eine Ausnahme. Man muss damit rechnen, dass andere Browser dies nicht in einer derart lockeren Weise implementieren. Ein weiteres Problem ergibt sich im Vergleich zwischen der Polling- und der Push-Variante. Beim Polling wird für jede Aufgabe ein eigener Request aufgebaut, verarbeitet und dann das Ergebnis verworfen. Im Gegensatz dazu steht die Push-Lösung, bei der die Verbindung bestehen bleibt und sich somit Unmengen von Daten ansammeln können. Da heutzutage die wenigsten Browser mit Methoden wie Comet gerechnet haben, wurde dieses Problem auch eher unter den Tisch gekehrt, da man bisher kaum Anwendungen mit dieser Technik vorfindet. Dies kann schnell zu einem Problem im Browser-Speicher werden, der auch mit einem eher unschönen „Out of memory“ den Dienst quittieren könnte. Der verbrauchte Speicher ist natürlich abhängig von Menge, Komplexität und Intervall der serverseitigen Events und sollte vom Entwickler im Auge behalten werden. Vielleicht wird es bei künftigen Browsergenerationen eine Möglichkeit geben, solche ungenutzten Daten von der Applikation selbst aufräumen zu lassen. Wir werden sehen, mit welchen Ideen die Browserhersteller versuchen werden, Entwickler und User glücklicher zu machen.

Einsatzgebiete

Wo sollte man nun besser die Comet-Methodik einsetzen und wo auf die altbekannte Variante setzen? Will man seinen Benutzern die Möglichkeit bieten, die gleichen Daten zur selben Zeit zu verändern und die Änderungen anderer User „live“ mitzuverfolgen, dann ist Comet wohl eindeutig die bessere Alternative. Durch die bestehende Verbindung zum Server entsteht eine geringere Latenzzeit und die Daten werden genau dann geliefert, wenn sie verfügbar sind. Dadurch reduziert sich der Arbeitsaufwand des Benutzers, da dieser sich nicht selbst darum kümmern muss, die Anwendung und ihre Daten zu aktualisieren. Man sollte hierbei dennoch auf die richtige Serverumgebung achten, damit es dem User auch mehr Vor- als Nachteile bringt. Ist es hingegen unwichtig, ob die Daten mit etwas Verspätung beim Benutzer ankommen, sollte man sich des Polling bedienen. Dies bereitet weniger Probleme für Client und Server, zumindest so lange, bis die Technologie rund um Comet ausgereift ist.

In Verbindung bleiben

Die über einen längeren Zeitraum geöffnete HTTP-Verbindung verkürzt zwar die Latenzzeit, birgt aber auch in manchen Situationen einige Tücken. Die XMLHttp­Request-Komponente des Internet Explorers hat die Eigenheit (oder sollten wir es Sicherheit nennen), erst eine Antwort zu liefern, wenn die Verbindung geschlossen wird. Zwar kann dies durch einen IFrame gelöst werden, dennoch muss sich jemand um die Implementierung solcher Lösungen kümmern. Dies kann zum einen der Entwickler selbst sein oder man greift auf Toolkits wie Dojo zurück, die solche Problemlösungen schon jetzt mit sich bringen und solche Probleme für den Entwickler hinter einem brauchbaren API verschleiern. Die kontinuierliche Verbindung zum Server ist die Grundlage aller Applikationen, die sich dem Konzept von Comet versprochen haben, und der Entwickler muss sich daher auf sie verlassen können. Es muss eine Garantie bestehen, dass der Client über diese Verbindung Daten vom Server empfangen kann. Dies kann gelegentlich aber auch schief gehen und es kommt zu Datenverlusten, wenn beispielsweise der Client gerade mit anderen Dingen beschäftigt ist und diese nicht abbrechen kann. Eine Möglichkeit dies zu umgehen, ist der Einsatz einer nachrichtenorientierten Middleware (Message Oriented Middleware), um den Nachrichtenaustausch zwischen Server und Client zu optimieren und zu unterstützen. Sollte der Client gerade beschäftigt sein, kümmert sich die Middleware um die spätere Zustellung der Daten. Eine Besonderheit der Middleware in diesem Kontext ist die Tatsache, dass der Client der Middleware (in unserem Fall) der Browser unserer Anwender ist. Ein Nachteil einer solchen Middleware ist die Tatsache, dass, falls die Middleware ausfällt, damit auch die komplette Kommunikation zwischen den beiden Stellen abbricht.

Es bildet sich momentan ein Team aus Entwicklern um Alex Russell, um eine solche Middleware namens Cometd (früher ShortBus) zu implementieren. Dabei handelt es sich um einen, wie sie ihn selbst beschreiben, skalierbaren, HTTP-basierten Event-routing Bus, der das Muster von Comet umsetzt. Angedacht sind serverseitige Implementierungen in Perl (welche auf Perlbal aufsetzen) und in Python (welche auf Twisted aufsetzen) sowie eine Client-Library in JavaScript. Auch diskutiert man, den serverseitigen Part ebenfalls in anderen Programmiersprachen wie PHP, Java oder auch Erlang anzubieten. Als Protokoll wird „Bayeux“ verwendet, dessen Spezifikation zur Zeit der Drucklegung leider noch nicht verfügbar war. Zwar gibt es bisher noch kein Release von Cometd, doch lohnt es sich, die Mailing-Lists zu verfolgen und dieses Projekt im Auge zu behalten.

Fazit

Die Lösungsansätze, die Comet uns für zukünftige Applikationen im Web 2.0 bietet, sind überragend. Bevor man diese Technik sicher im produktiven Einsatz nutzen kann, sind noch einige Randbedingungen zu klären, damit weniger Probleme auftreten. Wir können gespannt sein, was in den nächsten Monaten bez. ereignisgetriebener Architektur im Web auf uns zukommt.

Benjamin Muskalla ist freiberuflicher Softwareentwickler im Bereich Web Applications auf Basis von PHP und als freier Autor tätig. Er schreibt gerade an seinem Buch „Subversion kompakt“ und interessiert sich nebenher besonders für die Java- und die Eclipse-Plattform.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -