Rikas Internet-sovellus
Kokeneet kirjoittajat eivät ole vielä tarkistaneet sivun nykyistä versiota, ja se voi poiketa merkittävästi 19. heinäkuuta 2021 tarkistetusta
versiosta . tarkastukset vaativat
4 muokkausta .
Rikas internet (web) -sovellus [1] [2] ( eng. rich internet application , RIA ) on käyttäjän Internetin kautta lataama verkkosovellus , joka on suunniteltu suorittamaan perinteisten työpöytäsovellusten toimintoja ja joka toimii käyttäjän laitteessa ( ei palvelimella).
RIA:n toteuttamiseen käytetyt tekniikat:
Pääpiirteet:
- RIA koostuu kahdesta osasta: asiakas ja palvelin;
- RIA-palvelinosa toimii palvelimella, pystyy tallentamaan sovelluksen toimintaan tarvittavat tiedot ja käsittelemään RIA-asiakasosasta tulevia pyyntöjä;
- RIA-asiakasosa toimii käyttäjän tietokoneella, piirtää käyttöliittymän , suorittaa käyttäjäpyyntöjä ja voi tarvittaessa lähettää pyyntöjä RIA-palvelinosalle;
- RIA:n asiakasosa toimii suojatussa ympäristössä, jota kutsutaan " hiekkalaatikoksi " ( englanniksi hiekkalaatikko ), eikä se vaadi lisäohjelmistojen asentamista .
[3] mukaan heinäkuussa 2012 RIA:iden luomiseen käytetyt suosituimmat alustat olivat Adobe Flash , JavaFX ja Microsoft Silverlight .
Historia
Macromedia mainitsi ensimmäisen kerran termin "RIA" maaliskuussa 2002 julkaistussa valkoisessa kirjassa. RIA-idea oli olemassa muutama vuosi aiemmin seuraavilla nimillä:
- " Remote Scripting " ( Microsoft ; noin 1998 ) ;
- "X Internet" (Forrester Research; lokakuu 2000);
- "Rikas (verkko)asiakas";
- rikas verkkosovellus.
Perinteiset verkkosovellukset toimivat näin.
- Asiakas lähettää pyynnön palvelimelle ja odottaa vastausta.
- Palvelin vastaanottaa pyynnön asiakkaalta, luo ja lähettää vastauksen asiakkaalle.
- Asiakas vastaanottaa ja näyttää vastauksen.
Nämä toimet toistuvat jatkuvasti (sykli). Tällaisessa arkkitehtuurissa asiakas vain näyttää tietoja (staattinen sisältö, esimerkiksi HTML ) ja siirtää kaikki tietojenkäsittelytehtävät palvelimelle. Tämän arkkitehtuurin suurin haitta on, että palvelin tekee kaiken työn. Voit lisätä sovelluksen nopeutta, jos osa työstä siirtyy asiakkaalle.
RIA-arkkitehtuurissa osan tai koko työstä voi tehdä asiakas.
Internet-verkkostandardien asteittainen kehittäminen on johtanut mahdollisuuteen ottaa käyttöön RIA. On kuitenkin vaikea vetää selkeää rajaa siihen, mitkä tekniikat sisältävät RIA:n ja mitkä eivät. Mutta kaikilla RIA:illa on yksi ominaisuus: niin kutsuttu "asiakasmoottori" ladataan käyttäjän laitteelle ennen RIA:n käynnistymistä; tulevaisuudessa moottori voidaan ladata uudelleen sovelluksen aikana.
"Client engine" toteuttaa ominaisuuksia, jotka eivät ole perinteisten verkkosovellusten saatavilla, voidaan ladata verkkoselaimen (HTML, JavaScript) tai verkkoselaimen laajennuksen (lisäosa) (Adobe Flash ) yhteydessä. , JavaFX, Microsoft Silverlight, Native Client). "Asiakasmoottori" on yleensä vastuussa käyttöliittymän (UI) renderöimisestä (piirtämisestä) (esimerkiksi käyttöliittymän toteuttaminen RIA:lle voi olla yksinkertaisempaa ja nopeampaa kuin perinteisessä verkkosovelluksessa) ja vuorovaikutuksessa palvelimen kanssa (esim. RIA:n asiakaspuoli voi lähettää pyyntöjä RIA-taustajärjestelmään joko synkronisesti (kuten perinteiset verkkosovellukset) tai asynkronisesti ). "Asiakaskoneen" ominaisuuksia voivat rajoittaa käyttäjän laitteen ja käyttöjärjestelmän ominaisuudet .
Edut
Verkkosovellusten edut:
- verkkosovellus ei vaadi asennusta (käyttäjät lataavat sovelluksen palvelimelta tarpeen mukaan; tämä varmistaa sovelluksen automaattisen jakelun);
- verkkosovellus päivitetään automaattisesti (sovelluksen uusin versio on palvelimella);
- verkkosovellus voi toimia missä tahansa laitteessa, jossa on Internet-yhteys, ja missä tahansa käyttöjärjestelmässä (käyttöjärjestelmän moninaisuus ei aiheuta ongelmia yhden APIn ansiosta kaikille käyttöjärjestelmille );
- Web-sovellusta suoritettaessa käyttäjän laite on vähemmän altis virustartunnalle kuin suoritettavia binaaritiedostoja suoritettaessa (verkkosovellus suoritetaan hiekkalaatikossa).
RIA:n edut verrattuna perinteisiin verkkosovelluksiin, jotka saavutetaan käyttämällä "asiakasmoottorin" ominaisuuksia:
- mahdollisuus käyttää tavallisia käyttöjärjestelmän säätimiä käyttöliittymässä (esimerkiksi liukusäätimen avulla tietojen muuttamiseen);
- kyky käyttää vakiotoimintoja vuorovaikutuksessa muiden ohjelmien kanssa (esimerkiksi vetämällä ja pudottamalla , kopioimalla tietoja leikepöydälle );
- kyky suorittaa laskelmia käyttäjän laitteella (lähettämättä käyttäjän henkilökohtaisia tietoja palvelimelle (esimerkiksi asuntolainalaskin ));
- joustavat vaihtoehdot käyttöliittymän rakentamiseen (esimerkiksi käyttäjän syöttöprosessin aikana syöttämien tietojen validointi lähettämättä pyyntöjä palvelimelle ( interaktiivisuus ));
- kyky jatkaa sovellusta sen jälkeen, kun pyyntö on lähetetty palvelimelle (asynkroninen);
- mahdollisuus ladata tietoja palvelimelta ennen kuin käyttäjä pyytää tietoja (esimerkiksi Google Mapsissa käyttäjän tarkasteleman fragmentin vieressä olevat karttapalat ladataan etukäteen);
- mahdollisuus vähentää palvelimen kuormitusta (jos laskutoimituksia suoritetaan asiakkaalle) ja näin ollen mahdollisuus lisätä palvelimen käsittelemien istuntojen määrää samanaikaisesti (laitteiston vaihtamatta).
Haitat
RIA:n haitat:
- käyttöjärjestelmän resurssien puute (koska verkkosovellus toimii " hiekkalaatikossa "). Jos resurssien käyttöoikeudet ovat virheellisiä, RIA:t eivät välttämättä toimi kunnolla.
- web-sovelluksen käyttäminen saattaa edellyttää komentosarjakielellä kirjoitetun koodin suorittamista (esimerkiksi JavaScriptillä); jos käyttäjä poistaa koodin suorituskyvyn käytöstä, RIA ei välttämättä toimi kunnolla tai ei toimi ollenkaan;
- monialustaisten verkkosovellusten alhainen nopeus. RIA-alustan riippumattomuuden varmistamiseksi RIA-asiakaspuoli voi käyttää komentosarjakielellä (kuten JavaScriptillä) kirjoitettua koodia. kun tällaista koodia suoritetaan, suorituskyky heikkenee - vakava ongelma mobiililaitteille. Tätä ongelmaa ei esiinny käytettäessä asiakaspuolella käännettyä sulautettua kieltä (esimerkiksi Javaa), jonka suorituskyky on verrattavissa perinteisiin sulautettuihin kieliin, joko Adobe Flashiin tai Microsoft Silverlightiin , joissa ohjelmakoodi suoritetaan suoraan Flash Playerissa. tai Silverlight-laajennus, vastaavasti.
- tarve asentaa "asiakasmoottori";
- pitkä verkkosovellusten latausaika. Asiakas lataa RIA - asiakaspuolen palvelimelta joka kerta . Koska suurin osa ladatusta tiedosta on välimuistissa, RIA-asiakas on ladattava vähintään kerran käynnistyksen nopeuttamiseksi. Latausaika riippuu ladattujen tietojen koosta; RIA:n asiakasosan koon pienentämiseksi kehittäjät voivat pakata sen tai jakaa sen osiin, jotka ladataan tarpeen mukaan;
- eheyden menetys. Jos sovellus perustuu X/HTML:ään, sovelluksen tavoitteiden (joka luonnollisesti haluaa hallita esitystä ja toimintoja) ja X/HTML:n tavoitteiden (joka haluaa luopua hallinnasta) välillä voi olla ristiriitoja. X/HTML:n DOM-käyttöliittymä mahdollistaa RIA:n luomisen, mutta sen toimivuudesta ei ole takeita. Koska RIA-asiakasohjelma voi muuttaa sovelluksen perusrakennetta ja ohittaa sen toiminnot ja esityksen, tämä voi aiheuttaa sovelluksen epäonnistumisen asiakaspuolella. Loppujen lopuksi tämä ongelma voidaan ratkaista uudella asiakas-palvelin- mekanismilla , joka antaa RIA-asiakkaalle rajoitetun pääsyn muokata niitä resursseja, jotka eivät kuulu sen piiriin. Alkuperäisten standardiohjelmistojen työ ei aiheuta tällaisia ongelmia, koska niillä on automaattisesti kaikki tarvittavat oikeudet paikallisiin resursseihin;
- hakukoneiden mahdottomuus indeksoida verkkosovellusta . Hakukoneet eivät ehkä pysty indeksoimaan RIA-sisältöä. Usein indeksointia ei kuitenkaan vaadita;
- Internet-yhteyden riippuvuus. Työpöytäsovellusten korvaamiseen suunniteltujen RIA:iden tulisi antaa käyttäjille mahdollisuus muodostaa yhteys verkkoon tarpeen mukaan, esimerkiksi se ei saisi muuttua käyttökelvottomaksi, kun käyttäjä liikkuu langattomien peittoalueiden välillä . Vuoteen 2007 mennessä tyypilliset RIA-sovellukset vaativat kiinteän yhteyden verkkoon. HTML5:n myötä tästä ongelmasta tulee vähemmän tärkeä. HTML5-paikallinen tallennussovellusliittymä mahdollistaa tietojen tallentamisen asiakaspuolelle; HTML5 File API mahdollistaa pääsyn käyttäjän laitteen tiedostojärjestelmään .
Sovelluskehityksen haasteita
RIA - teknologian tuloon liittyi huomattavia vaikeuksia web - sovellusten kehittämisessä . Perinteiset web-sovellukset, jotka perustuvat tavalliseen HTML:ään, suhteellisen yksinkertaisella arkkitehtuurilla ja melko rajallisilla ominaisuuksilla, olivat suhteellisen helppoja kehittää ja hallita. RIA-teknologiaan perustuvia web-sovelluksia toteuttavat yksilöt ja organisaatiot kohtaavat usein ylimääräisiä kehitys-, testaus-, mittaus- ja tukihaasteita.
RIA-teknologian käyttö asettaa uusia haasteita SLM-palvelunhallinnalle ( palvelutason hallinta ), joista kaikkia ei ole toistaiseksi ratkaistu . Sovelluskehittäjät eivät aina ota huomioon SLM:ää koskevia kysymyksiä, eivätkä käyttäjät juuri huomaa niitä. Ne ovat kuitenkin elintärkeitä Internet-sovelluksen onnistuneelle toteuttamiselle. Tärkeimmät näkökohdat, jotka vaikeuttavat RIA-kehitysprosessia, ovat seuraavat:
- teknologinen monimutkaisuus . Mahdollisuus jakaa sovelluskoodia suoraan asiakkaiden kanssa antaa kehittäjille ja suunnittelijoille enemmän luovaa vapautta. Mutta tämä puolestaan vaikeuttaa sovelluksen kehitystä, lisää virheiden todennäköisyyttä toteutuksen aikana ja vaikeuttaa ohjelmiston testaamista . Nämä komplikaatiot pidentävät kehitysprosessia metodologian ja kehitysprosessin erityispiirteistä riippumatta. Joitakin näistä ongelmista voidaan vähentää käyttämällä verkkosovelluskehystä RIA -kehityksen standardointiin . Ohjelmistoratkaisujen monimutkaistuminen voi kuitenkin monimutkaistaa ja pidentää testausprosessia testattavien käyttötapausten määrän kasvaessa. Epätäydellinen testaus heikentää sovelluksen laatua ja luotettavuutta sen käytön aikana. Voidaan kiistellä siitä, koskeeko tämä vain RIA-teknologiaa vai kehityksen monimutkaisuutta yleensä. Esimerkiksi täsmälleen sama väite esitettiin, kun Apple ja Microsoft ilmoittivat itsenäisesti graafisesta käyttöliittymästä 1980-luvulla, ja ehkä jopa silloin, kun Ford esitteli Model T : n . Siitä huolimatta ihmiskunta on osoittanut huomattavaa kykyä ottaa vastaan kaikki teknologiset innovaatiot vuosikymmenten, ellei vuosisatojen ajan;
- RIA-arkkitehtuuri rikkoo verkkosivujen paradigman . Perinteiset verkkosovellukset ovat kokoelma web-sivuja ; ladatakseen jokaisen verkkosivun asiakas lähettää HTTP GET -pyynnön ; tällaista mallia kutsutaan web-sivuparadigmaksi. RIA "rikkoo" tämän paradigman; palvelimen on nyt palveltava asynkronisia pyyntöjä vuorovaikutteisemman käyttöliittymän tukemiseksi. Jotta saadaan tietoa RIA:n työhön käytetystä ajasta, tulisi kehittää uusia standarditekniikoita. Tällaisten teknologioiden (vakiotyökalujen) puuttuessa RIA-kehittäjien on lisättävä sovelluksiinsa SLM:lle tarvittavat mittaustyökalut;
- asynkronisuus vaikeuttaa suorituskykyongelmien tunnistamista . Paradoksaalista kyllä, sovelluksen vasteajan parantamiseksi tehdyt toimenpiteet vaikeuttavat vasteajan määrittämistä, ajan mittaamista ja sovelluksen hallintaa. Jotkut RIA:t suoritetaan verkkoselaimessa sen jälkeen, kun selain on ladannut yhden Web-sivun käyttämällä "asiakaskonetta" vaadittujen tietojen asynkroniseen lataamiseen. selain ei enää lähetä HTTP GET - pyyntöjä . RIA:n asiakaspuoli voidaan ohjelmoida lataamaan jatkuvasti uutta dataa (sisältöä) ja päivittämään näytön sisältöä, tai ( Comet -lähestymistapaa käyttävissä sovelluksissa ) RIA:n palvelinpuoli voi jatkuvasti lähettää uutta dataa (sisältöä) asiakaspuolelle. aina avoimen yhteyden kautta. Tässä tapauksessa "sivun lataamisen" käsite ei ole enää käyttökelpoinen. Kaikki tämä aiheuttaa tiettyjä vaikeuksia mitata aikaa ja sovelluksen vasteajan jakoa, jotka ovat perusvaatimuksia suorituskykyongelmien ja SLM:n tunnistamisessa. Perinteisten verkkosovellusten käytettävyyden mittaamiseen suunnitellut työkalut voivat ottaa huomioon jokaisen HTTP:n kautta pyydetyn verkkosivun erikseen tai toisiinsa liittymättömien indikaattoreiden joukkona. Mikään näistä lähestymistavoista ei kuitenkaan näytä, mitä sovellustasolla todella tapahtuu;
- "Asiakasmoottori" tekee sovelluksen vasteajan mittaamisen vaikeaksi . Perinteisissä web-sovelluksissa ajanmittausohjelmisto voi sijaita asiakaskoneella ja palvelimen lähellä olevassa koneessa se voi seurata verkkoliikenteen sujuvuutta TCP- ja HTTP - tasoilla . Koska TCP ja HTTP ovat synkronoituja ja ennustettavia protokollia, haistaja voi lukea tietoja TCP- ja HTTP-paketteista, tulkita luettua dataa ja päätellä vasteaikoja HTTP-sanomien seurannan ja matalan tason TCP-pakettien kuittausajan avulla. Snifferin käyttäminen RIA-arkkitehtuuria käyttävien sovellusten ajoituksen mittaamiseen on vaikeaa, koska käyttäjämoottori katkaisee asiakkaan ja palvelimen välisen vuorovaikutuksen kahdeksi erilliseksi silmukaksi, jotka toimivat asynkronisesti - etualan (käyttäjämoottorin) silmukaksi ja taustapäähän ( moottori-palvelin) silmukka. Molemmat syklit ovat tärkeitä, koska niiden yhteinen suhde määrää sovelluksen toiminnan. Mutta tämä suhde riippuu vain itse sovelluksen arkkitehtuurista, jota useimmissa tapauksissa ei voida ennustaa mittaustyökaluilla, etenkään ensimmäisellä (sniffer), joka voi tarkkailla vain toista kahdesta syklistä. Siksi RIA-ajan täydellisin mittaus voidaan saada vain käyttämällä työkaluja, jotka ovat asiakkaan ja tarkkailijan puolella molemmissa sykleissä.
Katso myös
Muistiinpanot
- ↑ Larry Seltzer. Rikkaat Internet-sovellukset houkuttelevat hyökkääjiä // PCWeek, 15.9.2010.
- ↑ Powers S., Powers S. Ajaxin lisääminen. - BHV-Petersburg, 2009. - S. 3–4. - ISBN 978-5-9775-0226-9 .
- ↑ Rikas Internet-sovellusten markkinaosuus (downlink) . Haettu 9. joulukuuta 2010. Arkistoitu alkuperäisestä 6. lokakuuta 2011. (määrätön)
Kirjallisuus
- Konstantin Kovalev. RIA tarkoittaa vapautta // PC:n maailma. - 2008. - Nro 3. - S. 62-65. — ISSN 0235-3520