Jini en OSGi, teamspelers of rivalen

Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: Prof. Dr. Ir. P. Demeester

Academiejaar 2004–2005

Jini en OSGi, teamspelers of rivalen

Tom Van den Steen

Promotor: Prof. Dr. Ir. F. Gielen Scriptiebegeleider: Lic. N. Goeminne

Scriptie voorgedragen tot het behalen van de graad van burgerlijk ingenieur in de computerwetenschappen

Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: Prof. Dr. Ir. P. Demeester

Academiejaar 2004–2005

Jini en OSGi, teamspelers of rivalen

Tom Van den Steen

Promotor: Prof. Dr. Ir. F. Gielen Scriptiebegeleider: Lic. N. Goeminne

Scriptie voorgedragen tot het behalen van de graad van burgerlijk ingenieur in de computerwetenschappen

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie 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 deze scriptie.”

Tom Van den Steen, mei 2005

Woord vooraf Toen ik vorig jaar in augustus aan mijn scriptie over Jini en OSGi, teamspelers of rivalen, begon, wist ik nauwelijks wat er achter beide termen schuilging. Jini en OSGi konden toen, bij wijze van spreken, nog even goed twee striphelden zijn, die eerst onderling nog moesten uitmaken met of tegen elkaar te zullen gaan vechten. Mijn zoektocht in hun beider literatuur bracht echter verheldering en maakte duidelijk dat het twee architecturen waren die in staat waren samen te werken. De ontwikkeling van een geschikte architectuur en de implementatie ervan bleek een hele opdracht en verliep vaak niet zo vlot, maar uiteindelijk bekwamen we een werkende toepassing. Ik leerde dit jaar dan ook enorm veel bij, zowel over mezelf als over de verschillende toegepaste technologieën. Dit alles zou echter niet gelukt zijn, zonder dat ik kon rekenen op de hulp, wijze raad en steun van enkele personen. Ik wil dan ook een aantal personen bedanken: • Prof. dr. ir. F. Gielen voor de begeleiding en promotorschap. • Lic. N. Goeminne voor de dagelijkse thesisbegeleiding. Nico wil ik in het bijzonder bedanken voor de vele keren dat hij me met raad en daad bij stond. • Elke voor haar steun en liefde. • Mijn familie en vrienden voor hun steun en begrip.

Tom Van den Steen Gent, 29 mei 2005

ii

Jini en OSGi, teamspelers of rivalen door Tom Van den Steen Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2004–2005 Promotor: Prof. Dr. Ir. F. Gielen Scriptiebegeleider: Lic. N. Goeminne Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Onderzoeksgroep Breedbandcommunicatienetwerken Voorzitter: Prof. Dr. Ir. P. Demeester

Samenvatting De hedendaagse gebruiker beschikt steeds meer over een diversiteit aan toestellen en apparaten die enige intelligentie bevatten en uitgerust worden met zowel een verwerkings- als een communicatie-eenheid. Deze toestellen kunnen voortaan netwerken vormen om samen te werken om grotere en complexere diensten aan te bieden. De organisatie en het beheer van deze ’home’ netwerken is echter veel complexer dan deze van een vast netwerk. Er bestaan al protocollen voor het automatisch detecteren en configureren van toestellen die niet echt tot een vast netwerk behoren, hiervan is Jini een voorbeeld. Software geschreven voor dergelijke netwerken zal bovendien sterk afhankelijk zijn van de aanwezige apparaten en beschikbare diensten in het netwerk. Er bestaan echter technologieën die het mogelijk maken om zeer dynamisch programma’s te installeren en te beheren, waaronder het OSGi-platform een heel aantrekkelijke speler is. In dit eindwerk wordt de compatibiliteit en de complementariteit van Jini en OSGi onderzocht. Dit gebeurt aan de hand van de ontwikkeling en implementatie van een Jini Driver service, verpakt als OSGi-bundel, en de uitwerking van een testcase.

Trefwoorden OSGi, Jini, Java, Jini Driver service

iii

Inhoudsopgave 1 Inleiding

1

1.1

Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.4

Doelstellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2 Gebruikte technologie 2.1

2.2

4

Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

Wat is Jini? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Hoe werkt Jini? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.3

Waarom Jini gebruiken? . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.1

Wat is OSGi? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.2

Hoe werkt OSGi? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2.3

Waarom OSGi gebruiken? . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.4

OSGi-implementaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3 Functionele vereisten

16

3.1

De Jini Driver service als OSGi-bundel . . . . . . . . . . . . . . . . . . . . . . . .

16

3.2

Services ontdekken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3.3

Exporteren van OSGi naar Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

3.4

Importeren van Jini naar OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4 Architectuur

20

4.1

De Jini Driver service starten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.2

De Jini Driver service stoppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

iv

Inhoudsopgave

4.3

Exporteren van een OSGi service in Jini . . . . . . . . . . . . . . . . . . . . . . .

22

4.4

Importeren van een Jini service in OSGi . . . . . . . . . . . . . . . . . . . . . . .

23

4.4.1

Jini-bewuste aanvragende bundel . . . . . . . . . . . . . . . . . . . . . . .

23

4.4.2

De onbewuste aanvrager . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

Toevoegen en wegvallen van LUS . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

4.5

5 Implementatie

27

5.1

Exporteren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

5.2

Importeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

5.3

Codebase versus security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.3.1

Probleem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.3.2

Alternatieven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.3.3

Oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5.4

Identieke exportklassen

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.5

Verschillende scenario’s

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

5.5.1

Jini Driver service starten . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.5.2

Jini Driver service stoppen . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.5.3

Een service exporteren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.5.4

Een service importeren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.5.5

Toevoegen en wegvallen van LUS . . . . . . . . . . . . . . . . . . . . . . .

41

De functionaliteit in klassen gegoten . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.6

6 Testen en demo

47

6.1

De Jini Driver service testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

6.2

De demotoepassing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

6.2.1

helloservice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

6.2.2

testJiniImport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

6.2.3

Uitvoering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.3

Andere mogelijke toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.4

Voordelen van het gebruik van de Jini Driver service . . . . . . . . . . . . . . . .

57

7 Besluit

61

v

Inhoudsopgave

A Overzicht van Jini’s concurrenten

63

A.1 OpenWings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

A.2 Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

A.3 UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

A.4 Inferno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

A.5 HAVi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

A.6 Ninja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

B Ledenlijst OSGi

67

C Beknopt overzicht van de JiniDriver-bundel

69

C.1 org.knopflerfish.bundle.jini package . . . . . . . . . . . . . . . . . . . . . . . . . .

69

C.2 org.osgi.service.jini package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

D Gebruikte tools

70

E Inhoud van de bijgevoegde CD-ROM

72

Bibliografie

73

vi

Tabel van afkortingen

• API – Application Programming Interface • DHCP – Dynamic Host Configuration Protocol • DNS – Domain Name Server • HAVi – Home Audio Video Interoperability • IIOP – Internet Inter ORB Protocol • JAR – Java Archive • JDK – Java Developer Kit • JVM – Java Virtual Machine • LUS – Jini Lookup Service • OSGi – Open Service Gateway Initiative • RMI – Remote Method Invocation • RPC – Remote Procedure Call • SOAP – Simple Object Access Protocol • TCP/IP – Transmission Control Protocol/Internet Protocol • UPnP – Universal Plug and Play • XML – eXtensible Markup Language

vii

Hoofdstuk 1

Inleiding 1.1

Context

Er bestaat een steeds grotere diversiteit aan toestellen en apparaten. Bovendien bevatten deze steeds meer een verwerkingseenheid en een communicatie-eenheid. Dit maakt het mogelijk dat toestellen, onderling gaan communiceren en in staat zijn samen complexere diensten aan te bieden. De organisatie van deze netwerken is ook complexer dan deze van een vast netwerk. De toestellen worden aan- of uitgezet, worden meegenomen of vervangen.

Figuur 1.1: Homenetwerken bevatten een steeds grotere diversiteit aan toestellen

Alle communicatie-eenheden werken niet volgens éénzelfde protocol. Men komt dus binnen een homenetwerk vaak tot een onderverdeling in verschillende deelnetwerken, die dan onderling verbonden worden via een centrale gateway.

1

Hoofdstuk 1. Inleiding

Alle toestellen beschikken wel elk over hun services die ze kunnen aanbieden aan de andere toestellen in het netwerk. Onder service verstaat men iets waartoe het toestel in staat is of wat het toestel kan betekenen voor een ander toestel in het netwerk. Het opzet is nu dat alle services, over de gateway heen, beschikbaar worden voor alle andere toestellen in het homenetwerk.

Figuur 1.2: Niet alle toestellen gebruiken hetzelfde protocol, waardoor verschillende subnetwerken ontstaan

1.2

Use cases

In de volgende paragrafen beschrijven we enkele mogelijke use cases. • Stel dat men over een Personal Digital Assistant (PDA) beschikt en er zich in huis een zwart-wit printer en een fotoprinter bevinden. De PDA communiceert draadloos met een Access Point op het netwerk in huis. De printers zijn via kabel aangesloten op datzelfde netwerk en bieden een printerservice aan. De PDA gebruiker kan nu dynamisch op zoek gaan naar een service die beantwoordt aan de eisen die een document, dat hij wil printen, stelt aan de printer. Bij het printen van een foto zal bijvoorbeeld automatisch de fotoprinterservice geselecteerd worden. • Stel dat er zich binnen het homenetwerk een wekkerradio en een televisietoestel bevinden. Beiden beschikken ze over een verwerkings- en een communicatie-eenheid. De wekkerradio biedt een klokservice aan, die andere toestellen in staat stelt de klok op te vragen. Vanop het televisietoestel is men nu in staat de service op te vragen en de klok weer te geven op het scherm.

2

Hoofdstuk 1. Inleiding

1.3

OSGi

In deze thesis wordt de gateway ge¨ımplementeerd aan de hand van een Open Service Gateway Initiative Service Platform (OSGi). Binnen dit platform kunnen verschillende bundels geladen en beheerd worden. Er kunnen verschillende bundels ge¨ınstalleerd worden die elk met een specifiek protocol in een deelnetwek overweg kunnen. De bundels vervullen dan een brugfunctie tussen de OSGi gateway en het specifieke subnet. Bovendien zal men van de bundels mogen verwachten dat ze nieuwe deelnetwerken automatisch detecteren en dat de services binnen de deelnetwerken automatisch herkend worden. Meer specifiek zullen we ons toespitsen op de brug tussen de Jini en OSGi technologie: of deze mogelijk is en of we in staat zijn een bundel tussen beiden te ontwikkelen.

1.4

Doelstellingen

De doelstelling van deze thesis zijn samen te vatten in de volgende punten: • Onderzoeken hoe en in welke mate de Jini en OSGi technologieën in staat zijn samen te werken en elkaar aan te vullen. • Beschrijven hoe Jini en OSGi te combineren zijn en eventuele knelpunten aanwijzen en deze eveneens beschrijven. • Een brug tussen beide standaarden ontwikkelen en implementeren. • De opgestelde implementatie testen.

3

Hoofdstuk 2

Gebruikte technologie 2.1 2.1.1

Jini Wat is Jini?

Jini is geen acroniem, maar afgeleid van het Arabische woord voor tovenaar, Jeenee. Jini bestaat uit een netwerkarchitectuur om, gebruikmakend van Java, een schaalbaar, robuust en gedistribueerd systeem op te zetten. Het bestaat uit een geheel van specificaties die het werkingsmodel van een Jini-netwerk beschrijven, alsook de benodigde protocols, klassen, interfaces, diensten en hulpprogramma’s. De Jini-technologie voorziet zo een flexibele infrastructuur voor het leveren van diensten in een netwerk en voor de ontwikkeling van spontane interacties tussen clienten binnen het netwerk die gebruik maken van deze diensten. Doordat dit alles gebeurt op basis van Java, kan dit bovendien gebeuren onafhankelijk van hun software- en hardwarespecificaties. [1] [2] Jini is gebouwd bovenop de stevige basis van de Java netwerktechnologieën1 . Deze technologieën waren reeds vanaf versie 1.0 van de JDK release aanwezig. Jini werd echter pas bruikbaar in de versies 1.2 en hoger. In 1999, ging een team van specialisten die ook meehielpen aan het eerste ontwerp van Java, onder leiding van Bill Joy en Jim Waldo, aan de slag om de Sun-droom Het ” netwerk is de computer” te realiseren. Hun ontwerp en onwikkelingen leidden tot de publicatie van de Jini 1.0 specificaties in 2001 en de 2.0 specificaties in juni 2003. 1

De Java netwerktechnologie omvat onder andere Sockets, RMI (Remote Method Invocation),...

4

Hoofdstuk 2. Gebruikte technologie

2.1.2

Hoe werkt Jini?

De Jini-visie kan eenvoudig als volgt weergegeven worden: Stel dat iemand toekomt in een bedrijf met zijn Jini-enabled toestel, dit zou bijvoorbeeld zijn digitale camera, de nieuwe printer of een PDA kunnen zijn. Hij plugt deze in in het TCP/IP netwerk en automatisch wordt het mogelijk om gebruik te maken van alle andere Jini-enabled toestellen in de buurt. Elke op het netwerk beschikbare bron wordt dan beschikbaar voor het toestel, net alsof deze rechtstreeks met het toestel zou verbonden zijn of net alsof deze expliciet zou geprogrammeerd zijn voor het toestel. Om een apparaat toe te voegen aan de netwerkgemeenschap volstaat het dus het in te pluggen in het netwerk. Evenzeer kunnen nieuwe softwarediensten toegevoegd en verwijderd worden, zonder uitgebreide configuratie en zonder alle apparaten in het netwerk te moeten op punt stellen voor de nieuwe dienst. Nu in het kort geschetst werd wat juist de visie van de Jini-technologie inhoudt, gaan we in de volgende paragrafen wat dieper in op de onderliggende structuur en technologie. Hoe slaagt men er nu juist in om de Jini-visie te bewerkstelligen? Vanuit het Jini oogpunt, zijn alle apparaten, zoals een scanner of printer, als een dienst opgevat. Jini gebruikt expliciet de term dienst om te verwijzen naar een eenheid op het netwerk die door andere Jini-gebruikers kan aangesproken worden. De diensten die deze eenheden bieden kunnen dan bestaan uit een hardware-toestel of een combinatie van toestellen, of een zuivere softwarecomponent of combinatie van componenten. In het verdere verloop van deze scriptie zullen we, wanneer we het hebben over diensten, vaak de engelse term services gebruiken. Toepassingen die gebruik willen maken van de aangeboden diensten, doen dit aan de hand van objecten, proxies genaamd. Deze voorzien in alle nodige code om met een bepaalde dienst te verbinden. Tot op zekere hoogte kan men deze proxies beschouwen als device drivers, aangezien zij het toepassingsprogramma toestaan met een bepaalde dienst te interageren zonder het bloot te stellen aan alle details van de aangesproken dienst. In tegenstelling tot de device drivers, die typisch ge¨ınstalleerd worden door de systeem-administrator alvorens het device te gebruiken, worden de Jini proxies door de diensten zelf gedragen en worden ze dynamisch gedownload naar de client wanneer deze een bepaalde dienst wenst te gebruiken. De toepassingen dienen aldus niet op de hoogte te zijn van de implementatiedetails van de proxies en eveneens dienen

5


