Helsingin yliopisto TietojenkŠsittelytieteen laitos Ubicomp Ð tulevaisuudenkuvako? -seminaari Ohjaaja FT Lea Kutvonen ADAPTIIVISET SOVELLUKSET Laatinut: Gitta Lehto Tallennettu: 6.11.2000
Helsingin yliopisto 06.11.00 i TietojenkŠsittelytieteen laitos Adaptiiviset sovellukset UBICOMB Ð tulevaisuudenkuvako? -seminaari Gitta Lehto TIIVISTELM Nykyajan tietojšrjestelmšt sisšltšvšt kannettavia tietokoneita, jotka voivat olla joko tšysin ilman verkkoyhteyttš tai vaihtoehtoisesti olla yhteydessš hitaaseen langattomaan (GSM) tai nopeaan kiinteššn verkkoon (ethernet). Suuret suorituskyvyn vaihtelut verkkoyhteyden palvelun laadussa (QoS, Quality of Service) aiheuttavat erityisiš vaatimuksia yhteyttš kšyttšville jšrjestelmille. Vaihto suorituskyvyltššn erilaisten verkkojen všlillš vaatii jšrjestelmiltš sopeutumista vaihtelevaan yhteyden laatuun. Toisaalta verkkoyhteyttš kšyttšvšllš jšrjestelmšllš voi olla omia vaatimuksia, esimerkiksi suorituskyky- tai kustannusvaatimuksia, verkkopalvelun tason suhteen, jolloin jšrjestelmšllš pitšisi olla mahdollisuus valita palvelun taso mahdollisimman hyvin tarpeitansa vastaavaksi. Joustavuus verkkopalvelun laadussa yhdistettynš langattomien tietoverkkojen luontaiseen epšluotettavuuteen johtaa siihen, ettš saadakseen parhaan hyšdyn irti tarjolla olevista verkkoyhteyksistš, tulee jšrjestelmien nyt ja tulevaisuudessa pystyš dynaamisesti sopeutumaan palvelutasoltaan vaihteleviin verkkoyhteyksiin. Adaptoitumista, eli sopeutumista voi tapahtua jšrjestelmšn eri tasoilla. Peruskerroksessa voidaan pyrkiš tasoittamaan langattoman ympšristšn kenttšvaihtelua sopeutuvalla virranhallinnalla. Siirtoyhteyskerroksessa suojaudutaan siirtovirheitš ja vuonvaihteluja vastaan sopeutuvilla vuonvaraustekniikoilla. Kuljetuskerroksessa voidaan uudelleenneuvotella dynaamisesti yhteyden parametreja. Sovelluskerroksessa voi sopeutumista tapahtua monilla eri tavoin, kuten hierarkisella uudelleenkoodauksella, tehokkaalla tiivistšmisellš, kaistanleveyden tasoittamisella, nopeuden sšštelyllš, virheiden hallinnalla ja adaptiivisella synkronoinnilla. TŠssŠ dokumentissa kšsitellššn adaptiivisuutta enimmškseen systeemiarkkitehtuurin ylimmillš tasoilla, eli kšyttšjšn ja sovelluksen nškškannalta. Jonkin verran perehdytššn myšs kšyttšjšrjestelmšn ja sovellusalustan adaptoitumismahdollisuuksiin, sillš vaikka nykyajan jšrjestelmšt tukevat adaptiivisuutta yleensš vain joissakin jšrjestelmšn osissa, tulevaisuuden tietojšrjestelmissš adaptiivisuutta tulee esiintymššn kaikilla tasoilla.
SisŠllys 1. Miksi adaptoitua?... 1 2. Miksi adaptoituvia sovelluksia?... 2 3. Adaptiivisuus jšrjestelmšn eri tasoilla... 3 3.1. Adaptiivisuus systeemitasolla... 4 3.2. Adaptiivinen sovellusalusta (Middleware)... 4 3.3. Adaptiivisuus sovellustasolla... 5 3.4. Adaptiivinen kšyttšjš... 5 4. Adaptiivinen sovellus... 6 4.1. Adaptiivisuuden tukeminen... 6 4.2. Sovelluksen sopeutumismahdollisuudet... 7 4.3. Adaptoitumisen ajoitus... 8 4.4. VerkkoympŠristšn tila... 8 5. EsimerkkinŠ MOST-projekti... 10 5.1. Systeemiarkkitehtuuri... 10 5.2. Sopeutuminen jšrjestelmštasolla... 12 5.3. KŠyttŠjŠn sopeutuminen... 13 6. MitŠ tšstš opimme?... 14
1. MIKSI ADAPTOITUA? Teknologian kehittymisen myštš on tullut yleisesti saataville kohtuulliseen hintaan erilaisia verkkoyhteysvaihtoehtoja, kuten ethernet, lšhiverkot (LAN), laaja-alueverkot (WAN) ja langattomat modeemit. Kannettavalla tietokoneella otetaan tavallisesti yhteyttš monenlaisiin tietoverkkoihin, jotka tarjoavat eritasoisia verkkopalveluja. Esimerkiksi kiintešt verkot, kuten ethernet, ovat halpoja ja laajakaistaisia yhteyksiš, mutta ne toimivat ainoastaan rajoitetulla alueella, kun taasen langattomat yhteydet ovat laaja-alaisia, mutta kalliimpia ja kapeakaistaisempia. Taulukossa 1 on esitetty langattomille palvelimille tavallisten verkkoyhteyksien QoS-parametrien arvoja (Quality of Service, palvelun laatu). Taulukko 1. QoS-parametrien arvoja yleisimmille verkoille [MOST99]. KiinteissŠ verkoissa sovellukset ja protokollat on ršštšlšity vastaamaan verkon ominaisuuksia, mutta langattomissa ympšristšissš sovelluksilta vaaditaan dynaamista sopeutumista muutoksiin verkkoyhteydessš. Esimerkiksi modernissa toimisto- tai tutkimusympšristšssš mobiili tietokone voi olla kiintešssš yhteydessš verkkoon kšyttšjšn pysytellessš omassa huoneessaan. Kun kšyttšjš liikkuu toimistoympšristšssš, voidaan yhteyttš yllšpitšš infrapunan tai WaveLANin všlityksellš. Jos kšyttšjš liikkuu paikallisen toimistoympšristšn ulkopuolelle, vaihtuu yhteyden status langattomaksi laaja-alueverkoksi. TŠllaisessa tilanteessa verkkoyhteyden nopeus voi vaihdella GSM-verkkojen tarjoamasta 9,6 kbit/s siirtonopeudesta ATM-runkoverkolla saavutettavaan 2,4 Gbit/s nopeuteen. Kaikilla verkkoyhteyden ominaisuuksilla on vaikutuksensa jšrjestelmšn suorituskykyyn. Yhteyden laadun vaihtelu verkon eri osissa voi olla huomattavaa suuruusluokkaa. Esimerkiksi kaistanleveys voi vaihdella kilobiteistš megabitteihin sekunnissa ja latenssi mikrosekunneista sekunteihin. Osa verkosta voi olla lšhes ruuhkaton ja hšvištšn ja toinen osa erittšin ruuhkainen ja lšhes kaikki paketit hšvittšvš. Langattoman lšhiverkon, kuten WaveLANin, ominaisuudet eroavat vastaavaan kiinteššn verkkoon verrattuna suurempana bittivirheiden mššršnš, joka johtaa suurempaan kadonneiden pakettien mššrššn [MOST99].
Vaihto suorituskyvyltššn erilaisten verkkojen všlillš vaatii jšrjestelmiltš sopeutumista vaihtelevaan yhteyden laatuun. Joustavuus verkkopalvelun laadussa yhdistettynš langattomien tietoverkkojen luontaiseen epšluotettavuuteen johtaa siihen, ettš saadakseen parhaan hyšdyn irti tarjolla olevista verkkoyhteyksistš, tulee jšrjestelmien pystyš dynaamisesti sopeutumaan palvelutasoltaan vaihteleviin verkkoyhteyksiin. 2. MIKSI ADAPTOITUVIA SOVELLUKSIA? Hajautettujen jšrjestelmien sovellukset pyšrivšt ympšristšissš, jotka voivat sisšltšš erilaisia verkkoarkkitehtuureja sekš sovellusalustoja. LisŠksi hajautetuissa ympšristšissš sovellus harvemmin pššsee yksinššn kšyttšmššn resursseja, sillš yleensš ne jaetaan monen sovelluksen ja kšyttšjšn kesken. TŠstŠ johtuen sovellukset saavat vaihtelevan tasoista palvelua ympšristšltššn. Kuvassa 1 on esimerkki hajautetusta mobiilista jšrjestelmšstš. Kuva 1. Hajautettu mobiili jšrjestelmš Monilla hajautettujen ympšristšjen sovelluksilla on kriittiset vasteaikavaatimukset. Suoritettavan tapahtuman vasteaika riippuu pitkšlti resurssien saatavuudesta, eli saatavilla olevasta kaistanleveydestš ja prosessoriajasta. Esimerkiksi nopean prosessorin tai verkkoyhteyden suorituskyky voi heikentyš kuormituksen kasvaessa, mutta jos tšllaisessa tilanteessa sovellus osaisi vaihtaa toiseen jšrjestelmšn osaan lennossa, ei kšyttšjš všlttšmšttš huomaisi minkššnlaista hidastumista toiminnassa. Vastaavasti suoritettaessa pitkškestoista hajautettua simulaatiota voidaan ruuhkaisten linkkien
vaikutusta všlttšš siirtšmšllš simulaatiota toiseen verkon osaan. Tietokanta, johon kšyttšjšt tekevšt samanaikaisesti useita vaativia kyselyjš, voi kšyttšjšlle vaikuttaa tšysin pysšhtyneeltš, mutta jos data olisi replikoitu myšs muille palvelimille, voisi sovellus vaihtaa palvelinta ja saada vastauksen sopivassa ajassa. Videokuvan siirtšminen ruuhkaisen verkon lšpi voi johtaa moniin hylšttyihin kehyksiin ja siten kuvan laadun heikkenemiseen, mutta ŠlykŠs filtteri voisi pšštellš mitkš kehyksistš ovat všhemmšn tšrkeitš, ja hylkššmšllš nšitš kehyksiš ja tšten všhentšmšllš tarvittavaa kaistanleveyttš, se pystyisi sšilyttšmššn audio-video synkronisaation. Suuret suorituskyvyn vaihtelut verkkoyhteyden palvelun laadussa aiheuttavat erityisiš vaatimuksia yhteyttš kšyttšville sovelluksille. Toisaalta verkkoyhteyttš kšyttšvšllš sovelluksella voi olla omia vaatimuksia, esimerkiksi suorituskyky- tai kustannusvaatimuksia, verkkopalvelun tason suhteen, jolloin sovelluksella pitšisi olla mahdollisuus valita palvelun taso mahdollisimman hyvin tarpeitansa vastaavaksi. Adaptiivisuuden tukemisella voidaan myšs sššstšš, sillš sovellus voi valita tarpeitaan vastaavan alemman palvelutason, esimerkiksi taatun palvelutason sijasta parhaan saatavilla olevan palvelutason. 3. ADAPTIIVISUUS J RJESTELM N ERI TASOILLA Adaptoitumista, eli sopeutumista, voi tapahtua jšrjestelmšn eri tasoilla. OSIviitemallin (Open Systems Interconnection) kerrosrakenteen mukaisesti jaoteltuna voidaan peruskerroksessa pyrkiš tasoittamaan langattoman ympšristšn kenttšvaihtelua sopeutuvalla virran hallinnalla. Siirtoyhteyskerroksessa suojaudutaan siirtovirheitš ja vuonvaihteluja vastaan sopeutuvilla vuonvaraustekniikoilla. Kuljetuskerroksessa voidaan uudelleenneuvotella dynaamisesti yhteyden parametreja. Sovelluskerroksessa voi sopeutumista tapahtua monilla eri tavoin, kuten datan hierarkisella uudelleenkoodauksella, tehokkaalla tiivistšmisellš, kaistanleveyden tasoittamisella, nopeuden sšštelyllš, virheiden hallinnalla ja adaptiivisella synkronoinnilla [STREAM99]. Jotta suuria muutoksia verkkoyhteydessš pystyttšisiin kšsittelemššn, tšytyy protokollapinon kerroksien muuttaa toimintamalliaan. YleensŠ sovellukset ja sovellustason protokollat ovat parhaita sopeutujia. Esimerkiksi www-selain voi pššttšš vaihtaa všrikuvat musta-valkokuviksi jos verkkoyhteys on huono, tai jšttšš kuvat kokonaan pois. Samoin, sopeutuva FTP voi lykštš tiedostojen latausta, jos verkkoyhteys on kallista. Sovellustason adaptoituminen ei kuitenkaan ole aina tarkoituksenmukaista tai mahdollista. Datan semanttisuudesta riippumaton sopeutuminen voidaan joskus suorittaa tehokkaammin alemmilla tasoilla. Esimerkiksi pakettien uudelleenlšhetys langattomassa ympšristšssš voidaan toteuttaa sovellukselle nškymšttšmšllš tavalla ja nšin všhentšš hšvišmisiš tukiaseman vaihtumisen aikana [PROTO99].
3.1. Adaptiivisuus systeemitasolla KŠyttšjŠrjestelmŠ ja erityisesti protokollapino ovat luonnollinen adaptointitekniikoiden toteutusympšristš. Yksinkertaisimmillaan kšyttšjšrjestelmš voi tukea valtavaa mššršš protokollia, joista jokainen on erityisesti ršštšlšity vastaamaan tietynlaista kommunikaatioteknologiaa. Kun verkkoympšristš vaihtuu, voi jšrjestelmš dynaamisesti vaihtaa uutta ympšristšš parhaiten tukevaan protokollaan. Esimerkki protokollatason sopeutumisesta on vaihtoehtoisten protokollien kšyttš sovitettaessa pakettien ajoitusta kuljetusteknologiaan. Suurinopeuksisissa verkoissa pakettien lšhettšmisen hallinnalla pyritššn všlttšmššn ruuhkaa ja yllšpitšmššn jatkuvan datan lšhettšmiseen tarvittavia QoS-parametreja. Esimerkiksi modeemilinjaa kšytettšessš latenssia ja yhteyden kustannuksia voidaan všhentšš ryhmittelemšllš dataa. JŠrjestelmissŠ, joissa kaistanleveys on erittšin rajoitettu, esimerkiksi langatonta WANia kšyttšvissš jšrjestelmissš, on syytš priorisoida lšhetettšvš data jonkin olennaisen kriteerin perusteella. Protokollatason sopeutuminen on monimutkaista tapauksissa, joissa on samaan aikaan kšytettšvissš useita ÓpŠŠllekkŠisiŠÓ verkkoja, jolloin protokollatason tšytyy pšštellš mikš tarjolla olevista kujetustavoista sopii parhaiten kyseessš olevalle datalle [MOST99]. Adaptoituminen muutoksiin verkkoyhteydessš ei ole ideana kovinkaan uusi, sillš verkkotason sopeutuminen on ollut osa Internet-protokollaa alusta alkaen. TCP (Transmission Control Protocol), internetin siirtoprotokolla, sopeuttaa lšhettšmšnsš datan mššršn verkon kapasiteettia vastaavaksi mittaamalla pakettien hšvištš ja siirtoviivettš. 3.2. Adaptiivinen sovellusalusta (Middleware) Monet projektit ovat tutkineet adaptiivisuutta tukevien palvelujen toteuttamista sovellusalustatasolla ja kolme perusratkaisua on noussut esille. Sovellusalustan palvelut voivat pyrkiš všhentšmššn sovelluksen tarvitsemaa kaistanleveyttš esimerkiksi lisššmšllš datan tiivistystš ennen lšhettšmistš. TŠmŠ tekniikka on erityisen tehokas silloin kun lšhetetššn jatkuvaa dataa, johon voidaan soveltaa tietoa hukkaavaa tiivistšmistš tai epšolennaisen tiedon pois suodattamista, eli filtteršintiš. Toinen vaihtoehto on tuottaa palveluja, jotka voivat noutaa korkealaatuisen yhteyden aikana dataa všlimuistiin ja pystyvšt nšin etukšteen varautumaan heikon yhteyden varalle. Jalostettu versio edellš mainitusta on priorisoida data etukšteen ja noutaa tšrkešt tiedot valmiiksi hyvšn yhteyden aikana. Esimerkiksi yhteydettšmšt postin- ja uutistenlukuohjelmat noutavat etukšteen yhteenvetoinformaation (otsikot ja aiheet) ja loput sanomasta tai artikkelista jos ja kun sitš tarvitaan. Tukipalvelut voivat soveltaa tštš tekniikkaa kšytšnnšssš tuomalla dokumentin ensimmšisen sivun nšytšlle ja noutamalla muita sivuja sillš aikaa kuin kšyttšjš lukee ensimmšistš. Kolmas lšhestymistapa on dynaamisesti luoda uusi yhteys clientin ja palvelimen všlille aina kun verkon tila muuttuu. YhteydettšmŠnŠ aikana clientti voi kytkeytyš
paikalliseen proxy-palvelimeen, kunnes verkkoyhteys voidaan jšlleen tarjota. TŠllŠ hetkellš suurin osa sovellusalustoista perustuu RPC-protokollan (Remote Procedure Call) mukaiseen prosessien všliseen kommunikointimuotoon, joka ei suvaitse keskeytyksiš yhteydessš. Perinteisen RPC:n semantiikan muokkaamiseksi všhemmšn synkroniseksi on tehty paljon tyštš, sillš erityisesti langattomassa ympšristšssš on suotavaa pystyš sopeutumaan katkoksiin yhteydessš [MOST99]. 3.3. Adaptiivisuus sovellustasolla Sovellusalustan tukipalvelut pyrkivšt lieventšmššn yhteyskerroksen muutosten vaikutusta sovelluksen toimintaan, mutta monissa tapauksissa sovellus itse pystyy parhaiten sopeutumaan muutoksiin verkon tilassa. Jotta adaptiivisuutta voidaan tukea sovellustasolla, vaatii se erityisesti dynaamisessa ympšristšssš toimimaan suunniteltujen sovellusten toteuttamista. Monet sovellukset pystyvšt yhtenššn tarkentamaan vaatimuksiaan tarvitsemiensa resurssien suhteen. Adaptiivinen sovellus voi lisštš tai všhentšš kšyttšmiensš prosessorien tai solmujen lukumššršš tai siirtyš suorittumaan kokonaan toiseen verkon osaan reagoidessaan muutoksiin verkon tilassa. Myšs verkon resurssit antavat sovellukselle mahdollisuuden toteuttaa adaptiivisuutta. KaistanleveydellŠ voidaan tehdš lehmšnkauppoja muiden parametrien, kuten tiedon tarkkuuden tai siirrettšvien objektien laadun kanssa. Sovellus voi esimerkiksi muuttamalla siirrettšvšn videokuvan kehyksen kokoa tai niiden lukumššršš suurentaa tai pienentšš siirtoon vaadittavaa kaistanleveyttš. Vaihtoehtoisesti sovellus voi tiivistšmisellš pienentšš kaistanleveysvaatimuksiaan, mutta tšllšin se tarvitsee vastakaupaksi prosessoriaikaa tiedon tiivistšmiseen ja purkamiseen. 3.4. Adaptiivinen kšyttšjš JŠrjestelmŠn kšyttšjšn voisi ajatella olevan sopeutumisen ensimmšisellš tasolla, sillš kšyttšjšn teot vaikuttavat epšsuorasti suurimpaan osaan verkon resurssivaatimuksista. Jos kšyttšjš olisi tietoinen valintojensa aiheuttamista toimenpiteistš verkkotasolla, voitaisiin monet verkon rajoituksista aiheutuvat ongelmat všlttšš. Jos esimerkiksi internet-selain tai FTP-palvelu antaa kšyttšjšlle palautetta siirron edistymisestš tai jšljellš olevasta ajasta, voi kšyttšjš helposti pššttšš haluaako jatkaa operaatiota. Helsingin Yliopistolla kehitetty Mowgli WWW-ohjelmisto mobiilille Internetin kšyttšjšlle tarjoaa hyvšn esimerkin adaptiivisuutta tukevasta kšyttšliittymšstš. KŠyttšliittymŠn dokumenttiasetusten avulla kšyttšjš voi esimerkiksi valita haetaanko upotetut kuvat tai taustakuvat dokumentin yhteydessš ja asettaa kokorajoituksia dokumentin objekteille. LisŠksi kšyttšjš pššsee vaikuttamaan mm. tiedon tiivistykseen, esitystapaan, verkkoyhteyteen, všlimuistin kokoon ja erštiedonsiirron ajastamiseen vaikuttaviin parametreihin. Mowglin WWW agentti muokkaa jokaisen kšyttšjšlle nšytettšvšn dokumentin, lisššmšllš sen ylšlaitaan rivin painikkeita, joilla kšyttšjš voi hallita dokumenttia esimerkiksi lukitsemalla sen všlimuistiin tai tuhoamalla sen všlimuistista. LisŠksi agentti lisšš dokumenttiin jokaisen hypertekstilinkin perššn pienen ikonin, jonka ilmentymš paljastaa onko
dokumentti noutamatta, parhaillaan noudossa vai noudettu jo. KŠyttŠjŠ voi lisštš noutamattoman dokumentin eršsiirtojonoon klikkaamalla ikonia [MOWGLI96]. Tavallisen kšyttšjšn kannalta ajatellen siirtyy adaptiivisuuden tukeminen takaisin sovellustasolle, sillš huolellisesti suunnitellut informatiiviset kšyttšliitymšt ovat helpoin tapa saada kšyttšjš sopeutumaan muutoksiin jšrjestelmšympšristšssš. 4. ADAPTIIVINEN SOVELLUS NykyŠŠn monet verkkosovellukset ovat adaptiivisia ja pystyvšt tekemššn sovellustason pšštšksiš, jotka perustuvat verkon ja yhteyden pšštepisteen tilaan. TŠllaiset sovellukset jaetaan yleensš kahteen kategoriaan. EnsimmŠisessŠ kategoriassa ovat sovellukset, jotka valitsevat palvelimen, johon olla yhteydessš palvelimen tšmšn hetkisen tilan perusteella. Palvelimen valitsevan sovelluksen tšytyy olla tietoinen verkon samansisšltšisistš palvelimista, joista se valitsee saamansa verkko- ja palvelininformaation perusteella sopivan palvelimen. Mekanismi, jolla sovellukselle tuotetaan lista palvelimista tai jolla sovellus valitsee niistš sopivan, vaihtelee sovelluksesta toiseen. Toiseen kategoriaan kuuluvat sovellukset, jotka kommunikoidessaan kaukaisten palvelimien kanssa, valitsevat tiedon esitystavan sen hetkisiin olosuhteisiin perustuen. NŠiden sovellusten pššmššršnš on yleensš pitšš vasteaika tai tehokkuus sopivana sisšllšn tarkkuuden kustannuksella. Myšs tšssš kategoriassa sovellukset kšyttšvšt erilaisia mekanismeja pššttšessššn tiedon esitystavasta [STEMM99]. 4.1. Adaptiivisuuden tukeminen Sovellusten adaptiivisuuden tukemiseen on pyritty kahdella eri tekniikalla: joko laajentamalla systeemialustaa siten, ettš sovellukset voivat saada palautetta verkon tilasta, tai kšyttšmšllš proxyjš suorittamaan adaptoituminen sovelluksen puolesta. EnsimmŠinen vaihtoehto yleensš edellyttšš uusien sovellusalustojen kehittšmistš, jotta verkon tilan nškymšttšmyys sovellukselle saadaan hšivytettyš. NŠihin laajennoksiin yhdistetššn usein muitakin hienouksia, kuten datan puskurointia, jotta sovellus voisi jatkaa operaatioitaan myšs verkkoyhteyden katkosten aikana. Toinen vaihtoehto perustuu seuraavalla sivulla olevan kuvan 2 kaltaisiin proxyarkkitehtuureihin, joissa taas mahdollistetaan suodatus-, všlimuisti- ja kššnnšskomponenttien sijoittaminen palvelimen ja clientin všliselle kommunikaatiovšylšlle. Proxy-palvelin pystyy muokkaamaan palvelimen ja clientin všlistš kommunikaatiovirtaa, sekš palvelimelta clientille ettš toisin pšin, vallitseviin QoS-ominaisuuksiin sopeutuvaksi. TŠmŠ sopeuttaminen tapahtuu joillakin seuraavista proxy-arkkitehtuurin perustoimenpiteistš [GENERA99]. Suodattaminen (filtering): Suodattava proxy všhentšš kuljetettavan datan mššršš poistamalla siitš epšolennaisempia osia. Muuntaminen (transforming): Muuntava proxy muuttaa prosessoimansa datavirran tyyppiš všhentšškseen sen voimakkuutta tai sovittaakseen sen formaatin clientille helposti esitettšvššn muotoon. Proxy voi esimerkiksi
muuttaa PostScript-dokumentin ASCII-tiedostoksi sšilyttšen datan tekstillisen sisšllšn, mutta jšttšmšllš formaatit ja kuvat pois. VŠlimuisti (caching): VŠlimuistina toimiva proxy lisšš asynkronisuutta tietovirtaan. ÓTarpeen niin vaatiessaó -perusteella toimivaa všlimuistiproxyš voidaan kšyttšš minimoimaan huonoa yhteyttš pitkin lšhetettšvšn datan mššršš. EtukŠteen muistiin noutava proxy taasen hyšdyntšš hyvšš yhteyttš ja noutaa dataa muistiin sen tarpeellisuuden ennakoiden. Kuva 2. Proxy-arkkitehtuuri [GENERA99]. 4.2. Sovelluksen sopeutumismahdollisuudet Yksinkertaisin adaptointitekniikka, jonka sovellus voi tuottaa, on mukauttaa kommunikointivaatimuksensa yhteyden tasoa vastaavaksi. Esimerkiksi multimediatietokannassa sovellus voi valita vastaanottavansa tekstikuvauksen ennemmin kuin huonolaatuisen kuvan, sillš vaikkapa ršntgenkuvia siirrettšessš kuvan laadun heikkeneminen voi olla kohtalokkaan harhaanjohtavaa. Toinen esimerkki adaptoitumisesta olisi tilanne, jossa sovellus noutaa tietokannasta useita tietueita selailua ja valintaa varten verkkoyhteyden Škillisesti heiketessš. TŠllšin adaptiivinen sovellus siirtšš tietueiden poimimisen proxypalvelimelle tai agentille ennen niiden siirtšmistš heikkoa yhteyttš pitkin sovellukselle. Kolmanneksi esimerkiksi adaptiivisuudesta valitaan hieman kehittyneempi sovellus, audio-video konferenssi-sovellus, joka pystyy sopeutumaan všhentšmšllš QoS-vaatimuksiaan parhaillaan siirrettšvšš mediaa vastaavaksi tai esimerkiksi luopumalla videokuvan siirrosta audioyhteyden hyvšksi. Tiedonsiirtotavan muuttamisen lisšksi sovellus voi uudelleen rakentautumalla pyrkiš sopeutumaan muutoksiin yhteysrakenteissa. Esimerkiksi ryhmšsovellus, joka vaatii ryhmšn tilan yllšpitoa, voi monilšhetystš (multicasting) tukevassa paikallisverkossa hajauttaa ryhmšn tilatiedon yllšpitšmisen saavutettavuuden ja vikasietoisuuden parantamiseksi. Tilanteessa, jossa osa ryhmšn jšsenistš siirtyy langattoman yhteyden pššhšn, joka ei tue ryhmškutsuja ja monilšhetystš, on sovelluksen helpompi hallita ryhmšn tilatietoa, jos hallinta keskitetššn tiettyyn pisteeseen. TŠllšin sovelluksen voi lisšksi olla mahdollista všhentšš yhteydenpitoa mobiileihin ryhmšn jšseniin, jotta parempien yhteyksien pššssš olevien jšsenten vasteajat eivšt kšrsisi [MOST99].
4.3. Adaptoitumisen ajoitus Dynaaminen sopeutuminen tarjoaa sekš haasteita ettš mahdollisuuksia systeemisuunnittelijoille. Yksi vaihtoehto sopeutumisen ajoittamiselle on sovelluksen lataamis- tai aloitusvaihe. TŠmŠ on helpoin vaihtoehto, sillš tšssš vaiheessa sovellus ei ole vielš asettunut minkššnlaiseen tilaan, mutta mikšli olosuhteet muuttuvat suorituksen aikana, ei sovellus pysty sopeutumaan muutoksiin. Esimerkki tšstš olisi sovellus, joka kykenisi valitsemaan mitš solmuja se kšyttšš, eli missš ympšristšssš se toimii. WWW-selain voi valita usean samansisšltšisen palvelimen tai proxy-palvelimen všliltš. Vaihtoehtoinen tapa on pššstšš sovellus adaptoitumaan sekš kšynnistymisen yhteydessš ettš suorittumisen aikana. Ajonaikainen sopeutuminen on monimutkaisempi toteuttaa, sillš tšllšin sovelluksen tšytyy kyetš muokkaamaan itseššn uudelleen [HETERO99]. Ajonaikaista sopeutumista voi tapahtua joko periodisesti, jolloin jšrjestelmš tasapainottaa kuorimituksen uudelleen aina t aikayksikšn všlein tai vaihtoehtoisesti periaatteilla tarpeen niin vaatiessa tai sopivan tilaisuuden tullen. KeskimmŠisessŠ tapauksessa jšrjestelmš pyrkii sopeutumaan aina kun jonkin parametrin arvo putoaa tietyn kynnyksen alapuolelle ja jšlkimmšisessš tapauksessa jšrjestelmš yrittšš aina opportunistisesti kšyttšš tilaisuuden hyšdykseen kun resursseja vapautuu. Ajonaikainen sopeutuminen lisšš huomattavasti ohjelmoinnin ja sopeutumisprosessin monimutkaisuutta, mutta se on všlttšmštšntš, jotta saavutettaisiin kelvollinen suorituskyky ajettaessa pitkškestoisia sovelluksia vaihtelevissa olosuhteissa. 4.4. VerkkoympŠristšn tila Sopeutuakseen vallitsevaan verkkoympšristšn tilaan tarvitsee sovellus tietoa siitš. Yhteysprotokollat tuottavat tietoa verkon tilasta ja jakavat tietouttaan myšs sovelluksille. Implisiittiseen palautteeseen perustuvat protokollat tarkkailevat sisššntulevaa tietovirtaa ja tekevšt sen perusteella pšštelmiš verkko-olosuhteista. TCP on hyvš esimerkki tšllaisesta protokollasta. TCP tulkitsee hylštyt paketit ruuhkan merkiksi verkossa, jolloin lšhettšjš voi pienentšš pakettien lšhetystahtia. Eksplisiittisen palautteen ollessa kyseessš jokin verkon sisšinen itsenšinen osio tuottaa tietoa verkon olosuhteista suoraan lšhettšjille. HyvŠ esimerkki on ATM:n (Asynchronous Transfer Mode) ABR Ðlaatuluokka (Available Bit Rate Ðclass), jossa lšhettšjšt saavat sššnnšllisin všliajoin tietoa verkon ruuhkatilanteesta tai niille voidaan jopa ilmoittaa suurin mahdollinen nopeus millš lšhettšminen sallitaan. Implisiittinen palautteen tuottaminen on aina toteutettavissa, sillš se ei vaadi verkkotukea, mutta sillš on myšs puutteensa. Implisiittinen palaute kertoo ainoastaan muutoksen lisšyksen, eli esimerkiksi kahden palvelimen
kommunikoidessa, všlittyy tieto siitš, miten niiden všlinen kaistanleveys kehittyy. LisŠksi implisiittistš tietoa saattaa olla vaikeaa tulkita. Pakettien hšvišminen kielii selvšsti ruuhkaisesta verkosta, mutta se ei kerro pitšisikš sovelluksen keskeyttšš lšhetys hetkeksi, lšhettšš paketteja uudelleen tai toimia jotenkin toisin. Implisiittinen informaatio perustuu kokemukseen, joten sovellus pystyy kerššmššn tietoa verkon tilasta ja palvelujen laadusta ainoastaan sellaisten verkon polkujen varrelta, joilla se operoi. LisŠksi palautetta kertyy ainoastaan silloin kun sovellus aktiivisesti kšyttšš verkkoa, eli sovelluksen kšynnistyessš tai ollessa joutilaana ei tietoa ole saatavilla. SelviytyŠkseen nšistš rajoitteista sovellus voisi sššnnšllisin všliajoin kokeilla kaikkia eri palveluluokkia selvittšškseen verkon suorituskyvyn kšytettšvissš olevien solmujen všlillš. Joissain tapauksissa edellš mainitun kaltainen ratkaisu voi olla sopiva, mutta kšytšnnšssš tehokkaiden verkontestausrutiinien toteuttaminen on vaikeaa. LisŠksi ylenmššršinen kokeileminen voi olla kallista, sillš se kuluttaa sekš sovelluksen aikaa ettš verkon resursseja. Eksplisiittinen palaute on helppokšyttšistš sovelluksille, mutta sen tuottaminen vaatii tukea verkkokerrokselta. EksplisiittistŠ palautetta voidaan tuottaa kahdella tavalla. Verkko voi tuottaa palautetta jatkuvasti, kuten esimerkiksi edellš mainitussa ABR-liikenteessŠ, jossa erillistš nopeudenhallinnointiin kšytettšvšš solua vaihdetaan verkon kanssa 32 solun všlein. Vaihtoehtoisesti sovellukselle voidaan antaa ilmoitus aina kun tapahtuu jotakin erityistš, kuten verkon kaistanleveys laskee alle tietyn arvon tai yhteys vaihtuu verkkotyypistš toiseen. Paljon laskentaa vaativat hajautetut tieteelliset simulaatiot pitšvšt yleensš yllš tietoa verkon tilasta joko sisšisesti mittaamalla jonkin tyškalun avulla verkon tilaa tai ulkoisesti mittaamalla eri solmuissa ja verkon eri osissa suorittuvien tšiden edistymistš. Simulaatiot myšs usein tasoittavat kuormitusta siirtšmšllš laskentaa pois solmuilta jotka edistyvšt muita hitaammin. YleensŠkin adaptoitumismalli, jossa sovellus tarkkailee omaa suorituskykyššn ja sopeutuu havaitessaan muutoksia on erittšin kšyttškelpoinen [HETERO99]. YleensŠ sopeutumista ei voida tehdš ilman ulkoisia mittauksia ympšristšn tilasta. Solmujen valinta suoritusta aloitettaessa tšytyy perustaa ulkoisille mittauksille, sillš ilman ei voida tietšš mitkš solmuista ovat kšytettšvissš. Dynaaminen vaihto solmujoukosta toiseen, kuten myšs solmujen lukumššršn kasvattaminen sovelluksen suorittumisen aikana, vaatii ulkoista tietoa solmuista, sillš sovelluksen sisšinen informaatio rajoittuu niiden solmujen tilaan, joita sovellus parhaillaan kšyttšš. Heterogeeniset ympšristšt ovat haasteellisia systeemisuunnittelijoille, joten on tšrkešš, ettš verkkoyhteydestš tietoa tuottava jšrjestelmš on yksinkertainen ja mobiili. YhtenŠinen runko, sekš erilaisten verkkoarkkitehtuurien resurssien monitorointijšrjestelmš, ovat všlttšmštšn aines adaptiivisten sovellusten kehittšmiselle [HETERO99].
5. ESIMERKKIN MOST-PROJEKTI MOST = Mobile Open Systems Technology for the Utilities Industry Adaptiivisuutta sovellus-, sovellusalusta- tai kšyttšjšrjestelmštasolla tukevia jšrjestelmiš on kehitetty useita, mutta sellaisia jšrjestelmiš, jotka tukisivat adaptiivisuutta kaikilla nšillš tasoilla on vain muutamia. Lancasterin Yliopisto ja EA Technology kehittivšt yhteistyšssš langattoman sovelluksen tukemaan sšhkšntuotantoteollisuuden kenttštyšntekijšiden toimintaa. TŠssŠ luvussa kuvaillaan MOST-projektin kehitystyšn tuloksena syntynyttš langatonta yhteistyšsovellusta, joka tukee adaptiivisuutta niin kšyttšjš-, sovellus-, sovellusalusta- kuin kšyttšjšrjestelmštasolla. KenttŠtyšntekijŠt ovat vastuussa sšhkšnjakeluverkon luomisesta ja yllšpidosta, joten heidšn tyšnsš koostuu enimmškseen rutiininomaisista rakennus- ja yllšpitotehtšvistš. killiset hširišt sšhkšnjakeluverkossa, kuten tšydelliset sšhkškatkokset, voivat aiheuttaa huomattavia vahinkoja esimerkiksi sairaaloiden tai raskaan teollisuuden toiminnalle. Virhetilanteen sattuessa jakeluverkon toiminnan palauttaminen nopeasti ja turvallisesti vaatii paljon resursseja ja koordinoitua yhteistyštš vian ja paikan mššrittšmiseen ja eristšmiseen sekš virheen korjaamiseen. MOST-projektissa otettiin erityisesti huomioon seuraavat jšrjestelmšlle asetettavat vaatimukset: Liikkuvuus: KenttŠinsinššrit liikkuvat paikasta toiseen ja tarvitsevat yhteyden sekš kiinteisiin ettš langattomiin kohteisiin. Paikkatieto: KenttŠinsinššrit kšsittelevšt paljon kaavioita ja muuta graafista tietoa, kuten karttoja, konepiirustuksia ja yhteysdiagrammeja. Multimedia: Kartat ja niiden viitetiedot sisšltšvšt sekš rasterið ettš vektorimuotoista dataa ja mahdollisesti myšs kšsin tehtyjš merkintšjš, joten on tarpeellista yllšpitšš myšs audio-yhteyttš insinššrien všlillš. YhteiskŠyttšisyys: JŠrjestelmŠn tulee mahdollistaa fyysisesti eri paikoissa sijaitsevien insinššrien kommunikointi puheen avulla sekš yhteisten jaettujen karttojen, kaavioiden ja osoitustyškalujen kšyttš. Yhteistyš (ulkopuolisten tahojen kanssa): JŠrjestelmŠltŠ vaaditaan yhteistyškykyisyyttš muiden (julkisten) laitosten tietojšrjestelmien kanssa. Sovellus kehitettiin toimimaan testiympšristšssš, joka koostuu ethernet-verkolla yhdistetyistš tyšasemista sekš kannettavista koneista modeemiyhteydellš, GSMverkon všlityksellš. 5.1. Systeemiarkkitehtuuri Sovellus koostuu kolmesta komponentista: sovelluskoodista, tukea antavasta hajautetun jšrjestelmšn sovellusalustasta ja modeemiyhteyden (dial-up)
verkkoajurista (S-UDP, Serial- User Datagramm Protocol). Kuvassa 2 on esitetty jšrjestelmšn yleisarkkitehtuuri. Kuva 2. MOSTin systeemiarkkitehtuuri [MOST99]. JŠrjestelmŠarkkitehtuuri perustuu ANSAwareÐnimiseen hajautettuun jšrjestelmšalustaan, jolla on ollut voimakas vaikutus ISO/ITU-T RM-ODP Ðstandardin (Reference Model for Open Distributed Processing) kehittšmisessš. ANSAware- jšrjestelmšalusta tukee suoraan operatiivisuutta muiden jšrjestelmien kanssa. MOST-projektin jšrjestelmšalustaan on lisšksi liitetty adaptiivisuutta tukevia piirteitš. JŠrjestelmŠ koostuu komponenteista, eli objekteista. Jokainen objekti kšsittšš koteloidun sisšisen tilan ja yhden tai useamman rajapinnan, jotka mššrittelevšt miten muut objektit voivat kommunikoida ko. objektin kanssa. Rajapinta on joukko nimettyjš operaatioita, joita voidaan kutsua joko synkronisesti tai asynkronisesti. Toiminnalliset rajapinnat yllšpidetššn všlityspalvelun avulla. Sovelluksen alimmalla tasolla on S-UDP -ajuri, joka toimii lšhes vastaavasti kuin SLIP (Serial Line Internet Protocol) tai PPP (Point-to-Point Protocol), eli se paketoi ja lšhettšš tiedon eteenpšin sarjaliikenneyhteyttš tai modeemilinjaa pitkin. S-UPD eroaa perinteisistš SLIPistŠ ja PPPstŠ siten, ettš sen QoS-rajapinta tarjoaa sovelluksille tietoa linjojen tilasta, yhteydettšmistš palvelimista ja odottavien pakettien mššršstš ja tilasta.
JŠrjestelmŠalustan objektiorientoitunutta mallia mukaillaan myšs itse sovelluksen toteutuksessa. Sovellus on itse asiassa kokoelma moduleja, joista jokainen vastaa yhden elementin toiminnallisuudesta sovelluksessa. PŠŠmodulit ja niiden toiminnat ovat seuraavat: GISÐmoduli (Geographic Information System): TŠmŠn modulin avulla insinššrit voivat katsella ja tehdš merkintšjš karttoihin ja kaavioihin. Moduli tukee myšs tosiaikaista synkronista ryhmštyšskentelyš konferenssin hallinta Ðmodulin avulla. Konferenssin hallinta Ðmoduli: TŠmŠ moduli yllšpitšš kšyttšjien všlisiš neuvotteluja, jotka sisšltšvšt audio-yhteyksiš ja yhteiskšyttšisiš sovelluksia, kuten GIS-moduli. Hajautetun tietokannan hallinta Ðmoduli: TŠmŠn modulin avulla pššstššn keskustietokannassa sijaitsevaan asiakasrekisteriin. Rakenteinen sšhkšposti: TŠmŠ moduli tukee rakenteisia sšhkšposteja, joissa voidaan lšhettšš esimerkiksi GIS-modulilla tuotettuja karttoja. Jokainen moduli on toteutettu yhdellš tai useammalla sovellusalustan komponentilla. Konferenssin hallinta Ðmoduli vastaa kaikista ryhmšaktiviteettien koordinnoinneista ja tarjoaa muille sovelluksen moduleille rajapinnan ryhmšn koostumuksen tarkasteluun. JŠrjestelmŠŠn on lisštty monia QoS-piirteitŠ, joiden avulla sovelluksen modulien on mahdollista tarkkailla ja kontrolloida vuorovaikutustaan muiden ohjelman komponenttien kanssa. Sovellusalusta ja sovellukset voivat sopeutua muutoksiin alemmissa kerroksissa lšpi koko arkkitehtuurin kulkevan QoS-informaation avulla. 5.2. Sopeutuminen jšrjestelmštasolla Kuten jo aikaisemminkin on todettu, voivat sovellukset kšyttšš resursseja tehokkaammin hyvškseen, jos niiden on mahdollista reagoida allaolevissa kerroksissa tapahtuviin muutoksiin. MOST-prototyypissŠ adaptoitumista on helpotettu yllšpitšmšllš QoSÐarkkitehtuuria, johon jšrjestelmšn eri tasot voivat rekisteršidš QoSÐvaatimuksensa ja jolta ne myšs saavat ilmoituksen palvelun laadun muuttuessa. QoSÐarkkitehtuuri tukee seuraavia parametreja: Suoritusteho Etenemisviive Joutoaika Tavoitettavuus JŠrjestelmŠn RPCÐmekanismi (Remote Procedure Call), nimeltššn QEX (Qualityof-Service driven remote EXecution), keršš statistiikkaa kahta ensimmšistš parametria varten. Protokolla kšyttšš statistiikaa uudelleenlšhettšmisen ajastamiseen ruuhkan všlttšmiseksi ja kontrolloimiseksi sekš tuottaa informaatiota
sovelluksia varten. Sovelluksen on mahdollista mššritellš sallitut poikkeamat yllš mainituille yhteyden parametreille ja se voi pyytšš tulla informoiduksi, jos parametrien raja-arvot rikkoutuvat. Sovellus voi myšs neuvotella uudet rajat poikkeamille saatuaan ilmoituksen rajojen rikkoutumisesta. Mobiileille sovelluksille tšmš piirre on erityisen hyšdyllinen, sillš ne voivat pšštellš onko viestien lšhettšminen ja vastaanottaminen jotakin tiettyš yhteyttš pitkin mahdollista lšhettšmšttš erityisiš testiviestejš. Joutoaika ja tavoitettavuusparametrit ovat arvokkaita ympšristšissš, joissa yhteydet ovat heikkoja. Perinteinen RPC tarjoaa yleensš mekanismit poikkeukselliseen yhteyden katkaisemiseen jos palvelimeen ei saada yhteyttš. Tilanteissa, joissa sovellus hyšdyntšš takaisinkutsuja tai periodisia pšivityksiš, on usein myšs palvelimen tarpeellista pystyš pššttelemššn onko clientti ollut kykenevš ottamaan siihen yhteyttš. Palvelin voi mššritellš yhteyden joutoajalle maksimin, jonka jšlkeen se lšhettšš takaisinkutsun, jos yhteyttš ei ole kšytetty. Tavoitettavuusparametrin avulla voidaan vahvistaa, ettei joutoaikaparametrin ylittyminen johdu esimerkiksi yhteyden katkeamisesta. JŠrjestelmŠn tuottama QoS-parametrien tarkkailu-, palaute- ja kontrollointimekanismi mahdollistaa sovellusten sopeutumisen. NykyisessŠ MOST-prototyypissŠ ohjelmamodulit voivat luoda tšsmšllisiš yhteyksiš muissa palvelimissa oleviin kolleegoihinsa ja tarkkailla palvelimien všlillš vallitsevia olosuhteita. Esimerkiksi hajautetun tietokannan hallinta Ðmoduuli kšyttšš QoSinformaatiota sovittaakseen lšhettšmšnsš datan volyymin saatavilla olevaan siirtokapasiteettiin. 5.3. KŠyttŠjŠn sopeutuminen Useimmiten kšyttšjš on loppujen lopuksi vastuussa verkkoliikenteen syntymisestš, joten kšyttšjšn tyšskentelytapojen ja valintojen sopeuttamisella kšytettšviš sovelluksia ja verkkoyhteyksiš parhaiten hyšdyntšvšksi on suuri vaikutus koko jšrjestelmšn toiminnan tehokkuuteen. Kuvassa 3, seuraavalla sivulla, on esitetty MOST-sovelluksen ryhmšnjohtajan kšyttšliittymš, joka kuvastaa ryhmštyšskentelyn tilaa. LiittymŠn avulla voidaan lisštš ja poistaa jšseniš ryhmšstš ja kontrolloida sovelluksen moduuleja. Kuva esittšš ryhmštyštilannetta kolmen osapuolen kesken. Jokaisen kšyttšjšn alla on rivistš pienempiš ikoneja, jotka kuvaavat kšyttšjšn kšytšssš olevia ohjelmakomponentteja. Ikonien ilmentymšn perusteella voidaan pšštellš mitkš komponenteista ovat ryhmštyštilassa ja lisšksi mitkš ryhmšn jšsenistš ovat yhteydessš kyseiseen komponenttin.
Kuva 3. MOST-sovelluksen kšyttšliittymš [MOST99]. Ikonien perusteella pystytššn myšs pššttelemššn kšyttšjšn yhteysrakenteen laatu. Jokainen aktiivinen moduli ottaa eksplisiittisen yhteyden hajautetun jšrjestelmšn muissa koneissa sijaitseviin moduleihin. KŠytšssŠ olevan yhteyden tehokkuutta kuvaavien QoS-parametrien rekisteršimisen hoitaa erityinen yhteyden kontrollointi Ðalusta (binding control interface). NŠiden QoS-parametrien arvojen avulla pšivitetššn ikonien taustavšri, joka kuvaa kšyttšjšn (verkko)yhteyden voimakkuutta. Jos ryhmšn tehokkuus laskee normaalin tyšskentelyn aikana, voidaan všrien perusteella pšštellš kuka kšyttšjistš on jšrjestelmšn pullonkaulana. RyhmŠn tyšskentelyn tehokkuuden lisššmiseksi tšmš kšyttšjš voidaan tilapšisesti jššvštš ryhmšn operaatioista. Tilanteessa, jossa synkroninen yhteydenpito kšy mahdottomaksi, voidaan sovelluksen rakenteista sšhkšpostia kšyttšš kiireettšmšn tiedon levittšmiseen. 6. MIT T ST OPIMME? EdellŠ on tarkasteltu mitš sovelluksen adaptiivisuus oikein tarkoittaa ja mitš kaikkea adaptiivisuuden tukeminen sovellustasolla vaatii sovellukselta ja sitš ympšršivšltš jšrjestelmšltš yleensš. Dokumentissa kuvailtuja erilaisia vaihtoehtoja sovelluksen sopeutumiseksi on tutkittu lukemattomissa projekteissa, joiden tuloksena on syntynyt monen nimisiš jšrjestelmiš adaptiivisuuden toteuttamiseksi. Julkaistun kirjallisuuden perusteella projektit voisi ryhmitellš kolmeen kategoriaan sen mukaan toteutetaanko adaptiivisuutta jšrjestelmš-, sovellusalusta- vai sovellustasolla. LŠhtškohta lšhes kaikissa julkaisuissa oli sama: Nykyaikaisessa verkkoympšristšssš resurssien saatavuus vaikuttaa sovelluksen suorituskykyyn, jolloin sovelluksen on všlttšmštšntš kyetš sopeutumaan ympšristšn muutoksiin, jotta se suorittuisi tehokkaasti jšrkevšssš vasteajassa. Loppujen lopuksi lšhes poikkeuksetta projektien yhteenvedoissakin tultiin samaan tulokseen: Tehokkaasti toimiva adaptiivinen jšrjestelmš on kokonaisuus, jossa kšyttšjšrjestelmš tarjoaa mekanismit adaptiivisuuteen, esimerkiksi tiedon vallitsevista QoSÐparametrien arvoista, ja sovellusalusta sekš sovellukset varustetaan nšitš mekanismeja hyvšksi kšyttšvillš adaptiivisilla menettelytavoilla.
L HTEET [GENERA99] Experiences of Using Generative Communications to Support Adaptive Mobile Applications; Distributed Multimedia Research Group, Lancaster University, 1999. http://www.comp.lancs.ac.uk/computing/research/mpg/reports_199 9.html [HETERO99] Adaptive Distributed Applications on Heterogeneous Networks, Th. Gross, P. Steenkiste, and J. Subhlok. In Proc. 8th Heterogeneous Computing Workshop (HCW'99) http://www.cs.cmu.edu/afs/cs.cmu.edu/project/cmcl/archive/remula c-papers/hcw99.ps [MOST99] Developing Adaptive Applications: The MOST Experience; A. Friday, N. Davies, G.S. Blair and K. W. J. Cheverst http://www.comp.lancs.ac.uk/computing/research/mpg/reports_199 9.html [MOWGLI96]Enhanced Services for World-Wide Web in Mobile WAN Environment; Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K. University of Helsinki, Department of Computer Science, April 1996. [PROTO99] On Providing Support for Protocol Adaptation in Mobile Wireless Networks; Pradeep Sudame and B. R. Badrinath. ftp://www.cs.rutgers.edu/pub/technical-reports/dcs-tr-333.ps.z [STEMM99] An Network Measurement Architecture for Adaptive Applications; Mark Richard Stemm http://www.cs.berkeley.edu/~stemm/publications/thesis/thesis.html [STREAM99] A Survey of Application Layer Techniques for Adaptive Streaming of Multimedia; Bobby Vandalore, Wu-chi Feng, Raj Jain and Sonia Fahmy. Submitted to the Journal of Real Time Systems (Special Issue on Adaptive Multimedia), April 1999. http://www.cis.ohio-state.edu/~jain/papers/amjrts99.htm Kaikkiin lšhteisiin on viitattu 6.11.2000.