Aplicație de internet bogată
Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de
versiunea revizuită la 19 iulie 2021; verificările necesită
4 modificări .
O aplicație web (web) bogată [1] [2] ( eng. rich internet application , RIA ) este o aplicație web descărcată de un utilizator prin Internet , concepută pentru a îndeplini funcțiile aplicațiilor desktop tradiționale și care rulează pe dispozitivul utilizatorului ( nu pe un server).
Tehnologii utilizate pentru implementarea RIA:
Caracteristici principale:
- RIA constă din două părți: client și server;
- partea de server RIA rulează pe server, poate stoca informațiile necesare pentru ca aplicația să funcționeze și poate gestiona cererile venite de la partea client RIA;
- partea client RIA rulează pe computerul utilizatorului, desenează interfața cu utilizatorul , execută cereri de utilizator și, dacă este necesar, poate trimite cereri către partea de server RIA;
- Partea client a RIA rulează într-un mediu securizat numit „ sandbox ” ( în engleză sandbox ) și nu necesită instalarea unui software suplimentar .
Conform [3] din iulie 2012, cele mai populare platforme utilizate pentru a crea RIA au fost Adobe Flash , JavaFX , Microsoft Silverlight .
Istorie
Termenul „RIA” a fost menționat pentru prima dată de Macromedia într-o carte albă din martie 2002. Ideea RIA a existat cu câțiva ani mai devreme cu următoarele nume:
- „ Remote Scripting ” ( Microsoft ; circa 1998 );
- „X Internet” (Forrester Research; octombrie 2000);
- „Client (web) bogat”;
- aplicație web bogată.
Aplicațiile web tradiționale funcționează astfel.
- Clientul trimite o cerere către server și așteaptă un răspuns.
- Serverul primește o solicitare de la client, generează și trimite un răspuns către client.
- Clientul primește și afișează răspunsul.
Aceste acțiuni se repetă în mod constant (ciclu). Într-o astfel de arhitectură, clientul este angajat doar în afișarea informațiilor (conținut static, de exemplu, HTML ) și transferă toate sarcinile de procesare a datelor către server. Principalul dezavantaj al acestei arhitecturi este că toată munca este realizată de server. Puteți crește viteza aplicației dacă o parte a lucrării este transferată către client.
În arhitectura RIA, o parte sau toată munca poate fi realizată de client.
Dezvoltarea treptată a standardelor de rețea Internet a condus la posibilitatea implementării RIA. Cu toate acestea, este dificil de trasat o linie clară între care tehnologii includ RIA și care nu. Dar toate RIA-urile au o singură caracteristică: așa-numitul „motor client” este încărcat pe dispozitivul utilizatorului înainte ca RIA să pornească; în viitor, motorul poate fi reîncărcat în cursul aplicației.
„Motorul client” implementează caracteristici care nu sunt disponibile pentru aplicațiile web tradiționale, pot fi încărcate în contextul unui browser web (HTML, JavaScript) sau în contextul unui plug-in de browser web (supliment) (Adobe Flash , JavaFX, Microsoft Silverlight, Native Client). „Motorul client” este de obicei responsabil pentru redarea (desenarea) interfeței cu utilizatorul (UI) (de exemplu, implementarea unei interfețe de utilizare pentru o RIA poate fi mai simplă și mai rapidă decât pentru o aplicație web tradițională) și interacțiunea cu serverul (de exemplu, partea client a unui RIA poate trimite cereri către backend-ul RIA fie sincron (ca aplicațiile web tradiționale) fie asincron ). Capacitățile „motorului client” pot fi limitate de capacitățile dispozitivului utilizatorului și ale sistemului de operare .
Beneficii
Beneficiile aplicațiilor web:
- aplicația web nu necesită instalare (utilizatorii descarcă aplicația de pe server după caz; aceasta asigură distribuția automată a aplicației);
- aplicația web se actualizează automat (cea mai recentă versiune a aplicației este găzduită pe server);
- o aplicație web poate rula pe orice dispozitiv cu conexiune la Internet și sub orice sistem de operare (varietatea de sisteme de operare nu creează o problemă datorită unui singur API pentru toate sistemele de operare );
- atunci când rulează o aplicație web, dispozitivul utilizatorului este mai puțin susceptibil la infecția cu virus decât atunci când rulează fișiere binare executabile (aplicația web este executată într-un sandbox).
Avantajele RIA în comparație cu aplicațiile web tradiționale, obținute prin utilizarea capabilităților „motorului client”:
- capacitatea de a utiliza controale standard ale sistemului de operare în interfața de utilizare (de exemplu, folosind un glisor pentru a schimba datele);
- abilitatea de a utiliza acțiuni standard pentru a interacționa cu alte programe (de exemplu, drag-and-drop , copierea datelor în clipboard );
- capacitatea de a efectua calcule pe dispozitivul utilizatorului (fără a trimite datele personale ale utilizatorului către server (de exemplu, un calculator ipotecar ));
- opțiuni flexibile pentru construirea unei interfețe de utilizare (de exemplu, validarea datelor introduse de utilizator în timpul procesului de introducere fără a trimite cereri către server ( interactivitate ));
- posibilitatea de a continua aplicația după trimiterea unei cereri către server (asincron);
- posibilitatea de a descărca date de pe server înainte ca utilizatorul să solicite date (de exemplu, în Google Maps , fragmentele de hărți situate lângă fragmentul pe care utilizatorul îl privește sunt încărcate în avans);
- posibilitatea reducerii sarcinii pe server (in cazul efectuarii de calcule pe client), si, in consecinta, posibilitatea cresterii numarului de sesiuni procesate de server simultan (fara inlocuirea hardware-ului).
Dezavantaje
Dezavantajele RIA:
- lipsa accesului la resursele sistemului de operare (deoarece aplicația web rulează într-un „ sandbox ”). Dacă permisiunile pentru resurse sunt incorecte, este posibil ca RIA-urile să nu funcționeze corect;
- rularea unei aplicații web poate necesita executarea unui cod scris într-un limbaj de scripting (de exemplu, în JavaScript); dacă utilizatorul dezactivează capacitatea de a executa cod, este posibil ca RIA să nu funcționeze corect sau să nu funcționeze deloc;
- viteză redusă a aplicațiilor web multiplatformă. Pentru a asigura independența platformei RIA, partea client RIA poate folosi cod scris într-un limbaj de scripting (cum ar fi JavaScript); la executarea unui astfel de cod, există o scădere a performanței - o problemă serioasă pentru dispozitivele mobile. Această problemă nu apare atunci când se utilizează un limbaj încorporat compilat pe partea client (de exemplu, Java), unde performanța este comparabilă cu utilizarea limbilor încorporate tradiționale, fie Adobe Flash , fie Microsoft Silverlight , în care codul programului rulează direct într-un Flash Player. sau, respectiv, pluginul Silverlight.;
- necesitatea instalării unui „motor client”;
- timp lung de încărcare a aplicației web. Clientul descarcă partea client RIA de pe server de fiecare dată . Deoarece majoritatea datelor care sunt încărcate sunt stocate în cache, clientul RIA trebuie încărcat cel puțin o dată pentru a accelera pornirea. Timpul de descărcare depinde de dimensiunea datelor descărcate; pentru a reduce dimensiunea părții client a RIA, dezvoltatorii o pot comprima sau împărți în părți care sunt încărcate după cum este necesar;
- pierderea integritatii. Dacă o aplicație se bazează pe X/HTML, pot exista conflicte între obiectivele aplicației (care dorește în mod natural să aibă control asupra prezentării și acțiunilor sale) și obiectivele X/HTML (care dorește să renunțe la control). Interfața DOM pentru X/HTML face posibilă crearea unui RIA, dar nu există nicio garanție că va funcționa corect. Deoarece clientul RIA poate modifica structura de bază a aplicației și poate suprascrie acțiunile și prezentarea acesteia, acest lucru poate duce la eșecul aplicației din partea clientului. În final, această problemă poate fi rezolvată printr-un nou mecanism client-server care oferă clientului RIA acces limitat pentru a modifica acele resurse care nu sunt în domeniul său. Lucrarea software-ului standard nativ nu provoacă astfel de probleme, deoarece prin definiție au automat toate drepturile necesare asupra resurselor locale;
- imposibilitatea indexării unei aplicații web de către motoarele de căutare . Este posibil ca motoarele de căutare să nu poată indexa conținutul RIA. Cu toate acestea, adesea, indexarea nu este necesară;
- dependență de conexiune la internet. RIA-urile concepute pentru a înlocui aplicațiile desktop ar trebui să permită utilizatorilor să se conecteze la rețea după cum este necesar, de exemplu, nu ar trebui să devină inoperabile atunci când un utilizator se deplasează între zonele de acoperire fără fir . Până în 2007, aplicațiile tipice RIA necesitau o conexiune permanentă la rețea. Odată cu apariția HTML5, această problemă devine mai puțin relevantă; API -ul de stocare local HTML5 vă permite să stocați date pe partea clientului; API-ul de fișiere HTML5 permite accesul la sistemul de fișiere al dispozitivului utilizatorului.
Provocări de dezvoltare a aplicațiilor
Apariția tehnologiei RIA a fost însoțită de dificultăți semnificative în dezvoltarea aplicațiilor web . Aplicațiile web tradiționale, bazate pe HTML standard, cu o arhitectură relativ simplă și un set de caracteristici destul de limitat, au fost relativ ușor de dezvoltat și gestionat. Persoanele și organizațiile care implementează aplicații web bazate pe tehnologia RIA se confruntă adesea cu provocări suplimentare de dezvoltare, testare, măsurare și suport.
Utilizarea tehnologiei RIA pune noi provocări pentru managementul serviciilor SLM ( managementul nivelului de servicii ), care nu au fost toate rezolvate până în prezent . Întrebările referitoare la SLM nu sunt întotdeauna luate în considerare de dezvoltatorii de aplicații și aproape că nu sunt percepute de utilizatori. Cu toate acestea, ele sunt vitale pentru implementarea cu succes a unei aplicații pe Internet. Principalele aspecte care complică procesul de dezvoltare a RIA sunt următoarele:
- complexitatea tehnologică . Abilitatea de a partaja codul aplicației direct cu clienții oferă dezvoltatorilor și designerilor mai multă libertate creativă. Dar acest lucru, la rândul său, complică dezvoltarea aplicației, crește probabilitatea de erori în timpul implementării și face dificilă testarea software-ului . Aceste complicații prelungesc procesul de dezvoltare, indiferent de specificul metodologiei și al procesului de dezvoltare. Unele dintre aceste probleme pot fi reduse prin utilizarea unui cadru de aplicații web pentru a standardiza dezvoltarea RIA . Cu toate acestea, creșterea complexității soluțiilor software poate complica și prelungi procesul de testare pe măsură ce crește numărul de cazuri de utilizare testate. Testarea incompletă reduce calitatea și fiabilitatea aplicației în timpul utilizării acesteia. Se poate argumenta dacă acest lucru se aplică numai tehnologiei RIA sau complexității dezvoltării în general. De exemplu, exact același argument a fost făcut atunci când Apple și Microsoft au anunțat independent GUI în anii 1980 și poate chiar și atunci când Ford și-a prezentat modelul T. Cu toate acestea, omenirea a demonstrat o capacitate remarcabilă de a absorbi toate inovațiile tehnologice de-a lungul deceniilor, dacă nu chiar secolelor;
- Arhitectura RIA rupe paradigma paginii web . Aplicațiile web tradiționale sunt o colecție de pagini web ; pentru a descărca fiecare pagină web, clientul trimite o solicitare HTTP GET ; un astfel de model se numește paradigma paginii web. RIA „rupe” această paradigmă; serverul trebuie acum să servească cereri asincrone pentru a sprijini o experiență mai interactivă. Pentru a obține informații despre timpul petrecut în activitatea RIA, ar trebui dezvoltate noi tehnologii standard. În absența unor astfel de tehnologii (instrumente standard), dezvoltatorii RIA trebuie să adauge aplicațiilor lor instrumente de măsurare a datelor necesare SLM;
- asincronia face dificilă identificarea problemelor de performanță . Paradoxal, măsurile luate pentru a îmbunătăți timpul de răspuns al aplicației fac dificilă determinarea timpului de răspuns, măsurarea timpului și gestionarea aplicației. Unele RIA rulează într-un browser web după ce browser-ul a descărcat o singură pagină web, folosind un „motor client” pentru a descărca asincron datele necesare; browserul nu mai trimite nicio solicitare HTTP GET . Partea client a RIA poate fi programată să descarce în mod constant noi date (conținut) și să actualizeze conținutul ecranului sau (în aplicațiile care utilizează abordarea Comet ) partea de server a RIA poate trimite constant date noi (conținut) către partea client. printr-o conexiune mereu deschisă. În acest caz, conceptul de „încărcare a unei pagini” nu mai este aplicabil. Toate acestea introduc anumite dificultăți în măsurarea timpului și împărțirea timpului de răspuns al aplicației, care sunt cerințe fundamentale pentru identificarea problemelor de performanță și SLM. Instrumentele concepute pentru a măsura timpul de funcționare al aplicațiilor web tradiționale, în funcție de specificul și setul de instrumente al aplicației, pot lua în considerare fiecare pagină web solicitată prin HTTP, individual sau ca un set de indicatori nelegați. Cu toate acestea, niciuna dintre aceste abordări nu arată ce se întâmplă cu adevărat la nivelul aplicației;
- „Motorul client” face dificilă măsurarea timpului de răspuns al aplicației . Pentru aplicațiile web tradiționale, software-ul de măsurare a timpului poate fi amplasat pe mașina client, iar pe o mașină apropiată de server, poate monitoriza fluxul de trafic de rețea la straturile TCP și HTTP . Deoarece TCP și HTTP sunt protocoale sincronizate și previzibile, snifferul poate citi date din pachetele TCP și HTTP, poate interpreta datele citite și deduce timpii de răspuns folosind urmărirea mesajelor HTTP și timpul de confirmare a pachetelor TCP de nivel scăzut. Utilizarea unui sniffer pentru a măsura sincronizarea aplicațiilor care utilizează arhitectura RIA este dificilă, deoarece motorul utilizatorului descompune interacțiunea dintre client și server în două bucle separate care funcționează asincron - bucla din prim-plan (motor de utilizator) și cea din spate ( motor-server) buclă. Ambele cicluri sunt importante deoarece relația lor comună determină comportamentul aplicației. Dar acest raport depinde doar de arhitectura aplicației în sine, care în cele mai multe cazuri nu poate fi prezisă de instrumentele de măsurare, în special de primul (sniffer), care poate observa doar unul dintre cele două cicluri. Prin urmare, cea mai completă măsurare a timpului RIA poate fi obținută numai folosind instrumente care se află pe partea clientului și a observatorului în ambele cicluri.
Vezi și
Note
- ↑ Larry Seltzer. Aplicațiile bogate de internet sunt atractive pentru atacatori // PCWeek, 15/09/2010.
- ↑ Puterile S., Puterile S. Adăugând Ajax. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
- ↑ Cotă de piață bogată a aplicațiilor Internet (link descendent) . Consultat la 9 decembrie 2010. Arhivat din original la 6 octombrie 2011. (nedefinit)
Literatură
- Constantin Kovalev. RIA înseamnă libertate // World of PC. - 2008. - Nr 3. - S. 62-65. — ISSN 0235-3520