OSGi: modulariteit zonder herstarts voor Enterprise Java applicaties

Wie de huidige ontwikkelingen rondom Java 7 een beetje heeft gevolgd zal het niet ontgaan zijn dat modulariteit tegenwoordig een begrip is dat overal opduikt: er waren en zijn diverse JSR's rond dit onderwerp: JSR-277, inmiddels gesuspend, JSR-291, gebaseerd op OSGi, JSR-294,  een module-systeem voor Java en recentelijk Project Jigsaw.

Waar andere JSR's nieuw terrein verkennen is OSGi reeds jaren een standaard die zichzelf ruimschoots bewezen heeft in diverse toepassingen. OSGi is als standaard rond 1999 ontstaan in de embedded hardware wereld. Met de beperkte capaciteit van deze hardware was het geen optie om voor elke Java applicatie een nieuwe Virtual Machine te starten, zodat meerdere applicaties eenvoudig dezelfde runtime moesten kunnen delen. Standaard levert Java hierbij echter onvoldoende ondersteuning: het lineaire classpath staat het niet toe om met meerdere versies van libraries te werken, er is geen mogelijkheid tot het verbergen van implementatiedetails voor andere applicaties en het expliciet maken van onderlinge afhankelijkheden, er is geen standaard faciliteit om applicaties een eigen lifecycle te geven en bovendien ontbreekt er een mechanisme voor het publiceren en ontdekken van services die door applicaties geboden worden. Om applicaties van verschillende leveranciers effectief samen te laten werken in een enkele VM zonder dat na elke installatie herstart moet worden zijn dit belangrijke eisen. 

Om aan deze eisen tegemoet te komen is de OSGi standaard opgesteld. Deze standaard wordt door meerdere organisaties die verenigd zijn in het OSGi consortium beheerd. Er zijn diverse implementaties van de OSGi standaard, waarvan 4.1 de huidige versie is en 4.2 op dit moment ontwikkeld wordt. Bekende open source implementaties zijn o.a. Apache Felix en Equinox. De laatste is met name bekend als de motor achter het plug-in model van Eclipse, de populaire Java ontwikkelomgeving.

Toepassing van OSGi

