Ontwerp en evaluatie van een OSGi en MHP gebaseerde applicatie voor een thuisomgeving van de toekomst

Transcriptie

1 Faculteit toegepaste wetenschappen Vakgroep Informatie Technologie Voorzitter Prof. Dr. Ir. P. Lagasse Ontwerp en evaluatie van een OSGi en MHP gebaseerde applicatie voor een thuisomgeving van de toekomst door Jirka De Kuyper Cédric De Schryver Promotor : Prof. Dr. Ir. B. Dhoedt Thesisbegeleiders : Dr. Ir. F. De Turck, Ir. K. Vlaeminck Afstudeerwerk voor het behalen van de academische graad van licenciaat in de informatica optie informatie en communicatietechnologie Academiejaar

2 Toelating tot bruikleen De auteurs geven de toelating dit afstudeerwerk voor consultatie beschikbaar te stellen en delen van het afstudeerwerk te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit dit afstudeerwerk. The authors and the promoters give the permission to use this thesis for consultation and to copy parts of it for personal use. Every other use is subject to he copyright laws, more specifically the source must be extensively specified when using results from this thesis. Jirka De Kuyper Cédric De Schryver

3 Dankwoord Aan het begin van dit afstudeerwerk zouden we enkele personen van harte willen bedanken voor hun hulp bij het realiseren ervan. Eerst en vooral willen we onze promotoren, Prof. dr. ir. Piet Demeester en Prof. dr. ir. Bart Dhoedt, bedanken voor het ter beschikking stellen van de Atlantis-infrastructuur, voor onze motivatie en voor de regelmatige opvolging van dit eindwerk. Natuurlijk danken we Filip De Turck en Koert Vlaeminck voor de steun, de opvolging, de tips en de uren werk die ze aan ons gehad hebben. Zij waren steeds bereid hulp te verschaffen wanneer we weer eens met de handen in het haar zaten. De Belgacom-medewerkers mogen we ook zeker niet vergeten, voor het aanbrengen van het onderwerp, het bezorgen van het nodige studiemateriaal, de praktische ervaring en vooral om ons dit jaartje opgenomen te hebben in hun hartelijke Belgacom-familie. Vooral Franky Bridelance die ons hielp met de XSARP integratie. In het bijzonder gaat onze dank uit naar onze ouders, die ons steeds onvoorwaardelijk gesteund hebben... En tenslotte willen we al onze lieve vrienden en vriendinnen bedanken voor het aanhoren van ons gezeur en hun trouwe steun. Jirka De Kuyper Cédric De Schryver Mei 2003

4 Ontwerp en evaluatie van een OSGi en MHP gebaseerde applicatie voor een thuisomgeving van de toekomst door Jirka De Kuyper, Cédric De Schryver Afstudeerwerk voor het behalen van de academische graad van licenciaat in de informatica optie informatie en communicatietechnologie Faculteit toegepaste wetenschappen Vakgroep Informatie Technologie Voorzitter Prof. Dr. Ir. P. Lagasse Promotoren : Prof. Dr Ir B. Dhoedt Thesisbegeleiders : Dr. Ir. F. De Turck, Ir. K. Vlaeminck Academiejaar Samenvatting: In dit afstudeerwerk worden OSGi en MHP onder de loep genomen aan de hand van een gelijkaardige applicatie in java geïmplementeerd die voldoet aan hun standaard rekening houdend met hun mogelijkheden en beperkingen. Hiertoe hebben we een client-, provider- en gateway-applicatie ontwikkeld. Er wordt een uitgebreide beschrijving gegeven van de platformen alsook van de implementatie. Tenslotte worden hun prestaties aangetoond aan de hand van testen. Trefwoorden: OSGi, Platform, Multimediarepository, middleware, RMI, interactiviteit, MHP, XSARP, framework, bundles, caroussel, locator, DVB

