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.
A Red Hat Runtimes for Spring Boot a Red Hat egyik termékcsomagja, ami Spring Boot keretrendszer-támogatást nyújt fejlesztők számára. A Spring Boot egy népszerű keretrendszer a Java alkalmazások fejlesztéséhez, amelyet a könnyűsúlyú és gyors prototípuskészítés, valamint az alkalmazások egyszerű konfigurációja jellemzi. A Red Hat Runtimes for Spring Boot segítségével a fejlesztők hatékony eszközöket és környezetet kapnak a Spring Boot alapú alkalmazásaik futtatásához és menedzseléséhez.
A Red Hat Runtimes for Spring Boot az alábbi előnyöket kínálja:
A Red Hat JBoss Enterprise Application Platform (JBoss EAP) egy nyílt forráskódú alkalmazásfejlesztési és alkalmazásüzemeltetési platform. Az EAP egy teljeskörű Java Platform, Enterprise Edition (Java EE) kompatibilis alkalmazás-szerver, amely kifejezetten vállalati környezetekben történő használatra lett tervezve. A platformot a Red Hat fejleszti és támogatja, és az egyik meghatározó megoldás a vállalati környezetekben történő Java alkalmazásfejlesztés és futtatás terén.
A JBoss EAP alapvető jellemzői:
Java EE Kompatibilitás: A JBoss EAP teljes körűen támogatja a Java Platform, Enterprise Edition (Java EE) specifikációt. Ez magában foglalja a Servletek, JSP-k, EJB-k (Enterprise Java Beans), JMS-t (Java Message Service), JPA-t (Java Persistence API) és számos más Java EE technológiát.
Moduláris Architektúra: Az EAP moduláris architektúrával rendelkezik, amely lehetővé teszi, hogy csak azokat a komponenseket használd, amelyekre szükséged van, ezáltal csökkentve az erőforrásigényt és javítva a teljesítményt.
Adminisztrációs eszközök: Az EAP kiterjedt adminisztrációs eszközöket és vezérlőfelületeket nyújt az alkalmazások konfigurálásához, kezeléséhez és felügyeletéhez.
Üzleti támogatás: A JBoss EAP hosszú távú támogatást nyújt vállalati ügyfelek számára, biztosítva a biztonsági frissítéseket és a hibajavításokat.
Klaszterezés: Az EAP támogatja a klaszterezést, ami lehetővé teszi az alkalmazások horizontális skálázását és a nagyobb rendelkezésre állást.
Könnyű integráció: Az EAP könnyen integrálható más Red Hat termékekkel és megoldásokkal, például a Red Hat JBoss Data Grid-del és a Red Hat JBoss Fuse szolgáltatás-buszrendszerrel.
Az EAP-t különféle alkalmazások fejlesztésére és futtatására használják, ideértve a webalkalmazásokat, az üzleti alkalmazásokat és a mikroszolgáltatásokat. A Red Hat JBoss EAP által nyújtott megbízhatóság és teljesítmény miatt sok vállalat választja ezt a platformot vállalati szintű Java alapú alkalmazásokhoz.
A Red Hat JBoss Web Server egy nyílt forráskódú webkiszolgáló szoftver, ami a Red Hat middleware portfóliójának a része. A JBoss Web Server az Apache Tomcat és az Apache HTTP Server komponensekre épül, és lehetővé teszi pehelysúlyú, hatékony és biztonságos webalkalmazások futtatását.
A Red Hat JBoss Web Server főbb jellemzői:
Apache Tomcat: A Red Hat JBoss Web Server meghatározó eleme az Apache Tomcat szoftverkomponens, ami egy nyílt forráskódú Java Servlet és JavaServer Pages (JSP) konténer. A Tomcat lehetővé teszi Java-alapú webalkalmazások futtatását és kezelését.
Apache HTTP Server: Az Apache HTTP Server a világ egyik legelterjedtebb webkiszolgáló szoftvere, az internet jelentős részén használják. A Red Hat JBoss Web Server az Apache HTTP Serverre épül, ahhoz kiegészítő funkciókat és teljesítményjavításokat biztosít.
Java Web Container: A Red Hat JBoss Web Server olyan webes konténerként működik, amely támogatja a Java Servlet API-t és a JavaServer Pages (JSP) technológiát. Ez lehetővé teszi a Java alapú webalkalmazások könnyű futtatását és kezelését.
Egyszerű telepítés és konfiguráció: A Red Hat JBoss Web Server egyszerű telepítést és konfigurációt biztosít, segítségével gyorsan készíthetünk olyan webkiszolgálót, amely képes webalkalmazások futtatására.
Biztonság: A Red Hat JBoss Web Server számos már alapértelmezetten is olyan előre definiált biztonsági beállításokkal rendelkezik, amelyek védelmet biztosítanak a legelterjedtebb webbiztonsági fenyegetésekkel szemben.
A Red Hat JBoss Web Servert gyakran használják olyan környezetekben, ahol egyszerűen szeretnének Java alapú webalkalmazásokat futtatni és ahol fontos a megbízhatóság és a biztonság. Az Apache Tomcat és az Apache HTTP Server együttes használata révén a JBoss Web Server a vállalati igényeket is maximálisan kielégíti mind teljesítmény, mind funkcionalitás szempontjából.
A Red Hat Data Grid egy elosztott, in-memory (memóriában működő) gyorsítótár és NoSQL adatbáziskezelő megoldás a Red Hattől. A Red Hat Data Grid biztosítja, hogy az alkalmazások a jellemzően nagyságrendekkel gyorsabb memóriában tárolják és kezeljék a gyakran használt adatokat, jelentősen növelve azok teljesítményét és skálázhatóságát.
A Red Hat Data Grid főbb jellemzői:
In-memory adattárolás: A Red Hat Data Grid az alkalmazások számára biztosít memóriában működő adattárolást, ami gyors és alacsony válaszidőt eredményez.
Elosztott architektúra: A Red Hat Data Grid elosztott architektúrával rendelkezik, ami lehetővé teszi az adatok elosztott tárolását és kezelését több szerveren átívelően. Ez növeli a rendelkezésre állást és skálázhatóságot.
Cache funkciók: A Red Hat Data Grid támogatja a gyorsítótás (cache) funkciókat, így az alkalmazások a gyakran használt adatokat memóriában tárolhatják, csökkentve a késleltetést és az adatbázis terhelését.
Tranzakciós támogatás: A Red Hat Data Grid támogatja a tranzakciókat, így biztosítva az adatok konzisztens és atomi módosítását.
Keretrendszerfüggetlen: A Red Hat Data Grid olyan platformfüggetlen megoldás, amely támogatja például a Java, .a NET, Node.js és más programozási keretrendszereket, nyelveket.
Integráció a Red Hat termékekkel: A Data Grid jól integrálható más Red Hat termékekkel, például a JBoss Enterprise Application Platform (JBoss EAP) és a Red Hat JBoss Middleware szoftverekkel.
A Red Hat Data Grid-t gyakran olyan alkalmazások fejlesztéséhez és futtatásához használják, ahol fontos a magas teljesítmény és skálázhatóság. Ilyenek például webalkalmazások, mikroszolgáltatások, adatelemzési alkalmazások és real-time alkalmazások.
A Red Hat AMQ a Red Hat által kínált üzenetküldő szoftvermegoldás, illetve megoldások, hiszen két meghatározó technológiára, az Apache ActiveMQ-ra és az Apache Kafkára épül.
A Red Hat AMQ egy rugalmas és megbízható messaging platform, célja az üzenetek hatékony és biztonságos továbbítása alkalmazások között, függetlenül attól, hogy azok melyik platformon futnak vagy milyen programozási nyelvet használnak.
A Red Hat AMQ főbb jellemzői és szolgáltatásai:
Üzenetküldés és -fogadás: Az AMQ lehetővé teszi az alkalmazások számára, hogy üzeneteket küldjenek és fogadjanak egymás között. Az üzenetek lehetnek egyszerű szöveges üzenetek, bináris adatok vagy akár strukturált formátumok is.
Queue-k és topicok: Az AMQ támogatja mind a queue-k, mind a topicok használatát. A queue-k esetén az üzeneteket több címzett között osztják meg, míg a topicok lehetővé teszik, hogy az üzeneteket több feliratkozó (subscriber) kapja meg.
Késeknek támogatása: Az AMQ támogatja a Java Message Service (JMS) és az Advanced Message Queuing Protocol (AMQP) szabványokat, amelyek együttműködést (kommunikációt) tesznek lehetővé különböző rendszerek között, függetlenül azok implementációs részleteitől és az azok létrehozására használt nyelvektől, keretrendszerektől.
Elosztott architektúra: Az AMQ elosztott architektúrával rendelkezik, így több üzenetkiszolgáló (broker) között oszthatja meg az üzeneteket, ami javítja a rendelkezésre állást és skálázhatóságot.
Állapotmentes (stateless) működés: Az AMQ szerverek állapotfüggetlenek, ami lehetővé teszi a könnyű bővítést és a megbízható működést.
Üzenetszűrők és transzformációk: Az AMQ lehetővé teszi az üzenetek szűrését és átalakítását, amely rugalmasságot és könnyű integrációt biztosít más rendszerekkel.
Klienskönyvtárak: Az AMQ-hez számos klienskönyvtár áll rendelkezésre különböző programozási nyelvekhez, mint például Java, Python, .NET, stb.
Az AMQ-t gyakran használják olyan alkalmazások és rendszerek fejlesztéséhez, ahol fontos a megbízható és skálázható üzenetküldés, például a mikroszolgáltatások közötti kommunikáció, az integrált alkalmazások közötti adatcsere, és a hálózaton átívelő kommunikációhoz. Az AMQ lehetővé teszi a fejlesztők és az üzemeltetők számára, hogy könnyedén kezeljék az üzeneteket és biztosítsák az alkalmazások hatékony és megbízható kommunikációját.
A Red Hat Single Sign-On (SSO) egy nyílt forráskódú, szabványos és biztonságos azonosítási és hitelesítési megoldás, amely lehetővé teszi, hogy a felhasználók egyetlen bejelentkezési folyamatot (Single Sign-On) használva férjenek hozzá több különböző alkalmazáshoz és szolgáltatáshoz.
Az SSO olyan technológia, amely biztosítja, hogy a felhasználónak csak egyszer kelljen bejelentkeznie egy rendszerbe, és ezt követően az azonosítása automatikusan továbbítódik más alkalmazásokhoz anélkül, hogy újra meg kellene adni a bejelentkezési adatokat. Ez nem csak a felhasználók számára kényelmesebbé teszi az alkalmazások használatát, hanem csökkenti az (adminisztratív) overheadet és növeli az informatikai biztonságot.
A Red Hat SSO a következő fő jellemzőkkel rendelkezik:
Azonosítási és hitelesítési szabványok támogatása: Az SSO támogatja a modern azonosítási és hitelesítési protokollokat, például SAML (Security Assertion Markup Language), OAuth és OpenID Connect, amelyek lehetővé teszik a biztonságos és szabványos bejelentkezési folyamatokat.
Központosított felhasználó- és hozzáféréskezelés: Az SSO lehetővé teszi a felhasználók központi kezelését és az egységes hozzáférési jogosultságokat több alkalmazáshoz.
Klienskönyvtárak és API-k: A Red Hat SSO klienskönyvtárakkal és API-kkal rendelkezik, amelyek egyszerűvé teszik az SSO integrációját a meglévő alkalmazásokkal és szolgáltatásokkal.
Többfaktoros azonosítás (MFA): Az SSO támogatja a többfaktoros azonosítást, ami tovább növeli az alkalmazások biztonságát.
Skálázhatóság és megbízhatóság: A Red Hat SSO architektúrája lehetővé teszi a nagy terhelések kezelését és a megbízható működést.
A Red Hat SSO-t gyakran vállalati környezetekben alkalmazzák, ahol fontos az egyszerű és biztonságos azonosítás és hozzáféréskezelés a számos alkalmazáshoz és szolgáltatáshoz. Az SSO segít az informatikai csapatoknak egyszerűsíteni az üzemeltetést és növelni az adatbiztonságot, miközben a felhasználók kényelmét is javítja.