miercuri, mai 23, 2007

OSGi - the future

Prima oara am auzit de OSGi cand lucram cu Eclipse. Undeva intre versiunea 3.0 si 3.1 s-a produs migrarea din vechiul sistem de plugin-uri la o implemetare de OSGi, care a devenit cunoscuta sub numele de Equinox. A doaua oara cand am simtit ca e ceva bun cu OSGi a fost atunci cand Spring a ales sa ofere suport pentru OSGi in containerul lor (chiar a devenit un obiectiv important pentru Interface 21). In acest punct am inceput sa-mi pun intrebari. Ce reprezinta de fapt OSGi?

OSGi (Open Services Gateway initiative) este o specificatie intretinuta de OSGi Aliance ajunsa la versiunea 4. Scopul ei este acea de a defini The Dynamic Module System for Java ceea ce inseamna suport pentru module dinamice in Java, adica o inbunatatire a actual-ului sistem de module reprezentat prin clasicele jar-uri. Exista trei implementari open source ale acestei specificatii: Felix(Apache), Equinox(Eclipse), Knopflerfish(MakeWave). Exista si alte implementari comerciale. Referince implementation este Equinox care si-a dovedit calitatile si in
Eclipse. Exista alte incercari de a inbunatati vechile jar-uri, aflate sub umbrela jcp.org dar din nefericire par a fi doar incercari (JSR-227, JSR-291) fata de OSGi care cativa ani de existenta si destule impelementari.

Ce se intelege prin sistem dinamic de module in Java? Este tocmai ce jar-urile nu pot acum sa ofere: posibilitatea de a deploya in runtime in JVM, de a avea versiuni diferite ale aceluiasi modul in runtime, de a cupla modulele aplicatei printr-un numar cat mai mic si bine definit de puncte de interactiune, etc.

A deploya in runtime e posibul doar pentru aplicatiile enterprise (ear, war) prin mecanismele pe care le ofera serverul de aplicatii (JBoss se pricepe bine la asta - are un mecanism de incarcare de clase cu totul deosebit asa cum se vede aici) dar acest lucru nu este posibil cu un jar oarecare. Daca avem doua clase cu acelasi nume (provenite sa zicem din doua jar-uri diferit) doar prima clasa gasita in CLASSPATH va fi incarcata - nu se pune problema de versionare. Asa cum sunt cnstruite jar-urile, avand un jar in CLASSPATH-ul JVM-ului, toate resursele din acel jar pot fi incarcate de ClassLoader-eri - se creaza astfel dependente putenice intre modulele aplicatiei - inposibilitatea plugin-abilitatii.

Este interesant sa fii partas la inceputul unei tehnologii (mai bine zis la maturizarea ei - a inceput in 99). Deci mai bine zis sa fii contemporan cu ea. La fel cum AOP a devenit mijlocul standard de a oferi servicii de middleware, AJAX filosofia care ne-a scapat de refresh-ul pe pagina Web, OSGi va deveni modul standard de a realiza sisteme plugin-abile. Vom vedea.