Posted by Carsten Bormann
Sat, 22 Oct 2005 18:46:00 GMT
Schlußfolgerungen aus Web-basierten Umfragen sind stets mit besonderer
Vorsicht zu behandeln. Nichtsdestoweniger finde ich die Ergebnisse
einer Web-Umfrage eines Burton-Group-Mitarbeiters unter
AJAX-Entwicklern (angekündigt vor ein paar Tagen im Ajaxian
Blog) beeindruckend.
Knapp ein Drittel der Teilnehmer berichten, sie hätten
AJAX-Anwendungen bereits im Produktionsbetrieb. Ein weiteres Drittel
entwickelt schon; ein weiteres Viertel probiert offenbar noch
(und ein paar denken noch nach).
Was sind nun die Serverumgebungen, mit denen AJAX-Techniken umgesetzt
werden? Die größte Gruppe benutzt PHP (über 40 %), dicht gefolgt von
Java (35 %). Wer gedacht hätte, AJAX würde nur in hypermodernen
Entwicklungs-Umgebungen wie Ruby on Rails eingesetzt (15 %), wird
überrascht, selbst die .NET-Gruppe hatte mit 18 % mehr Antworten.
Schließlich war noch die Frage nach dem Client-seitigen Toolkit von
Interesse. Die größte Gruppe (40 %) tinkert direkt mit
XMLHttpRequest, eine Vorgehensweise, die wir im AJAX-Buch
nicht empfehlen. Die zweitgrößte Gruppe (23 %) benutzt
prototype, was gegenwärtig auch unsere Empfehlung ist, nicht
zuletzt wegen script.aculo.us, der wunderbaren Zusatzbibliothek
von Thomas Fuchs, die 18 % weitere Nennungen bekommen hat (ebenso
wie Rails mit 10 %, was aber ja auch nichts anderes als prototype und script.aculo.us
heißt). Auf über 10 % kamen auch noch die beiden Toolkits DWR
(Java-Umgebung) und Dojo. Einen Ehrenpreis bekommt mit 8 %
schließlich die deutsche Entwicklung Ajax.NET; danach kommt der long tail der anderen Toolkits.
Gibt es, wie im Buch vorhergesagt, schon so etwas wie eine Konsolidierung der Toolkits?
Posted in AJAX | 3 comments | 432 trackbacks
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?
Posted in AJAX | Tags AJAX, InstantMessaging, Presence | no comments | 434 trackbacks
