Modelul de aplicaţie web Comet

Comet este un model de aplicație web, în care o cerere HTTP permite unui server web să trimită date la un browser, fără ca browserul să le solicite în mod explicit. Comet este un termen umbrelă care cuprinde mai multe tehnici pentru realizarea acestei interacțiuni. Toate aceste metode se bazează pe caracteristicile incluse în mod implicit în browsere, cum ar fi JavaScript, mai degrabă decât pe plugin-uri non-standard. Abordarea Comet diferă de modelul original de web, în care un browser solicită o pagină web completă, la un moment dat.

Folosirea tehnicilor Comet în dezvoltarea web precede utilizarea cuvântului Comet ca un neologism pentru tehnicile colective. Comet este cunoscută sub mai multe alte nume, printre care Ajax Push, Reverse Ajax, Two-way-web, HTTP Streaming, şi HTTP server push, printre altele. Termenul Comet nu este un acronim, dar a fost inventat de Alex Russell în 2006 într-un  post pe blog, Comet: Low Latency Data for the Browser.

Implementări

Aplicații Comet încearcă să elimine limitările modelului web pagină-cu-pagină și interogarea tradițională prin oferirea de două sensuri de interacțiune susținută, folosind o conexiune persistentă sau de lungă durată HTTP între server și client. Deoarece browserele și proxy-urile nu sunt proiectate special cu evenimente pentru servere, mai multe tehnici pentru a realiza acest lucru au fost elaborate, fiecare cu diferite avantaje și dezavantaje. Cel mai mare obstacol este caietul de sarcini HTTP 1.1, care prevede „această descriere … încurajează clienții să fie conservatori la deschiderea mai multor conexiuni”. Prin urmare, existenţa unei conexiuni deschisă pentru evenimente în timp real are un impact negativ asupra uzabilităţii browserului: Browserul poate fi blocat de trimiterea unei noi cereri în timp ce se găseşte în așteptarea rezultatelor unei cereri anterioare, de exemplu o serie de imagini. Acest lucru poate fi rezolvat prin crearea unui nume de gazdă distinct pentru informații în timp real, ceea ce este un alias pentru acelaşi server fizic. Această strategie este o aplicație de sharding de domeniu.

Metodele specifice de implementare a Comet se împart în două mari categorii: streaming și de interogare lungă.

Streaming

O aplicație care utilizează streaming Comet deschide o singură conexiune persistentă de la browser-ul client la server pentru toate evenimentele Comet. Aceste evenimente sunt incremental manipulate și interpretate pe partea de client de fiecare dată când serverul trimite un nou eveniment, fără ca nicio parte să închidă conexiunea.

Tehnici specifice pentru realizarea de streaming Comet includ următoarele:

iFrame ascuns

O tehnică de bază pentru aplicatii web dinamice este de a utiliza un element HTML iframe ascuns (un frame inline, care permite unui site web să încorporeze un document HTML în interiorul altuia). Acest iframe invizibil este trimis ca un bloc chunked, care se declară implicit ca infinit de mult timp (uneori numit „frame permanent”). În timp ce evenimentele au loc, iframe este umplut treptat cu etichete script, care conțin JavaScript pentru a fi executate în browser. Deoarece browserele redau pagini HTML treptat, fiecare etichetă script este executată imediat ce este primită. Unele browsere necesită o anumită dimensiune minimă de document înainte de începerea analizei și execuție, care poate fi obținută prin trimiterea inițială a 1-2 kB de spaţii de umplutură.

Un beneficiu al metodei iframe este că funcționează în toate browserele obişnuite. Două dezavantaje ale acestei tehnici sunt lipsa unei metode de manipulare a eroriilor de încredere, precum și imposibilitatea de urmărire a stării procesului de apelare a solicitării.

XMLHttpRequest

Obiectul XMLHttpRequest (XHR), principalul instrument utilizat de aplicații Ajax pentru comunicarea browser-server, poate fi, de asemenea, folosit în mesajele server browser Comet, în câteva moduri diferite.

În 1995, Netscape Navigator a adăugat o caracteristică denumită „server push„, care a permis serverelor să trimită noi versiuni ale unei imagini sau pagini HTML la acel browser, ca parte a unui răspuns HTTP multipart, folosind tipul de conținut multipart/x-mixed-replace. Începând cu anul 2004, browserele tip Gecko, precum Firefox, acceptă răspunsuri multipart la XHR, prin urmare putând fi utilizate ca transport streaming Comet. Pe partea de server, fiecare mesaj este codificat ca o porțiune separată a răspunsului multipart, iar pe partea de client funcția de apel invers furnizată funcției XHR onreadystatechange va fi apelată odată cu sosirea fiecărui mesaj. Această funcționalitate este inclusă în browserele tip Gecko, există discuții pentru adăugarea ei şi la WebKit. Internet Explorer 10 suportă de asemenea această funcționalitate.

În loc de a crea un răspuns multipart, și să depindă de browser pentru a analiza transparent fiecare eveniment, este de asemenea posibil să se genereze un format de date personalizat pentru un răspuns XHR, și să se analizeze fiecare eveniment folosind JavaScript pe partea de browser, bazându-se doar pe apelarea inversă browseronreadystatechange de browser de fiecare dată când primește noi date.

Ajax cu interogare lungă