de proxies niet op voorhand door de toepassingen gekend, laat staan voorzien, te worden. De proxies verzorgen dan verder de communicatie met de aangesproken diensten, zodat de client zich niet dient te bekommeren over het diensten-specifieke protocol waarin de communicatie gebeurt. Een mogelijkheid om dynamisch proxy-code te downloaden volstaat echter niet. Het eenvoudig dynamisch downloaden zegt immers niets over hoe men in staat is terug te vinden welke diensten er beschikbaar zijn op het netwerk. Jini voorziet daarom in een speciale dienst die alle andere diensten in het netwerk, ook wel de gemeenschap genoemd, bijhoudt. Deze dienst, de lookup service genoemd, is in essentie een meta-dienst die voorziet in de toegang tot alle andere diensten. Wanneer een dienst zich wenst beschikbaar te stellen, dan publiceert hij zijn proxy door deze op te slaan in de lookup service. Clients kunnen dan connecteren met de lookup service en opvragen welke diensten er beschikbaar zijn. De lookup service is onmisbaar binnen de Jini infrastructuur, hij houdt de proxies van de diensten binnen de gemeenschap bij, maakt ze beschikbaar voor clients en is in staat om ge¨ınteresseerde partijen te informeren over het verdwijnen of verschijnen van nieuwe diensten. En ondanks het feit dat deze dienst zo belangrijk is, is het toch maar een gewone dienst met de eigenschappen van elke andere Jini-dienst. Dit leidt echter tot een ander groot probleem: als toepassingen diensten gebruiken door proxies te downloaden van lookup services en deze lookup service zelf een dienst is, hoe komt de toepassing dan aan de proxy van de lookup service? Dit wordt het bootstrapping-probleem genoemd. Het antwoord van Jini hierop is echter eenvoudig en toch krachtig. Jini maakt gebruik van een proces, discovery genaamd, waarbij lookup services en de applicaties die deze willen gebruiken, periodiek berichten uitsturen over het netwerk. Het resultaat is dat de applicatie automatisch de naburige lookup services zal terugvinden en een IP-adres en poortnummer zal ontvangen van waar het de proxy van de lookup service zal kunnen downloaden. Zo zorgt dit protocol er voor dat Jini-diensten uit zichzelf gemeenschappen, communities genoemd, zullen vormen rondom lookup services. De drie zojuist besproken technologieën - proxies, lookup services en discovery - vormen samen het hart van de Jini-infrastructuur, maar zullen op zich niet volstaan om een robuust, gedistribueerd systeem te ondersteunen. Daarom voorziet Jini bovenop deze basis nog enkele technologieën die zullen zorgen voor betrouwbaarheid en detectie van veranderingen binnen het netwerk. We onderscheiden drie grote technologieën die bovenop de basis van discovery en lookup komen.

6


Eerst halen we deze even kort aan, om er nadien wat meer duiding bij te geven: • Leasing vormt de techniek die Jini toepast om aan zelfgenezing te doen. In essentie houdt dit in dat Jini nooit voor altijd toegang zal verlenen tot bepaalde middelen, maar dat de eigenaar van de middelen continu zijn lease zal moeten vernieuwen. • Een remote event systeem wordt voorzien, zodat gedistribueerde systemen met elkaar zullen kunnen communiceren. • Jini ondersteunt een licht distributed transactions”-model opdat bewerkingen in een ” veilige status zouden eindigen. Leasing is gebaseerd op het idee dat, in plaats van toegang tot een dienst toe te staan voor een onbepaalde tijd, de dienst geleend” wordt voor een welbepaalde periode. Jini leases vereisen ” een bewijs van interesse van de gebruiker, opdat deze de dienst verder zou kunnen gebruiken. De Jini leases zijn te vergelijken met deze uit het dagelijkse leven. Jini leases kunnen geweigerd worden door de leasegever. Ze kunnen vernieuwd worden door de bezitter. Ze zullen vervallen op een tevoren vastgesteld tijdstip, tenzij ze vernieuwd worden. Ze kunnen vroegtijdig beëindigd worden en, tenslotte, kan er onderhandeld worden over een lease, maar heeft de leasegever hierover steeds het laatste woord. Met de leasing-technologie voorziet Jini een middel om ongebruikte en onnodige middelen binnen het netwerk vrij te geven. Wanneer een dienst verdwijnt, gewild of ongewild zonder alles achter zich op te kuisen, zullen zijn leases uiteindelijk verlopen en zal de dienst verwijderd worden. Dit maakt het zeer moeilijk om het volledige systeem om zeep te helpen. Door leasing doet het systeem immers aan zelfbehoud, zodat wanneer lease management vergeten wordt, of wanneer een programmeerbug er voor zorgt dat een lease niet vernieuwd wordt, deze onbetrouwbare code automatisch zal verdwijnen uit het netwerk. Bovendien maakt leasing het Jini netwerk quasi onderhoudsvrij. De systeemadministrator zal nooit door de logbestanden dienen te gaan om uit te maken welke diensten er nu actief zijn, welke inactief en welke ijle data er in het systeem verspreid zitten. Remote Events. Jini, net zoals Java, gebruikt events voor asynchronous notifications. Dit laatste zijn berichten die rechtstreeks naar de software component gestuurd worden en die buiten de normale werking van de component behandeld worden. Een event is dan weer een object dat informatie bevat over een externe statusverandering waarin een bepaalde softwarecomponent

7


ge¨ınteresseerd kan zijn. In het Java eventmodel wordt, éénmaal een event is ingevoerd in een systeem, het verzonden naar alle ge¨ınteresseerde componenten die er iets willen van horen. In Jini gebeurt dit op identiek dezelfde manier, maar is het model uitgebreid om overweg te kunnen met gedistribueerde systemen. Er zijn immers enkele belangrijke verschillen tussen het lokaal en het gedistribueerd afleveren van events: • In het lokale geval is het veel eenvoudiger de berichten af te leveren in de volgorde waarin ze gegenereerd werden. De lokale systemen kunnen immers een centrale wachtlijn gebruiken. • In het lokale geval zal een event steeds afgeleverd worden. In het gedistribueerde systeem kan een gedeeltelijk wegvallen van het netwerk leiden tot het verlies van het event. • In het gedistribueerde systeem kan de tijd nodig voor het versturen van een event domineren boven de tijd nodig voor de reactie op het event, daar waar dit in het lokale systeem normaal omgekeerd is. Bij een te vaak gebruik van events zou er dus meer tijd gaan naar het versturen van events dan naar het verwerken ervan, wat tot een lage performantie zou leiden. • In een gedistribueerd systeem kan een ontvanger van een event tijdelijk offline of buiten dienst zijn. Dient de zender het event dan bij te houden tot de ontvanger terug online komt, dient hij het event te verwijderen of dient hij te blijven proberen het te verzenden? Jini biedt een bijzonder antwoord op al deze bijkomende moeilijkheden. Het ondersteunt geen enkele van de mogelijke strategieën, maar voorziet een algemeen mechanisme waarmee toepassingen de methode voor het afhandelen van de events eenvoudig kunnen uitbreiden. Men kan dus eenvoudig een nieuwe dienst schrijven die gelijk welk type event van gelijk welk type dienst kan ontvangen en verzenden. De nieuwe dienst implementeert dan de juiste afhandelingsstrategie voor de bepaalde toepassing. Distributed transactions. Transacties zijn een manier om een gerelateerde serie van operaties te groeperen, zodat het geheel maar twee mogelijke uitkomsten heeft. Ofwel slagen alle operaties, ofwel falen alle operaties. In beide gevallen, eindigt het systeem in een gekende en controleerbare staat. In een lokaal systeem worden de transacties geregeld door een transaction manager. Dit is een softwaretool die de status van de verschillende, gegroepeerde operaties nagaat en dan, al dan niet, de transactie doorvoert. In een gedistribueerd systeem zoals het Jini-netwerk, ligt het

8


concept van transacties complexer. De statuscontrole kan niet meer eenvoudig centraal gebeuren door een transaction manager, aangezien sommige bewerkingen dienen te gebeuren op externe machines waar men geen controle over heeft. Jini voorziet daarom een eenvoudige transactie API, waarbij het volstaat een transactie aan te maken, door te geven welke bewerkingen deze dient te groeperen en deze uit te voeren, waarna zal teruggegeven worden of deze geslaagd is of niet. De Jini-programmeur is dus volledig afgeschermd van de achterliggende complexiteit.

2.1.3

Waarom Jini gebruiken?

Nu we een overzicht hebben gegeven van de verschillende architectuursaspecten die aan bod komen in de Jini-infrastructuur, zijn we in staat te zeggen waarom men de Jini-technologie zou toepassen. In hoofdzaak kan men de voordelen in vier puntjes opsplitsen: eenvoud, betrouwbaarheid, schaalbaarheid en toestel-onafhankelijkheid. Dit waren dan ook de gebieden waar de Jini-ontwerpers het meeste aandacht aan besteedden. Eenvoud. Jini gaat, in hoofdzaak, over hoe diensten met elkaar connecteren, niet over wat die diensten zijn, wat ze doen of hoe ze werken. Jini-diensten kunnen eigenlijk geschreven worden in een andere taal dan Java, de enige noodzaak is dat er zich ergens op het netwerk een beetje code bevindt dat geschreven is in Java en in staat is deel te nemen aan de mechanismen die Jini gebruikt om andere Jini-diensten en -toestellen terug te vinden. Betrouwbaarheid. In de Jini-architectuur kunnen diensten op een zeer eenvoudige manier verschijnen en verdwijnen. Jini laat diensten toe te komen en te gaan zonder enige statische configuratie of administratie te vereisen. De mogelijkheid voor een dienst om zelf de code nodig om de dienst te gebruiken, met zich mee te dragen, maakt dat er geen nood meer is aan installatie van een driver of software. Op die manier ondersteunt Jini wat spontaneous networking kan genoemd worden. Tegelijk heeft dit ook een zelfgenezend effect op de netwerkstructuur. Jini is in staat netwerkfouten af te handelen zodat het systeem uiteindelijk zelf zijn schade zal kunnen herstellen. Jini zal nooit de veronderstelling maken dat een netwerk perfect is of dat software nooit faalt. Schaalbaarheid. Zoals reeds aangehaald in 2.1.2, zullen Jini-diensten zich steeds groeperen in samenwerkende verzamelingen, communities genoemd. Alle diensten in een community zijn zich

9


bewust van elkaars aanwezigheid en zijn in staat elkaar te gebruiken. Jini ondersteunt schaalbaarheid door toepassing van federation. Federation is de capaciteit van de Jini communities om met elkaar te verbinden in grotere groepen. De federation steunt op het feit dat de lookup services, waarrond de communities zich opbouwen, zelf simpele Jini-diensten zijn. De lookup service is bijgevolg in staat zichzelf te registreren bij andere communities, waardoor hij zich daar ter beschikking stelt van de andere diensten en gebruikers. Voor een gebruiker in een bepaalde community is het van dan af ook mogelijk een dienst aan te spreken die een community verder zit. Toestel-onafhankelijkheid. Jini is onverschillig ten opzichte van de toestellen. Hoofdzakelijk betekent dit dat Jini ontworpen is om een uitgebreide verscheidenheid aan eenheden te ondersteunen die kunnen deelnemen aan een Jini community. Deze eenheden mogen zowel bestaan uit enkel software of hardware of een combinatie van beiden. Meestal is het voor de gebruiker van de eenheid zelfs onmogelijk om te achterhalen om wat type het juist gaat. Bovendien vereist Jini zelfs niet dat een dienst geschreven is in Java of Java verstaat. Het enige dat nodig is, is dat er een of ander Java-sprekend toestel als proxy wil ageren voor de uitzonderlijke dienst.

2.2 2.2.1

OSGi Wat is OSGi?

OSGi staat voor Open Services Gateway Initiative. De missie van deze organisatie is het ontwerpen van open specificaties voor het leveren van diensten over een netwerk aan toestellen en aan het lokale netwerk. Het biedt aan serviceproviders, gateway-operatoren, ontwikkelaars en software-verkopers een gemeenschappelijk raamwerk voor het ontwikkelen, opzetten en beheren van services. Door het flexibel en eenvoudig beheren van diensten, opent de standaard zo een reeks nieuwe mogelijkheden voor smart-devices, zoals set-top boxes, kabelmodems, auto’s, pc’s en vele andere. Al deze toestellen waar een implementatie van de OSGi specificaties op aanwezig is, zullen immers de service providers, zoals telefoonmaatschappijen en kabeloperatoren, in staat stellen een ruimer en een meer gedifferentieerd aanbod aan diensten aan te bieden. Bovendien zorgt het gebruik van Java als ontwikkelingstaal ervoor dat de services platformonafhankelijk kunnen ontworpen worden. Het Open Services Gateway Initiative werd opgericht in mei 1999. De eerste specificatie van het OSGi-raamwerk zag het daglicht in mei 2000. Het was vooral gericht op het gebruik van

10


diensten op afstand op home network gateways. Dit zijn apparaatjes, zoals set-top boxes en DSL modems, die verbonden zijn met een netwerk en diensten kunnen aanbieden aan thuisgebruikers. Voortbouwend op het succes van de eerste werd de tweede release uitgebracht in oktober 2001. Deze voorzag verbeteringen op het vlak van beveiliging en beheer van service platformen op afstand. Bovendien maakte het de implementatie van complexe toepassingen eenvoudiger, waardoor de scope werd uitgebreid naar consumer electronics, beveiligingsproducten en mobiele telefoons. De derde release van de specificatie, verscheen in maart 2003 en breidde opnieuw de bestaande API’s uit. Daarenboven werd een sectie toegevoegd met verschillende aanbevelingen en volledige specificaties omtrent nieuwe diensten die nog niet volledig op punt staan of nog zullen groeien onder invloed van ervaring. Deze sectie omvat onder meer Jini driver-specificaties, UPnP-specificaties en namespace-specificaties. Het oorspronkelijke model waarop het OSGi framework ontworpen is, is een groot netwerk beheerd door een operator bestaande uit een groot aantal service platforms. Deze staan volledig onder controle van de operatoren en kunnen services aanbieden van verschillende serviceproviders. Dit is echter slechts één mogelijk scenario voor het gebruik van de OSGi-specificaties, want de specificatie laat vele andere mogelijkheden open, waardoor het bovendien onmogelijk is juist één model uit te kiezen als finale architectuur voor OSGi.

2.2.2

Hoe werkt OSGi?

Het service platform bestaat uit een Java Virtuele Machine (JVM), een implementatie van het OSGi framework en een set bundels die erop draaien. De structuur van een service platform kan gezien worden als bestaande uit verschillende horizontale lagen. We overlopen in de volgende paragrafen de opeenvolgende lagen. Het besturingssysteem en de hardware vormen samen de onderste laag. Voor de werking van OSGi is deze schakel minder belangrijk. Voor het verder verloop van de thesis kan dit wel belangrijk zijn, aangezien een implementatie ontwikkeld zal worden die onder andere gebruik maakt van OSGi. De tweede laag bestaat uit de Java Virtual Machine. Deze zorgt voor een platformonafhankelijke basis waarvan het OSGi framework dankbaar gebruik maakt. Verder onderscheiden we nog twee bovenliggende lagen, respectievelijk het OSGi-raamwerk

11