5 Inhoudsopgave Hoofdstuk 1 Inleiding 1 Hoofdstuk 2 OSGi I Inleiding 6 II Technology Stack Bundels Device Discovery Framework Java Virtual Machine Operating System Hardware 17 III OSGi en HAVi 19 IV Implementatie 20 V Verbeteringen 31 VI Voorbeelden 33 Hoofdstuk 3 MHP I Inleiding 35 II Technology Stack Applicaties Inleiding MHP-talen Profiles ClassLoaders Tabellen System Software Inleiding API Transport Protocols Locators Application Manager Resources Hardware MPEG - processing and Graphics I/O Devices 60 III Werking van MHP 61 IV Implementatie 4.1 Multimediarepository MHP en HAVi 67 V Voorbeelden 67 Hoofdstuk 4 XSARP 70

6 Hoofdstuk 5 Performantiemetingen I OSGi implementatie 74 II MHP implementatie 77 III XSARP implementatie 78 IV Resultaten 79 Hoofdstuk 6 Reality TV 84 Hoofdstuk 7 Besluit 90 Afkortingen 92 Referenties 95 Bijlage A Installatie 96 Bijlage B Compilatie 99 Bijlage C SHOUTcast 101 Bijlage D JAMon 102 Bijlage E Inhoud van de cd-rom 105 Bijlage F Metingen 106

7 Lijst van figuren Figuur 1: huidige situatie 1 Figuur 2: gewenste situatie 2 Figuur 3: het interactieve huis 3 Figuur 4: OSGi technology stack 8 Figuur 5: lifetime cycle 9 Figuur 6: driver detection 14 Figuur 7: hardware 18 Figuur 8: shoutcast configuratie 21 Figuur 9: shoutcast configuratie 2 22 Figuur 10: XML 26 Figuur 11: opstelling 27 Figuur 12: verbeterde opstelling 31 Figuur 13: technology stack 38 Figuur 14: opdeling applicaties 39 Figuur 15: Xlet state diagram 41 Figuur 16: applications area's and profiles 42 Figuur 17: class loaders 44 Figuur 18: tabel structuur 45 Figuur 19: events voor een service 46 Figuur 20: interaction channel protocol stack 48 Figuur 21: caroussel 49 Figuur 22: statische caroussel 50 Figuur 23: dynamische caroussel 50 Figuur 24: PID 52 Figuur 25: implementation 57 Figuur 26: hardware vereisten 58 Figuur 27: GOP 59 Figuur 28: werking transmissie MHP applicatie 61 Figuur 29: multimediarepository in MHP 65 Figuur 30: opstelling multimediarepository voor MHP 66 Figuur 31: the Quiz 68 Figuur 32: integratie in XSARP 71 Figuur 33: XSARP integration 73 Figuur 34: communicatie in OSGi implementatie 75 Figuur 35: communicatie voor MHP implementatie 78 Figuur 36: communicatie voor de XSARP implementatie 79 Figuur 37: tonen van content 80 Figuur 38: tijd tussen opvragen en effectief afspelen 81 Figuur 39: tijd tussen de aanvraag en terug gewekt worden 83

8 Hoofdstuk 1 Inleiding Het huis van de Jetsones met zijn supermoderne inrichting en tools is niet meer zover weg als sommigen wel denken. Maar hoewel de technologie rijp is, blijven de interactieve diensten meestal nog toekomstmuziek. Het knelpunt is meestal geld: de kost van de applicaties voor een specifiek apparaat liggen meestal te hoog en bedrijven zouden hun diensten niet of met verlies moeten verkopen. Een duidelijk voorbeeld vinden we bij betaaltelevisies; naast de grote kost van uitzendrechten, kampen dezen nog met het probleem dat hun applicaties geschreven zijn voor een bepaalde set-top box. Deze situatie staat geschetst in figuur 1. Elke provider heeft zijn applicaties, zijn eigen specifieke API en een specifiek platform. Wanneer deze providers een nieuwe dienst willen aanbieden aan hun klanten, zijn ze volledig overgeleverd aan de onbarmhartige handen van de programmeurs die hun machtspositie maar al te graag uitbuiten. Ze kunnen niet gemakkelijk overschakelen naar andere systemen omdat dan al hun reeds bestaande diensten geherprogrammeerd moeten worden. Het hoge prijskaartje van de applicaties wordt dan natuurlijk doorgerekend aan de consument. Figuur 1: huidige situatie - 1 -

