Una vecchia tecnologia Web sta lentamente risorgendo dalle profondità della storia. Una caratteristica dei browser non considerata per anni ancora una volta sta per essere impiegata per portare una migliore risposta alle nostre pagine Web. I server stanno imparando a far fronte ad un nuovo modo di fare le cose. E non sto parlando di Ajax.

Nuovi servizi come Jot Live e Meebo sono costruiti con uno stile di comunicazione che non è né tradizione né Ajax. Il loro modo di trasferire i dati low-latency ai browser è unico, e sta diventando sempre più comune. Mancando un termine migliore, ho iniziato a chiamare questo stile di event-driver, server-push data stream "Comet".  Questo non vale per tutto, e non sono sicuro che dovrebbe. C'è molta confusione su come queste tecniche funzionino, e usando le definizioni preesistenti si avrebbe la stessa possibilità di ottenere definizioni corrette come errate.

Definizione di Comet

Per essere utile, un nuovo termine, almeno abbiamo bisogno di alcuni esempi di questa tecnologia, una lista di problemi che sono stati risolti e proprietà che la distinguono da altre tecniche. Come con Ajax, queste non sono difficili da trovare. Una breve lista di queste applicazioni include:

• GMail’s GTalk integration

• Jot Live

• Renkoo

• cgi:irc

• Meebo

Quindi, cosa rende queste applicazioni speciali? Cosa le rende differenti dalle altre cose che a prima vista possono sembrare simili? Fondamentalmente esse usano connessioni HTTP con alto TTL per ridurre la latenza con la quale i messaggi sono passati al server. In parole povere, esse non fanno richieste occasionali al server. Invece il server ha una linea aperta di comunicazione con la quale effettua il push dei dati ai client.

Dalla prospettiva dell'attività del netword, possiamo modificare il diagramma originale di Ajax di JJG per illustrare come comet differisce

Come illustrato sopra, le applicazioni Comet possono trasportare i dati ai client in qualsiasi momento, non solo in risposta alla richiesta di un client. I dati sono trasportati su una singola, precedente aperta. Questo approccio riduce la latenza per il trasporto dei dati in maniera significativa.

L'architettura conta su una visione dei dati che è guidata dagli eventi da entrambi i lati della connessione HTTP. Gli ingegneri che hanno familiarità con SOA o middleware orientati ai messaggi troveranno questo diagramma straordinariamente familiare. L'unica sostanziale differenza è che il punto di destinazione è il browser.

Da una parte Comet è simile ad Ajax poichè è asincrono, le applicazioni che implementano il paradigma Comet possono comunicare lo stato del cambiamento con latenza trascurabile. Questo la rende adatto per molti tipi di monitoraggio e applicazioni collaborative multi utente che altrimenti sarebbero difficili o impossibili da gestire in un browser senza plugins.

Perchè Comet è meglio per gli utenti?

Le applicazioni Ajax migliorano la reattività dell'interfaccia per un singolo utente, ma al costo di permettere al contesto di andare in stallo per pagine ad alto TTL.

I cambiamenti ai dati degli altri utenti vanno persi finché l'utente non ricarica l'intera pagina. n applicazione può in alternativa ritornare lo stato di "bad old days" e mantenere una sorta di meccanismo di stato con il quale richiama le modifiche dall'ultima richiesta. L'utente deve inoltre aspettare finchè vengono eseguite alcune azioni che lancino una richiesta per vedere la pagina aggiornata con i dati inseriti dagli altri utenti (cosa che potrebbe impattare negativamente sulle performance!) or richiedere i cambiamenti al server regolarmente (chiamato "polling"). Dato che il web è intrinsecamente multi utente, è abbastanza ovvio che le applicazioni ajax normali impongono usabilità e trasparenza per gli utenti. Le applicazioni che adottano il paradigma Comet possono evitare questo problema effettuando il push degli aggiornamenti ai client appena questi vengono inseriti.