Niciunul dintre transporturile streaming de mai sus nu funcţionează în toate browserele moderne fără efecte secundare negative. Aceasta obligă dezvoltatorii Comet să pună în aplicare mai multe transporturi complexe de streaming, şi să comute între ele în funcție de browser. Prin urmare multe aplicații Comet folosesc interogarea lungă, care este mai ușor de pus în aplicare pe partea de browser, și funcţionează, la minim, în fiecare browser care acceptă XHR. După cum sugerează și numele, interogarea lungă impune clientului să interogheze serverul pentru un eveniment (sau un set de evenimente). Browser-ul face o cerere tip Ajax la server, care este păstrat deschis până când serverul are noi date pentru a le trimite la browser, care sunt trimise la browser într-un răspuns complet. Browserul inițiază o nouă cerere de interogare lungă pentru a obține evenimentele ulterioare. Printre tehnologii specifice pentru realizarea interogării lungi se numără următoarele:

Interogarea lungă XMLHttpRequests

În cea mai mare parte, interogarea lungă XMLHttpRequest funcționează ca orice utilizare standard a XHR. Browserul face o cerere asincron a serverului, care poate aștepta ca datele să fie disponibile înainte de a răspunde. Răspunsul poate conține date codificate (de obicei, XML sau JSON) sau Javascript pentru a fi executate de către client. La sfârșitul prelucrării răspunsului, browserul creează și trimite un alt XHR, pentru a aștepta următorul eveniment. Astfel, browserul menţine permanent o cerere cu serverul, pentru a i se răspunde de fiecare dată când se produce fiecare eveniment.

Interogarea lungă cu eticheta script

În timp ce orice transport Comet poate fi făcut să lucreze între subdomenii, nici unul dintre transporturile de mai sus nu poate fi folosit între diferite domenii de nivel secundar (SLD), din cauza politicilor de securitatea browserelor destinate să prevină atacurile cross-site scripting. Astfel, în cazul în care pagina web principală este servită de la un SLD, iar serverul Comet este situat pe un alt SLD (care nu are activată partajarea resurselor de origine cross), evenimentele Comet nu pot fi folosite pentru a modifica HTML și DOM în pagina principală, folosind aceste transporturi. Această problemă poate fi evitată prin crearea unui server proxy înaintea unuia sau ambelor surse, ceea ce le face să pară că provin de la același domeniu. Cu toate acestea, acest lucru nu este de dorit, din motive de complexitate sau de performanță.

Spre deosebire de iframe sau obiecte XMLHttpRequest, etichetele script pot fi ţintite către orice URI, și codul JavaScript în răspuns va fi executat în documentul HTML curent. Acest lucru creează un risc potențial de securitate pentru ambele servere implicate, deși riscul pentru furnizorul de date (în cazul nostru, serverul Comet) pot fi evitate folosind JSONP.

Un transport Comet cu comunicare lungă poate fi creat prin crearea dinamică a elementelor script, și stabilirea sursa lor în locația serverului Comet, care apoi trimite înapoi JavaScript (sau JSONP) cu un eveniment ca sarcina sa utilă. De fiecare dată cererea script este finalizată, browserul deschide una nouă, la fel ca și în cazul interogării lungi XHR. Această metodă are avantajul de a fi cross-browser, în timp ce permite încă implementarea între domenii.

Alternative

Tehnologiile de browser nativ sunt inerente în termen de Comet. Încercările de a îmbunătăți comunicarea HTTP non-interogare au venit din mai multe părți:

• Specificaţia proiectului HTML 5 produsă de Web Hypertext Application Technology Working Group (WHATWG) specifică așa numitele evenimente transmise de server, definind o nouă interfață JavaScript EventSource și un nou tip MIME text/event-stream. Punerea în aplicare experimentală a acestei caracteristici a fost introdus în Opera 9.
• Proiectul în lucru API WebSocket HTML 5 specifică o metodă de a crea o conexiune persistentă cu un server și a primi mesaje prin intermediul unui apel invers onmessage.
• Protocolul Bayeux al Fundaţiei Dojo. Lasă transporturile specifice browserului, și definește un protocol de nivel superior pentru comunicare între browser și server, cu scopul de a permite re-utilizarea codului JavaScript pe parte de client de mai multe servere Comet, și a permite aceluiaşi server Comet să comunice cu multiple implementări JavaScript pe parte de client. Bayeux se bazează pe un model de publicare/subscriere, astfel serverele care suportă Bayeux au inclus modelul publicare/subscriere.
• Protocolul BOSH al fundaţiei de standarde XMPP. Acesta emulează un flux bidirecțional între browser și server prin folosirea a două conexiuni HTTP sincrone.
• Obiectul JSONRequest, propus de Douglas Crockford, ar fi o alternativă la obiectul XHR.
• Utilizarea de plugin-uri, cum ar fi applet-uri Java sau proprietare gen Adobe Flash (folosind protocolul RTMP pentru datele de streaming de aplicaţii Flash). Acestea au avantajul de a lucra în mod identic în toate browserele cu plugin-ul adecvat instalat, și nu trebuie să se bazeze pe conexiuni HTTP, dar dezavantajul este de a cere ca plugin-ul să fie instalat.
• Google a anunțat un nou Channel API pentru Google App Engine, implementând un API tip Comet cu ajutorul unei biblioteci JavaScript client pe browser. Acesta ar putea fi înlocuită ulterior cu WebSocket HTML5.

Traducere din Wikipedia