Bohatá internetová aplikace

Bohatá internetová (webová) aplikace [1] [2] ( anglicky  rich internet application , RIA ) je webová aplikace stažená uživatelem přes internet , určená k provádění funkcí tradičních desktopových aplikací a spuštěná na zařízení uživatele ( ne na serveru).

Technologie použité k implementaci RIA:

• značkovací jazyk HTML5 a programovací jazyk JavaScript ;
• (Google) Native Client ;
• Adobe Flash ;
• ( Oracle ) JavaFX ;
• Microsoft Silverlight .

Hlavní rysy:

• RIA se skládá ze dvou částí: klienta a serveru;
• serverová část RIA běží na serveru, může ukládat informace potřebné pro fungování aplikace a vyřizovat požadavky přicházející z klientské části RIA;
• klientská část RIA běží na počítači uživatele, kreslí uživatelské rozhraní , zpracovává požadavky uživatelů a v případě potřeby může odesílat požadavky na serverovou část RIA;
• Klientská část RIA běží v zabezpečeném prostředí zvaném " sandbox " ( anglicky  sandbox ) a nevyžaduje instalaci dalšího softwaru .

Podle [3] k červenci 2012 nejoblíbenější platformy používané k vytváření RIA byly Adobe Flash , JavaFX , Microsoft Silverlight .

Historie

Termín „RIA“ byl poprvé zmíněn společností Macromedia v březnu 2002 v bílé knize. Myšlenka RIA existovala o několik let dříve s těmito názvy:

• " Vzdálené skriptování " ( Microsoft ; cca 1998 ) ;
• "X Internet" (Forrester Research; říjen 2000);
• "Bohatý (webový) klient";
• bohatá webová aplikace.

Tradiční webové aplikace fungují takto.

1. Klient odešle požadavek na server a čeká na odpověď.
2. Server přijme požadavek od klienta, vygeneruje a odešle klientovi odpověď.
3. Klient obdrží a zobrazí odpověď.

Tyto akce se neustále opakují (cyklus). V takové architektuře se klient zabývá pouze zobrazováním informací (statický obsah, například HTML ) a přenáší všechny úlohy zpracování dat na server. Hlavní nevýhodou této architektury je, že veškerou práci provádí server. Rychlost aplikace můžete zvýšit, pokud se část práce přesune na klienta.

V architektuře RIA může část nebo veškerou práci provádět klient.

Postupný vývoj standardů internetových sítí vedl k možnosti implementace RIA. Je však obtížné stanovit jasnou hranici mezi tím, které technologie zahrnují RIA a které nikoli. Ale všechny RIA mají jednu vlastnost: takzvaný „klientský engine“ je načten do zařízení uživatele před spuštěním RIA; v budoucnu lze motor v průběhu aplikace znovu načíst.

