Gazdag internetes alkalmazás

A gazdag internetes (webes) alkalmazás [1] [2] ( rich  internet application , RIA ) a felhasználó által az interneten keresztül letöltött webes alkalmazás , amely a hagyományos asztali alkalmazások funkcióit hivatott ellátni, és a felhasználó eszközén fut ( nem a szerveren).

A RIA megvalósításához használt technológiák:

• HTML5 jelölőnyelv és JavaScript programozási nyelv ;
• (Google) Natív kliens ;
• Adobe Flash ;
• ( Oracle ) JavaFX ;
• Microsoft Silverlight .

Főbb jellemzői:

• A RIA két részből áll: kliensből és szerverből;
• a RIA szerver rész a szerveren fut, képes tárolni az alkalmazás működéséhez szükséges információkat, és kezelni tudja a RIA kliens részről érkező kéréseket;
• a RIA kliens rész a felhasználó számítógépén fut, megrajzolja a felhasználói felületet , végrehajtja a felhasználói kéréseket, és szükség esetén kéréseket tud küldeni a RIA szerver résznek;
• A RIA kliens része egy " sandbox "-nak ( angolul  sandbox ) nevezett biztonságos környezetben fut , és nem igényel további szoftverek telepítését .

A [3] szerint 2012 júliusában a RIA-k létrehozásához használt legnépszerűbb platformok az Adobe Flash , a JavaFX és a Microsoft Silverlight voltak .

Történelem

A "RIA" kifejezést először a Macromedia említette egy 2002. márciusi fehér könyvében. A RIA ötlete néhány évvel korábban létezett a következő nevekkel:

• " Remote Scripting " ( Microsoft ; 1998 körül );
• "X Internet" (Forrester Research; 2000. október);
• "Gazdag (webes) kliens";
• gazdag webes alkalmazás.

A hagyományos webes alkalmazások így működnek.

1. A kliens kérést küld a szervernek, és várja a választ.
2. A szerver kérést kap a klienstől, generál és választ küld a kliensnek.
3. Az ügyfél megkapja és megjeleníti a választ.

Ezek a műveletek folyamatosan ismétlődnek (ciklus). Egy ilyen architektúrában a kliens csak információk megjelenítésével foglalkozik (statikus tartalom, például HTML ), és minden adatfeldolgozási feladatot átad a szervernek. Ennek az architektúrának a fő hátránya, hogy minden munkát a szerver végzi. Növelheti az alkalmazás sebességét, ha a munka egy részét áthelyezik az ügyfélre.

A RIA architektúrában a munka egy részét vagy egészét az ügyfél is elvégezheti.

Az internetes hálózati szabványok fokozatos fejlődése a RIA bevezetésének lehetőségéhez vezetett. Nehéz azonban egyértelmű határvonalat húzni aközött, hogy mely technológiák tartalmazzák a RIA-t, és melyek nem. De minden RIA-nak van egy funkciója: az úgynevezett „kliensmotor” betöltődik a felhasználó eszközére, mielőtt a RIA elindulna; a jövőben az alkalmazás során újratölthető a motor.