L'interfaccia non va fuori sincronia e ogni cambiamento fatto da ogni utente varranno per tutti gli utenti che usano l'applicazione. Ajax migliora la reattività per il singolo utente. Comet migliora la reattività per le applicazioni collaborative, multi-utente e lo fa senza decadimento di prestazioni associate al polling intermittente.

Ma è scalabile?

Nuovi server sono spesso richiesti per far si che le applicazioni costruite usando Comet possano scalare, ma il pattern event-driven IO server side stanno iniziando a prendere piede. Anche Apache distribuirà un modulo Comet nella versione 2.2. Fino ad allora strumenti come Twisted, POE, Nevow, mod_pubsub, e altre astrazioni ad alto livello del modello event-driver IO stanno rendendo Comet disponibile agli sviluppatori al volo. I moderni sistemi operativi sopportano una sorta di event-driver IO a livello di kernel. Ho anche sentito che il pacchetto NIO di Java inizierà ad avvantaggiarsi di questa tecnologia nelle prossime versioni. Questi strumenti stanno trasformando il futuro in realtà. Questi strumenti scalano, e molti di essi son già disponibili oggi.

Darò maggiori dettagli su questo topic su ETech e descriverò le varie tecniche con cui le applicazioni basate su Comet possono impiegare il push data dal server al client. Co me sempre, posterò anche delle slide come sempre.

Il futuro del web in lettura/scrittura è multi-utente. Quella è la vita dopo Ajax.

Conclusioni

Primo, una parola sulla terminologia e la sua importanza. "Ajax" fu coniato per descrivere il trasferimento di dati in background. Molti di noi avevano lavorato alle soluzioni per fare esattamente questo, ma finchè non è stato possibile per la gente costruire direttamente applicazioni queste non erano altro che un nome e una descrizione.

La terminologia comune non è soltato una scorciatoia durante le discussioni fra i tecnici, ma anche come ponte per coloro che non possono dare una spiegazione tecnica adeguata e vogliono spiegare come una tecnologia funzioni.

Come con Ajax, chi di noi costruisce la tecnologia ora si trovano di fronte ad una nuova sfida. Abbiamo un duro scoglio per il quale sono disponibili soluzioni (e ci sono state per molto tempo) ma non c'era modo di comunicare su esse. La terminologia è nuovamente il collegamento mancante. Oggi, mantenere una connessione HTTP aperta per fare trasferimento di dati a bassa latenza verso i browser ha un nome comprensibile. Quando descrissi un nuovo hack, non c'è nulla con cui associarlo. Quando le persone dicono "come diavolo fanno a fare una cosa del genere?", noi non abbiamo una risposta compatta. Anche se, nello spirito di migliorare la comunicazione (e non la tecnologia inventata), ho proposto un nuovo nome per questa cosa.

Poi, per quelli che programmano a livello network o sono familiari con socket e/o con il protocollo TCP, potrete probabilmente farvi beffe del concetto che una web application finalmente può supportare fare questo tipo di scambio dati. Abbastanza giusto. E' comunque interessante notare che mentre moltre GUI reattive sono state disponibili per molte piattaforme fin qui, il web ha "vinto" con una vasta maggioranza di marketshare per la maggiorparte delle classi di applicazioni nelle quali il browser fornisce abbastanza supporto nativo (plugin esclusi) per rendere le prestazioni e l'interfaccia flessibile. Comet può essere un nuovo nome per un set di vecchie idee mescolate insieme in un simpatico hack, ma questo in alcuno modo diminuisce l'impatto nel mercato che avrà (e che già ha).

Infine, come gli utenti Dojo possono aspettarsi, Dojo supporta già Comet via dojo.io.bind(). Più di un anno fa progettammo l'API con Comet in testa. Nelle prossime settimane mostrerò come questa api possa essere combinata con gli eventi di Dojo per  fornire un meccanismo di trasporto basato sui messaggi.

3 Marzo 2006

Alex Russell