9 Deze situatie was onhoudbaar, de te hoge kosten beperkten het succes van o.a. interactieve diensten. Daarom werd er gedacht aan een platformonafhankelijke open standaard. Bovenop de reeds bestaande apparaten wordt er een middleware geïnstalleerd die deze standaard begrijpt en het nodige kan doen zodat alle diensten effectief kunnen uitgevoerd worden. Dit zal een gunstig effect hebben voor zowel provider als consument: de provider zal zijn interactieve diensten kunnen kopen van verschillende concurrerende bedrijven, langs de andere kant zal de consument kunnen kiezen tussen een groter aantal set-top boxen (STB) die op hun beurt goedkoper zullen zijn, doordat de hardware om interactieve diensten te tonen dan in massa geproduceerd kan worden. Dit ideale beeld wordt weergegeven in figuur 2. Dezelfde service-providers als in figuur 1 zijn te zien maar nu is er maar 1 API die elke service kan accepteren en aan eender welke STB kan aanbieden. Figuur 2 : gewenste situatie Jammer genoeg loopt het definiëren van een standaard ook niet zoals gewenst; met andere woorden er bestaat nog niet zoiets als één standaard; wel meerdere. In deze thesis hebben we de grootste eruit genomen nl. OSGi en MHP. Deze twee hebben hetzelfde doel; nl. zoals hierboven reeds vermeld, een open standaard definiëren, maar ze zijn wel van een verschillend startpunt vertrokken

10 MHP levert, vanuit zijn DVB-achtergrond een standaard voor interactieve diensten op STB s voor digitale televisie terwijl OSGi netwerkgebaseerde services in het algemeen beheert en dus een standaard voor HomeGateways definieert. Figuur 3: het interactieve huis Hoewel ze van een andere invalshoek zijn vertrokken evolueren ze beiden in dezelfde richting. OSGi situeert zich meer in het domein van de domotica, terwijl MHP verder bouwt op interactieve televisie. Hoe verhouden deze twee zich dan ten opzichte van elkaar? Een MHP compatibele STB kan aan een OSGi gateway gekoppeld worden en perfect werken. Anderzijds is MHP, net als OSGi, een open standaard en zijn functionaliteit zou dus in principe kunnen uitgebreid worden tot een coördinator van het interactieve huis. Een standaard definiëren is één, een markt creëren is wat anders. Service providers hebben reeds lang hun standaard gekozen en willen compatibel blijven met honderdduizenden STB s die ze verhuren aan hun klanten. Een voorbeeld hiervan vinden we bij canal+ die een deel van zijn applicaties 2 maal - 3 -

11 uitzendt, nl. één keer compatibel met de MHP standaard en één keer met zijn specifieke MediaHighWay- protocol. Wij zullen doorheen dit afstudeerwerk de lezer eerst vertrouwd maken met OSGi en MHP. Daarna wordt een beschrijving gegeven van de opstelling die in elk van de standaarden geïmplementeerd werd om af te sluiten met een bespreking van de prestatie-resultaten. Het afstudeerwerk is als volgt opgedeeld: Hoofdstuk 1: Inleiding Hoofdstuk 1 vormt de inleiding van dit afstudeerwerk. Normaal gezien hebt u deze net gelezen. Hoofdstuk 2: OSGi Na een stukje geschiedenis over het ontstaan van OSGi, wordt de lezer vertrouwd gemaakt met de standaard, alsook met de technologiestack en de automatische detectie van services. Ook willen we de lezer aantonen waar er nog knelpunten zitten in de huidige OSGi implementatie van de huidige OSGi versie. Hoofdstuk 3: MHP In dit hoofdstuk krijgt de lezer het concept van interactieve televisie te verwerken, geïmplementeerd in MHP. Er wordt een duidelijk beeld gegeven over de werking van MHP, de aflevering van informatie, het coderen, zijn toepassingen, zijn sterktes en zwaktes. Tenslotte ook nog een woordje over de multimediarepository voor MHP. Hoofdstuk 4: XSARP Tot slot wordt de probleemstelling en implementatie van de multimediarepository uitgelegd, met zijn variant geïmplementeerd voor de plugin factory van Belgacom XSARP Hoofdstuk 5: Performantie metingen - 4 -

