OSGi.nl

De laatste jaren hebben we intern en met klanten regelmatig een discussie over de desktop. Het eerste discussiepunt is dan vaak: wel of geen web applicatie. Daarbij worden de voor- en nadelen van web applicaties afgewogen tegen het gebruik van een desktop applicatie.Wat meestal niet gebeurt, is dat het extra stapje achteruit genomen wordt, om eens te kijken waarom web applicaties ineens zo populair werden. Dat antwoord vind je mijns inziens niet als je kijkt naar de technologie die erachter zit: een complexe mix van server-side code, client-side browser-specifieke javascript, state management, gebruik van HTML, XML en CSS om het er toch maar enigzins uit te laten zien als een “normale applicatie”. Dat aspect van web applicaties is verre van elegant!

Het probleem ligt ergens anders.

Een van de grootste nadelen van desktop applicaties is het uitrollen en updaten ervan naar grote groepen gebruikers. Dat is tevens het grootste verschil met web applicaties, waar het enige wat je uit moet rollen een (ondersteunde) browser versie is.

Nu zijn er al verschillende pogingen gedaan om het beheren van desktop applicaties te vereenvoudigen. Als we ons even beperken tot Java, dan zijn er belangrijkste opties:

• applets, en de daaraan gerelateerde java plugins, die in een HTML pagina werden opgenomen;
• Java web start, waarbij in feite de browser alleen nog gebruikt wordt als bootstrap mechanisme om de applicatie voor ‘t eerst te installeren.

Applets zijn niet echt geschikt om een desktop applicatie mee te bouwen. Je zou er kleine stukjes web applicatie mee kunnen bouwen, bijvoorbeeld om een grafiek component interactief te maken, maar als je er een volledige applicatie mee gaat maken loop je tegen allerlei visuele en technische beperkingen aan, zoals:

• als mijn applet de hele pagina vult, wat voegt de browser er dan nog aan toe?
• als ik een nieuw window open, en de gebruiker sluit het browser window, dan sluit mijn applicatie.

Wat dat betreft is Java web start al beter geschikt voor desktop applicaties. Vanuit een browser installeer je de applicatie met één muisclick en vervolgens is de applicatie lokaal op je computer beschikbaar. Je hebt geen browser meer nodig om hem te starten.

Het is een goede eerste stap, maar het lost de volgende problemen nog niet op:

• Java web start checkt alleen bij het starten van de applicatie of er updates zijn en als die er zijn, worden ze gelijk geïnstalleerd. Vanuit het oogpunt van de gebruiker is dat zo’n beetje het slechtste moment: die wil aan de slag en moet wachten tot zijn applicatie is “geupdate”.
• Applicaties zijn nog steeds monolieten: één grote berg code die meestal tijdens ontwikkeling gepackaged moet worden. Dat strookt niet met het bouwen van applicaties als componenten en het run-time samenstellen van applicaties uit componenten.

Beide problemen vragen eigenlijk om een uitgebreidere en gedetailleerdere controle over het life-cycle model. Zowel van de hele applicatie als van de individuele componenten.

In de basis voorziet OSGi hierin, maar nog steeds zul je moeten bepalen hoe je OSGi in een Swing applicatie wilt gebruiken. De oplettende lezer ziet dat ik hier ineens de scope nog wat aanscherp tot Swing, waarmee ik andere UI toolkits als SWT niet wil diskwalificeren, maar ik heb ‘t nodig voor mijn bruggetje richting JSR-296: The Swing Application Framework.

Zo’n 10 jaar na het ontstaan van Swing wil men nu een basis leggen voor het bouwen van desktop applicaties met Swing. Daarbij wordt de focus gelegd op de volgende core services:

• life-cycle management van de applicatie;
• beheer van resources (voornamelijk ten dienste van het vertalen van applicaties);
• actions, een uniforme manier om kort lopende handelingen in de applicatie uit te voeren;
• tasks, een uniforme manier om lang lopende, eventueel onderbreekbare handelingen uit te voeren;
• sessions, het zo goed mogelijk onthouden van de toestand van de applicatie.

Het model wat vervolgens geschetst wordt in het introductie artikel vertoont opmerkelijke overeenkomsten met het OSGi service model:

De application context is vergelijkbaar met de OSGi bundle context en wordt gebruikt om verschillende services ter beschikking te stellen. De application kan worden geïmplementeerd als bundle en krijgt daardoor een life-cycle die vergelijkbaar is met dit model.

Er zijn zelfs een aantal extra voordelen die je krijgt als je deze specificatie implementeert met OSGi.

Het life-cycle model voor de applicatie gaat verder in die zin dat je nu de applicatie kunt updaten zonder hem helemaal te hoeven stoppen. Daarnaast kun je de applicatie zelf ook opdelen, waardoor je hem op maat kunt samenstellen uit componenten. Bovendien heb je meer controle over het moment waarop je (delen van je) applicatie update. Immers, de “management agent” draait niet alleen bij het opstarten van de applicatie, maar blijft actief en kan daardoor op de achtergrond componenten ophalen en installeren (bijvoorbeeld bij het afsluiten of op een ander “gunstig” moment).

Alle andere services die via de context ter beschikking gesteld worden, kunnen ook dynamisch gemaakt worden. Dat betekent bijvoorbeeld concreet dat je verschillende talen in de vorm van bundles ter beschikking kunt stellen en wederom zonder te hoeven herstarten kunt installeren. Daardoor kun je bijvoorbeeld een gebruiker “live” van taal laten wisselen. Hetzelfde geldt ook voor andere services: de look and feel, extra functionaliteit die slechts zelden nodig is of waar een gebruiker een licentie voor heeft verkregen, en zelfs lang lopende taken die met wat extra inspanning zelfs remote uitgevoerd kunnen worden.

Momenteel is JSR-296 nog volop in ontwikkeling. De eerste implementatie is inmiddels uit, en een NetBeans IDE prototype met support hiervoor ook. Het zal interessant zijn om te zien hoe deze specificatie zich ontwikkelt. Ik verwacht niet dat de daadwerkelijke implementatie op basis van OSGi zal werken, maar het ontwerp leent zich er wel voor en het loont waarschijnlijk de moeite om zo’n implementatie te maken.