Rig internetapplikation
Den aktuelle version af siden er endnu ikke blevet gennemgået af erfarne bidragydere og kan afvige væsentligt fra den
version , der blev gennemgået den 19. juli 2021; checks kræver
4 redigeringer .
En rig internet (web) applikation [1] [2] ( eng. rich internet application , RIA ) er en webapplikation, der downloades af en bruger over internettet , designet til at udføre funktionerne i traditionelle desktop-applikationer og køre på brugerens enhed ( ikke på en server).
Teknologier, der bruges til at implementere RIA:
Hovedtræk:
- RIA består af to dele: klient og server;
- RIA-serverdelen kører på serveren, kan gemme de oplysninger, der er nødvendige for, at applikationen kan fungere, og kan håndtere anmodninger, der kommer fra RIA-klientdelen;
- RIA-klientdelen kører på brugerens computer, tegner brugergrænsefladen , udfører brugeranmodninger og kan om nødvendigt sende anmodninger til RIA-serverdelen;
- Klientdelen af RIA kører i et sikkert miljø kaldet " sandbox " ( engelsk sandbox ), og kræver ikke installation af yderligere software .
Ifølge [3] i juli 2012 var de mest populære platforme, der blev brugt til at oprette RIA'er, Adobe Flash , JavaFX , Microsoft Silverlight .
Historie
Udtrykket "RIA" blev første gang nævnt af Macromedia i en hvidbog fra marts 2002. Ideen om RIA eksisterede et par år tidligere med følgende navne:
- " Remote Scripting " ( Microsoft ; ca. 1998 );
- "X Internet" (Forrester Research; oktober 2000);
- "Rich (web)klient";
- rig webapplikation.
Traditionelle webapplikationer fungerer på denne måde.
- Klienten sender en anmodning til serveren og venter på et svar.
- Serveren modtager en anmodning fra klienten, genererer og sender et svar til klienten.
- Klienten modtager og viser svaret.
Disse handlinger gentages konstant (cyklus). I en sådan arkitektur er klienten kun engageret i at vise information (statisk indhold, for eksempel HTML ), og overfører alle databehandlingsopgaver til serveren. Den største ulempe ved denne arkitektur er, at alt arbejdet udføres af serveren. Du kan øge hastigheden på ansøgningen, hvis en del af arbejdet flyttes til klienten.
I RIA-arkitekturen kan noget af eller hele arbejdet udføres af bygherren.
Den gradvise udvikling af internetnetværksstandarder har ført til muligheden for at implementere RIA. Det er dog svært at trække en klar grænse mellem, hvilke teknologier der inkluderer RIA, og hvilke der ikke gør. Men alle RIA'er har én funktion: den såkaldte "klientmotor" indlæses på brugerens enhed, før RIA starter; i fremtiden kan motoren genindlæses i løbet af applikationen.
"Klientmotoren" implementerer funktioner, der ikke er tilgængelige for traditionelle webapplikationer, kan indlæses i konteksten af en webbrowser (HTML, JavaScript) eller i sammenhæng med et webbrowser -plugin (tilføjelse) (Adobe Flash ) , JavaFX, Microsoft Silverlight, Native Client). "Klientmotoren" er normalt ansvarlig for at gengive (tegne) brugergrænsefladen (UI) (for eksempel kan implementering af en brugergrænseflade til en RIA være enklere og hurtigere end for en traditionel webapplikation) og interagere med serveren (f.eks. klientsiden af en RIA kan sende anmodninger til RIA-backend enten synkront (som traditionelle webapplikationer) eller asynkront ). Mulighederne for "klientmotoren" kan være begrænset af mulighederne på brugerens enhed og OS .
Fordele
Fordele ved webapplikationer:
- webapplikation kræver ikke installation (brugere downloader applikationen fra serveren efter behov; dette sikrer automatisk distribution af applikationen);
- webapplikationen opdateres automatisk (den seneste version af applikationen er hostet på serveren);
- en webapplikation kan køre på en hvilken som helst enhed med en internetforbindelse og under ethvert operativsystem (de mange forskellige OS skaber ikke et problem takket være en enkelt API for alle OS'er );
- når man kører en webapplikation, er brugerens enhed mindre modtagelig for virusinfektion end når man kører eksekverbare binære filer (webapplikationen køres i en sandbox).
Fordele ved RIA sammenlignet med traditionelle webapplikationer, opnået gennem brugen af "klientmotorens" funktioner:
- evnen til at bruge standard OS-kontroller i brugergrænsefladen (for eksempel ved at bruge en skyder til at ændre data);
- evnen til at bruge standardhandlinger til at interagere med andre programmer (for eksempel træk-og-slip , kopiering af data til udklipsholderen );
- evnen til at udføre beregninger på brugerens enhed (uden at sende brugerens personlige data til serveren (for eksempel en realkreditberegner ));
- fleksible muligheder for opbygning af en brugergrænseflade (for eksempel validering af de data, som brugeren indtaster under inputprocessen uden at sende anmodninger til serveren ( interaktivitet ));
- evnen til at fortsætte applikationen efter at have sendt en anmodning til serveren (asynkron);
- muligheden for at downloade data fra serveren, før brugeren anmoder om data (for eksempel i Google Maps indlæses kortfragmenter placeret ved siden af det fragment, som brugeren kigger på), på forhånd);
- muligheden for at reducere belastningen på serveren (i tilfælde af at udføre beregninger på klienten), og som følge heraf muligheden for at øge antallet af sessioner, der behandles af serveren samtidigt (uden at erstatte hardwaren).
Ulemper
Ulemper ved RIA:
- manglende adgang til OS-ressourcer (da webapplikationen kører i en " sandbox "). Hvis ressourcetilladelserne er forkerte, fungerer RIA'er muligvis ikke korrekt;
- at køre en webapplikation kan kræve udførelse af kode skrevet i et scriptsprog (for eksempel i JavaScript); hvis brugeren deaktiverer muligheden for at udføre kode, fungerer RIA muligvis ikke korrekt eller virker måske slet ikke;
- lav hastighed af multiplatform webapplikationer. For at sikre RIA-platformens uafhængighed kan RIA-klientsiden bruge kode skrevet i et scriptsprog (såsom JavaScript); når en sådan kode udføres, er der et ydelsesfald - et alvorligt problem for mobile enheder. Dette problem opstår ikke, når du bruger et indlejret sprog, der er kompileret på klientsiden (for eksempel Java), hvor ydeevnen kan sammenlignes med at bruge traditionelle indlejrede sprog, enten Adobe Flash eller Microsoft Silverlight , hvor programkoden kører direkte i en Flash Player eller Silverlight plugin, henholdsvis. ;
- behovet for at installere en "klientmotor";
- lang indlæsningstid for webapplikationer. Klienten downloader RIA - klientsiden fra serveren hver gang . Fordi de fleste af de data, der indlæses, er cachelagret, skal RIA-klienten indlæses mindst én gang for at fremskynde opstarten. Downloadtiden afhænger af størrelsen af de downloadede data; for at reducere størrelsen af klientdelen af RIA kan udviklere komprimere den eller opdele den i dele, der indlæses efter behov;
- tab af integritet. Hvis en applikation er baseret på X/HTML, kan der opstå konflikter mellem applikationens mål (som naturligvis ønsker at have kontrol over sin præsentation og handlinger) og målene for X/HTML (som ønsker at opgive kontrollen). DOM-grænsefladen til X/HTML gør det muligt at oprette en RIA, men der er ingen garanti for, at den fungerer korrekt. Fordi RIA-klienten kan ændre applikationens grundlæggende struktur og tilsidesætte dens handlinger og præsentation, kan dette medføre, at applikationen fejler på klientsiden. I sidste ende kan dette problem løses af en ny klient-server- mekanisme , der giver RIA-klienten begrænset adgang til at ændre de ressourcer, der ikke er inden for dens omfang. Arbejdet med indfødt standardsoftware forårsager ikke sådanne problemer, da de per definition automatisk har alle de nødvendige rettigheder til lokale ressourcer;
- umuligheden af at indeksere en webapplikation af søgemaskiner . Søgemaskiner kan muligvis ikke indeksere RIA-indhold. Men ofte er indeksering ikke påkrævet;
- afhængighed af internetforbindelse. RIA'er designet til at erstatte desktop-applikationer bør tillade brugere at oprette forbindelse til netværket efter behov, for eksempel bør de ikke blive ubrugelige, når en bruger bevæger sig mellem trådløse dækningsområder . I 2007 krævede typiske RIA-applikationer en permanent forbindelse til netværket. Med fremkomsten af HTML5 bliver dette problem mindre relevant; HTML5 lokal lagring API giver dig mulighed for at gemme data på klientsiden; HTML5 File API giver adgang til filsystemet på brugerens enhed.
Udfordringer til applikationsudvikling
Fremkomsten af RIA-teknologi blev ledsaget af betydelige vanskeligheder i udviklingen af webapplikationer . Traditionelle webapplikationer, baseret på standard HTML, med en relativt simpel arkitektur og et ret begrænset funktionssæt, var relativt nemme at udvikle og administrere. Enkeltpersoner og organisationer, der implementerer webapplikationer baseret på RIA-teknologi, står ofte over for yderligere udviklings-, test-, målings- og supportudfordringer.
Brugen af RIA-teknologi giver nye udfordringer for SLM service management ( service level management ), som ikke alle er løst til dato . Spørgsmål vedrørende SLM tages ikke altid i betragtning af applikationsudviklere og bliver næsten ikke opfattet af brugerne. De er dog afgørende for en vellykket implementering af en applikation på internettet. De vigtigste aspekter, der komplicerer RIA-udviklingsprocessen, er følgende:
- teknologisk kompleksitet . Muligheden for at dele applikationskode direkte med klienter giver udviklere og designere mere kreativ frihed. Men dette komplicerer til gengæld udviklingen af applikationen, øger sandsynligheden for fejl under implementeringen og gør det vanskeligt at teste softwaren . Disse komplikationer forlænger udviklingsprocessen, uanset de særlige forhold i metodologien og udviklingsprocessen. Nogle af disse problemer kan reduceres ved at bruge en webapplikationsramme til at standardisere RIA-udvikling . Men stigende kompleksitet i softwareløsninger kan komplicere og forlænge testprocessen, efterhånden som antallet af use cases, der testes, stiger. Ufuldstændig test reducerer kvaliteten og pålideligheden af applikationen under brugen. Man kan diskutere, om dette kun gælder for RIA-teknologi eller for kompleksiteten i udvikling generelt. For eksempel blev nøjagtig det samme argument fremsat, da Apple og Microsoft uafhængigt annoncerede GUI'en i 1980'erne, og måske endda da Ford introducerede sin Model T. Ikke desto mindre har menneskeheden vist en bemærkelsesværdig evne til at absorbere alle teknologiske innovationer gennem årtier, hvis ikke århundreder;
- RIA-arkitektur bryder websidens paradigme . Traditionelle webapplikationer er en samling af websider ; for at downloade hver webside sender klienten en HTTP GET-anmodning ; sådan en model kaldes webside-paradigmet. RIA "bryder" dette paradigme; serveren skal nu betjene asynkrone anmodninger for at understøtte en mere interaktiv grænseflade. For at få oplysninger om mængden af tid brugt i arbejdet med RIA bør der udvikles nye standardteknologier. I mangel af sådanne teknologier (standardværktøjer) skal RIA-udviklere tilføje datamålingsværktøjer, der er nødvendige for SLM, til deres applikationer;
- asynkroni gør det vanskeligt at identificere ydeevneproblemer . Paradoksalt nok gør de foranstaltninger, der er truffet for at forbedre applikationens responstid, det vanskeligt at bestemme responstid, måle tid og administrere applikationen. Nogle RIA'er kører i en webbrowser, efter at browseren har downloadet en enkelt webside, ved at bruge en "klientmotor" til asynkront at downloade de nødvendige data; browseren sender ikke længere nogen HTTP GET- anmodninger . Klientsiden af RIA'en kan programmeres til konstant at downloade nye data (indhold) og opdatere skærmindholdet, eller (i applikationer, der bruger Comet -tilgangen ) kan serversiden af RIA konstant sende nye data (indhold) til klientsiden gennem en altid åben forbindelse. I dette tilfælde er begrebet "indlæsning af en side" ikke længere anvendeligt. Alt dette introducerer visse vanskeligheder med at måle tiden og opdelingen af applikationens responstid, som er grundlæggende krav til identifikation af ydeevneproblemer og SLM. Værktøjer designet til at måle oppetiden for traditionelle webapplikationer, afhængigt af specifikationerne og applikationsværktøjssættet, kan betragte hver webside, der anmodes om via HTTP, individuelt eller som et sæt ikke-relaterede indikatorer. Ingen af disse tilgange viser dog, hvad der virkelig foregår på applikationsniveau;
- "Klientmotoren" gør det vanskeligt at måle applikationens responstid . For traditionelle webapplikationer kan tidsmålingssoftwaren være placeret på klientmaskinen, og på en maskine tæt på serveren kan den overvåge strømmen af netværkstrafik på TCP- og HTTP - lagene . Da TCP og HTTP er synkroniserede og forudsigelige protokoller, kan snifferen læse data fra TCP- og HTTP-pakker, fortolke de læste data og udlede responstider ved hjælp af HTTP-meddelelsessporing og TCP-pakkebekræftelsestid på lavt niveau. Det er svært at bruge en sniffer til at måle timingen af applikationer, der bruger RIA-arkitekturen, fordi brugermotoren opdeler interaktionen mellem klienten og serveren i to separate sløjfer, der fungerer asynkront - forgrundsløkken (brugermotor) og bagenden ( motor-server) sløjfe. Begge disse cyklusser er vigtige, fordi deres fælles forhold bestemmer applikationens adfærd. Men dette forhold afhænger kun af selve applikationens arkitektur, som i de fleste tilfælde ikke kan forudsiges af måleværktøjer, især den første (sniffer), som kun kan observere en af de to cyklusser. Derfor kan den mest komplette måling af RIA-tid kun opnås ved hjælp af værktøjer, der er på klient- og observatørsiden i begge cyklusser.
Se også
Noter
- ↑ Larry Seltzer. Rich internetapplikationer er attraktive for angribere // PCWeek, 15/09/2010.
- ↑ Powers S., Powers S. Tilføjer Ajax. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
- ↑ Markedsandel for rig internetapplikation (downlink) . Hentet 9. december 2010. Arkiveret fra originalen 6. oktober 2011. (ubestemt)
Litteratur
- Konstantin Kovalev. RIA betyder frihed // World of PC. - 2008. - Nr. 3. - S. 62-65. — ISSN 0235-3520