Jarenlang bleef de toepassing van OSGi beperkt tot embedded devices (BMW gebruikt bijv. OSGi in zijn auto's) en enkele specialistische toepassingen. De laatste jaren is er echter ook steeds meer interesse ontstaan voor het gebruik van OSGi in de Enterprise Java wereld. Zo maken vele application servers tegenwoordig gebruik van OSGi en zijn er meerdere frameworks en runtime omgevingen beschikbaar om ook als applicatie-ontwikkelaar OSGi te kunnen toepassen op de server. Ook zijn er diverse oplossingen bedacht om de ontwikkelaar te ondersteunen in het omgaan met de complexiteit die een volledig dynamische omgeving als OSGi met zich meebrengt: services kunnen op elk moment komen maar ook verdwijnen, zodat een applicatie te allen tijde om moet kunnen gaan met het onbeschikbaar worden van een gebruikte service. In eerste instantie lijkt dit de complexiteit ten opzichte van standaard Java applicaties alleen maar te verhogen, maar als verder gekeken wordt blijkt dat juist het correct afhandelen van dit soort situaties essentieel is voor het bouwen van robuuste software die kan blijven werken als andere applicaties tijdelijk onbeschikbaar zijn, bijvoorbeeld omdat er een nieuwe versie geïnstalleerd wordt.

Een framework dat hier een belangrijke rol in speelt is Spring Dynamic Modules (Spring-DM), een open-source framework dat het programmeermodel van Spring integreert met OSGi zodat een oplossing ontstaat waarin OSGi een volwaardig componentmodel krijgt. Het pionierswerk dat in Spring-DM is verricht door medewerkers van SpringSource, BEA en Oracle wordt op dit moment gestandaardiseerd binnen RFC-124 dat onderdeel zal uitmaken van OSGi 4.2. Spring-DM versie 2 zal de referentie-implemenatie zijn van deze nieuwe standaard.
Server-side OSGi

Dit alles betekent dat er een heel nieuw toepassingsgebied voor OSGi is ontstaat: de server-side. De mogelijkheden die OSGi biedt voor het netjes modularisen van applicaties en voor het werken volgens een dynamische, service-gebaseerde aanpak sluiten goed aan op de wensen die tegenwoordig leven op het gebied van application servers. Zo is het vaak geen optie meer om een applicatie volledig uit de lucht te halen als een deel van de funtionaliteit geupgrade moet worden, laat staan dat daarna de server waarop ook andere applicaties draaien gereboot kan worden. Verder onstaan er steeds meer problemen met de verschillende versies van third party libraries die applicaties nodig hebben: de enige oplossing is dan vaak om elke applicatie al zijn afhankelijkheden maar mee te laten packagen en dan maar te hopen dat deze onderling compatibel zijn; en bovendien dat er niet ergens in de classloader hierarchy al andere versie bekend waren van de gebruikte libraries die in de weg zitten. Voor het delen van standaard functionaliteit over applicaties heen zijn eigenlijk alleen maar oplossingen beschikbaar die gebaseerd zijn op remoting: een faciliteit voor het aanbieden van lokale services die door meerdere applicaties eenvoudig gedeeld kunnen worden ontbreekt. Een OSGi Enterprise Expert Group is inmiddels bezig om een aantal eisen die het gebruik van OSGi in bedrijfsapplicaties stelt in kaart te brengen en oplossing in dit gebied te standaardiseren.

Op dit moment blijft de toepassing van OSGi in de meeste servers beperkt tot de binnenkant: producten als IBM's WebSphere Application Server en Suns laatste Glassfish release maken intern weliswaar gebruik van OSGi, maar de applicatie-ontwikkelaars merken daar uiteindelijk weinig van. Zij programmeren nog altijd op de vertrouwde Java EE wijze, waarbij applicaties als grote monolieten op de server uitgerold worden. De markt is echter in beweging: er komen diverse poducten beschikbaar die zich richten op het gebruik van OSGi in bedrijfsapplicaties, zoals Infiniflow van Paremus. Deze producten stellen de gebruiker in staat om bedrijfsapplicaties te ontwikkelen die profiteren van de mogelijkheden die OSGi biedt, maar vereisen wel een manier van werken die anders is dan Java EE ontwikkelaars gewend zijn. Een van de redenen dat de meeste application servers OSGi voorlopig alleen intern gebruiken is dat het gebruik van OSGi in bedrijfsapplicaties, naast de genoemde voordelen, ook een aantal problemen met zich meebrengt. Deze problemen worden vooral veroorzaakt doordat veel enterprise libraries code bevatten die niet compatibel is met het OSGi model, waarin zeer strikte zichtbaarheidsregels gelden. Zo kan een library standaard geen code 'zien' van applicaties die van deze library gebruik maken, terwijl de werking van veel moderne libraries juist gebaseerd is op het principe dat dit wel mogelijk is. Hierdoor kunnen libraries bijv. dynamisch code genereren op basis van de code in applicaties: in OSGi is dit niet zomaar mogelijk, omdat de libraries geen afhankelijkheid declareren op de betreffende applicaties.

De SpringSource dm Server

Een andere oplossing op dit gebied is de SpringSource dm Server. Dit is een application server die gebaseerd is op Apache Tomcat, Equinox en Spring-DM. Het doel van de dm Server is om het mogelijk te maken bestaande enterprise libraries, zoals Spring en Hibernate, te kunnen toepassen binnen web- en andere bedrijfsapplicaties die ook zelf gebruik maken van OSGi. Het grote verschil met de andere servers is dus dat OSGi hier niet uitsluitend 'onder de motorkap' wordt gebruikt: applicatie-ontwikkelaars kunnen zelf aan de slag met OSGi modules (zogenaamde bundles) om hun grote applicaties op te delen in kleinere modules die communiceren via een service-gebaseerde architectuur.
Dit is geen SOA in de gebruikelijke zin van het woord: de individuele modules draaien nog altijd binnen dezelfde server, maar hun afhankelijkheden zijn expliciet gemaakt en er is sprake van een veel lossere koppeling door het gebruik van services. Dit levert diverse voordelen op. Een is een groter potentiëel voor hergebruik: meerdere applicaties kunnen dezelfde service gebruiken. Verder betekent dit bij meerdere applicaties per server vaak een lager geheugengebruik: libraries hoeven maar eens per server geladen te worden in plaats van eens per applicatie. Daarnaast is ook de server zelf modulair van opzet, zodat ongebruikte functionaliteit eenvoudig uitgeschakeld kan worden, wat de opstarttijd en geheugenverbruik ten goede komt. Zo kan de Tomcat server volledig uitgeschakeld blijven als er geen applicaties met een web interface zijn.

Om deze voordelen te bereiken is het wel nodig dat alle gebruikte libraries beschikbaar zijn in de vorm van OSGi bundles. Bij vele populaire open source libraries is dit (nog) niet het geval. Om aan de vraag naar deze bundles te voldoen is SpringSource een apart project gestart: de Enterprise Bundle Repository, te bereiken onder http://www.springsource.com/repository. Via deze applicatie kunnen van honderden enterprise java libraries OSGi-versies worden gedownload. Deze versies worden gratis ter beschikking gesteld en kunnen worden gebruik met iedere OSGi implementatie, dus niet alleen met de dm Server.

Een belangrijke functie die de dm Server toevoegt aan standaard OSGi is het concept van een applicatie die uit meerdere bundles bestaat: een zogenaamd Platform Archive of PAR-file. Door modules als een applicatie te bundelen ontstaat een eenheid voor beheer, zodat zaken als installeren en monitoren van een applicatie makkelijker worden. Ook biedt dit concept een vorm van 'scoping' aan, waarbij types en services binnen dezelfde applicatie niet beschikbaar zijn buiten de applicatie. Hierdoor kunnen onder andere meerdere versies van dezelfde applicatie op dezelfde server draaien. Code die gedeeld moet worden door meerdere applicaties blijft uiteraard gewoon beschikbaar, maar wordt dus niet in de applicatie meegeleverd.
Verder levert de dm Server oplossingen voor het werken met libraries die technieken gebruiken die standaard niet werken in een OSGi-omgeving, zoals het dynamisch genereren of 'weaven' van code, zoals gebruikelijk is in JPA-implementaties. Ook wordt een volledige oplossing geboden voor het werken met webapplicaties, iets waarvoor OSGi van zichzelf slechts beperkte ondersteuning biedt.

Conclusie

OSGi is duidelijk bezig met een opmars in de enterprise Java wereld. De voordelen van echt modulair kunnen werken in een dynamische runtime omgeving trekt vele ontwikkelaars aan. Veel application servers maken reeds gebruik van OSGi, en met innovatieve producten als Paremus Infiniflow en de SpringSource dm Server komt het gebruik van OSGi ook binnen handbereik van applicatie-ontwikkelaars. Het zal nog wel even duren voor OSGi gemeengoed is geworden, maar dat Enterprise OSGi een ontwikkeling is die de komende jaren een hoge vlucht gaat nemen lijkt onmiskenbaar.

Joris Kuipers is Senior Consultant voor SpringSource Nederland.