en de bundels. Deze kunnen binnen de gestandaardiseerde omgeving, geleverd door het OSGi, dynamisch geladen, gestart, gestopt, ge¨ updatet en gede¨ınstalleerd worden. In het OSGi Service Platform, zijn de bundels de enige methodes om een Java-gebaseerde applicatie op te zetten. Een bundel omvat alle Java-klassen en andere resources die nodig zijn om een bepaalde functie aan te bieden aan de gebruikers of om een service aan te bieden aan andere bundels. Een bundel is opgeslagen als JAR files of Java ARchive files – een standaard ZIP-gebaseerd bestandsformaat –. Het archief bevat: • Al het nodige om geen of meerdere services te implementeren. Dat kunnen Java-klassebestanden zijn, maar evengoed andere data zoals HTML-bestanden, help-bestanden en dergelijke. • Een gestandaardiseerd manifest-bestand [3] met enkele specifieke OSGi-headers, dat de inhoud van het JAR-bestand beschrijft. Aan de hand van headers specifieert dit manifest parameters die het framework nodig heeft opdat het de bundel correct zou kunnen installeren en activeren. • Een verwijzing naar een speciale klasse binnen de bundel die optreedt als bundel-activator. De activator is een implementatie van de BundleActivator-interface die een start()- en stop()-methode bevat. Aan de hand van deze activator kan het framework de bundel starten en stoppen. Op die manier kan gezorgd worden voor de initialisatie bij het opstarten en het opkuisen van de geheugenruimte bij het stoppen van de bundel. • Optionele documentatie die niet nodig is voor het laten lopen van de bundel. De documentatie plaatst men in de OSGI-OPT directory. Vaak valt hier ook de broncode onder. Na de start van de bundel zijn de services en de geëxporteerde packages beschikbaar voor andere bundels. Het framework regelt zelf alle afhankelijkheden tussen bundels. Gedurende zijn levensloop kan een bundel zich in één van de volgende toestanden bevinden: • INSTALLED: De bundel werd succesvol ge¨ınstalleerd en de eventuele vereiste native libraries zijn aanwezig.

12


• RESOLVED: Alle klassen vereist door de bundel zijn aanwezig. De bundel is ofwel klaar om gestart te worden of is reeds gestopt. Packages die de bundel exporteert, worden beschikbaar gemaakt voor andere bundels, wanneer hij voor de eerste keer in deze toestand terechtkomt. • STARTING: De bundel werd gestart, maar het startproces is nog niet beëindigd. • STOPPING: De bundel werd gestopt, maar het stopproces is nog niet beëindigd. • ACTIVE: De bundel werd succesvol gestart en is momenteel actief. De services die hij heeft geregistreerd zijn beschikbaar voor andere bundels. • UNINSTALLED: De bundel werd gede¨ınstalleerd. Dit is een eindtoestand en de bundel kan niet meer van toestand veranderen. Het installeren, starten, stoppen en de¨ınstalleren van een bundel kan door commando’s in te geven, rechtstreeks2 in het OSGi framework of vanuit andere bundels. Deze manier van werken maakt het bijvoorbeeld ook mogelijk om bundels vanop afstand te installeren door middel van een beheerdersbundel, bijvoorbeeld door middel van een webinterface. De overgang tussen verschillende toestanden binnen het OSGi framework kan een aantal events veroorzaken. Het framework kent de volgende events: • Een FrameworkEvent meldt dat het framewerk gestart is, dat packages vernieuwd zijn of dat er zich een fout heeft voorgedaan. • Een BundleEvent wordt gegenereerd wanneer er zich een toestandsovergang voordoet bij één van de bundels. • Het ServiceEvent wordt verstuurd bij het registreren, deregistreren en wijzigen van services. Dit maakt het mogelijk dat bundels die gebruik maken van services, hun resources kunnen vrijgeven wanneer ze melding krijgen, onder de vorm van een ServiceEvent, van het stopzetten van de services.

2.2.3

Waarom OSGi gebruiken?

Het gebruik van het OSGi framework biedt vele voordelen. Dit zijn enkele van de belangrijkste: 2

Eigenlijk is de console waar deze commando’s kunnen ingegeven worden, niets meer dan een bundel die

tekstuele commando’s vertaalt naar de juiste methode-oproepen in het framework.

13


• Open. De OSGi-specificatie is open, onafhankelijk van een specifiek bedrijf of onderneming. Bovendien is het OSGi framework ook open in het opzicht dat het niet beperkt is tot een bepaald scenario. De specificaties mogen en kunnen ge¨ımplementeerd worden voor gelijk welk scenario, geen beperkingen worden opgelegd. Het ontwikkelen van de specificaties gebeurt door de OSGi-leden, een volledige lijst van de leden is terug te vinden als in Bijlage B. • Platformonafhankelijk. Het OSGi framework steunt op het gebruik van het Javaplatform, dat op zichzelf al platformonafhankelijk is. Bijgevolg kan het framework op elk apparaat met Java-ondersteuning ge¨ınstalleerd en gebruikt worden. Bundels dienen niet specifiek voor elk type of merk van het doelapparaat herschreven te worden, maar slechts één keer in Java. • Eenvoudige (de-)installatie van bundels. De installatie van bundels vereist geen uitgebreide installatieprocedure, het opstarten van de bundel volstaat om de services beschikbaar te maken. Bovendien kan het starten zowel lokaal als over het netwerk gebeuren. Het de¨ınstalleren van bundels verloopt al even eenvoudig, door het aanroepen van de stop()-methode uit de activator.

2.2.4

OSGi-implementaties

De OSGi Alliance zorgt voor het ontwikkelen en de specificatie van het services platform. De eigenlijke implementatie wordt overgelaten aan individuele leden van de Alliance of aan derden. Enkele van de huidige implementaties zijn: • aveLinkTM Software Suite (Atinav) [4] • HubTeaTM Service Gateway Solution Suite (Connected Systems) [5] • LONWORKS Bundle Deployment Kit (Echelon) [6] • Espial DeviceTopTM (Espial) [7] • KnopflerFish (Open Source Software) [8] • Ubiserv (Gatespace Telematics AB) [9] Grotendeels gebouwd op de Knopflerfish open source implementatie • IBM Service Management Framework (IBM) [10]

14


• mBedded Server 5.2 (Prosyst) [11] • Samsung Service Provider 3.1 (Samsung) [12] • The RIO (RIO Implements OSGi) framework (Siemens VDO Automotive) [13] • Java Embedded Server 2.0 (SUN) • Oscar (Open Source Software) [14]

15

Hoofdstuk 3

Functionele vereisten 3.1

De Jini Driver service als OSGi-bundel

De Jini Driver service wordt ge¨ımplementeerd als een bundel die te laden is in het OSGiraamwerk. De bundel gaat tewerk volgens het driver model van de OSGi Device Access ”” specificatie [15] en handelt met de Jini Lookup Services en de OSGi services. Het raamwerk voorziet de mogelijkheden om de bundel te installeren, starten, stoppen en updaten. De Jini Driver Service zal op die manier actief kunnen worden binnen de OSGi-architectuur en gebruikt kunnen worden door andere aanwezige services. Zoals we reeds aangehaald hebben in 2.2.1, bevat release 3.0 van de OSGi-standaard ook specificaties voor technologieën die in de toekomst nog zullen veranderen onder invloed van opgedane ervaringen. Hieronder bevindt zich ook een Jini Driver Service”-specificatie. [16] ” De OSGi Service Platform”-specificaties stellen dat Jini (zie 2.1) en OSGi perfect in staat zijn ” elkaar aan te vullen. De Jini Driver zal de brug vormen tussen beide technologieën en zal in essentie moeten en kunnen voldoen aan de volgende eigenschappen: • Transparantie: Jini services dienen bruikbaar te zijn als OSGi services en vice versa. • Export-mogelijkheden: Een bundel moet in staat zijn een OSGi service te exporteren als een Jini service (indien deze Jini-compatibel is). • Import-mogelijkheden: Een bundel moet in staat zijn een OSGi service te gebruiken, die een Jini service voorstelt.

16

Hoofdstuk 3. Functionele vereisten

3.2

Services ontdekken

Wanneer de Jini Driver gestart wordt, moet deze luisteren op het Jini netwerk voor Jini Lookup Discovery events. Dit gebeurt aan de hand van de standaard Jini discovery-klassen gespecifieerd in de Jini-specificaties. Eens een Jini Lookup Service Registrar ontdekt wordt op het netwerk, moet de Jini Driver zijn proxy-object ophalen en het registreren als een net.jini.core.lookup.ServiceRegistrar service in het OSGi-raamwerk. Deze services zullen dan later gebruikt worden door de Jini Driver voor het importeren en exporteren van services. Eveneens kunnen ze aangesproken worden door andere services die in staat zijn rechtstreeks met het Jini-protocol te interageren. De Jini Driver service moet vervolgens alle services ophalen uit de Service Registrars die voldoen aan

ServiceTemplate-objecten,

opgegeven

door

Jini-bewuste

OSGi-bundels.

Een

ServiceTemplate-object omschrijft een aantal kenmerken waaraan een gezochte service moet voldoen. Elk van de matching services moet geregistreerd worden in de service-registers van het OSGi-raamwerk. Dit gebeurt telkens met het zetten van de volgende eigenschappen: • SERVICE ID – Een unieke Jini service identiteit. Elke service wordt verondersteld een unieke identiteit te hebben. De Jini Driver service bepaalt deze waarde aan de hand van de identiteit van de service binnen de Lookup Service. • ENTRIES – Deze waarden houden een beschrijving in van de Jini service.

Deze

net.jini.core.entry.Entry-objecten komen overeen met de attributen van het ServiceItem in de Service Registrar.

Om in Jini een bepaalde service terug te vinden, stelt men typisch een ServiceTemplate-object op aan de hand van een aantal Entry-objecten die vereisten stellen voor de waarden van de service-attributen. Men kan in OSGi niet gewoon zoeken op de service-attributen, aangezien deze niet beschikbaar zijn in het OSGi service-register. Jini definieert immers geen manier om Entry-objecten te vertalen naar Strings of getallen waarop zou kunnen geselecteerd worden door middel van een OSGi-filter. Dit houdt bovendien ook in dat enkel kan gezocht worden op basis van gelijkheid en niet op basis van groter-dan of kleiner-dan relaties, zoals bij OSGi-filters mogelijk is.

17


3.3

Exporteren van OSGi naar Jini

De Jini Driver service moet een OSGi service registreren bij alle ontdekte Jini Service Registrars wanneer de service Jini-compatibel is en geregistreerd is met de registratie-eigenschap JiniDriver.EXPORT. Opdat een conventionele OSGi service Jini-compatibel zou zijn, moet hij voldoen aan enkele bijkomende vereisten, opgelegd door de Jini-specificatie: • Het geëxporteerde service object en al de objecten naar waar het verwijst, moeten serialiseerbaar zijn. Jini maakt immers gebruik van Remote Method Invocation (RMI), waarvoor deze eigenschap vereist is. • Het geëxporteerde service object wordt aangemaakt in de lokale virtuele machine (VM), maar wanneer het uitgevoerd wordt, wordt het dit ook in de VM van de client. Dit betekent dat het service object typisch een proxy dient te zijn voor de eigenlijke service die draait in het OSGi-raamwerk. De Jini Driver service moet de levenscyclus van de Jini services beheren in overeenstemming met de staat van de levenscyclus van de gerelateerde OSGi services. Eens een service geregistreerd is in het raamwerk, moet de Jini Driver service de OSGi service automatisch aanmelden bij de beschikbare Jini Lookup Services. De Jini Driver service beheert dan alle protocols die samengaan met de discovery en join van Jini Registrars. Wanneer een bundel stopgezet wordt en de OSGi service deregistreert, dient de Jini Driver service alle services leases te annuleren en tenslotte de service uit de Jini-gemeenschap te verwijderen. Een geëxporteerde service moet geregistreerd worden met de volgende eigenschappen: • DEVICE CATEGORY – Dit is de toestelcategorie-eigenschap zoals die beschreven is in de OSGi Device Access ”-specificatie [15]. De waarde van deze eigenschap moet jini” zijn. ” ” • EXPORT – Deze eigenschap geeft voor de Jini Driver service aan dat de OSGi service wil geëxporteerd worden als een Jini service. De waarde is irrelevant. De Jini Driver service moet enkel controleren of deze variabele aanwezig is. • LUS EXPORT GROUPS – Deze optionele eigenschap bevat de namen van de Jini-groepen waarin de geëxporteerde service wil geregistreerd worden. Wanneer deze array van Strings niet gedeclareerd is, dan wordt de default-waarde van de Jini Driver gebruikt.

18


• SERVICE ID – Een unieke Jini service-identiteit wordt vastgelegd door de exporterende bundel. Deze identiteit wordt gebruikt om de service te identificeren binnen de Lookup Service. Deze is van het type String. Wanneer deze optionele eigenschap niet gedeclareerd is, moet de Jini Driver service zelf een unieke identiteit creëren. • ENTRIES – Een array van net.jini.core.entry.Entry-objecten . Dit zijn de attributen die de service beschrijven en normaal gebruikt worden om de gepaste Jini service terug te vinden. Deze eigenschap is eveneens optioneel.

3.4

Importeren van Jini naar OSGi

De Jini-naar-OSGi-importmogelijkheid stelt de toepassingen in een OSGi-raamwerk in staat om te interageren met Jini services. Bundels moeten bijgevolg geen extra componenten bevatten om Jini services te gebruiken. In feite dienen ze zelfs niet op de hoogte te zijn van het feit dat de het service platform Jini ondersteunt. De Jini Driver service zorgt voor de nodige transparantie. Wanneer echter een bundel expliciet om een specifieke Jini service vraagt, dan haalt deze de Jini Driver service op en vraagt dat bepaalde Jini services geregistreerd worden als OSGi services. Het aanvragen van specifieke services gebeurt via het registreren van een array van ServiceTemplate-objecten die als een filter voor Jini services functioneren. Eénmaal aangeroepen, zijn de Jini services vermomd als OSGi services en kunnen ze gebruikt worden aan de hand van de standaard OSGi-operaties. Daarnaast is het mogelijk dat bundels gewone OSGi services aanvragen en onbewust zijn van het feit dat dit mogelijks een Jini service is. De bundel vraagt simpelweg een OSGi service aan met de standaard OSGi-operaties. De bekomen service kan dan een vermomde Jini service zijn, maar dit zonder dat de bundel dit ooit zou weten.

19

Hoofdstuk 4

Architectuur In de volgende secties zullen we aan de hand van verschillende scenario’s die kunnen optreden bij het gebruik van de Jini Driver service, de architectuur specifieker uitwerken. Bij elk scenario wordt omschreven wat ondernomen moet worden, wanneer één van de basisactiviteiten optreedt. We beschrijven telkens aan de hand van een sequentiediagram met daarin de verschillende interacties met de Jini- en OSGi-omgevingen en een bijhorende verklaring.

4.1

De Jini Driver service starten

Voor het starten van de Jini Driver service, zoals aangegeven in figuur 4.1, veronderstellen we dat het OSGi platform en de Jini LUS reeds actief zijn en dat er nog geen te exporteren of te importeren services geregistreerd zijn. We installeren vervolgens de OSGi Jini Driver Service. Bij het starten, gaat de Jini Driver service vooreerst op zoek naar een of meerdere Jini Lookup Services, ook wel Service Registrars genaamd, binnen het Jini-netwerk door middel van het discovery protocol (zie pagina 6). Hiertoe zendt de Jini Driver service een multicast request for LUS uit. De Lookup Services die deze aanvraag ontvangen, antwoorden met een discovery event. De Jini Driver service haalt vervolgens de interface van de Lookup Service op en registreert deze in het Service Registry van het OSGi platform. Een service tracker wordt aangemaakt om melding te krijgen van services die wensen geëxporteerd te worden. De service tracker zal op zoek gaan naar OSGi services die wensen geëxporteerd te worden en dit aangeven door aan bepaalde eigenschappen te voldoen. Naast deze tracker maakt de Jini Driver service ook een