12 Na deze theorie komen er praktische resultaten: hoe goed zijn deze platformen wel, hoe presteren ze ten opzichte van elkaar? In dit hoofdstuk worden een aantal performantiemetingen gedaan. Hoofdstuk 6: Reality tv Natuurlijk bestaan er nog andere standaarden dan MHP en OSGi. Hoe worden ze onthaald, waar worden ze gebruikt, wat zijn de problemen? Hoe wordt MHP in de praktijk gebruikt? U snapt het al: in dit hoofdstuk willen we van de theoretische kant af en de realiteit onder ogen zien. OpenTv, DreamTV, IO, MediaHighway, indien deze namen u niets zeggen, wordt u dringend verzocht Hoofdstuk 5 van buiten te leren. Hoofdstuk 7: Besluit Rekening houdend met het gehele onderzoek, welke zijn de voor- en nadelen die de nieuwe concepten met zich meebrengen? Is de vernieuwing lof waard? Bijlagen: Hierin bevindt zich de gebruiksaanwijzing voor het ontwikkelen en uitvoeren van de applicaties. Informatie over JamonAPI, shoutcast, singleton classes,... kortom alle tools die gebruikt werden voor het realiseren van dit eindwerk en die een extra woordje uitleg vragen staan hier uitvoerig beschreven

13 Hoofdstuk 2 OSGi I. Inleiding Zoals reeds in de inleiding aangehaald, was er nood aan een gemeenschappelijk platform dat op een gestandaardiseerde manier kan worden aangesproken zodat er een mogelijkheid is om zelfde applicaties te gebruiken voor verschillende eindgebruikers. Een groep fabrikanten waaronder Ericsson, IBM en Oracle stichtten de Connected Alliance om deze standaard te definiëren. Oorspronkelijk was het de bedoeling dat deze aan het Java Community Process (JCP) zou toebehoren maar in de Intellectual Property Rights (IPR) staat dat alle belangen eigendom van Sun worden wanneer een standaard een Java-standaard wordt. Dat IBM hier niet blij mee was, is dan ook geen verrassing. Daarom besloot de Connected Alliance zelf een organisatie rond hun standaard te creëren nl. OSGi; dit staat voor Open Service Gateway interface. In mei 2000 kwam de eerste versie uit. OSGi is een framework dat toelaat om dynamische code op te laden en uit te voeren en dit in een open, gemeenschappelijke IP-gebaseerde architectuur voor zowel wide-area netwerken als lokale netwerken. De code is geschreven in Java, dat door zijn platformonafhankelijkheid ideaal is voor deze taak. Het framework vereist niet veel geheugen en kan dus probleemloos op een residentiële gateway draaien. De services die kunnen draaien op het framework, worden aangeboden als aparte modules, als componenten die naast elkaar staan en elkaar kunnen gebruiken. De toegang tot de componenten gebeurt via interfaces zodat de implementatie verborgen blijft. Dit is vooral van belang omdat verschillende apparaten via bepaalde services misschien wel dezelfde functionaliteit aanbieden maar intern toch de data anders gaan verwerken

14 Het handige aan services is dat ze dynamisch kunnen worden geïnstalleerd, gestart en gestopt. Er wordt dus een geheel nieuwe categorie gecreëerd van slimme devices dankzij een flexibele gecontroleerde ontwikkeling van deze services. De services worden doorgestuurd door de OSGi service gateway in de vorm van bundels naar het framework waar ze worden geïnstalleerd en uitgevoerd in een welgedefinieerde omgeving. Om deze bundels op te vangen wordt elk huis voorzien van een unieke virtuele service gateway. Deze service gateway is een applicatie van dewelke services kunnen gedownload worden en naar dewelke er ook services kunnen geupload worden. Op deze manier kunnen verschillende services met elkaar communiceren en kunnen verschillende terminals toegang hebben tot dezelfde service zonder dat ze er elk een aparte device voor nodig hebben. II. Technology stack OSGi is ontwikkeld om een veilig gebruiksvriendelijke omgeving te creëren voor zowel gebruiker als developer. Om dit te bereiken zijn o.a. volgende doelen nagestreefd: Gestandaardiseerd: elke component kan door een ander bedrijf worden gemaakt, daarom moeten de componenten goed gedefinieerd en vervangbaar zijn. Platformonafhankelijk: OSGi produceert middelware, welke platformonafhankelijk is; OSGi software kan dus geïmplementeerd worden op verschillende types van residentiële gateways. Open en schaalbaar: de technologie mag geen absolute of specifieke vereisten hebben voor de services of protocols. Ze moet dus ook onbeperkt uitbreidbaar zijn Veilig en hoge integriteit: OSGi biedt verschillende niveaus van system security aan waaronder digitale handtekeningen en object acces control. Device acces specifications: OSGi-platformen moeten administratie vanop afstand ondersteunen

