OSGi.nl

Een van de services van de OSGi core specificatie is de start level service. De naam impliceert dat je hiermee de start volgorde van bundles kunt bepalen. Toch zitten daar wat haken en ogen aan waar je op moet letten. Dit artikel baseert zich daarbij op OSGi R4.1, ofwel start level specificatie versie 1.1.Allereerst, wat doet deze service precies?

Als je bekend bent met de runlevels van linux dan is dat een goede analogie. Start levels worden (door de management agent) toegekend aan bundles. Daarnaast zal het framework zelf ook altijd in een bepaalde start level zitten. Simpel gezegd, alleen bundles met een start level kleiner dan of gelijk aan de start level van het framework zijn actief. Heeft een bundle een hogere start level dan het framework, dan zal hij dus niet actief zijn. Wel kun je aangeven dat zo’n bundle gestart moet worden zodra het framework de betreffende startlevel krijgt (persistently started).

Bij het opstarten zal het framework stap voor stap door de start levels heen gaan tot de gewenste level bereikt is. Dat betekent dat je door het toekennen van start levels controle hebt over de opstartvolgorde van bundles. Overigens heb je geen controle over de volgorde waarin bundles met dezelfde start level gestart worden.

Er zijn echter twee dingen die je hierbij niet uit het oog moet verliezen:

1. De start level service is optioneel en als deze niet aanwezig is, heb je geen controle meer over de opstartvolgorde.
2. Ga nooit uit van de aanwezigheid van bijvoorbeeld services die gepubliceerd worden door bundles met een lagere startlevel. Immers, services zijn dynamisch en kunnen op elk moment weer verdwijnen. Een heel goed voorbeeld is tijdens een update van zo’n bundle. De service zal dan altijd even verdwijnen. Hou je hier geen rekening mee, dan merk je die problemen pas wanneer je daadwerkelijk updates gaat doen.

Met andere woorden, in principe moeten bundles altijd in een willekeurige volgorde gestart kunnen worden zonder dat dat problemen oplevert. Hooguit kan ‘t zo zijn dat een andere volgorde minder efficiënt is, maar ‘t kan niet zo zijn dat een applicatie daardoor helemaal niet meer opstart. Zorg dus dat je dit al tijdens de ontwikkeling van je OSGi applicatie controleert.

Met dat in ‘t achterhoofd zijn er een aantal interessante toepassingen voor start levels:

• Diagnostics mode
  Waarmee je extra bundles activeert die monitoring of debugging functionaliteit toevoegen. Zo’n diagnostics mode heeft dus een hogere start level dan normaal en kan door een management agent worden geactiveerd als er iets mis lijkt te gaan in het framework.
• Power save mode
  Voor embedded applicaties kan een speciale power save start level bundles uitschakelen die in zo’n mode niet nodig zijn. Zo zou een applicatie met een user interface in zo’n mode die user interface onzichtbaar kunnen maken.
• High priority features
  Denk hierbij aan bundles die als eerste gestart moeten worden, zoals logging of een splash window. Dat zijn typisch bundles die je een lage start level geeft zodat ze snel beschikbaar zijn.

Samengevat kun je stellen dat start levels gebruikt kunnen worden om de opstartvolgorde van bundles en daarmee je applicatie te bepalen. Je mag er echter niet van uitgaan als je je bundle ontwerpt (als bundle weet je immers niets van start levels).