20

Hoofdstuk 4. Architectuur

service listener aan. Deze zal waarnemen, wanneer nieuwe LUS toegevoegd worden aan het Jini-netwerk om deze dan te registreren in het OSGi-raamwerk. Nadat al deze operaties zonder fouten zijn afgehandeld, kan de Jini Driver service zich tenslotte registreren in het OSGi Service Registry.

Figuur 4.1: Het sequentiediagram voor het starten van een Jini Driver service in het OSGi-raamwerk

4.2

De Jini Driver service stoppen

In figuur 4.2 wordt het sequentiële verloop van het stoppen van een Jini Driver service voorgesteld, in de veronderstelling dat er, op het moment van stopzetting, services ge¨ımporteerd en geëxporteerd zijn. De service dient eerst de releases, die hij heeft verleend aan geëxporteerde services, te annuleren. Vervolgens kan hij de geëxporteerde services verwijderen uit de Jini Service Registrar. Anderzijds dient de Jini Driver service ook de vanuit Jini ge¨ımporteerde services te deregistreren in het OSGi

21


Service Registry, net zoals de Service Registrar Services. Pas wanneer dit alles gebeurd is, kan de service zichzelf deregistreren uit het OSGi Service Registry.

Figuur 4.2: Het sequentiediagram voor het stoppen van de Jini Driver service in het OSGi-raamwerk

4.3

Exporteren van een OSGi service in Jini

De Jini Driver service moet in staat zijn een OSGi service te exporteren naar het Jini platform. Hij mag enkel de services exporteren die expliciet aangeven dit te wensen. Een service die geëxporteerd wenst te worden, zal zich in het OSGi-raamwerk registreren met een JiniDriver.EXPORT-eigenschap. De service zal bovendien Jini-compatibel moeten zijn. Het geëxporteerde service object moet serialiseerbaar zijn om via RMI verstuurd te kunnen worden, en het service object moet een proxy zijn voor de in OSGi aanwezige service. In figuur 4.3 wordt het sequentiediagram weergegeven voor het exporteren van een service To”

22


BeExportedService”. We veronderstellen dat de Jini Driver service reeds actief is binnen het framework en dus een service tracker heeft geactiveerd met de gepaste filter. De filter filtert voor services die registreren met de eigenschap EXPORT. De te exporteren service ToBeExportedService”, registreert zich bij het Service Registry met de ” eigenschap JiniDriver.EXPORT. De Jini Driver service wordt hiervan op de hoogte gesteld aan de hand van een door de service tracker gegenereerd service event en vraagt deze service aan. De ToBeExportedService” wordt vervolgens door de Jini Driver service toegevoegd aan het Jini ” Service Registrar, op voorwaarde dat deze tot de toegelaten groepen behoort. De toegelaten exportgroepen zijn deze bepaald door de JiniDriver.CM_LUS_EXPORT_GROUPS-eigenschap. Deze optionele service-eigenschap bevat, zoals vastgelegd in de OSGi Framework Specifications ” Release 3”, de groepen waarin de Jini Driver service zou moeten ge¨ınteresseerd zijn bij het exporteren van services naar het Jini-netwerk. De service ontdekt enkel LUS die lid zijn van minstens één van deze groepen. Hij ontdekt alle LUS wanneer de eigenschap niet gedefinieerd is, en geen enkele wanneer deze array geen groepen bevat. Vervolgens beschouwen we wat er gebeurt wanneer een geëxporteerde service verwijderd wordt uit het OSGi-raamwerk. Op het moment dat een geëxporteerde OSGi service zich deregistreert bij het Service Registry, wordt dit door middel van een service event gemeld aan de Jini Driver service. Deze zal vervolgens alle verstrekte leases van de service annuleren en de service verwijderen uit de Jini Service Registrar.

4.4

Importeren van een Jini service in OSGi

Een OSGi service die een Jini service gebruikt, kan dit bewust of onbewust doen.

4.4.1

Jini-bewuste aanvragende bundel

De OSGi service die een bepaalde service aanvraagt, is er zich van bewust dat de gevraagde service zich binnen een Jini platform bevindt. De vragende service stelt een service template voorop waaraan de Jini service moet voldoen. In figuur 4.4 is het sequentiediagram gegeven voor een service die een bepaalde service nodig heeft, maar er zich van bewust is dat deze zal moeten ge¨ımporteerd worden vanuit Jini. De

23


Figuur 4.3: Het sequentiediagram voor het toevoegen en verwijderen van een naar Jini exporterende service

vragende service vraagt de Jini Driver service aan bij het Service Registry. Deze geeft de referentie naar de Jini Driver service terug. De service zet een service tracker met filter op de te importeren service en geeft zijn service template van de gezochte service door aan de Jini Driver service. De Jini Driver service zal dan in de LUS, die behoren tot de toegelaten groepen, op zoek gaan naar de services die overeenkomen met de template en krijgt de overeenstemmende service interfaces terug. De toegelaten importgroepen zijn deze bepaald door de JiniDriver.CM_LUS_IMPORT_GROUPS-eigenschap. Deze optionele service eigenschap bevat, zoals vastgelegd in de OSGi Framework Specifications ” Release 3”, de groepen waarin de driver zou moeten ge¨ınteresseerd zijn bij het importeren van services vanuit het Jini-netwerk. De Jini Driver service ontdekt enkel LUS-leden die lid zijn van minstens een van deze groepen. Hij ontdekt alle LUS wanneer de eigenschap niet gedefinieerd is, en geen enkele wanneer deze array geen groepen bevat.

24


Laten we veronderstellen dat de benodigde service (ToBeImportedService) het Jini Service Registrar reeds gejoined heeft en bovendien behoort tot een toegelaten LUS-groep. De Jini Driver service registreert dan de gevonden Jini services in het OSGi Service Registry. Dit wordt opgemerkt door de tevoren aangemaakte service tracker, wat een service event genereert aan het adres van de vragende service, zodat deze de Jini services kan gebruiken. Elke bundel kan zijn eigen set van service templates opstellen. De Jini Driver service voegt al deze templates samen en importeert en registreert alle overeenstemmende Jini services in het Jini Service Registry.

Figuur 4.4: Een OSGi Service vraagt specifiek een Jini service aan.

4.4.2

De onbewuste aanvrager

Deze bundel heeft een service nodig van een bepaald type, die voldoet aan bepaalde attributen. De service is er zich niet van bewust dat zijn vooropgestelde kenmerken overeenstemmen met een Jini service en contacteert enkel het Service Registry om zijn template door te geven. Indien de

25


gezochte service reeds door een andere, wel bewuste, bundel ge¨ımporteerd is, zal deze aanwezig zijn in het register en gebruikt kunnen worden door de vragende, onbewuste bundel. Indien de service tevoren niet opgehaald is, zal de bundle geen service terugkrijgen. De gebruikende bundel is er zich volledig onbewust van dat hij een Jini service aanspreekt. De Jini Driver service moet dus in staat zijn om een ge¨ımporteerde Jini service te registreren alsof het om een gewone OSGi service gaat.

4.5

Toevoegen en wegvallen van LUS

We veronderstellen in deze situatie dat het OSGi-raamwerk en de Jini Driver service beiden ge¨ınstalleerd en actief zijn. Bij het toevoegen van een LUS aan het Jini-netwerk, voert deze een broadcast uit. Het gegenereerde service event wordt door een listener, die bij het opstarten van de Jini Driver service gezet werd en luistert voor nieuwe Service Registrars, opgevangen. De nieuwe LUS wordt geregistreerd in het OSGi-raamwerk, waardoor er op deze LUS ook kan gezocht worden naar te importeren services en waardoor er naar deze LUS ook OSGi services kunnen geëxporteerd worden. Het importeren en exporteren gebeurt natuurlijk opnieuw rekening houdend met de groepen aanwezig in respectievelijk JiniDriver.CM_LUS_IMPORT_GROUPS (zie 4.4.1) en JiniDriver.CM_LUS_EXPORT_GROUPS (zie 4.3).

26

Hoofdstuk 5

Implementatie In dit hoofdstuk bespreken we de manier waarop we de Jini Driver service ge¨ımplementeerd hebben. We beschrijven en verklaren de keuzes die gemaakt werden. Eerst behandelen we de twee grote hoofdfunctionaliteiten, exporteren en importeren, daarna gaan we over naar een verdere bespreking van de verschillende scenarios die reeds aangehaald werden in het hoofdstuk 4.

5.1

Exporteren

Het exporteren, van OSGi naar Jini, implementeren we aan de hand van een ServiceTrackeren een BundleCodeBaseService-object. Een object van de OSGi-klasse org.osgi.util.tracker.ServiceTracker, maakt het tracken van de registratie, modificatie of verwijdering van services eenvoudig beschikbaar. Bij creatie wordt opgegeven welke services de tracker moet volgen. Hij observeert dan alle ServiceEvents die gegenereerd worden door de services die voldoen aan de gegeven criteria. Een ServiceEvent is een object van de klasse org.osgi.framework.ServiceEvent en wordt gecreëerd bij elke registratie, deregistratie of veranderingen in de eigenschappen van een service object. Een ServiceTracker-klasse kan aangepast worden door implementatie van haar interface org.osgi.util.tracker.ServiceTrackerCustomizer. Op die manier kan men bepalen hoe de tracker dient te reageren wanneer een service toegevoegd, verwijderd of gewijzigd wordt. Wij maken gebruik van een ServiceTracker-object om op zoek te gaan naar services die in het OSGi-raamwerk geregistreerd zijn met de eigenschappen DEVICE_CATEGORY = jini” en EXPORT. ” Net deze services kunnen immers geëxporteerd worden naar de Jini-gemeenschap. De eigenschap

27

Hoofdstuk 5. Implementatie

EXPORT, dient niet aan een bepaalde waarde gelijk te zijn, haar aanwezigheid is voldoende. Om gepast te kunnen handelen, wanneer een geschikte service gevonden of gewijzigd wordt, implementeren we de ServiceTrackerCostumizer-interface.

Deze bevat drie methoden,

addingservice(), modifiedservice() en removedservice(), die zoals hun benaming aangeeft bij de verschillende gedetecteerde service events uitgevoerd worden. Wanneer een service toegevoegd wordt, creëeren we een codebase voor de service en registreren we de service aan de hand van een LookupDiscovery en JoinManager, beiden Jini-concepten. Het LookupDiscovery-object laten we enkel op zoek gaan naar de LUS die zich binnen de opgegeven toegestane exportgroepen bevinden. Het JoinManager-object neemt het joinen van de service aan deze LUS voor zijn rekening, dit gebeurt bovendien met bijhorende entries en LeaseRenewalManager. Het LeaseRenewalManager-object zorgt ervoor dat alle leases verbonden aan de geëxporteerde service, correct afgehandeld en opgevolgd worden. Bij wijziging van een service, wordt de modifiedService()-methode opgeroepen. Deze update alle eigenschappen, zoals de entries en de toegelaten exportgroepen, van de geëxporteerde service. Bij het verwijderen van een geëxporteerde service, beëindigt de removedService()-methode de join manager en de lookup discovery. Tenslotte wordt ook de codebase van de service verwijderd. Naast een ServiceTracker-object maken we voor de export ook gebruik van een BundleCodeBaseService-object. Deze klasse is in het leven geroepen om te voldoen aan het dynamic classloading concept binnen Jini. Bij het exporteren van een service wordt zijn package via een url publiek beschikbaar gesteld, zodat services die niet bekend zijn met de implementatie van een door hun ontvangen service object, de implementatiecode kunnen afhalen van de codebase. Om de codebase op te stellen wordt in het begin, bij het opstarten van de Jini Driver service, op zoek gegaan naar een http-service binnen het raamwerk. Bij deze service wordt een vaste url geregistreerd waaronder dan later alle geëxporteerde packages kunnen geplaatst worden. De vaste url is bijvoorbeeld van de vorm ’http://hostname:8080/RMI/’. Onder deze directory komen dan de verschillende klasse-implementaties. Deze manier van werken stelt wel enkele probleempunten aangaande de veiligheid. Deze problematiek wordt uitvoerig besproken in 5.3.

28


5.2

Importeren

De importzijde van de Jini Driver service wordt ge¨ımplementeerd door middel van de org.osgi.framework.ServiceFactory interface. Deze laat services toe om op maat gemaakte services te voorzien in het OSGi-raamwerk. We gebruiken deze interface aangezien elke ge¨ımporteerde service telkens bepaald wordt door de opgegeven beschrijving, die door de importerende bundel aangemaakt wordt, en dus telkens per service anders is. De service factory zal telkens een JiniDriverImpl-object, specifiek aangepast aan de aanvragende bundel, teruggeven wanneer aangeroepen. Het opzoeken van te importeren services gebeurt door een net.jini.lookup.LookupCacheobject te gebruiken. Dit object zoekt matching services op en volgt ze op. Deze cache wordt gecreëerd op basis van drie objecten: een van het type net.jini.core.lookup.ServiceTemplate, een implementatie van de interface net.jini.lookup.ServiceItemFilter en een implementatie van de interface net.jini.lookup.ServiceDiscoveryListener. Via het ServiceTemplateobject geven we de kenmerken op waaraan de gezochte services moeten voldoen.

De

ServiceItemFilter-interface implementatie breidt het filtermechanisme van de service template verder uit, maar kunnnen we op null zetten aangezien het ServiceTemplate-criterium volstaat voor het selecteren van de te importeren services. Het object dat de ServiceDiscoveryListenerinterface implementeert, stellen we in op het type van de gezochte services, zodat we merken wanneer een matching service ge¨ımporteerd, gewijzigd of verwijderd is. Via

de

klasse

FromJiniImportingListener,

een

implementatie

van

de

interface

ServiceDiscoveryListener, leggen we vast welke acties moeten ondernomen worden bij een toevoeging, wijziging of verwijdering van een matching service. De interface bevat de drie methoden : serviceAdded(), serviceChanged() en serviceRemoved(). Deze worden ten gepaste tijde opgeroepen door de lookup cache. Wanneer een matching service toegevoegd wordt, registreren we deze met zijn entries en service id als attributen, in het OSGi-raamwerk. Bij het wijzigen van een ge¨ımporteerde service, vernieuwt de serviceChanged()-methode de eigenschappen waarmee de service in OSGi geregistreerd is. Wanneer een ge¨ımporteerde service tenslotte wordt verwijderd, zal de serviceRemoved()-methode de Jini service deregistreren in het OSGi-raamwerk.

29


5.3 5.3.1

Codebase versus security Probleem