15 Figuur 4 : OSGi technology stack Om de werking van OSGi goed te begrijpen, zullen we in de volgende paragrafen de opeenvolgende delen van de technology stack bespreken zoals weergegeven in figuur 4. Tegen de traditie in, bespreken we hem van boven naar onder omdat het gemakkelijker is om uit te leggen en om het geheel te vatten. Dit heeft ook het voordeel dat u vertrekt van wat u kent en waarmee u dagelijks zal omgaan, nl. de effectieve applicaties, nadien kan u verder spitten en uitzoeken wat er achter zit. 2.1 Bundels Services bieden zich aan onder de vorm van bundels. Een bundel is een jar-file die gegevens bevat om 1 of meerdere services te implementeren alsook de nodige class-files en data. Deze bundels kunnen worden opgeladen en moeten dan geïnstalleerd worden in het framework. Eens ze geïnstalleerd en geregistreerd zijn, zijn de services beschikbaar voor andere bundels. Het installeren en registreren van een dienst is de taak van de Activator. Deze is ook degene die methodes kan aanroepen om een bundel te starten of te stoppen. De Activator krijgt bij het starten van een bundel een speciaal object mee nl. een bundlecontext. Via deze bundlecontext kan de bundel contact krijgen met het - 8 -

16 framework en andere diensten. Zo kan hij refereren naar andere services, services registreren, persistente opslagruimte bekomen, nieuwe bundels starten,... De servicespecifieke informatie zit vervat in de Manifest file. Deze informatie kan worden opgevraagd en doorgegeven. Verder bevat de jar-file nog native code, java-code, service implementatie, resources en java-packages om te exporteren naar andere bundels. Als een applicatie dan effectief gebruik wil maken van een service, dan zeggen we dat de applicatie dynamisch zal afhangen van die service. Het framework (zie paragraaf 2.2) zal deze dynamische afhankelijkheid bijhouden en zal de applicatie de mogelijkheid geven de service graceful vrij te geven, mocht deze services plots beëindigd worden. Ook Lifetime cycle management (zie figuur 5) is voorzien, zodat bundels kunnen verwijderd worden wanneer ze niet meer gebruikt worden, opnieuw wordt dit geregeld door de activator. Hij zorgt er ook voor dat bundels kunnen worden geüpdatet zonder het gehele systeem te blokkeren. Dit gebeurt als volgt: eerst wordt de nieuwe bundel gedownload. Als deze actief wordt, wordt de oude bundel gestopt en zijn data wordt bewaard. Met deze data wordt de nieuwe bundel geactiveerd. De oude bundel wordt verwijderd. De java-packages geëxporteerd door de oude jar-file blijven wel actief tot het framework herstart wordt of tot de package administration service opgewekt wordt en een refresh afdwingt. Figuur 5: lifetime cycle - 9 -