A "kliensmotor" olyan funkciókat valósít meg, amelyek nem állnak rendelkezésre a hagyományos webes alkalmazások számára, betölthetők egy webböngésző (HTML, JavaScript) vagy egy webböngésző -bővítmény (add-on) kontextusában (Adobe Flash , JavaFX, Microsoft Silverlight, natív kliens). Az "kliensmotor" általában felelős a felhasználói felület (UI) rendereléséért (rajzolásáért) (például egy RIA felhasználói felület megvalósítása egyszerűbb és gyorsabb lehet, mint egy hagyományos webalkalmazás esetében), valamint a szerverrel való interakcióért (pl. a RIA kliens oldala szinkron módon (a hagyományos webes alkalmazásokhoz hasonlóan) vagy aszinkron módon küldhet kéréseket a RIA háttérrendszernek . A "kliens motor" képességeit korlátozhatják a felhasználó eszközének és operációs rendszerének képességei .

Előnyök

A webes alkalmazások előnyei:

• webes alkalmazás nem igényel telepítést (a felhasználók szükség szerint letöltik az alkalmazást a szerverről; ez biztosítja az alkalmazás automatikus terjesztését);
• a webalkalmazás automatikusan frissül (az alkalmazás legújabb verziója a szerveren található);
• a webalkalmazás bármely internetkapcsolattal rendelkező eszközön és bármilyen operációs rendszer alatt futhat (az operációs rendszer változatossága nem okoz problémát az összes operációs rendszer egyetlen API -jának köszönhetően );
• webes alkalmazás futtatásakor a felhasználó eszköze kevésbé érzékeny a vírusfertőzésre, mint futtatható binárisok futtatásakor (a webalkalmazás egy homokozóban fut).

A RIA előnyei a hagyományos webalkalmazásokhoz képest, az „ügyfélmotor” képességeinek felhasználásával:

• az operációs rendszer szabványos vezérlőinek használatának képessége a felhasználói felületen (például csúszkával az adatok módosításához);
• normál műveletek használatának képessége más programokkal való interakcióhoz (például fogd és vidd , adatok másolása a vágólapra );
• számítások elvégzésének képessége a felhasználó eszközén (anélkül, hogy a felhasználó személyes adatait elküldené a szervernek (például jelzálog- kalkulátor ));
• rugalmas lehetőségek a felhasználói felület felépítéséhez (például a felhasználó által a beviteli folyamat során bevitt adatok érvényesítése anélkül, hogy kéréseket küldene a szervernek ( interaktivitás ));
• az alkalmazás folytatásának lehetősége a szervernek küldött kérés után (aszinkron);
• az adatok letöltésének lehetősége a szerverről, mielőtt a felhasználó adatokat kérne (például a Google Mapsben a felhasználó által megtekintett töredék mellett található térképrészletek előre betöltődnek);
• a szerver terhelés csökkentésének lehetősége (a kliensen történő számítások elvégzése esetén), és ebből következően a szerver által feldolgozott munkamenetek számának egyidejű növelésének lehetősége (hardvercsere nélkül).

Hátrányok

A RIA hátrányai:

• az operációs rendszer erőforrásaihoz való hozzáférés hiánya (mivel a webalkalmazás " sandbox "-ban fut). Ha az erőforrás-engedélyek helytelenek, előfordulhat, hogy a RIA-k nem működnek megfelelően;
• webalkalmazás futtatásához szükség lehet egy szkriptnyelven (például JavaScriptben) írt kód végrehajtására; ha a felhasználó letiltja a kód végrehajtásának lehetőségét, előfordulhat, hogy a RIA nem működik megfelelően, vagy egyáltalán nem működik;
• többplatformos webes alkalmazások alacsony sebessége. A RIA platform függetlenségének biztosítása érdekében a RIA kliensoldal használhat szkriptnyelven (például JavaScript) írt kódot; az ilyen kód végrehajtásakor teljesítménycsökkenés tapasztalható - ez komoly probléma a mobileszközök számára. Ez a probléma nem fordul elő, ha olyan beágyazott nyelvet használunk, amely az ügyféloldalon van lefordítva (például Java), ahol a teljesítmény összehasonlítható a hagyományos beágyazott nyelvek (az Adobe Flash vagy a Microsoft Silverlight ) használatával, amelyekben a programkód közvetlenül a Flash Playerben fut. vagy Silverlight bővítmény. ;
• az „ügyfélmotor” telepítésének szükségessége;
• hosszú webalkalmazás betöltési idő. A kliens minden alkalommal letölti a RIA kliens oldalát a szerverről . Mivel a legtöbb betöltött adat gyorsítótárban van, a RIA-ügyfelet legalább egyszer be kell tölteni az indítás felgyorsítása érdekében. A letöltési idő a letöltött adatok méretétől függ; a RIA kliens részének méretének csökkentése érdekében a fejlesztők tömöríthetik vagy részekre oszthatják, amelyeket szükség szerint betöltenek;
• az integritás elvesztése. Ha egy alkalmazás X/HTML alapú, akkor ütközések adódhatnak az alkalmazás céljai (amely természetesen irányítani akarja a megjelenítését és a műveleteit) és az X/HTML céljai között (amely fel akar adni az irányítást). Az X/HTML DOM interfésze lehetővé teszi RIA létrehozását, de nincs garancia arra, hogy megfelelően fog működni. Mivel a RIA-ügyfél megváltoztathatja az alkalmazás alapvető szerkezetét, és felülírhatja annak műveleteit és megjelenítését, ez az alkalmazás kliensoldali meghibásodását okozhatja. Végül ez a probléma megoldható egy új kliens-szerver mechanizmussal , amely korlátozott hozzáférést biztosít a RIA kliens számára azon erőforrások módosításához, amelyek nem tartoznak a hatáskörébe. A natív szabványos szoftverek munkája nem okoz ilyen problémákat, mivel definíció szerint automatikusan rendelkeznek minden szükséges joggal a helyi erőforrásokhoz;
• egy webalkalmazás keresőmotorok általi indexelésének lehetetlensége . Előfordulhat, hogy a keresőmotorok nem tudják indexelni a RIA tartalmat. Azonban gyakran nincs szükség indexelésre;
• internetkapcsolat-függőség. Az asztali alkalmazások helyettesítésére tervezett RIA-knak lehetővé kell tenniük a felhasználók számára, hogy szükség szerint csatlakozzanak a hálózathoz, például nem válhatnak működésképtelenné, amikor a felhasználó vezeték nélküli lefedettségi területek között mozog . 2007-re a tipikus RIA-alkalmazások állandó hálózati csatlakozást igényeltek. A HTML5 megjelenésével ez a probléma kevésbé aktuális; A HTML5 helyi tárolási API lehetővé teszi az adatok kliensoldali tárolását; A HTML5 File API hozzáférést tesz lehetővé a felhasználó eszközének fájlrendszeréhez .

Alkalmazásfejlesztési kihívások

A RIA technológia megjelenése jelentős nehézségekkel járt a webes alkalmazások fejlesztésében . A hagyományos, szabványos HTML-re épülő, viszonylag egyszerű architektúrájú és meglehetősen korlátozott szolgáltatáskészletű webalkalmazásokat viszonylag könnyű volt fejleszteni és kezelni. A RIA technológián alapuló webalkalmazásokat megvalósító egyének és szervezetek gyakran további fejlesztési, tesztelési, mérési és támogatási kihívásokkal néznek szembe.

A RIA technológia használata új kihívások elé állítja az SLM-szolgáltatásmenedzsmentet ( szolgáltatásszint-menedzsment ), amelyek közül a mai napig nem sikerült mindegyiket megoldani .  Az SLM-mel kapcsolatos kérdéseket az alkalmazásfejlesztők nem mindig veszik figyelembe, és a felhasználók szinte észre sem veszik őket. Ezek azonban létfontosságúak egy internetes alkalmazás sikeres megvalósításához. A RIA fejlesztési folyamatot bonyolító főbb szempontok a következők:

• technológiai összetettség . Az alkalmazáskód ügyfelekkel való közvetlen megosztása nagyobb kreatív szabadságot biztosít a fejlesztőknek és a tervezőknek. Ez viszont megnehezíti az alkalmazás fejlesztését, növeli a hibák valószínűségét a megvalósítás során , és megnehezíti a szoftver tesztelését . Ezek a komplikációk meghosszabbítják a fejlesztési folyamatot, függetlenül a módszertan és a fejlesztési folyamat sajátosságaitól. E problémák egy része csökkenthető webalkalmazás-keretrendszer használatával a RIA fejlesztés szabványosítására .  A szoftvermegoldások egyre bonyolultabbá válása azonban bonyolíthatja és meghosszabbíthatja a tesztelési folyamatot, ahogy a tesztelt használati esetek száma növekszik. A hiányos tesztelés csökkenti az alkalmazás minőségét és megbízhatóságát a használata során. Lehet vitatkozni azon, hogy ez csak a RIA technológiára vonatkozik-e, vagy általában a fejlesztés összetettségére. Például pontosan ugyanez az érv hangzott el, amikor az Apple és a Microsoft egymástól függetlenül bejelentette a grafikus felhasználói felületet az 1980-as években, és talán még akkor is, amikor a Ford bemutatta T-modelljét. Mindazonáltal az emberiség figyelemre méltó képességet mutatott az összes technológiai újítás befogadására évtizedek, ha nem évszázadok során;
• A RIA architektúra megtöri a weboldal paradigmáját . A hagyományos webes alkalmazások weboldalak gyűjteményét jelentik ; az egyes weboldalak letöltéséhez az ügyfél HTTP GET kérést küld ; egy ilyen modellt weboldal paradigmának neveznek. A RIA „megtöri” ezt a paradigmát; a szervernek most már aszinkron kéréseket kell kiszolgálnia az interaktívabb élmény támogatása érdekében. A RIA munkájában eltöltött időről való információszerzés érdekében új szabványos technológiákat kell kidolgozni. Ilyen technológiák (standard eszközök) hiányában a RIA fejlesztőinek az SLM-hez szükséges adatmérő eszközöket kell hozzáadniuk alkalmazásaikhoz;
• Az aszinkronitás megnehezíti a teljesítményproblémák azonosítását . Paradox módon az alkalmazás válaszidejének javítására hozott intézkedések megnehezítik a válaszidő meghatározását, az idő mérését és az alkalmazás kezelését. Egyes RIA-k webböngészőben futnak, miután a böngésző letöltött egyetlen weboldalt, és egy „kliensmotor” segítségével aszinkron módon tölti le a szükséges adatokat; a böngésző többé nem küld HTTP GET kéréseket . A RIA kliens oldala programozható úgy, hogy folyamatosan töltsön le új adatokat (tartalmakat) és frissítse a képernyő tartalmát, vagy ( Comet megközelítést alkalmazó alkalmazásokban ) a RIA szerver oldala folyamatosan küldjön új adatokat (tartalmakat) a kliens oldalra. mindig nyitott kapcsolaton keresztül. Ebben az esetben az „oldal betöltése” fogalma már nem alkalmazható. Mindez bizonyos nehézségeket okoz az alkalmazás válaszidejének időmérésében és felosztásában, amelyek alapvető követelményei a teljesítményproblémák és az SLM azonosításának. A hagyományos webalkalmazások üzemidejének mérésére tervezett eszközök a sajátosságoktól és az alkalmazás eszközkészletétől függően minden egyes HTTP-n keresztül kért weboldalt külön-külön vagy független mutatók halmazaként is figyelembe vehetnek. Azonban e megközelítések egyike sem mutatja meg, mi is történik valójában az alkalmazás szintjén;
• Az "ügyfélmotor" megnehezíti az alkalmazás válaszidejének mérését . Hagyományos webes alkalmazások esetén az időmérő szoftver a kliens gépen, a szerverhez közeli gépen pedig a TCP és HTTP rétegen a hálózati forgalom áramlását figyelheti. Mivel a TCP és a HTTP szinkronizált és megjósolható protokollok, a szippantó képes kiolvasni a TCP- és HTTP-csomagokból származó adatokat, értelmezni az olvasott adatokat, és a HTTP-üzenetkövetés és az alacsony szintű TCP-csomagok nyugtázási idejének segítségével kikövetkeztetheti a válaszidőket. A sniffer használata a RIA architektúrát használó alkalmazások időzítésének mérésére nehézkes, mivel a felhasználói motor az ügyfél és a szerver közötti interakciót két különálló, aszinkron módon működő hurokra bontja – az előtér (felhasználói motor) hurokra és a háttérre ( motor-szerver) hurok. Mindkét ciklus fontos, mert közös kapcsolatuk határozza meg az alkalmazás viselkedését. De ez az arány csak magának az alkalmazásnak az architektúrájától függ, ami a legtöbb esetben nem jelezhető előre mérőeszközökkel, különösen az első (sniffer), amely a két ciklus közül csak az egyiket képes megfigyelni. Ezért a RIA idő legteljesebb mérése csak olyan eszközökkel érhető el, amelyek mindkét ciklusban a kliens és a megfigyelő oldalon vannak.

Lásd még

• Rich media
• WAI-ARIA

Jegyzetek

1. ↑ Larry Seltzer. A gazdag internetes alkalmazások vonzóak a támadók számára // PCWeek, 2010.09.15.
2. ↑ Powers S., Powers S. Ajax hozzáadása. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
3. ↑ Gazdag internetes alkalmazások piaci részesedése (downlink) . Letöltve: 2010. december 9. Az eredetiből archiválva : 2011. október 6.. (határozatlan) 

Irodalom

• Konsztantyin Kovaljov. A RIA szabadságot jelent // World of PC. - 2008. - 3. sz. - S. 62-65. — ISSN 0235-3520