Wanneer een Jini service via een geserialiseerde stroom ten gevolge van een RMI-call, een object ontvangt waarvan de klassedefinitie zich niet bevindt in zijn classpath, zal deze op zoek gaan in de meegegeven codebase. Om aan dit RMI-principe te kunnen voldoen bij het exporteren van OSGi services, dienen de klassebestanden van de geëxporteerde OSGi service ter beschikking gesteld te worden via een codebase. In onze implementatie zorgt de BundleCodeBaseServiceklasse hiervoor. De BundleCodeBaseService-klasse zet bij het starten van de Jini Driver service via een, in het raamwerk aanwezige, http-service een algemene codebase op. De codebase vormt een url die samengesteld wordt aan de hand van de hostnaam, het poortnummer van de http-service en een meegegeven mountpoint. Onder deze codebase worden dan alle klassedefinities van geëxporteerde packages beschikbaar gesteld. We krijgen dus een locatie vanwaar andere services de klassedefinities van voor hen onbekende geëxporteerde service-objecten kunnen ophalen. Deze manier van werken houdt echter een groot nadeel in. Alle klassedefinities worden publiek beschikbaar. Sommige klassen van een OSGi service moeten toegankelijk zijn voor het RMI codebase-principe, maar dit houdt niet in dat alle klassen zomaar beschikbaar kunnen gesteld worden voor iedereen. Om dit probleem trachten te verhelpen, zijn we op zoek gegaan naar alternatieven en mogelijke oplossingen en hebben we deze op hun beurt onderling afgewogen.

5.3.2

Alternatieven

We zijn begonnen met de veronderstelling dat Jini en RMI een logische eenheid vormden en onafscheidelijk samenhoren. Maar is dit wel het geval? Is RMI codebase nodig om Jini te implementeren? Hoewel Jini de RMI code loading”-semantiek ondersteunt, is er geen verplichting om Jini servi” ces te implementeren met RMI. Er zijn verschillende andere bestaande protocolstandaarden die gebruikt worden voor remote method calls, zoals Simple Object Access Protocol (SOAP), een XML gebaseerde implementatie, of Internet Inter-ORB Protocol (IIOP). Een logische conclusie

30


zou hier dus zijn om Jini en RMI van elkaar te scheiden en RMI te vervangen door een andere protocolstandaard. Om RMI in Jini te vervangen, dient de interface tussen beiden gevonden te worden. Jini en RMI blijken echter zeer sterk met elkaar verstrengeld. De interface terugvinden en uitzoeken welke afhankelijkheden de verschillende Jini klassen hebben, is dan ook onbegonnen werk. In totaal zijn er meer dan 140 Jini klassen die direct en indirect gebruik maken van RMI, bovendien zijn dit vaak circulaire afhankelijkheden. [17] Als men het code loading”-protocol en het communicatie-protocol van elkaar scheidt, dan ” kunnen Jini services, opgebouwd aan de hand van raw sockets of Remote Procedure Calls (RPC), ook code op afstand ophalen. Sockets zijn een flexibele manier om data uit te wisselen tussen twee hosts en zijn voldoende voor algemene communicatie. Wanneer echter meer dan data moet uitgewisseld of code moet uitgevoerd worden, is het ontwerp van een protocol om de uitgewisselde berichten te encoderen en te decoderen, niet enkel lastig, maar leidt het ook tot verschillende en vaak incompatibile versies. RPC’s laten remote calls er uit zien als lokale methode-oproepen. Ze functioneren echter niet goed binnen gedistribueerde objectsystemen, waar het niet voldoende is om eenvoudig weg een server-methode op te roepen, doch wel om te communiceren met gehele objecten en remote method invocations uit te voeren. [18] Via RMI wordt het voor de programmeertaal mogelijk objecten elkaar te laten oproepen zonder dat ze van elkaar weten waar ze zich in het netwerk bevinden. Het blijven gebruiken van RMI en de codebase lijkt dan ook de beste manier van werken. We kiezen er dus voor om het dynamische classloading-principe, steunend op de codebase, te implementeren, hoewel het enkele nadelen heeft. De verschillende pro’s en contra’s noemen we hieronder op. Pro: • Door het gebruik van de codebase urls, heb je een grote flexibiliteit van waar de downloadbare code wordt opgeslaan en beheerd. De RMI aanpak laat een grote flexibiliteit toe. • Security policy files geven toestemmingen op basis van de plaats van waar de code geladen wordt. De plaats wordt gespecifieerd aan de hand van een url. Het RMI-codebase schema past dus in het Java beveiligingsmechanisme.

31


Contra: • Een webserver dient actief te zijn, om de codebase op te zetten en de klassen aan te bieden. • Wanneer een grote hoeveelheid services lopen en slechts weinig gebruikt worden, worden veel resources verkwist. Men kan dit opvangen aan de hand van het activation framework. Dit laat toe een server object te desactiveren (en dus geen lopende JVM te hebben) wanneer het niet nodig is en opnieuw op te starten wanneer een client een methode-oproep doet (oa. gebruikt in de Lookup Service). Een gevolg hiervan is wel het verlies aan performantie. Bij het heropstarten, dient immers het object opnieuw samengesteld, de classfile nagekeken, de VM opgestart en de security verwerkt te worden.

5.3.3

Oplossing

Aangezien we besluiten om het dynamic classloading-principe te ondersteunen via het opzetten van een codebase, blijft natuurlijk de security issue gelden. Bij het beschikbaar stellen van het package van een geëxporteerde service, worden alle class-bestanden publiek beschikbaar. Ook klassen die anders, voor bepaalde of alle gebruikers afgeschermd worden, worden zo eenvoudig bereikbaar. Om aan dit probleem tegemoet te komen, kunnen we in het manifest van de bundel, een extra header invoeren. Deze header (bv. Jini-ExportClasses) zou dan een lijst bevatten met alle klassen die moeten geëxporteerd worden. De Jini Driver service zal dan alvorens een bundel te exporteren, de header ophalen uit het manifest en enkel deze klassen die in de lijst voorkomen publiek beschikbaar stellen. Deze methode heeft wel verschillende pro’s en contra’s. Pro: • Er is controle over welke klassen publiek beschikbaar gesteld worden, waar anders alle code voor iedereen bereikbaar zou zijn. • Het is een haalbare en doenbare oplossing. • Het is eenvoudig toe te voegen en toe te passen. Contra: • De programmeur moet meer begrijpen van de achterliggende concepten en werking. Dit vergt extra inzicht in de RMI- en dynamic classloading-principes.

32


• Het brengt extra complexiteit met zich mee voor het opstellen van een exporteerbare OSGi-bundel. De te delen en niet te delen delen moeten gescheiden worden.

5.4

Identieke exportklassen

OSGi services die geëxporteerd worden naar Jini, stellen hun klassedefinities beschikbaar via een codebase, om te voldoen aan de dynamische classloadingconcepten in Jini. Het feit dat twee geëxporteerde services eenzelfde klasse exporteren, kan voor problemen zorgen wanneer de versies van de klassen verschillend zijn of wanneer de klassedefinitie offline gehaald wordt door het verwijderen van een van de services. In de veronderstelling dat nieuwere versies van een klasse steeds de functionaliteit van de oudere versies moet blijven ondersteunen, mogen we er van uit gaan dat we oudere klassedefinitieversies mogen vervangen door hun nieuwere. Op die manier maken alle exporterende services gebruik van die nieuwe versie. Om tegen te gaan dat een klassedefinitie verwijderd wordt, terwijl ze nog in gebruik is door een andere service, kunnen we een lijst bijhouden van alle geëxporteerde klassen. Bij elke klasse houden we dan bij door hoeveel services deze geëxporteerd is. Telkens een service de klasse exporteert, wordt de teller ge¨ıncrementeerd. Telkens een geëxporteerde service verwijderd wordt uit het OSGi-raamwerk en dus niet meer beschikbaar mag gesteld worden, wordt de teller gedecrementeerd. Enkel wanneer de teller op nul staat, moet de klasse niet langer beschikbaar gesteld worden via de codebase. Momenteel is deze klassencontrole nog niet ge¨ımplementeerd in de Jini Driver service. Bij verdere ontwikkeling van de bundel, zal deze use count zeker moeten ge¨ımplementeerd worden.

5.5

Verschillende scenario’s

In de volgende secties werken we verder de verschillende scenario’s uit die reeds aan bod kwamen bij de architectuurbespreking. We beschrijven de interacties en aanroepen tussen de verschillende klasse-objecten; telkens verduidelijkt met het bijhorend sequentiediagram.

33


5.5.1

Jini Driver service starten

In figuur 5.1 zien we het sequentiediagram voor het opstarten van de Jini Driver service. Bij het starten van de Jini Driver-bundel, gaat het OSGi-raamwerk op zoek naar de BundleActivatorheader in het manifest-bestand. Het raamwerk roept uit de activator de start()-methode van de bundel op. Er wordt eerst een OsgiToJini-object aangemaakt, wat inhoudt dat de algemene codebase ingesteld wordt en dat er een service tracker gecreëerd wordt die op zoek gaat naar alle beschikbare, exporteerbare OSGi services.

In de figuur wordt de codebase

aangemaakt door oproep van de getBundleCodeBaseService("/RMI")-methode. De codebase wordt in dit geval dan ’http://hostnaam:poortnummer/RMI’. Dit is de algemene basis-codebase, de packages worden hieronder beschikbaar gesteld op het moment dat ze geëxporteerd worden. Om het ServiceTracker-object te kunnen aanmaken, dient eerst een Filter- en een ToJiniExportingServiceTracker-object aangemaakt te worden. Dit laatste is een implementatie van de ServiceTrackerCustomizer-interface. Een service tracker begint pas te tracken wanneer hij geopend is. Na het openen van de tracker is de volledige exportzijde van de Jini Driver service actief en zijn de te exporteren OSGi services beschikbaar in Jini. Na de exportzijde wordt nu gestart met het opzetten van de importzijde, door het aanmaken van een JiniDriverServiceFactory-object. Dit object zal opeenvolgend een LookupDiscovery-, ServiceDiscoveryManager-, ServiceTemplate- en Listener-object aanmaken om, aan de hand van deze, dan een LookupCache-object te creëren. Deze lookup cache zal de services die voldoen aan de service template, opsporen, importeren en beheren. Als dit alles zonder problemen verlopen is, registreert de Jini Driver-bundel zichzelf in het OSGiraamwerk.

5.5.2

Jini Driver service stoppen

Zoals we in het sequentiediagram in figuur 5.2 kunnen zien, stopt het OSGi-raamwerk de bundel door de stop()-methode uit de activator op te roepen. De Jini Driver-bundel begint met zijn service in het OSGi-raamwerk te deregistreren. Vervolgens gaat het eerst over tot het sluiten van zijn exportzijde. Opeenvolgend sluit het de service tracker en vernietigt het de bundle codebase. Dit laatste gebeurt door het mountpoint te deregistreren bij de http-service.

34


Figuur 5.1: Sequentiediagram voor het starten van de Jini Driver service-bundel

35


Figuur 5.2: Sequentiediagram voor het stoppen van de Jini Driver service-bundel

36


Eenmaal de exportzijde afgesloten, gaan we over naar het sluiten van de importzijde door het beëindigen van het JiniDriverServiceFactory-object. Dit laatste gebeurt door het respectievelijk beëindigen van het ServiceDiscoveryManager- en de LookupDiscovery-object. Tenslotte zetten we het BundleContext-object van de Jini Driver-bundel op null.

5.5.3

Een service exporteren

We veronderstellen, zoals in figuur 5.3 weergegeven, dat een naar Jini exporteerbare service zich registreert in het OSGi-raamwerk.

De registratie gebeurt met de eigenschappen

DEVICE_CATEGORY = jini en EXPORT en genereert een service event dat opgemerkt wordt door de service tracker. Deze werd gezet bij het opstarten van de Jini Driver service. Door de detectie wordt de AddingService()-methode van het ToJiniExportingServiceTracker-object opgeroepen.

Figuur 5.3: Sequentiediagram voor het exporteren van een OSGi service naar Jini

De methode maakt een nieuw ToJiniExportedService-object aan, dat de OSGi service aanpast en registreert in de Jini-gemeenschap. Het toevoegen van de service aan de Jini-gemeenschap gebeurt aan de hand van een JoinManager-object.

Daarvoor dient men echter eerst een

ReleaseManager- en LookupDiscovery-object aan te maken en de entries en service id juist

37


in te stellen. Dit laatste gebeurt in de methode init(). private void init(ServiceReference serviceReference) { this.serviceReference = serviceReference; this.service = Activator.bc.getService(serviceReference); this.serviceID = Util.getServiceID ((String) serviceReference.getProperty( JiniDriver.SERVICE_ID)); this.entries = (Entry[]) serviceReference.getProperty(JiniDriver.ENTRIES); }

De service ID wordt opgehaald uit de optionele eigenschap jini.service.id, zoals gedeclareerd in de JiniDriver-specificatie van de OSGi specificaties release 3. Voor de entries wordt op gelijkaardige wijze de eigenschap jini.entries opgehaald. Alvorens het LookupDiscovery-object aan te maken, bepalen we welke groepen mogen ontdekt worden en dus naar welke groepen de service mag uitgevoerd worden. Het bepalen van de exportgroepen gebeurt via de methode getLusExportGroups(). private String [] getLusExportGroups() { String[] service_lusExportGroups = (String []) serviceReference.getProperty( JiniDriver.LUS_EXPORT_GROUPS); if (service_lusExportGroups != null) return service_lusExportGroups;

String system_String_lusExportGroups = System.getProperty(JiniDriver. CM_LUS_EXPORT_GROUPS); if (system_String_lusExportGroups != null) return Util.splitwords (system_String_lusExportGroups);

String [] cm_LusExportGroups = OsgiToJini.getCMLusExportGroups(); if (cm_LusExportGroups != null) return cm_LusExportGroups;

return null; }

Het bepalen van de groepen is onderhevig aan regels bepaald door de OSGi-specificaties. Wanneer de eigenschap bepaald in JiniDriver.LUS_EXPORT_GROUPS (jini.lus.export.groups)

38


bestaat,

dan worden deze groepen gebruikt.

Indien de eigenschap bepaald in

JiniDriver.CM_LUS_EXPORT_GROUPS (jini.lus.export.groups) gedeclareerd is, specifieert deze de groepen. Zoniet halen we de variabele cm_lusExportGroups op uit de klasse OsgiToJini. Tenslotte geeft de addingService()-methode het ToJiniExportedService-object terug, zodat de service tracker deze service zal kunnen opvolgen en bij wijzigingen gepast zal kunnen handelen. Op het moment dat een geëxporteerde service verwijderd wordt uit het OSGi-raamwerk, zullen de acties ondernomen worden zoals beschreven in het sequentiediagram in figuur 5.4.

Figuur 5.4: Sequentiediagram voor het verwijderen van een geëxporteerde OSGi service

Het service event gegenereerd door het verwijderen van de OSGi service zorgt er voor dat de service tracker de methode removedService() binnen het ToJiniExportingServiceTracker-object oproept. De methode verwijdert alle ToJiniExportedService-objecten door opeenvolgend hun JoinManager- en LookupDiscovery-objecten te beëindigen. Vervolgens vernietigt de methode de codebase van de service door de bundel uit de bijgehouden verzameling van geëxporteerde bundels te verwijderen.

5.5.4

Een service importeren

In figuur 5.5 zijn in een sequentiediagram de opeenvolgende acties weergegeven, die ondernomen worden bij het importeren van een Jini service. Een bundel die een Jini service wil gebruiken begint met het ophalen van het Jini Driver service-object. Via de methode getService() krijgt hij een JiniDriverImpl-object terug. Dit object voorziet methoden om aan de hand van het