17 2.2 Device discovery framework Het OSGi framework is de kern van het OSGi service platform. Het is de middleware tussen de OSGi bundels ( applicaties ) en de service gateway. Zijn grootste voordeel is het feit dat hij ervoor zorgt dat verschillende applicaties eenzelfde Java Virtuele Machine ( JVM ) kunnen delen. Het framework heeft een gelijkaardige relatie met de JVM als het besturingssysteem met de hardware. Als er iemand aan de deur aanbelt dan willen we de deur kunnen openen. Hoe weet het framework dat hij een applicatie moet openen die de deur, indien gewenst, kan openen en niet de ramen openzet of de lichten aansteekt? We willen dat, wanneer een applicatie een dienst vraagt, ze niet zelf op zoek moet gaan naar apparaten. Hierbij is niet het merk van het apparaat of het type van belang maar wel de actie die hij kan uitvoeren en eventueel de eigenschappen die het apparaat heeft. In grote lijnen kan deze probleemstelling als volgt beschreven worden: 1. een device komt online 2. de base driver OSGi device acces detecteert dit en registreert het device 3. het framework probeert een algemene beschrijving (aan de hand van kenmerken en eigenschappen van het device) op te stellen en houdt deze bij 4. de applicatie vraagt aan het framework naar een geschikt apparaat voor zijn gewenste service 5. het framework vergelijkt vraag en aanbod en geeft de beste/meerdere match(es) terug Het eerste deel is triviaal; een device komt online, wordt gedetecteerd en geregistreerd als een beschikbaar device. OSGi bevat reeds een raamwerk voor het detecteren van devices. Maar dan komt de vraag van de client naar een service of een apparaat voor een bepaalde service. Er moet dus gekeken worden naar de noden van deze service. Het framework zal nood aan diensten en aanbod van apparaten vergelijken en een match terug geven

18 Om de juiste dienst te kunnen bezorgen moet er een beschrijving zijn van diensten die kunnen vergeleken worden met de vraag van de service. De vraag van de applicatie is eigenlijk niets anders dan een kernachtige beschrijving van wat de dienst moet kunnen. Typenummers, identificatiecodes, serienummers van apparaten,... zijn handig om een apparaat te vinden maar meestal heeft de essentie van een dienst niets te maken met de fabrikant ervan. Wat de applicatie en de gebruiker nodig hebben is een kernachtige omschrijving van wat de dienst moet kunnen. Een applicatie kan afhankelijk van zijn context op verschillende manieren beschreven worden en gebruikt. Bvb een televisie dienst om beeld weer te geven: audio, sound, video, film een teletekst te kunnen opzoeken HAVi-tuner Deze eigenschappen volgen gemakkelijk uit de aard van het apparaat; een device met luidsprekers is een mogelijke kandidaat als u muziek wilt afspelen. Voor het framework zijn dit eigenschappen die het gemakkelijk kan te weten komen. Maar er zijn ook een groot aantal praktische eigenschappen voor ons als gebruiker die het framework niet zomaar kan achterhalen, zoals de plaats waar het device zich bevindt. Hiervoor heb u een open beschrijving nodig die veel verder gaat. Intuïtief kunt u van volgende kenmerken vertrekken om een zo open mogelijke apparaatbeschrijving te bekomen: een basisconcept : waarover handelt de dienst een of meerder acties, handelingen : wat kan er met het basisconcept worden gedaan? extra eigenschappen: welke zijn de details van de dienst? Meer bepaald zouden hier de volgende zaken in kunnen worden opgenomen: plaats: waar moet de dienst worden geleverd? Dit is een speciale eigenschap die niet uit de dienst zelf kan gehaald worden. In het

19 kader van device discovery is het wel een nuttige eigenschap, want elk apparaat in verbinding met de residentiële gateway heeft wel zijn locatie. Een uitzondering hierop zouden draadloze apparaten; of beter gezegd ze hebben een locatie die willekeurig vaak verandert en de gebruiker zal er niet voor kiezen om elke keer hij zijn toestel van kamer verandert het framework te verwittigen. Maar hoe worden de locaties benoemd, kent uw homegateway het woord keuken? Meer nog; u kunt niet van het framework verwachten dat hij elke kamer sowieso kent. Bent u dan verplicht om elke kamer in te geven bij eerste gebruik? prioriteit: aan welke applicaties mag de dienst geleverd worden? En vooral aan welke gebruikers? Deze eigenschap zou kunnen verhinderen dat kinderen de temperatuur van de boiler met 5 graden verhogen. Dit beveiligingsaspect kan zeker nuttig zijn bij het manipuleren van diensten en apparaten. beschikbaarheid: wanneer kan de dienst worden geleverd? Dit zou een eigenschap kunnen zijn die een ja / neen terug geeft maar het nut van een dergelijk eigenschap is eerder beperkt want meer dan een fout generen kan dit niet. Langs de andere kant zou het een soort agenda kunnen zijn die van elke dienst noteert hoelang hij al in gebruik is, welke diensten gereserveerd zijn, welke vrij komen,... maar ook dit is vrij onrealistisch omdat we niet van de gebruiker mogen eisen dat hij elk gebruik van een dienst meedeelt aan het framework. id: een unieke sleutel voor de dienst. Dit is vooral intern interessant als u nog eens gebruik wilt maken van dezelfde dienst. naam: naar de gebruiker toe, is dit misschien wel vriendelijker maar dan zal de gebruiker elk toestel een naam moeten geven en deze aan het framework meedelen en vooral zal hij zich nog alle namen kunnen herinneren?