„Klientský engine“ implementuje funkce, které nejsou dostupné tradičním webovým aplikacím, lze je načíst v kontextu webového prohlížeče (HTML, JavaScript) nebo v kontextu zásuvného modulu webového prohlížeče (add-on) (Adobe Flash , JavaFX, Microsoft Silverlight, Native Client). „Klientský engine“ je obvykle zodpovědný za vykreslování (kreslení) uživatelského rozhraní (UI) (například implementace uživatelského rozhraní pro RIA může být jednodušší a rychlejší než pro tradiční webovou aplikaci) a interakci se serverem (např. klientská strana RIA může odesílat požadavky do backendu RIA buď synchronně (jako tradiční webové aplikace), nebo asynchronně . Možnosti „klientského enginu“ mohou být omezeny možnostmi zařízení a OS uživatele .

Výhody

Výhody webových aplikací:

• webová aplikace nevyžaduje instalaci (uživatelé si aplikaci podle potřeby stahují ze serveru; tím je zajištěna automatická distribuce aplikace);
• webová aplikace je aktualizována automaticky (poslední verze aplikace je hostována na serveru);
• webová aplikace může běžet na jakémkoli zařízení s připojením k internetu a pod jakýmkoli OS (rozmanitost OS nečiní problém díky jedinému API pro všechny OS );
• při spuštění webové aplikace je zařízení uživatele méně náchylné k virové infekci než při spuštění spustitelných binárních souborů (webová aplikace se spouští v sandboxu).

Výhody RIA ve srovnání s tradičními webovými aplikacemi, dosažené využitím schopností „klientského enginu“:

• možnost používat standardní ovládací prvky OS v uživatelském rozhraní (například pomocí posuvníku pro změnu dat);
• schopnost používat standardní akce k interakci s jinými programy (například přetažení , kopírování dat do schránky );
• možnost provádět výpočty na zařízení uživatele (bez odesílání osobních údajů uživatele na server (například hypoteční kalkulačka ));
• flexibilní možnosti pro sestavení uživatelského rozhraní (například ověření dat zadaných uživatelem během vstupního procesu bez odesílání požadavků na server ( interaktivita ));
• schopnost pokračovat v aplikaci po odeslání požadavku na server (asynchronní);
• možnost stáhnout data ze serveru dříve, než uživatel o data požádá (například v Mapách Google se předem načtou fragmenty mapy umístěné vedle fragmentu, na který se uživatel dívá);
• možnost snížení zátěže serveru (v případě provádění výpočtů na klientovi) a následně možnost zvýšení počtu relací zpracovávaných serverem současně (bez výměny hardwaru).

Nevýhody

Nevýhody RIA:

• nedostatek přístupu k prostředkům operačního systému (protože webová aplikace běží v " sandbox "). Pokud jsou oprávnění zdrojů nesprávná, RIA nemusí fungovat správně;
• spuštění webové aplikace může vyžadovat spuštění kódu napsaného ve skriptovacím jazyce (například v JavaScriptu); pokud uživatel zakáže možnost spouštění kódu, RIA nemusí fungovat správně nebo nemusí fungovat vůbec;
• nízká rychlost multiplatformních webových aplikací. K zajištění nezávislosti platformy RIA může klientská strana RIA používat kód napsaný ve skriptovacím jazyce (jako je JavaScript); při provádění takového kódu dochází k poklesu výkonu – vážný problém pro mobilní zařízení. K tomuto problému nedochází při použití vloženého jazyka kompilovaného na straně klienta (například Java), kde je výkon srovnatelný s použitím tradičních vložených jazyků, ať už Adobe Flash nebo Microsoft Silverlight , ve kterých programový kód běží přímo v přehrávači Flash Player. nebo plugin Silverlight, v daném pořadí.
• nutnost instalace "klientského motoru";
• dlouhá doba načítání webové aplikace. Klient si pokaždé stáhne stranu klienta RIA ze serveru. Protože většina načtených dat je uložena v mezipaměti, musí být klient RIA načten alespoň jednou, aby se urychlilo spouštění. Doba stahování závisí na velikosti stahovaných dat; pro zmenšení velikosti klientské části RIA ji mohou vývojáři komprimovat nebo rozdělit na části, které se načítají podle potřeby;
• ztráta integrity. Pokud je aplikace založena na X/HTML, může docházet ke konfliktům mezi cíli aplikace (která přirozeně chce mít kontrolu nad svou prezentací a akcemi) a cíli X/HTML (která se chce kontroly vzdát). Rozhraní DOM pro X/HTML umožňuje vytvořit RIA, ale není zaručeno, že bude správně fungovat. Protože klient RIA může změnit základní strukturu aplikace a přepsat její akce a prezentaci, může to způsobit selhání aplikace na straně klienta. Tento problém lze nakonec vyřešit novým mechanismem klient-server , který klientovi RIA umožní omezený přístup k úpravě těch zdrojů, které nejsou v jeho působnosti. Práce nativního standardního softwaru takové problémy nezpůsobuje, protože podle definice mají automaticky všechna potřebná práva k místním zdrojům;
• nemožnost indexovat webovou aplikaci vyhledávači . Vyhledávače nemusí být schopny indexovat obsah RIA. Indexování však často není vyžadováno;
• závislost na internetovém připojení. RIA navržené jako náhrada desktopových aplikací by měly uživatelům umožnit připojení k síti podle potřeby, například by neměly být nefunkční, když se uživatel pohybuje mezi oblastmi bezdrátového pokrytí . Do roku 2007 vyžadovaly typické aplikace RIA trvalé připojení k síti. S příchodem HTML5 se tento problém stává méně relevantním; API místního úložiště HTML5 umožňuje ukládat data na straně klienta; HTML5 File API umožňuje přístup k souborovému systému zařízení uživatele.

Výzvy pro vývoj aplikací

Nástup technologie RIA doprovázely značné potíže při vývoji webových aplikací . Tradiční webové aplikace, založené na standardním HTML, s relativně jednoduchou architekturou a poměrně omezenou sadou funkcí, bylo relativně snadné vyvíjet a spravovat. Jednotlivci a organizace implementující webové aplikace založené na technologii RIA často čelí dalším problémům s vývojem, testováním, měřením a podporou.

Využití technologie RIA představuje pro správu služeb SLM ( service level management ) nové výzvy, z nichž ne všechny byly dosud vyřešeny .  Otázky týkající se SLM nejsou vývojáři aplikací vždy brány v úvahu a uživatelé je téměř nevnímají. Jsou však životně důležité pro úspěšnou implementaci aplikace na internetu. Hlavní aspekty, které komplikují proces vývoje RIA, jsou následující:

• technologická složitost . Možnost sdílet aplikační kód přímo s klienty dává vývojářům a návrhářům větší tvůrčí svobodu. To ale zase komplikuje vývoj aplikace, zvyšuje pravděpodobnost chyb při implementaci a ztěžuje testování softwaru . Tyto komplikace prodlužují proces vývoje bez ohledu na specifika metodiky a procesu vývoje. Některé z těchto problémů lze snížit použitím rámce webových aplikací pro standardizaci vývoje RIA .  Rostoucí složitost softwarových řešení však může komplikovat a prodlužovat proces testování, protože se zvyšuje počet testovaných případů použití. Neúplné testování snižuje kvalitu a spolehlivost aplikace při jejím používání. O tom, zda se to týká pouze technologie RIA nebo komplexnosti vývoje obecně, lze polemizovat. Například přesně stejný argument zazněl, když Apple a Microsoft nezávisle oznámily GUI v 80. letech a možná dokonce i když Ford představil svůj Model T. Přesto lidstvo během desetiletí, ne-li staletí, prokázalo pozoruhodnou schopnost absorbovat všechny technologické inovace;
• Architektura RIA narušuje paradigma webových stránek . Tradiční webové aplikace jsou sbírkou webových stránek ; ke stažení každé webové stránky klient odešle požadavek HTTP GET ; takový model se nazývá paradigma webové stránky. RIA „rozbíjí“ toto paradigma; server musí nyní obsluhovat asynchronní požadavky, aby podporoval interaktivnější prostředí. Pro získání informací o množství času stráveného prací RIA by měly být vyvinuty nové standardní technologie. Při absenci takových technologií (standardních nástrojů) musí vývojáři RIA do svých aplikací přidat nástroje pro měření dat nezbytné pro SLM;
• asynchronie ztěžuje identifikaci problémů s výkonem . Paradoxně opatření přijatá ke zlepšení doby odezvy aplikace ztěžují stanovení doby odezvy, měření doby a správu aplikace. Některá RIA běží ve webovém prohlížeči poté, co prohlížeč stáhne jedinou webovou stránku, přičemž k asynchronnímu stažení požadovaných dat používá „klientský stroj“; prohlížeč již neposílá žádné požadavky HTTP GET . Klientská strana RIA může být naprogramována tak, aby neustále stahovala nová data (obsah) a aktualizovala obsah obrazovky, nebo (v aplikacích využívajících přístup Comet ) může serverová strana RIA neustále odesílat nová data (obsah) na stranu klienta. prostřednictvím vždy otevřeného připojení. V tomto případě již koncept „načítání stránky“ neplatí. To vše přináší určité potíže při měření času a rozdělení doby odezvy aplikace, což jsou základní požadavky pro identifikaci problémů s výkonem a SLM. Nástroje navržené k měření doby provozuschopnosti tradičních webových aplikací v závislosti na specifikách a sadě aplikačních nástrojů mohou zvážit každou webovou stránku vyžádanou přes HTTP, jednotlivě nebo jako sadu nesouvisejících indikátorů. Žádný z těchto přístupů však neukazuje, co se skutečně děje na aplikační úrovni;
• „Klientský engine“ ztěžuje měření doby odezvy aplikace . U tradičních webových aplikací může být software pro měření času umístěn na klientském počítači a na stroji v blízkosti serveru může monitorovat tok síťového provozu na vrstvách TCP a HTTP . Protože TCP a HTTP jsou synchronizované a předvídatelné protokoly, může sniffer číst data z paketů TCP a HTTP, interpretovat načtená data a odvodit časy odezvy pomocí sledování zpráv HTTP a času potvrzení paketů TCP na nízké úrovni. Použití snifferu k měření časování aplikací využívajících architekturu RIA je obtížné, protože uživatelský engine rozděluje interakci mezi klientem a serverem do dvou samostatných smyček, které fungují asynchronně – smyčky popředí (user-engine) a back-end ( motor-server) smyčka. Oba tyto cykly jsou důležité, protože jejich společný vztah určuje chování aplikace. Tento poměr ale závisí pouze na architektuře samotné aplikace, kterou ve většině případů nelze předpovědět měřicími nástroji, zejména prvním (sniffer), který dokáže pozorovat pouze jeden ze dvou cyklů. Nejúplnější měření času RIA lze proto získat pouze pomocí nástrojů, které jsou v obou cyklech na straně klienta i pozorovatele.

Viz také

• Rich media
• WAI-ARIA

Poznámky

1. ↑ Larry Seltzer. Bohaté internetové aplikace jsou pro útočníky atraktivní // PCWeek, 09/15/2010.
2. ↑ Powers S., Powers S. Přidání Ajaxu. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
3. ↑ Rich Internet Application Market Share (downlink) . Získáno 9. prosince 2010. Archivováno z originálu dne 6. října 2011. (neurčitý) 

Literatura

• Konstantin Kovalev. RIA znamená svobodu // World of PC. - 2008. - č. 3. - S. 62-65. — ISSN 0235-3520