CARISMA Context-Aware Reflective Middleware System for Mobile Applications

Problemstilling Mobile enheter er fortsatt avhengige av fysiske begrensninger (les: stasjonære begrensninger) Mobile enheter vil altså bevege seg rundt i domener bestemt av stasjonære enheter (ressurser) Tenk både eksterne (nettverk, båndbredde…) og interne ressurser (batteri, skjermstørrelse…) samt applikasjonsbestemte ressurser (brukeraktivitet og humør) Trenger altså system for ”context-awareness” I dette tilfellet CARISMA

Over til løsningen… Mellomvare tilbyr generelt abstraksjon og transparens Mellomvare må ta beslutninger for applikasjonene – egnet for det generelle tilfellet, men hva med mobile enheter??? Viktig prinsipp: ”reflection” – brukes sentralt i artikkelen for å lage nytt system for abstraksjon i middleware Det nye systemet passer bedre mht context- awareness

Løsningen innebærer Det distribuerte, mobile systemet behandles som en ”økonomi” for konfliktløsning Mellomvare tar imot bud som på auksjon og det vinnende budet får hjelp med den QoS forespurt Mer om dette utover…

Den refleksive modellen 1 Nøkkel: deler av mellomvaren eksplisitt og aksesserbar fra applikasjonen gjennom ”reification” Applikasjoner kan da utføre  Introspeksjon (dynamisk inspisere mellomvare oppførsel)  Adaptering (dynamisk endre mellomvare oppførsel) Prosessen der deler av systemet endres eller overskrives, kalles absorpsjon CARISMA er et system med slik kapabilitet

Den refleksive modellen 2 Bruk av applikasjonsprofiler for å avgjøre hvilken policy som kan brukes i nåværende kontekst Bruk av refleksiv API for å la applikasjoner se sin profil og endre/slette denne Den refleksive API’en gjør altså at applikasjonene kan endre oppførsel hos mellomvaren! Utgangspunkt for slik endring kan være brukerpreferanser

Konflikthåndtering To grunnleggende konflikter kan oppstå  Intraprofil konflikt En konflikt finnes inne i en applikasjons profil som kjører på en gitt enhet. Denne konflikten gjelder bare en instans av mellomvaren (lokal)  Interprofil konflikt En konflikt finnes mellom applikasjoners profiler som kjører på flere enheter. Altså er feilen distribuert mellom instanser av mellomvaren. Spesialtilfelle: ”N-on-1” = konflikt mellom applikasjoners profiler som kjører på samme enhet

Krav (Requirements) Dynamicity (dynamiskhet?)  Konflikter kan ikke løses statisk (kompleks oppgave = eksplosjon i kontekstinformasjonen som må sjekkes)  …mange grunner til dette følger… Simplicity (enkelhet)  Enkel i den forstand at konfliktløsningen ikke krever mye av ressurser som det allerede er mangel på i mobile enheter Customization (tilpasning)  Mellomvare trenger hjelp fra applikasjonene under konfliktløsing siden den ikke vet hvor viktig forskjellige utførelser av ”policies” er for dem (applikasjonene)

Mikroøkonomisk prosess Auksjonsprotokoll  N agenter (applikasjoner) gjør bud på P alternativer (”policies”). Auksjonisten (mellomvaren) velger løsningen med høyest sum på budene. …veldig detaljert utførelse av auksjonsprosessen følger…

Utnyttelsesfunksjon Brukere må få være med på konfliktløsning (de er de eneste som vet hva som ønskes og hva det fører til) Her kommer utnyttelsesfunksjon inn  Tillater brukeren å angi bud på ”policies” (for å oppfylle ønsket mål)  Utnyttelsesfunksjoner er dynamiske, ”policy”- spesifikasjoner er statiske Oppfyller kravet ”customization”

Utnyttelsesfunksjon (en del detaljtemaer) 4.3 Kvoteallokering 4.4 Konferanseapplikasjonen 4.5 Intraprofil konflikt: Talepåminner (?) 4.6 Interprofil Konflikt: Sende meldinger … veldig mye om detaljer rundt hvordan ting skjer i praksis – like greit å pugge på egenhånd om ønskelig…

Evaluering (ytelse og brukbarhet) 1 Ytelse  … først masse vås om hardware…  Måling basert på 20 tjenesteforespørsler Effekt av refleksjon  Lineær økning i overhead Effekt av kontekst oppmerksomhet  Pga eksponentiell vekst i sammenligninger mellom nåværende kontekst og assosiasjoner i profilen, har vi skalerbarhetsgrense på 10 ”policies” med 5 kontekster hver med 10 ressurser per kontekst  Vanskelig å nå denne grensen ifølge artikkel… (vel…?)

Evaluering (ytelse og brukbarhet) 2 Effekt av konflikter  Liten effekt i praksis på ytelse i CARISMA  Pga overhead er det best å ha minimal kontekst konfigurasjon og heller overlate problemene til auksjonssystemet Effekt av distribusjon  Konstant overhead selv ved økning av enheter

Evaluering (ytelse og brukbarhet) 3 Brukbarhet  Målt ved å bygge konferanseapplikasjonen  …mange detaljer ved implementasjonen…  Sluttbrukerens innsats for å lære opp systemet til å gjøre som ønsket kommer an på applikasjonens tilpasningsdyktighet  Problemene er ikke unike for CARISMA – de oppstår generelt der tilpasning til kontekst og brukerkrav er sentralt

Konklusjon Trenger mellomvare som støtter kontekst oppmerksomhet og tilpasning Om CARISMA løsningen og dens måte å bruke mikroøkonomiske prinsipper til å løse problemer (auksjonssystemet) …så en del om fremtidig forskning…