20 U merkt al dat dit niet zo eenvoudig ligt. Er is dan ook nog veel onderzoek naar beschrijvingen en over hoe men ze moet opstellen. 1 Nemen we het voorbeeld van een televisie terug, met de klassieke beschrijving: Basis concept: entertainment, sound, audio, video, film, movies, television, TV, teletekst, IO Acties: play, enable, disable, mute, set channel, get channel, set volume, stop Eigenschappen: colour, stereo Deze benadering van contexten en beschrijvingen is belangrijk omdat een personal video recorder op deze manier zich kan laten bedienen als een ouderwetse videorecorder. Dit is wat ook al werd aangehaald in de inleiding; beide kunnen dezelfde informatie binnenkrijgen, dezelfde services leveren maar intern de informatie anders verwerken zodat de personal video recorder een meer gesofisticeerde layout heeft dan de oude videorecorder. De volgende vraag is: waar worden al deze beschrijvingen opgeslaan, wie zal vraag en aanbod vergelijken en acties genereren zodat de gewenste instructies worden uitgevoerd en vooral hoe zorgen we ervoor dat de informatie consistent blijft? Hier kunnen we twee oplossingen suggereren: 1. een applicatie moet bij elke dienst die hij zoekt de gegevens van de dienst presenteren en zelf voor de matching zorgen. 2. de residentiële gateway houdt de beschrijvingen bij een vergelijkt zelf de gegevens. De tweede oplossing is sneller maar het probleem dat zich hier kan stellen is het veranderen van een beschrijving. Meestal zal de aard van de dienst niet veranderen, hoogstens een upgrade. Maar de eigenschappen kunnen wel veranderen bvb een videorecorder met een schrijfbeveiligde tape. 1 Voor onderzoek over eigenschappen formuleren van devices, verwijzen we naar het eindwerk en doctoraatswerk van A. Wils

21 Eens er consequente beschrijvingen opgesteld zijn, kan er aan de selectie begonnen worden. Het selecteren bestaat uit het bekijken van de eigenschappen van de applicatie, het vergelijken van dezen met deze van de devices en het teruggeven van al degene die matchen. Dit matchen gebeurt met een puntensysteem zoals getekend in figuur 6. Aan eigenschappen worden punten toegekend qua belangrijkheid. Het device dat de meest belangrijke eigenschappen heeft, zal uiteindelijk ook de hoogste score hebben en zal worden teruggeven, het is dit apparaat dat geselecteerd zal worden voor het effectief uitvoeren van de dienst, indien het beschikbaar is natuurlijk. Indien dit geen resultaten oplevert kunnen we nog een poging doen door de context van de service en het device te vergelijken: hoewel uw computer en uw gsm niet dezelfde eigenschappen hebben kunt u surfen ( wappen ) met uw gsm (zij het in beperkte mate). Als ook dit niet lukt, dan heeft het geen zin om diensten terug te geven, ze zullen toch onbruikbaar zijn voor de applicatie; uw bad zal nooit koffie kunnen zetten ook al stroomt er warm water uit het kraantje omdat uw bad niet de eigenschappen heeft van een koffieapparaat en ook hun contexten niet overeen komen. Als een apparaat wordt geselecteerd dan zal zijn status moeten veranderd worden naar onbeschikbaar zodat er geen conflicten kunnen optreden. Eens de dienst niet meer nodig is, kan het apparaat weer gekozen worden. Figuur 6: driver detection

