Rik internetapplikation
Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från
versionen som granskades den 19 juli 2021; kontroller kräver
4 redigeringar .
En rik internetapplikation (webb) [1] [2] ( eng. rik internetapplikation , RIA ) är en webbapplikation som laddas ner av en användare över internet , designad för att utföra funktionerna hos traditionella skrivbordsapplikationer och köras på användarens enhet ( inte på en server).
Teknik som används för att implementera RIA:
Huvuddrag:
- RIA består av två delar: klient och server;
- RIA-serverdelen körs på servern, kan lagra den information som krävs för att applikationen ska fungera och kan hantera förfrågningar som kommer från RIA-klientdelen;
- RIA-klientdelen körs på användarens dator, ritar användargränssnittet , exekverar användarförfrågningar och kan, om nödvändigt, skicka förfrågningar till RIA-serverdelen;
- Klientdelen av RIA körs i en säker miljö som kallas " sandbox " ( engelsk sandbox ), och kräver ingen installation av ytterligare programvara .
Enligt [3] från och med juli 2012 var de mest populära plattformarna som användes för att skapa RIA:er Adobe Flash , JavaFX , Microsoft Silverlight .
Historik
Termen "RIA" nämndes först av Macromedia i en vitbok från mars 2002. Idén om RIA fanns några år tidigare med följande namn:
- " Remote Scripting " ( Microsoft ; cirka 1998 );
- "X Internet" (Forrester Research; oktober 2000);
- "Rik (web)klient";
- rik webbapplikation.
Traditionella webbapplikationer fungerar så här.
- Klienten skickar en begäran till servern och väntar på ett svar.
- Servern tar emot en begäran från klienten, genererar och skickar ett svar till klienten.
- Klienten tar emot och visar svaret.
Dessa åtgärder upprepas ständigt (cykel). I en sådan arkitektur är klienten endast engagerad i att visa information (statiskt innehåll, till exempel HTML ), och överför alla databearbetningsuppgifter till servern. Den största nackdelen med denna arkitektur är att allt arbete utförs av servern. Du kan öka hastigheten på applikationen om en del av arbetet flyttas till klienten.
I RIA-arkitekturen kan en del eller hela arbetet utföras av beställaren.
Den gradvisa utvecklingen av standarder för Internetnätverk har lett till möjligheten att implementera RIA. Det är dock svårt att dra en tydlig gräns mellan vilka tekniker som inkluderar RIA och vilka som inte gör det. Men alla RIA har en funktion: den så kallade "klientmotorn" laddas på användarens enhet innan RIA startar; i framtiden kan motorn laddas om under applikationens gång.
"Klientmotorn" implementerar funktioner som inte är tillgängliga för traditionella webbapplikationer, kan laddas i en webbläsares sammanhang (HTML, JavaScript) eller i en webbläsares plugin-program (tillägg) (Adobe Flash ) , JavaFX, Microsoft Silverlight, Native Client). "Klientmotorn" är vanligtvis ansvarig för att rendera (rita) användargränssnittet (UI) (till exempel kan implementering av ett användargränssnitt för en RIA vara enklare och snabbare än för en traditionell webbapplikation) och interagera med servern (till exempel, klientsidan av en RIA kan skicka förfrågningar till RIA-backend antingen synkront (som traditionella webbapplikationer) eller asynkront ). Möjligheterna hos "klientmotorn" kan begränsas av funktionerna hos användarens enhet och OS .
Fördelar
Fördelar med webbapplikationer:
- webbapplikation kräver ingen installation (användare laddar ner applikationen från servern efter behov; detta säkerställer automatisk distribution av applikationen);
- webbapplikationen uppdateras automatiskt (den senaste versionen av applikationen finns på servern);
- en webbapplikation kan köras på vilken enhet som helst med en Internetanslutning och under vilket operativsystem som helst (variationen av operativsystem skapar inga problem tack vare ett enda API för alla operativsystem );
- när en webbapplikation körs är användarens enhet mindre känslig för virusinfektion än när körbara binärfiler körs (webbapplikationen körs i en sandlåda).
Fördelar med RIA jämfört med traditionella webbapplikationer, uppnådda genom användning av funktionerna i "klientmotorn":
- möjligheten att använda standard OS-kontroller i användargränssnittet (till exempel använda en reglage för att ändra data);
- möjligheten att använda standardåtgärder för att interagera med andra program (till exempel dra-och-släpp , kopiering av data till urklipp );
- förmågan att utföra beräkningar på användarens enhet (utan att skicka användarens personliga data till servern (till exempel en bolånekalkylator ) );
- flexibla alternativ för att bygga ett användargränssnitt (till exempel validering av data som angetts av användaren under inmatningsprocessen utan att skicka förfrågningar till servern ( interaktivitet ));
- möjligheten att fortsätta applikationen efter att ha skickat en begäran till servern (asynkron);
- möjligheten att ladda ner data från servern innan användaren begär data (till exempel i Google Maps laddas kartfragment som finns bredvid fragmentet som användaren tittar på i förväg);
- möjligheten att minska belastningen på servern (vid utförande av beräkningar på klienten), och följaktligen möjligheten att öka antalet sessioner som behandlas av servern samtidigt (utan att ersätta hårdvaran).
Nackdelar
Nackdelar med RIA:
- brist på tillgång till OS-resurser (eftersom webbapplikationen körs i en " sandlåda "). Om resursbehörigheterna är felaktiga kanske RIA:er inte fungerar korrekt;
- att köra en webbapplikation kan kräva exekvering av kod skriven på ett skriptspråk (till exempel i JavaScript); om användaren inaktiverar möjligheten att exekvera kod kanske RIA inte fungerar korrekt eller inte alls;
- låg hastighet för multiplattformswebbapplikationer. För att säkerställa RIA-plattformens oberoende kan RIA-klientsidan använda kod skriven på ett skriptspråk (som JavaScript); när man kör sådan kod finns det ett prestandafall - ett allvarligt problem för mobila enheter. Detta problem uppstår inte när man använder ett inbäddat språk kompilerat på klientsidan (till exempel Java), där prestanda är jämförbar med att använda traditionella inbäddade språk, antingen Adobe Flash eller Microsoft Silverlight , där programkoden körs direkt i en Flash Player eller Silverlight plugin, respektive. ;
- behovet av att installera en "klientmotor";
- lång laddningstid för webbapplikationer. Klienten laddar ner RIA - klientsidan från servern varje gång . Eftersom de flesta data som laddas är cachelagrade måste RIA-klienten laddas minst en gång för att snabba på uppstarten. Nedladdningstiden beror på storleken på den nedladdade datan; för att minska storleken på klientdelen av RIA kan utvecklare komprimera den eller dela upp den i delar som laddas efter behov;
- förlust av integritet. Om en applikation är baserad på X/HTML kan det uppstå konflikter mellan applikationens mål (som naturligtvis vill ha kontroll över sin presentation och handlingar) och målen för X/HTML (som vill avstå från kontrollen). DOM-gränssnittet för X/HTML gör det möjligt att skapa en RIA, men det finns ingen garanti för att den kommer att fungera korrekt. Eftersom RIA-klienten kan ändra applikationens grundläggande struktur och åsidosätta dess åtgärder och presentation, kan detta göra att applikationen misslyckas på klientsidan. I slutändan kan detta problem lösas med en ny klient-server- mekanism som ger RIA-klienten begränsad tillgång till att modifiera de resurser som inte är inom dess omfattning. Arbetet med inbyggd standardprogramvara orsakar inte sådana problem, eftersom de per definition automatiskt har alla nödvändiga rättigheter till lokala resurser;
- omöjligheten att indexera en webbapplikation av sökmotorer . Sökmotorer kanske inte kan indexera RIA-innehåll. Men ofta krävs inte indexering;
- beroende av internetuppkoppling. RIA som utformats för att ersätta skrivbordsapplikationer bör tillåta användare att ansluta till nätverket vid behov, till exempel bör de inte bli obrukbara när en användare flyttar mellan trådlösa täckningsområden . År 2007 krävde typiska RIA-applikationer en permanent anslutning till nätverket. Med tillkomsten av HTML5 blir detta problem mindre relevant; HTML5 lokala lagrings -API låter dig lagra data på klientsidan; HTML5 File API tillåter åtkomst till filsystemet på användarens enhet.
Utmaningar för applikationsutveckling
Tillkomsten av RIA-teknik åtföljdes av betydande svårigheter i utvecklingen av webbapplikationer . Traditionella webbapplikationer, baserade på standard HTML, med en relativt enkel arkitektur och en ganska begränsad funktionsuppsättning, var relativt enkla att utveckla och hantera. Individer och organisationer som implementerar webbapplikationer baserade på RIA-teknik står ofta inför ytterligare utmaningar inom utveckling, testning, mätning och support.
Användningen av RIA-teknik ställer till nya utmaningar för SLM-servicehantering ( service level management ), som inte alla har lösts hittills . Frågor om SLM tas inte alltid hänsyn till av applikationsutvecklare och uppfattas nästan inte av användarna. De är dock avgörande för framgångsrik implementering av en applikation på Internet. De viktigaste aspekterna som komplicerar RIA-utvecklingsprocessen är följande:
- teknisk komplexitet . Möjligheten att dela applikationskod direkt med kunder ger utvecklare och designers mer kreativ frihet. Men detta komplicerar i sin tur utvecklingen av applikationen, ökar sannolikheten för fel under implementeringen och gör det svårt att testa programvaran . Dessa komplikationer förlänger utvecklingsprocessen, oavsett särdragen i metodiken och utvecklingsprocessen. Vissa av dessa problem kan minskas genom att använda ett ramverk för webbapplikationer för att standardisera RIA-utveckling . Ökande komplexitet i mjukvarulösningar kan dock komplicera och förlänga testprocessen när antalet användningsfall som testas ökar. Ofullständig testning minskar applikationens kvalitet och tillförlitlighet under dess användning. Man kan tvista om huruvida detta bara gäller RIA-teknik eller komplexiteten i utveckling i allmänhet. Exakt samma argument framfördes till exempel när Apple och Microsoft oberoende tillkännagav GUI på 1980-talet, och kanske till och med när Ford introducerade sin Model T. Ändå har mänskligheten visat en anmärkningsvärd förmåga att absorbera alla tekniska innovationer under decennier, om inte århundraden;
- RIA-arkitektur bryter webbsidans paradigm . Traditionella webbapplikationer är en samling webbsidor ; för att ladda ner varje webbsida skickar klienten en HTTP GET-begäran ; en sådan modell kallas webbsidesparadigmet. RIA "bryter" detta paradigm; servern måste nu betjäna asynkrona förfrågningar för att stödja ett mer interaktivt gränssnitt. För att få information om hur mycket tid som spenderas i RIA:s arbete bör nya standardtekniker utvecklas. I avsaknad av sådana teknologier (standardverktyg) måste RIA-utvecklare lägga till datamätverktyg som är nödvändiga för SLM till sina applikationer;
- asynkroni gör det svårt att identifiera prestandaproblem . Paradoxalt nog gör de åtgärder som vidtagits för att förbättra applikationens svarstid det svårt att bestämma svarstid, mäta tid och hantera applikationen. Vissa RIA:er körs i en webbläsare efter att webbläsaren har laddat ner en enda webbsida, med hjälp av en "klientmotor" för att asynkront ladda ner nödvändig data; webbläsaren skickar inte längre några HTTP GET- förfrågningar . Klientsidan av RIA:n kan programmeras för att ständigt ladda ner ny data (innehåll) och uppdatera skärminnehållet, eller (i applikationer som använder Comet -metoden ) kan serversidan av RIA ständigt skicka ny data (innehåll) till klientsidan genom en alltid öppen anslutning. I det här fallet är konceptet "ladda en sida" inte längre tillämpligt. Allt detta introducerar vissa svårigheter att mäta tiden och fördelningen av applikationens svarstid, vilket är grundläggande krav för att identifiera prestandaproblem och SLM. Verktyg utformade för att mäta upptiden för traditionella webbapplikationer, beroende på specifikationerna och applikationens verktygslåda, kan överväga varje webbsida som begärs via HTTP, individuellt eller som en uppsättning orelaterade indikatorer. Inget av dessa tillvägagångssätt visar dock vad som verkligen händer på applikationsnivå;
- "Klientmotorn" gör det svårt att mäta applikationens svarstid . För traditionella webbapplikationer kan tidsmätningsprogramvaran placeras på klientdatorn och på en maskin nära servern kan den övervaka flödet av nätverkstrafik på TCP- och HTTP- lagren . Eftersom TCP och HTTP är synkroniserade och förutsägbara protokoll, kan sniffern läsa data från TCP- och HTTP-paket, tolka lästa data och härleda svarstider med hjälp av HTTP-meddelandespårning och lågnivå TCP-paketbekräftelsetid. Att använda en sniffer för att mäta tidpunkten för applikationer som använder RIA-arkitekturen är svårt eftersom användarmotorn bryter interaktionen mellan klienten och servern i två separata slingor som fungerar asynkront - förgrundsslingan (användarmotor) och bakänden ( motor-server) loop. Båda dessa cykler är viktiga eftersom deras gemensamma förhållande avgör applikationens beteende. Men detta förhållande beror bara på arkitekturen för själva applikationen, som i de flesta fall inte kan förutsägas av mätverktyg, särskilt den första (sniffer), som bara kan observera en av de två cyklerna. Därför kan den mest kompletta mätningen av RIA-tid endast erhållas med hjälp av verktyg som finns på klient- och observatörssidan i båda cyklerna.
Se även
Anteckningar
- ↑ Larry Seltzer. Rika internetapplikationer är attraktiva för angripare // PCWeek, 2010/09/15.
- ↑ Powers S., Powers S. Lägger till Ajax. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
- ↑ Rich Internet Application Market Share (nedlänk) . Hämtad 9 december 2010. Arkiverad från originalet 6 oktober 2011. (obestämd)
Litteratur
- Konstantin Kovalev. RIA betyder frihet // World of PC. - 2008. - Nr 3. - S. 62-65. — ISSN 0235-3520