Az alábbi interjúban Mark Newton a JBoss OSGi-val kapcsolatban kérdezte Ales Justint, aki a JBoss Microcontainer, JBoss AS 5 fejlesztője, és Seam integrációs szakember, emellett tagja a JSR-291 és az OSGi szakértői csoportoknak.
A JBoss K+F már egy ideje az új OSGi implementáción dolgozik. Mi a célja ennek a munkának?
Az egyik célunk az, hogy létrehozzunk egy OSGi alapú osztálytöltőt (classloader). Ezt először a futásidő szolgáltatásainknak hozzuk létre, majd pedig az OSGi Enterprise Expert Group (EEG) közreműködésével megpróbáljuk ezt az alkalmazásfejlesztők rendelkezésére bocsátani. A másodlagos célunk az, hogy a teljes OSGi alap specifikáció 4.1-es verziójú implementációját létrehozzuk. Ezt sokkal egyszerűbben elérhetjük, mivel a JBoss Microcontainer (MC) már az összes OSGi alapjellemzővel rendelkezik. Ráadásként az új OSGi EEG „komponens modell” támogatást is bevezetjük. Végül, mivel a JBoss AS 5 fejlett a profilok terén, az OSGi Bundle Repository (OBR) használatát a ProfileService-ünkkel integráljuk majd.
Miért nem használtok egy létező OSGi implementációt?
A jelenlegi OSGi szolgáltatás adatbázis (registry) nem rendelkezik azokkal a jellemzőkkel, melyekre szükségünk van, vagyis például a finom granularitású függőséggel, az AOP integrációval, a régi JMX támogatással, a scope-olt metaadatokkal, nyílt mbeans-szel, Virtuális Fájlrendszerrel (VFS), generikus deployerekkel stb. Ha egy már meglévő implementációt választanánk, és ezeket a jellemzőket hozzáadnánk, valószínűleg ugyanannyi erőfeszítésre lenne szükség, ha nem többre ahhoz, hogy mindent egyberakjunk. Illetve azáltal, hogy a saját implementációnkat hozzuk létre, az alkalmazásszerverünk alapja, azaz a rendszermagja feletti ellenőrzésünket biztosítjuk.
Valószínűleg a már meglévő OSGi keretrendszerek osztálytöltő (classloading) jellemzőit is tudnánk használni, de ez ismét plusz erőfeszítést jelentene. Mivel egy szilárd implementációt akartunk létrehozni, ahol minden kellemetlen részlet a privát vagy védett módosítók (private/protected modifier) mögé van rejtve, fontos volt, hogy a szabályrendszereken (policy) és a delegáción keresztül szoros ellenőrzés alatt tudjuk tartani a hozzáférést. Ebből a szempontból nagyobb értelme volt annak, hogy a saját osztálytöltő rétegünket implementáljuk. Ez azt is jelentette, hogy az olyan dolgok, mint az erőforrás kikeresések a Virtuális Fájlrendszer segítségével implementálhatók, ami valóban jó hozzáférést nyújt nekünk a deployolt alkalmazásokhoz, attól függetlenül, hogy hol helyezkednek el, vagy milyen a struktúrájuk (csomagolt vagy nem csomagolt).
Az OSGi erőfeszítések hogyan kapcsolódnak a Spring nemrégi bejelentéséhez a Dinamikus Dependencia Modulokról?
A Spring ezen tevékenysége hasonló ahhoz, ami már az OSGi-ban létezik, ahol ezt Deklaratív Szolgáltatási Támogatásnak (DSS) nevezzük. Ez alapvetően azzal áll kapcsolatban, hogy hogyan konfiguráljuk a szolgáltatásainkat XML-en keresztül. A fejlesztők felfedezték a DSS biztonsági réseit, (az OSGi Alliance embereinek segítségével), és ezek kijavításával egy jobb komponens modell jött létre. Még ennél is fontosabb, hogy végül megpróbáltak valamit a specifikáció mögé rakni.
Ez az OSGi egyik egyszerűbb aspektusa. A Spring egyszerűbb módot nyújt arra, hogy a meglévő összetett OSGi jellemzőket használjuk. A mi erőfeszítésünk jelentős mértékben különbözik, mivel mi mind azokat az összetett jellemzőket az alapoktól implementáljuk, és szintén hasonló támogatást nyújtunk a komponensek számára.
A Seam jelenleg nyújt OSGi támogatást?
Jelenleg nem, de az OSGi EEG a Seam jellemzők (EJB, JSP, JSF) támogatásán dolgozik. Ennek fejlődésével a Seam elkezdi majd ezt a támogatást implementálni. Jelenleg hasonló finomszemcsés verziótámogatást tudnánk nyújtani az MC-t és Seam beépülési pontokat (hook) használó POJO komponenseknek. Ez tulajdonképpen hasonló ahhoz, ahogy jelenleg a hot deployment működik.
Mit nyújt majd a JBoss AS 5 az OSGi jellemzőket használó alkalmazásfejlesztőknek?
A hagyományos JEE alkalmazásfejlesztők most nem tapasztalnak előnyöket, mivel az OSGi funkcionalitás jelenleg a futásidejű szolgáltatás szintjén van. Nekik várniuk kell majd az OSGi EEG fejlesztés első eredményeire, mielőtt azt JEE-ben kezdenék el használni. Ebből a szempontból az a célunk, hogy a versenytársakat megelőzzük, mivel szabadon megváltoztathatjuk a saját OSGi implementációnkat, hogy az EE jellemzőket a lehető leghamarabb tudjuk nyújtani. A szolgáltatás-fejlesztőknek (azok, akik .sar archívumokat hoznak létre) az OSGi támogatás azonnal elérhető lesz majd. Különösen a JBoss ESB felhasználóinak, fejlesztőinek lesz ez izgalmas.
Mit nyújt az OSGi azoknak, akik a JBoss AS 5-ön alapuló testreszabott futásidejű rendszert nyújtanak?
Szerintem a legnagyobb előny az új osztálytöltő réteg lesz. Gyakran okoz az problémát, ha néhány szolgáltatást frissíteni szeretnénk, de osztály kompatibilitási problémák lépnek fel. Az új OSGi alapú osztálytöltő funkcionalitás kiküszöböli majd ezeket a problémákat.
Ami még szintén jó, az a láthatósági (visibility) szabályok szigorúsága. Ez azt jelenti, hogy most már szabályozhatjuk az implementációs részleteink láthatóságát a szolgáltatások összecsomagolásakor, ezáltal kiküszöböljük annak a lehetőségét, hogy a felhasználók vagy a fejlesztők a kódot hackeljék.
Hogyan kapcsolódik az OSGi a JEE-hez?
Az OSGi és a JEE két különbözi implementáció, melyek különböző, de egymást átfedő problémákra adnak választ. 2006 végén megalakult az új OSGi szakértői csoport annak megválaszolására, hogy hogyan valósítható meg a kettő integrálása annak érdekében, hogy a legjobbat hozzuk ki belőlük. Ahogy az várható volt, vannak bizonyos korlátok, mivel mindkét specifikáció, az OSGi 4.1 és JEE 5 jelenlegi verziói is készen vannak. Azonban remélem, hogy mivel minden jelentős EE gyártó képviselteti magát ebben a csoportban, a következő megjelenések során jobb integrációt láthatunk majd.
A JBoss hogyan járul hozzá ehhez az erőfeszítéshez?
A szakértői csoport tagja Mark Little, Kevin Conner valamint jómagam. Mind Mark mind Kevin a JBoss ESB fejlesztői csapatának tagjai. Engem a komponens modell érdekel, és a jellemzők, melyek az MC fejlesztésünkre hasonlítanak. Markot és Kevint főleg a szolgáltatásokkal kapcsolatos dolgok érdeklik, például az SCA és a szolgáltatás-felfedezés (service discovery). Mivel újak vagyunk az OSGi-ban és a saját jellemzőinket épp most fejlesszük, semmi konkrétummal nem járultunk még hozzá. Azonban az RFC/RFP-kkel egy folyamatot követünk, és van egy architektúránk, amivel a kezdeti implementációkat támogatjuk.
Mi érdekel leginkább az alkalmazásszerver fejlesztésének jövőjét illetően?
Felhasználóként leginkább a profilok érdekelnek. Ez azt jelenti, hogy egy nagyon kicsi futásidejű mérettel kezdhetsz, ami csak a rendszertöltőből áll. Ahogy aztán elkezdjük a szolgáltatásokat vagy alkalmazásokat használni, a rendszermag megpróbálja a létező dependenciákat úgy feloldani, hogy kiveszi őket a helyi vagy nyilvános tárházból. Végül ez azt jelenti, hogy nem kell aggódnunk az osztálytöltéssel kapcsolatban, és csak a kívánt jellemzők fejlesztésére kell koncentrálhatunk.
Alkalmazásszerver fejlesztőként tetszik, ami az OpenJDK körül történik és az erőfeszítésünk, hogy hozzájáruljunk. Ez azt jelenti, hogy végül majd meg tudunk oldani néhány olyan problémát, melyek a valóban 0 idejű újradeployolást megakadályozzák.
Mik a hírek a JBoss-szal, az OSGi-val és a közösséggel kapcsolatban?
Ahogy látható, a legtöbb OSGi implementációnk az MC projekt része, kivéve az OBR-t, mely esetén előnyösebb, hogy az a JBoss AS 5 része a ProfileServices mellett. Az MC egy izgalmas projekt, ahogy azt te is tudod, mivel hozzájárultál a dokumentáció és a példák megírásához. Ezért arra szeretnék mindenkit bátorítani, hogy fontolgassa a hozzájárulást. Ezzel a moduláris implementációval és a problémakörök egymástól való szigorú elválasztásával az MC-nek nagy tere van a növekedésre, az OSGi csak az egyik. Az osztálytöltő már majdnem kész van a 2.0.0 verzióhoz, de vannak még befejezésre váró tulajdonságok.
Köszönöm az interjút.
Én köszönöm.