39


doorgeven van de service template van de gezochte service, de Jini services te importeren. De vragende bundel geeft dus zijn service template aan de implementatie van de Jini Driver service via de setServiceTemplate()-methode.

Figuur 5.5: Sequentiediagram voor het importeren van een Jini service in een OSGi-raamwerk

De Jini Driver service doorloopt dan de verschillende templates van alle aanvragende bundels en stelt voor elke template een LookupCache-object op. Dit gebeurt telkens aan de hand van een FromJiniImportingListener-object, specifiek voor de service template. Op daaropvolgende service events van matching Jini services roept de lookup cache telkens de gepaste methode op uit de Listener-klasse. Wanneer een Jini service gevonden wordt die voldoet aan de service template, wordt de serviceAdded()-methode opgeroepen. Deze registreert de service in OSGi met de attributen

40


en service id van de Jini service als OSGi service-eigenschappen. Wat er gebeurt bij het verwijderen van een ge¨ımporteerde service kunnen we ook aflezen in figuur 5.5. De lookup cache komt door observatie van de service events te weten dat een van zijn ge¨ımporteerde services verwijderd is. Hij roept bijgevolg de serviceRemoved()-methode op, die dan de verwijderde service in het OSGi-raamwerk verwijdert. Wanneer een service tijdens de periode dat hij ge¨ımporteerd is, wijzigt, roept het LookupCacheobject op gelijkaardige wijze de serviceChanged()-methode op. Deze zal de eigenschappen waarmee de service in OSGi geregistreerd is, updaten naar de nieuwe waarden.

5.5.5

Toevoegen en wegvallen van LUS

Een nieuwe Lookup Service die zich toevoegt aan de Jini-gemeenschap, zoals weergegeven in figuur 5.6, meldt dit via een broadcast. Het daardoor gegenereerde service event, wordt opgevangen door de JoinManager-objecten van de geëxporteerde services en door het LookupCacheobject dat zoekt naar services van de klasse net.jini.core.lookup.ServiceRegistrar. De JoinManager-objecten controleren of de groep van de nieuwe LUS behoort tot de toegelaten exportgroepen. Indien dit het geval is, zal hij zijn service ook exporteren naar of dus registreren in de nieuwe Lookup Service. De ServiceRegistrar-lookup cache die bij het starten van de Jini Driver service in de JiniDriverServiceFactory-klasse aangemaakt wordt, roept de serviceAdded()-methode van het FromJiniImportingListener-object aan. Deze methode importeert dan de service proxy van de Lookup Service en registreert de LUS in het OSGi-raamwerk. Bij het verwijderen van een Jini Lookup Service, zoals weergegeven in figuur 5.7, worden de LookupCache- en JoinManager-objecten opnieuw geactiveerd door het gegenereerde service event.

Het

LookupCache-object

roept

de

serviceRemoved()-methode

van

het

FromJiniImportingListener-object op. Deze methode deregistreert de LUS in het OSGiraamwerk. De join managers detecteren het verdwijnen van de LUS en houden hiermee rekening bij volgende exports.

41


Figuur 5.6: De reactie van de Jini Driver service op het toevoegen van een Jini Lookup Service weergegeven in een sequentiediagram

5.6

De functionaliteit in klassen gegoten

Wanneer we alle in paragrafen 5.1 en 5.2 besproken klassen en hun interfaces samennemen in een klassendiagram, bekomen we figuur 5.8. In deze figuur zijn om de overzichtelijkheid te bewaren de methoden van de klassen achterwege gelaten. Het klassendiagramma met methoden halen we verder in de tekst nog aan. We zien bovenaan in figuur 5.8 de Activator-implementatie van de BundleActivator-interface. Deze klasse bevat de methoden om de bundle te starten en te stoppen. Bij het starten en het lopen van de bundel maakt het Activator-object, OSGiToJini- en JiniDriverServiceFactoryobjecten aan. In het linkse deel van de figuur hebben we alle klassen aan exportzijde. Een object van de klasse OsgiToJini, maakt enerzijds een ToJiniExportingServiceTracker-object en anderzijds een BundleCodeBaseService-object aan. De exporting service tracker is een implementatie van de ServiceTrackerCustomizer-interface, en maakt op zijn beurt objecten aan van het type

42


Figuur 5.7: De reactie van de Jini Driver service op het verwijderen van een Jini Lookup Service weergegeven in een sequentiediagram

ToJiniExportedService. Deze laatste klasse is een implementatie van de ServiceIDListenerinterface. De codebase service maakt gebruik van BundleHttpContext-objecten die een implementatie zijn van de HttpContext-interface. In het rechtse gedeelte van de figuur vinden we de klassen terug die instaan voor de import van de Jini services in het OSGi-raamwerk. Een object van de JiniDriverServiceFactory-klasse geeft telkens aan de hand van een FromJiniImportingListener-object een JiniDriverImpl-object terug. De JiniDriverServiceFactory-klasse is een implementatie van de ServiceFactoryen de ManagedService-interface. De FromJiniImportingListener-klasse implementeert de ServiceDiscoveryListener-interface. De JiniDriverImpl-klasse, tenslotte, implementeert de JiniDriver-interface die vooropgesteld werd door de OSGi Platform Specifications Release 3”. ” In figuur 5.9 zijn de verschillende klassen met hun uiteindelijk ge¨ımplementeerde methoden en belangrijkste variabelen weergegeven. Bij het benoemen van de verschillende methoden en variabelen, hebben we steeds zo duidelijk mogelijk trachten te werk te gaan. Enkel met de

43


interpretatie van de benamingen van de verschillende elementen is men op die manier al in staat een groot deel van de werking te achterhalen. Voor verdere gedetailleerde en uitgebreide specificaties verwijzen we naar de javadoc-pagina’s, te vinden op de bijgevoegde CD-ROM (Bijlage E).

44


Figuur 5.8: De verschillende klassen en hun interfaces zoals in de uiteindelijke implementatie

45


Figuur 5.9: Alle klassen met hun uiteindelijk ge¨ımplementeerde methoden en belangrijkste variabelen

46

Hoofdstuk 6

Testen en demo In de vorige hoofdstukken werd de ontwikkeling en implementatie van de Jini Driver service beschreven. We hebben nu een OSGi-bundel die de brug vormt tussen OSGi en Jini. In dit hoofdstuk zullen we de bundel testen aan de hand van een OSGi-implementatie en een ontwikkelde demotoepassing. We beginnen met het testen van het starten en stoppen van de bundel in het OSGi-raamwerk. Daarnaast mogen we nu van de ontwikkelde bundel verwachten dat hij in staat is om services op een transparante manier te importeren en te exporteren. Om te testen of om aan te tonen dat de bundel hiertoe werkelijk in staat is, werden twee OSGi-demobundels ontwikkeld. Enerzijds een exporterende bundel die zijn OSGi service wil beschikbaar stellen binnen Jini en anderzijds een importerende bundel die in de Jini-gemeenschap op zoek wil gaan naar een voor hem geschikte bundel.

6.1

De Jini Driver service testen

Met de Jini Driver service implementatie beschikken we over een bundel die kan ge¨ınstalleerd worden in het OSGi-raamwerk. In deze paragraaf testen we de functionaliteiten van de ontwikkelde bundel binnen een OSGi-implementatie. We beperken ons in dit eerste geval tot het starten, stoppen en updaten van de bundel. Het testen en nagaan van de export- en importcapaciteit bespreken we verder in paragraaf 6.2.3, bij het uitvoeren van de demotoepassing. Starten Bij het starten zijn twee gevallen mogelijk. Ofwel zijn er al Jini Lookup Services actief op het

47

Hoofdstuk 6. Testen en demo

moment dat de bundel opstart, ofwel worden deze pas later actief. In beide gevallen moet de Jini Driver service deze detecteren en succesvol importeren in OSGi. Bij het eigenlijke testen hebben we beide gevallen gecontroleerd. Wanneer we de Jini Driver service startten in de Knopflerfish-omgeving, zonder dat we eerst een LUS opgestart hadden, installeerde de bundel succesvol. We kregen melding van het opzetten van de codebase en de LUS werd geregistreerd van zodra deze beschikbaar werd bij het opstarten van de Reggie. Als de Reggie reeds actief was bij het opstarten van de Jini Driver-bundel, werd de LUS onmiddellijk ge¨ımporteerd. Stoppen Het stoppen van de bundel binnen de Knopflerfish-omgeving verliep steeds zonder problemen. Na het stoppen kon de bundel weer gestart worden. Updaten Het verversen van de bundel binnen de Knopflerfish-omgeving verliep steeds zonder problemen.

6.2

De demotoepassing

De testbundels die ontwikkeld werden, implementeren een eenvoudige HelloService-dienst. De dienst antwoordt bij het oproepen met een String name” als argument, met een String Hello ” ” name”, Hola name” of Hallo name”. Dit afhankelijk van de tevoren ingestelde taal. ” ” Het opzet van de testdemo bestaat niet uit één bundel die eenvoudig een service van een OSGi service naar de Jini community exporteert, gecombineerd met een andere bundel die een andere Jini service opzoekt en importeert in het OSGi-raamwerk. De demobundels gaan verder en behandelen éénzelfde type service. De service geëxporteerd door de ene bundel zal door de andere bundel opnieuw ge¨ımporteerd worden in een ander OSGi-raamwerk. De keuze om de demo op deze manier op te vatten, is bewust gebeurd. Enerzijds blijkt uit deze opstelling duidelijk de transparantie, export- en importmogelijkheden. Anderzijds willen we via deze keuze ook aangeven dat het scenario waarbinnen de Jini Driver service kan gebruikt worden, niet enkel beperkt moet gezien worden als één enkele OSGi gateway die verbonden is met één enkele Jini community. In de demo wordt immers een OSGi-bundel, over het Jini-netwerk heen,

48


getransporteerd naar een ander OSGi-raamwerk. Het is immers mogelijk dat er meer dan één OSGi-raamwerk verbonden is met het Jini-netwerk. In de volgende paragrafen bespreken we de beide ontwikkelde bundels. We gaan in op hoe de bundels nu juist importeren en exporteren gebruikmakend van de Jini Driver service. Tenslotte bespreken we de uitvoering van de demobundels. Voor de broncode van beide bundels verwijzen we naar de inhoud van de bijgevoegde CD-ROM. (Bijlage E)

6.2.1

helloservice

De helloservice-bundel is een exporterende OSGi-bundel. Hij registreert zich in het OSGiraamwerk met de eigenschappen nodig om zich te laten exporteren naar Jini. De bundel biedt een HelloService service aan, die in staat is een String met een opgegeven argument terug te geven in een tevoren gekozen taal. De bundel bevat twee klassen, Activator en HelloServiceImpl, en één interface, HelloService, zoals men kan zien in figuur 6.1.

Figuur 6.1: Het klassendiagram van de helloservice-bundel

De helloservice.HelloService-klasse definieert de interface voor de service. Ze bevat de declaratie van de sayHello()-methode. De interface wordt ge¨ımplementeerd door de klasse helloservice.HelloServiceImpl. Deze klasse-implementatie zal geregistreerd en geëxporteerd

49


worden. De Activator-klasse is een implementatie van de BundleActivator-interface en staat in voor het starten en stoppen van de bundel. Laten we even de onderstaande start()-methode bekijken en zien hoe deze aangeeft te willen geëxporteerd worden. public void start(BundleContext context) throws BundleException { Dictionary props = new Hashtable();

props.put("description","a simple example of an exporting OSGi service"); props.put("language", "nl");

// Properties for exporting to Jini props.put(JiniDriver.EXPORT,""); props.put(org.osgi.service.device.Constants.DEVICE_CATEGORY, JiniDriver.DEVICE_CATEGORY);

// Setting the entries property to a serviceinfo property Entry[] entries =

new Entry[] {

new ServiceInfo("HelloService","Tom Van den Steen", "Tom Van den Steen","1.0","1","001")}; props.put(JiniDriver.ENTRIES, entries);

reg = context.registerService(HelloService.class.getName(), new HelloServiceImpl((String)

props.get("language")),

props); }

We zien dat de methode een object van de klasse HelloServiceImpl registreert in het OSGiraamwerk met de eigenschappen meegegeven in het Dictionary-object. Naast enkele gewone eigenschappen, zoals de description, voegen we ook de eigenschappen EXPORT en DEVICE_CATEGORY toe. Via deze eigenschappen geven we aan dat de service mag geëxporteerd worden naar Jini. We voegen ook nog een ENTRIES-eigenschap toe. Deze bestaat uit een lijst van Entry-objecten die bij het exporteren, door Jini zullen ingelezen worden als attributen. Meer specifiek, definiëren we hier een ServiceInfo Entry-object dat algemene informatie bevat over de service en zal kunnen ge¨ınterpreteerd worden door Jini.

50


Om dus een service te exporteren naar Jini volstaat het de OSGi service in het OSGi-raamwerk te registreren met de eigenschappen EXPORT en DEVICE_CATEGORY. De DEVICE_CATEGORY moet gelijk zijn aan jini. Wat betreft de EXPORT-eigenschap, volstaat haar aanwezigheid. Zij dient niet op een bepaalde waarde ingesteld te worden. In de bovenstaande code werd de jini-eigenschap niet rechtstreeks ingesteld, maar wel aan de hand van de import van de JiniDriver-interface.

6.2.2

testJiniImport

De testJiniImport-bundel is een importerende OSGi-bundel. De bundel gaat, éénmaal geregistreerd in het OSGi-raamwerk, op zoek naar een Jini service die voldoet aan de helloservice.HelloService-interface. Bij het installeren van de bundel, gaan we er dan ook van uit de helloservice.HelloService-interface beschikbaar is binnen OSGi en we op zoek gaan naar een implementatie van deze interface. In het klassendiagram van de bundel, figuur 6.2, zien we dat deze bestaat uit twee klassen.

Enerzijds hebben we opnieuw een Activator-klasse die een implementatie is van de

BundleActivator-interface. Deze bevat de methoden om de bundel te starten en te stoppen. Anderzijds hebben we een implementatie van de ServiceTrackerCustomizer-interface.

Figuur 6.2: Het klassendiagram van de testJiniImport-bundel

De nood aan een dergelijke implementatie zullen we duidelijk maken aan de hand van de bespreking van de Activator.start()-methode. De broncode van deze methode luidt:

51


public void start(BundleContext bundleContext) throws Exception {

Activator.bc = bundleContext;

// Get the JiniDriver Service JiniDriver jinidriver = (JiniDriver) bc.getService( bc.getServiceReference( "org.osgi.service.jini.JiniDriver"));

// Define Jini Services to be imported ServiceTemplate templates [] ={ new ServiceTemplate(null, new Class[] { helloservice.HelloService.class}, null)};

// Import the Jini Services as OSGi services jinidriver.setServiceTemplates(templates);

ServiceTrackerCustomizer serviceTrackerCustomizer = new HelloServiceTracker();

serviceTracker = new ServiceTracker(bc, "helloservice.HelloService", serviceTrackerCustomizer);

serviceTracker.open(); }