22 Het is de bedoeling dat er op elk moment apparaten kunnen in- en uitpluggen maar het systeem moet ook kunnen omgaan met diegene die geen automatische detectie van apparaten ondersteunen. Er zijn stuurprogramma s (drivers) verantwoordelijk voor de representatie van een apparaat in het OSGi-framework. Een speciale categorie van drivers zijn diegene die de aanwezigheid van apparaten buiten het framework kunnen detecteren (bvb door verwittiging van een device-driver in eigen code). Een andere categorie die base-drivers genoemd worden, registreren dan een eerste voorstelling van een device bij het framework. Een voorstelling van een device is dus eigenlijk niets anders dan een geregistreerde dienst die een interface device implementeert. Verder zijn er ook stuurprogramma s die vertrekkend van een device een meer verfijnde voorstelling van een apparaat registreren en die interface driver genoemd worden. Daarnaast bestaan er ook nog device managers die interacties tussen devices en drivers coördineren en een reeks driver locators die nieuwe drivers kunnen downloaden. Deze apparaatstuurprogramma s moeten kunnen geladen worden zonder dat er enige kennis is van het apparaat. De interface van het apparaat is volledig gescheiden van waar en de wijze waarop het is aangesloten. Een programma is bvb niet geïnteresseerd hoe zijn internetverbinding tot stand komt; met kabel of ADSL maar een ADSL-modem wil wel PPP-specifieke gegevens krijgen. OSGi ondersteunt daarom meerdere voorstellingen van een apparaat en scheidt de interface van een device van de manier waarop het aangesloten is. Wanneer een onbekend HAVi apparaat zich aanmeldt, kennen we noch zijn API, noch zijn specifieke eigenschappen. Eens het apparaat geselecteerd is, verwacht de gebruiker er bepaalde services van. De nodige services kunnen bekomen worden door in het framework een service referentie op te zoeken. Dit opzoeken gebeurt met behulp van een ServiceTracker: deze zoekt een set services die overeenstemmen met de zoekcriteria. De referentie van de service ( opgeslagen in een set ) wordt gebruikt om de eigenlijke service te halen. Het opgehaalde service object wordt gecast naar het geschikte Java type

23 Dit gecaste service object zal de gevraagde methodes leveren die nodig zijn om de service-vraag te vervullen. Nu de service gehaald is, heeft de bundel een service listener nodig om op de hoogte te blijven van de toestand van de service ( een service kan bvb. onverkrijgbaar worden, als de bundle niet op de hoogte is van de toestand van de service zou hij een vervallen service kunnen gebruiken ). Hierboven werd er van algemene services gesproken maar men kan evengoed gebruik maken van een service factory die voor elke request bundle een verschillende ( custom made ) service terug geeft. Natuurlijk hoeft het niet bij één service te blijven, er kunnen ook een reeks van acties ondernomen worden op verschillende apparaten die elkaar opwekken. Stel dat u een ochtend programma heeft dat om 7.30 de badkamer begint op te warmen, om 8:00 moet deze applicatie op zoek gaan naar een apparaat dat muziek kan weergeven want u wilt met een zacht deuntje wakker worden en ook naar eentje dat koffie zet. Nu moet het ochtendprogramma te weten komen tot welke netwerken hij toegang heeft, welke apparaten er zich in bevinden, welke beschikbaar zijn en of hij ze kan aansturen. Hij moet zowel in staat zijn om een Philips -machine als een Krups of een Siemens aan te sturen. Nu is het apparaat geselecteerd, maar een apparaat selecteren is natuurlijk iets anders dan de effectieve actie; een koffieapparaat vinden is gemakkelijker dan koffie zetten. De actie zet koffie moet uitgevoerd worden. Het is de bedoeling om het framework de juiste actie te laten kiezen, de parameters correct te laten interpreteren, te vertalen en het juiste bevel te geven aan het correcte apparaat. Het grote knelpunt is het doorgeven van de informatie. Momenteel zijn er in OSGi slechts twee mogelijkheden: ofwel draait er een device discovery bundel die voor een dienst het beste apparaat zoekt en de informatie aan deze levert; in het andere geval wordt de informatie gegeven aan het device dat de service vroeg ongeacht of deze ze kan representeren. Vandaar het belang van het beschrijven van apparaten en services maar zoals u zelf hebt kunnen aanvoelen, is dit niet zo voor de hand liggend