Hierin zien we dat we de importerende bundel eerst de Jini Driver service laten ophalen uit het OSGi Registry. Hij stelt vervolgens zijn service templates op, die weergeven aan welke eisen de gezochte services moeten voldoen. Bij deze bundel gaan we op zoek naar een service die van het klassetype helloservice.HelloService is. De opgestelde service templates geven we vervolgens door aan het JiniDriver-object via de setServiceTemplates()-methode. De Jini Driver service gaat voor de service op zoek naar matching services binnen de Jini ´ enmaal services gevonden worden, worden deze geregistreerd in het OSGiLookup Services. E´ raamwerk. Opdat de bundel deze import zou merken en gepast zou kunnen reageren, maken we een ServiceTracker-object aan. Dit zal op zoek gaan naar OSGi services van het klassetype helloservice.HelloService en zal aangepast worden door een implementatie van de ServiceTrackerCustomizer-interface.

52


Via de HelloServiceTracker-klasse is de bundel dan in staat de ge¨ımporteerde services op te zoeken en hun levenscyclus gepast op te volgen. Deze implementatie geeft duidelijk aan dat het importeren van een Jini service met behulp van de Jini Driver service, op zeer eenvoudige wijze mogelijk is. De aanvragende bundel hoeft zich niets aan te trekken van de typische Jini-concepten. Alle discovery-, joinen leasemanagement komt op rekening van de Jini Driver service te staan en wordt volledig afgeschermd van de importerende bundel.

6.2.3

Uitvoering

De testopstelling voor het uitvoeren van de demo-applicatie bestond uit twee pc’s die in netwerk stonden met elkaar. Op beide computers maakten we gebruik van de Knopflerfish OSGiimplementatie. Op de ene pc werd de exporterende bundel gestart, op de andere werd de door de eerste pc geëxporteerde bundel opnieuw ge¨ımporteerd. De uitvoering van de testcase kan opgesplitst worden in twee delen: enerzijds de export van de HelloService naar Jini en anderzijds de import van diezelfde service naar OSGi. We bespreken eerst de uitvoer van de HelloService-bundel. Export - HelloService Deze installatie gebeurde op een eerste host, Odila genaamd. De Jini Driver-bundel werd geladen binnen de Knopflerfish-implementatie van het OSGi-raamwerk. Naast de OSGi-omgeving startten we ook een Jini Lookup Service (figuur 6.3), of Reggie bijgenaamd, en een Jini-browser op op deze host. De Jini-browser stelde ons in staat te surfen tussen de verschillende LUS en een overzicht te krijgen van de verschillende aanwezige serviceregistraties. De HelloService-bundel werd vervolgens opgestart binnen het OSGi raamwerk. Daarop verscheen de helloservice.HelloService tussen de imported packages van de Jini Driver service, eveneens meldde de Jini Driver service via output-berichten in Knopflerfish dat de bundel geëxporteerd werd. Wanneer we vervolgens in de Jini-browser gingen kijken, zagen we dat het helloservice.HelloService-object inderdaad geëxporteerd was en nu beschikbaar was in de Odila-Reggie (zie figuur 6.4). In de Jini-browser waren we in staat de meegegeven entries, beschreven in het codefragment

53


Figuur 6.3: De Jini Lookup Service gestart op de host Odila

Figuur 6.4: Via de Jini-browser zien we dat na installatie van de exporterende bundel, de hello service beschikbaar wordt in Jini

in punt 6.2.1, op te vragen. We kregen de voorziene service informatie te zien zoals in het screenshot in figuur 6.5 weergegeven is. Met drie actoren binnen het exportproces (de Reggie, de Jini Driver service en de exporterende bundel), zijn verschillende sequenties van starten en verschillende sequenties van stoppen (of in het slechtste geval verdwijnen) mogelijk. De verschillende gevallen hebben we uitgetest en gaven allemaal positieve resultaten. De opstelling bleef steeds consistent. Import - testJiniImport Deze installatie gebeurde op een tweede host, Egidius genaamd. Opnieuw werd de Jini Driver bundel gestart binnen de Knopflerfish OSGi-omgeving en werd een Jini-browser gestart. De beide hosts stonden in hetzelfde netwerk, de browser detecteerde dan ook de Odila-Reggie en

54


Figuur 6.5: De service informatie van de geëxporteerde HelloService

gaf hetzelfde beeld als in figuur 6.4. Naast de Jini Driver bundel, installeerden we ook de HelloService-api-bundel. Deze bundel is een bundel met zuivere bibliotheekfunctie en bevat enkel de helloservice.HelloServiceinterface declaratie. Het installeren van deze bundel is nodig omdat de importerende bundel de interface-declaratie moet kennen van zijn gezochte bundel. De testJiniImport-bundel werd vervolgens geladen in het OSGi platform. De Jini Driver service gaf aan aangevraagd te worden door de bundel en een LookupCache-object te creëren. Eénmaal matching services gevonden, werd ons gemeld dat deze geregistreerd werden in het OSGi framework. Wanneer we bij de Jini Driver service gingen kijken naar de geëxporteerde packages, zagen we dat de helloservice.HelloService hier inderdaad aan toegevoegd was. We startten en stopten nu elk van de beide bundels afzonderlijk. Telkens werden de ge¨ımporteerde of geëxporteerde services netjes gederegistreerd en de Jini Driver service gereleased. Na het stoppen waren de bundels telkens opnieuw op te starten, zonder enig probleem. Opnieuw hebben we binnen dit proces verschillende actoren: de Reggie, de Jini Driver service, de Jini service en de importerende bundel. Deze kunnen in verschillende volgorde opgestart of gestopt worden of verdwijnen. De verschillende sequenties werden uitgetest en leidden steeds

55


tot een consistente opstelling. Besluit Het exporteren van een OSGi-bundel naar Jini en het importeren van een Jini service gaat zonder problemen. Zelfs het importeren van een eerder geëxporteerde service is perfect mogelijk. De bundels kunnen gestart, gestopt en verwijderd worden, telkens deregistreren of registreren de ge¨ımporteerde services zich opnieuw. Hetzelfde geldt voor de geëxporteerde services binnen Jini.

6.3

Andere mogelijke toepassingen

De toepassingen die we in de volgende paragrafen bespreken, werden niet ge¨ımplementeerd in deze scriptie, maar zijn enkele ideeën voor andere mogelijke demotoepassingen, die kwamen bovendrijven tijdens de ontwikkeling van de Jini Driver service. Ze kunnen als basis dienen voor verdere demonstraties of ontwikkelingen. Een eerste andere mogelijke toepassing die we beschrijven is een dynamische webcam-webpaginabundel. Deze OSGi-bundel maakt aan de hand van webcam-services die hij vindt in de Jini community, een webpagina aan met daarop de mogelijkheid deze webcamservices te openen. De webpagina publiceert hij via het gebruik van de OSGi http-service. De webcamservices die in Jini teruggevonden worden, zijn op hun beurt afkomstig en dus geëxporteerd vanuit OSGiraamwerken. Het is met deze raamwerken dat de webcamera’s verbonden zijn. Een client is dus in staat om een webpagina op te vragen die gecreëerd is door een OSGibundel en die een overzicht geeft van alle webcamera’s die op dat moment verbonden zijn met OSGi-raamwerken ergens in het Jini-netwerk. Via deze toepassing wordt opnieuw enerzijds de export- en importcapaciteit aangetoond en anderzijds de mogelijkheid te transporteren over het Jini-netwerk heen. Door de importerende bundel gebruik te laten maken van verschillende andere in het OSGi-raamwerk aanwezige bundels, zoals de http-service, is de bundel in staat een grote diversiteit aan services aan te bieden. Een andere mogelijke toepassing is het ontwikkelen van een bestandsverkenner-bundel. Deze OSGi-bundel kan op zoek gaan naar storage services in Jini. Bij het aanklikken van een bepaald bestand zal de bestandsverkenner automatisch opzoeken welke OSGi-bundel in staat is het

56


bestand te verwerken. Indien er geen geschikte bundel aanwezig is in het OSGi-raamwerk, kan hij zoeken in het Jini-netwerk of gebruikmaken van de bundlerepository-bundel in Knopflerfish OSGi. In tegenstelling tot de vorige toepassingen, wordt bij deze bundel enkel de importcapaciteit van de Jini Driver service benut. De voor handen zijnde OSGi services worden uitgebreid met de beschikbare Jini services.

6.4

Voordelen van het gebruik van de Jini Driver service

Na het testen van de bundel en het uitvoeren van een demotoepassing van de Jini Driver service, zijn we in staat een overzicht te geven van de verschillende voordelen die het gebruik van de Jini Driver service met zich meebrengt. Waar mogelijk tonen we het voordeel aan aan de hand van een voorbeeld. • De Jini Driver service zorgt voor al het typische Jini-management, wat de programmeur verlost van een heleboel werk en code. Om de winst qua code en werk aan te tonen, vergelijken we de situatie van een bundel die een Jini service wil gebruiken zonder dat de Jini Driver service aanwezig is in het raamwerk met deze waarbij de bundel wel gebruik kan maken van een in het raamwerk aanwezige Jini Driver service. We geven eerst de code die zou nodig zijn wanneer er geen Jini Driver service aanwezig is. // De interface van de Jini service die we willen gebruiken HelloService hello = null;

// Installeer een RMI Security Manager System.setSecurityManager(new RMISecurityManager());

// Maak de discovery van LUS mogelijk LookupDiscovery discovery = new LookupDiscovery(LookupDiscovery.ALL_GROUPS);

// Maak de discovery van services mogelijk ServiceDiscoveryManager serviceDiscoveryManager = serviceDiscoveryManager = new ServiceDiscoveryManager(lookupDiscovery, null);

57


// Definieer de service die we willen ServiceTemplate template = new ServiceTemplate(null, new Class[]{HelloService. class}, null);

// Start het beheer van de ontdekte services

die met ons template

overeenstemmen LookupCache cache = serviceDiscoveryManager.createLookupCache(template, null, new ServiceDiscoveryListener() {

public void serviceAdded(ServiceDiscoveryEvent event) { if (hello == null){ ServiceItem item = event.getPostEventServiceItem(); hello = (HelloService) item.service; } } public void serviceChanged(ServiceDiscoveryEvent event) { } public void serviceRemoved(ServiceDiscoveryEvent event) { hello = null; } );

// Gebruik de service service.sayHello("hello");

In de code is door middel van commentaar aangegeven wat de bundel allemaal zou moeten ondernemen om een service te kunnen importeren. Hij zou zelf moeten in staan voor de securityManager nodig om gebruik te kunnen maken van RMI, voor de discovery van zowel de LUS als de door hem gezochte services. Eénmaal de service gevonden, moet hij deze importeren en de originele Jini services blijven opvolgen. Dit laatste is nodig om te kunnen ingrijpen wanneer wijzigingen van de service optreden. Pas na al dit Jinimanagement, is de bundel in staat een methode van de Jini service aan te roepen. Men kan al aanvoelen dat een heel deel van deze code vervalt bij het gebruik van de Jini Driver service. We bekijken de code die zou nodig zijn bij aanwezigheid van een Jini Driver service.

58


// Haal de Jini Driver service op via de standaard manier om OSGi service op te halen JiniDriver driver = (JiniDriver) bundleContext.getService( bundleContext.getServiceReference( JiniDriver.class.getName()));

// Definieer de Jini services die moeten geimporteerd worden ServiceTemplate templates [ ] ={ new ServiceTemplate(null, new Class[] { HelloService.class }, null) };

// Importeer de Jini services als OSGi services driver.setServiceTemplates(templates);

// Haal de geimporteerde Jini service op HelloService service = (HelloService) bundleContext.getService( bundleContext.getServiceReference("HelloService"));

// Gebruik de service service.sayHello("hello");

Het eerste wat natuurlijk opvalt is dat deze code veel korter en minder complex is. Alles wat samengaat met het gebruik van RMI en het join en discovery protocol binnen Jini wordt uitgevoerd door de Jini Driver service. De importerende bundel dient enkel de Jini Driver service op te halen, net zoals hij elke andere standaard-service zou ophalen, en zijn service template door te geven. Eénmaal services ge¨ımporteerd, kan de bundel de Jini services op dezelfde standaardwijze aanroepen. Er is dus geen discovery- en join-code nodig, noch is er extra speciale code nodig voor het gebruik van de Jini Driver service. Het standaard aanroepen van services binnen OSGi volstaat. • Wat niet aan bod kwam in de bovenstaande codefragmenten, maar wat zeker zal moeten gebeuren bij het niet gebruiken van de Jini Driver service, is de afhandeling van de leases. De bundel die zelfstandig een Jini service aanroept, moet ook de leases van de service beheren. Bij gebruik van de Jini Driver verzorgt de Jini Driver volledig de afhandeling van de leases. De gebruikende bundel hoeft hier niets van te merken.

59


• De bruikbaarheid van het OSGi-raamwerk gaat er op vooruit, doordat nieuwe Jini Services toegevoegd worden aan de beschikbare services. • De Jini-gemeenschap vaart er ook wel bij, aangezien deze kan gebruik maken van de geëxporteerde services van het OSGi Service Platform. • Bundels dienen zich niet bewust te zijn van Jini of van de Jini Driver service. Deze eigenschap die een logisch gevolg is van de transparency voorwaarde, zorgt er voor dat OSGi services nietswetend kunnen gebruik maken van Jini services en vice versa.

60

Hoofdstuk 7

Besluit Het doel van dit eindwerk was tweeledig: enerzijds een duidelijk beeld geven van de relatie tussen de Jini en OSGi architecturen en anderzijds een implementatie ontwikkelen van een brug tussen beiden. Allereerst werd onderzoek gedaan naar de technologieën achter de Jini- en OSGi-architectuur. Er werd onderzocht hoe er binnen de architecturen omgegaan wordt met diensten en hoe deze zouden kunnen uitgewisseld worden. Tijdens het bestuderen van de literatuur, bleken de OSGi ” Service Platform -specificaties, release 3, reeds een sectie te bevatten over de Jini en OSGi ” combinatie. Deze sectie bevatte aanbevelingen omtrent een Jini Driver service-bundel die ons in staat stelt OSGi-diensten te exporteren naar Jini en Jini-diensten te importeren in het OSGiraamwerk. Het Jini Driver service-concept werd verder uitgewerkt. De functionele vereisten werden nagegaan en een gepaste architectuur werd ontwikkeld. Tijdens de implementatie kwamen enkele knelpunten aan het licht zoals het verlies van veiligheid bij het gebruik van de codebase en het dubbel gebruik van geëxporteerde klassen. Voorstellen tot oplossingen of aanpassingen werden hierover geformuleerd. Eénmaal de Jini Driver service ge¨ımplementeerd, werd een demotoepassing ontwikkeld die ons in staat stelt de werking van de Jini Driver service te testen en aan te tonen. Er werd enerzijds een bundel aangemaakt die een dienst exporteert en anderzijds een bundel die de geëxporteerde dienst opnieuw wenst te importeren. Aan de hand van deze bundels in een testopstelling, werd de werking van de Jini Driver service aangetoond.

61

Hoofdstuk 7. Besluit

Via het gebruik van de Jini Driver service wordt de waaier van beschikbare diensten binnen het OSGi-raamwerk, uitgebreid met deze uit het Jini-netwerk, kunnen er extra diensten beschikbaar worden in het Jini-netwerk en wordt het gebruik van een Jini-dienst zeer eenvoudig. We mogen dan ook stellen dat Jini en OSGi als teamspelers kunnen beschouwd worden. Ze hebben elk hun eigenschappen en specifieke kenmerken, maar zijn in staat elkaar aan te vullen en samen te werken. Bij de realisatie van dit eindwerk hebben we heel wat ervaring opgedaan over hoe men bij het ontwerp van een dergelijk softwarecomponent te werk gaat. Bovendien hebben we leren werken met verschillende softwaretechnologieën. Het was een boeiende en leerrijke ervaring.

62

Bijlage A

Overzicht van Jini’s concurrenten In de volgende paragrafen geven we een beperkt overzicht van de mede-marktspelers van Jini, die tot op zekere hoogte als concurrenten kunnen gezien worden. Het gaat hier echter niet over een limitatief overzicht.

A.1

OpenWings

Dit is een open-community, non-proprietary poging om specificaties te definiëren voor zichzelf vormende en zichzelf onderhoudende systemen. In juni 1999 werd het OpenWings consortium opgericht door Motorola en Sun Microsystems. De OpenWings-architectuur voorziet een raamwerk om plug-and-play, service-georiënteerde, netwerk-centrische, zelf-vormende, zelf-genezende systemen te bouwen die onafhankelijk zijn van de middleware, databanken, platformen en de ontwikkelomgeving. Voor OpenWings luidt de klantenvisie: closing the personal digital divide”. ” http://www.openwings.org

A.2

Salutation

De Salutation-architectuur werd gecreëerd om de problemen van discovery en utilization op te lossen bij een brede waaier van toepassingen en uitrusting en in een omgeving van wijd-verspreide connectiviteit en mobiliteit. De architectuur voorziet een standaard methode voor applicaties, services en toestellen om hun capaciteiten in te schrijven of ten toon te stellen bij andere applicaties, services en toestellen en

63

Bijlage A. Overzicht van Jini’s concurrenten

tegelijk hun capaciteiten uit te zoeken. De architectuur stelt applicaties, services en toestellen ook in staat om andere applicaties, services en toestellen te zoeken voor een bepaalde capaciteit en om sessies met hen aan te vragen en op te zetten om hun capaciteiten te gebruiken. Wegens de grote diversiteit aan doeltoepassingen en uitrusting in een wijd-verspreide connectiviteit, is de architectuur, processor, besturingssysteem en communicatie-protocol onafhankelijk en laat ze schaalbare implementaties toe, zelfs in zeer goedkope toestellen. [19] De centrale slogan voor Salutation luidt: Find and Bind” for Pervasive Computing. ” http://www.salutation.org Op zijn webstek deelt het Salutation consortium, gesticht in juli 1995, mee dat het zichzelf zal ontbinden op 30 juni, 2005.

A.3

UPnP

Universal Plug and Play (UPnP) is een architectuur voor doordringende peer-to-peer netwerkconnectiviteit van intelligente toepassingen, draadloze toestellen, en pc’s onder welke vorm dan ook. Het is ontworpen om eenvoudig te gebruiken, flexibele en standaard-gebaseerde connectiviteit te introduceren in ad-hoc of onbeheerde netwerken, thuis, in kleine bedrijven, in publieke plaatsen of verbonden met het Internet. UPnP is een gedistribueerde, open netwerkarchitectuur die TCP/IP en de Web technologieën verheft om naadloos proximity networking mogelijk te maken bovenop de controle en data transfer tussen netwerktoestellen thuis, op het kantoor en op openbare plaatsen. UPnP is meer dan zomaar een eenvoudige uitbreiding van het plug and play peripheral model. Het is ontworpen om zero-configuratie te ondersteunen, onzichtbaar netwerken en automatische discovery voor een diversiteit aan soorten toestellen van een brede waaier aan verkopers. Dit betekent dat een toestel dynamisch een netwerk kan vervoegen, een IP adres verkrijgen, zijn capaciteiten overbrengen en leren over de aanwezigheid en capaciteiten van andere toestellen. DHCP en DNS servers zijn optioneel en worden enkel gebruikt wanneer ze beschikbaar zijn binnen het netwerk. Uiteindelijk kan een toestel het netwerk eenvoudig en automatisch verlaten, zonder enige ongewenste situatie achter te laten. UPnP: Foundation of the Connected Home”. ” http://www.upnp.org

64


A.4

Inferno

Inferno is een compact besturingssysteem ontworpen om gedistribueerde en netwerksystemen te bouwen op een brede waaier van toestellen en platformen. Het werd oorspronkelijk ontwikkeld door het Computing Science Research Centre of Bell labs”, de R&D afdeling van Lucent ” Technologies, en werd later verder ontwikkeld door Vita Nuova en Lucent. Inferno kan als een gebruikersapplicatie draaien bovenop een bestaand besturingssysteem of als een stand-alone besturingssysteem. http://www.vitanuova.com/inferno/

A.5

HAVi

Home Audio Video Interoperability (HAVi) is een initiatief van acht grote Consumer Electronics bedrijven. De acht CE bedrijven zijn Grundig AG, Hitachi, Ltd., Matsushita Electrical Industrial Co., Ltd. (Panasonic), Royal Philips Electronics, Sharp Corp., Sony Corp., Thomson Multimedia en Toshiba Corp. De eerste specificaties van deze architectuur zagen het licht in december 1998. [20] De HAVi-architectuur specifieert een set Application Programming Interfaces (APIs) die producenten van elektronica voor consumenten, en anderen toelaten om applicaties te ontwikkelen voor het thuis-netwerk. Het thuis-netwerk wordt gezien als een gedistribueerd computing platform. Het voornaamste doel van de HAVi-architectuur is te verzekeren dat producten van verschillende verkopers kunnen samenwerken. De HAVi-architectuur is een open, licht-gewicht, platform onafhankelijke en architecturaal neutrale specificatie. Ze kan ge¨ımplementeerd worden op verschillende hardware of software platformen en houdt geen opties in die uniek zijn voor één van de platformen. [21] HAVi for networking digital home entertainment products”. ” http://www.HAVi.org

A.6

Ninja

Berkeley’s Ninja-architectuur is ook gericht op zeer schaalbare netwerk-georiënteerde applicaties. Het Ninja project tracht de brede innovatie van robuste, schaalbare, gedistribueerde Internet

65


services mogelijk te maken en de klasse van extreem heterogene toestellen toe te laten deze services naadloos te gebruiken. [22] Het Ninja project: Enabling Internet-scale Services from Arbitrarily Small Devices”. ” http://ninja.cs.berkeley.edu

66

Bijlage B

Ledenlijst OSGi Een actuele lijst is steeds terug te vinden op http://www.osgi.org/about/member list.asp Alpine Electronics Europe Gmbh http://www.alpine-europe.com/ Aplix Corporation http://www.aplix.co.jp/ Belgacom http://www.belgacom.be/ BMW Group http://www.bmw.com/ Cablevision Systems http://www.cablevision.com/ Computer Associates http://www.ca.com/ Deutsche Telekom AG http://www.telekom3.de/ Echelon Corporation http://www.echelon.com/ Electricit´ e de France (EDF) http://www.edf.fr/ Ericsson Mobile Platforms AB http://www.ericsson.com/mobileplatforms Esmertec http://www.esmertec.com/ Espial Group, Inc. http://www.espial.com/ ETRI Electronics and Telecommunications Research Institute http://www.etri.re.kr/ France Telecom http://www.francetelecom.fr/ Gatespace Telematics AB http://www.gatespacetelematics.com/ Gemplus http://www.gemplus.com/ Hitachi, Ltd. http://www.koigakubo.hitachi.co.jp/ IBM Corporation http://www.ibm.com/ Industrial Technology Research Institute http://www.itriweb.itri.org.tw/ Insignia Solutions http://www.insignia.com/ Intel Corporation http://www.intel.com/

67

Bijlage B. Ledenlijst OSGi

KDDI R&D Laboratories, Inc. http://www.kddilabs.jp/ KT Corporation http://www.kt.co.kr/kt home/eng/index.jsp Mitsubishi Electric Corporation http://www.mitsubishielectric.com/ Motorola, Inc. http://www.motorola.com/ NEC Corporation http://www.nec.com/ Nokia Corporation http://www.nokia.com/ NTT http://www.ntt.co.jp/index e.html Oracle Corporation http://www.oracle.com/ Panasonic Technologies, Inc. http://www.research.panasonic.com/ Philips Consumer Electronics http://www.philips.com/ ProSyst Software GmbH http://www.prosyst.com/ Robert Bosch Gmbh http://www.bosch.com/ Samsung Electronics Co., Ltd. http://www.samsung.com/ SavaJe Technologies, Inc. http://www.savaje.com/ Sharp Corporation http://www.sharp.co.jp/ Siemens AG http://www.siemens.com/ Sun Microsystems, Inc. http://www.sun.com/ Telcordia Technologies, Inc. http://www.telcordia.com/ Telefonica I+D http://www.tid.es/ TeliaSonera http://www.teliasonera.com/ Toshiba Corporation http://www.toshiba.co.jp/ Vodafone Group Services Limited http://www.vodafone.com/

68

Bijlage C

Beknopt overzicht van de JiniDriver-bundel C.1

org.knopflerfish.bundle.jini package

org.knopflerfish.bundle.jini.Activator org.knopflerfish.bundle.jini.OsgiToJini org.knopflerfish.bundle.jini.ToJiniExportingServiceTracker org.knopflerfish.bundle.jini.ToJiniExportedService org.knopflerfish.bundle.jini.BundleCodeBaseService org.knopflerfish.bundle.jini.BundleHttpContext org.knopflerfish.bundle.jini.JiniDriverServiceFactory org.knopflerfish.bundle.jini.FromJiniImportingListener org.knopflerfish.bundle.jini.JiniDriverImpl

C.2

org.osgi.service.jini package

org.osgi.service.jini.JiniDriver

69

Bijlage D

Gebruikte tools Ant Een build-tool om het compileren, builden van bundels en genereren van javadoc te automatiseren. http://ant.apache.org/ ArgoUML-0.16.1 Gebruikt voor het opstellen van de UML klassediagramma. http://argouml.tigris.org AutoScreenRecorder 1.0 Pro Screen capturing tool, gebruikt bij de demo-demonstratie. http://www.wisdom-soft.com CVS Een Concurrent Versions System. http://www.cvshome.org/ Eclipse Een integrated development environment (IDE) uitermate geschikt voor Java-ontwikkeling. http://www.eclipse.org/ Knopflerfish Gebruikt als implementatie van de OSGi-specificatie. http://www.knopflerfish.org LATEX Het typesetting systeem waarmee deze scriptie geschreven is. http://www.ctan.org/ Microsoft PowerPoint 2002 Gebruikt voor het opstellen van diaprojectie’s. http://www.microsoft.com Microsoft Visio 2002 Gebruikt om figuren met samen te stellen. http://www.microsoft.com/ MiKTEX Een compleet TEX-systeem voor Microsoft Windows. http://www.MiKTeX.org

70

Bijlage D. Gebruikte tools

Sun Java 2 SDK 1.4.2 Om alle Java software uit te voeren op de PC. http://java.sun.com/j2se/1.4.2 Sybase Powerdesigner v10 Gebruikt voor het opstellen van de UML sequentiediagramma. http://www.sybase.com TEXnicCenter Een integrated development environment (IDE) om LaTeX-documenten, zoals deze scriptie, te ontwikkelen binnen Microsoft Windows. http://www.TeXnicCenter.org TortoiseSVN Open-source cliënt voor het Subversion version control systeem. http://www.tortoisesvn.tigris.org

71

Bijlage E

Inhoud van de bijgevoegde CD-ROM • Dit boek in pdf-formaat • De finale Powerpoint-presentatie gebruikt voor de thesisverdediging op 25 mei 2005 • Software – De Jini Driver service-bundel – De broncode van de Jini Driver service-bundel – De Javadocs van de Jini Driver service – De ontwikkelde testbundels – De broncode van de testbundels – Een Reggie of Jini Lookup Service – De Jini-browser – Een http-resourcemanager OSGi-bundel om de Reggie bestanden ter beschikking te stellen (nodig bij het opstarten van de Reggie) • Een Knopflerfish OSGi-omgeving, geconfigureerd om alle besproken en nodige bundels standaard in te laden • Handleidingen om de verschillende componenten op te starten

72

Bibliografie [1] Sun Microsystems, Inc. Jini Network Technology. http://www.sun.com/software/jini/ (29 May 2005). [2] S. Li, R. Ashri, M. Buurmeijer, E. Hol, B. Flenner, J. Scheuring, A. Schneider. Professional Jini. Wrox Press Ltd., 2000. [3] Sun Microsystems, Inc. Jar manifest specificaties. http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#JAR%20Manifest (29 May 2005). [4] Atinav Inc. aveLink Embedded Gateway. http://www.atinav.com/osgi/ (29 May 2005). [5] Connected Systems. HubTea Embedded Server. http://www.connectedsys.com/eng/index.html (29 May 2005). [6] Echelon. The LonWorks Network Platform. http://www.echelon.com/products/lonworks/ (29 May 2005). [7] Espial. Espial DeviceTop. http://www.espial.com/index.php?action=products,devicetop (29 May 2005). [8] Knopflerfish OSGi. The Knopflerfish OSGi framework. http://www.knopflerfish.org (29 May 2005). [9] Gatespace Telematics AB. Ubiserv. http://www.gatespacetelematics.com/userarea/login/ubiserv.shtml (29 May 2005). [10] IBM Software. IBM Service Management Framework. http://www-306.ibm.com/software/wireless/smf/ (29 May 2005). [11] ProSyst Software. mBedded Server Framework. http://www.prosyst.com/products/osgi framework.html (29 May 2005).

73

Bibliografie

[12] Samsung. Samsung Service Provider. http://www.samsung.com/ (29 May 2005). [13] Siemens VDO Automotive. Top Level Architecture (TLA). http://www.siemensvdo.com/default.aspx?menu=tla (29 May 2005). [14] The OSCAR Team. Open Source Cluster Application Resources(OSCAR). http://oscar.openclustergroup.org/ (29 May 2005). [15] The Open Services Gateway Initiative. Osgi service platform release 3. Device Access Specification, p223. IOS Press, March 2003. http://www.osgi.org. [16] The Open Services Gateway Initiative. Osgi service platform release 3. Jini Driver Service Specification, p489. IOS Press, March 2003. http://www.osgi.org. [17] P. Minnig, M. Widmer. Jini at your Doorstep - Jini For Limited Devices. Diploma Thesis DA-2002.10, Swiss Federal Institute of Technology Zurich, 2001-2002. [18] C. Kr¨ ugel. Jini Connectivity for Home and Building Automation A Case Study for EIB. Diplomarbeit, Institut f¨ ur Rechnergest¨ utzte Automation der Technischen Universit¨ at Wien, 2000. [19] The Salutation Consortium. Salutation Architecture Specification (Part-1), Version 2.1. http://www.salutation.org. [20] HAVi Organization. Technical Background. HAVi, the A/V digital network revolution http://www.HAVi.org. [21] HAVi, Inc. The HAVi Specification, Version 1.1. http://www.HAVi.org. [22] S.D. Gribble, M. Welsh, R. von Behren, E.A. Brewer, D. Culler, N. Borisov, S. Czerwinski, R. Gummadi, J. Hill, A. Joseph, R.H. Katz, Z.M. Mao, S. Ross, B. Zhao. The Ninja Architecture for Robust Internet-Scale Systems and Services. The University of California at Berkeley, 2000. http://ninja.cs.berkeley.edu.

74

Jini en OSGi, teamspelers of rivalen

Recommend Documents