A JBoss AS 5 RC1 kemény fejlesztői munka után hamarosan megjelenik. Az alábbi interjúban Dimitris Andreadis, a projektvezető az új jellemzőkről és a megjelentetés részleteiről számol be. Emellett az interjúban szó lesz a Java EE 6 jellemzőiről, a JBoss AS előnyeiről, és kitérünk a versenyre, valamint arra, hogy a JBoss AS5 fejlesztői csapata miért választott hordozható komponenseket az OSGi helyett.
Melyek az új verzió legfőbb jellemzői, és mik jelentenek újdonságot a korábbi verziókhoz képest? Mesélj az új API-ról is!
A JBoss AS5 legfontosabb új előnyei abból származnak, hogy az összes jelentős JBoss alrendszert továbbfejlesztettük. A JBoss Messaging 1.4 leváltotta a régebbi JBossMQ-t, és ez lett az alapértelmezett JMS szolgáltató. A JBM alapértelmezetten készen támogatja a klaszterezett sorokat (queues) és témákat (topics) a transzparens failover és intelligens üzenet újraelosztással együtt. Az üzeneteket a csomópontok között a memórián keresztül replikálhatjuk, elkerülve ezáltal a lemezműveleteket, vagy azt, hogy a perzisztenciához olyan népszerű relációs adatbázist kelljen használnunk lapozási technikával, ami támogatja a nagyon nagy üzeneteket. A JBM kiemelkedő teljesítményt mutat, és ez csak egyre jobb lesz az új, csak a hozzáfűzést támogató naplózó tárolás megjelenésével.
A JBoss WebServices 3.0 teljes támogatást nyújt a JAX-WS/JAX-RPC számára, XOP & SwA csatolmányokkal, valamint WS-* szabványok hosztjával. A JBMS egy plugin-alapú architektúrára váltott, ami lehetővé teszi az alapot képező WebServices készlet leváltását, így a natív JBossWS helyett a Sun Metróra vagy az Apache CXF-re is válthatunk. Így mindig azon webszolgáltatások készletét alkalmazhatjuk, ami a legjobban megfelel az adott probléma megoldására.
Az AS5-ben a klaszterezés támogatja a buddy replikációt az SFSB-k (StateFul Session Bean) számára a jobb méretezhetőség és a klaszterezett websession-ök passziválása érdekében a memóriahasználat ellenőrzéséhez. Az EJB3 Entity & Hibernate gyorstárazás nagyban fejlődött, mivel most már különálló gyorstárakat használhatunk az entitások (invalidációs gyorstár) és a lekérdezés (replikációs gyorstár) esetén. Az alapot képező JGroups protokoll készletben más teljesítménybeli fejlesztések is történtek.
A JBoss Transactions a JBoss 5 alapértelmezett tranzakció-menedzsere. A JBoss TS tesztelt az AS 4.2-n a JBoss Webbel együtt. A JBoss Web a JBoss 5 szervlet konténere, ami egy olyan implementáció, ami Apache Tomcaten alapul, és támogatja a natív APR-alapú konnektorokat a nagyobb méretezhetőség és teljesítményi jellemzők elérése érdekében, melyek megfelelnek az Apache HTTP szerver jellemzőinek, sőt felülmúlják azokat.
Az API-k tekintetében az AS5 a Java EE 5 implementációja, így minden kapcsolódó API implementációját megtalálhatjuk benne. A legtöbb olyan API esetén, melyek újak a Java EE 5-ben, mint például az EJB3, a JAX-WS, a JPA stb., már a JBoss AS 4.2-ben is léteztek implementációk, azonban a JBoss AS5 esetén a megfelelőségi követelmények sokkal szigorúbbak a nagyobb TCK tesztelési kiterjedtség miatt.
Sokszor elhangzott már az a kritika, hogy a JBoss Application Server 5-ös verzióját egy meglehetősen hosszas fejlesztési ciklus jellemzi, legalábbis, más konténerekhez képest. Ez miért van így? A 4.2 megjelenése hozzájárult ehhez a késéshez egyáltalán?
Bizony, a JBoss AS 4.2 és az Enterprise Application Platform (EAP 4.2) első verziója hatással vannak az AS 5-re is. Végesek az erőforrásaink, és a termékesítési erőfeszítések, melyek a Fedora/RHEL modellt követték, újdonságot jelentettek a JBoss fejlesztők számára. Másrészt a 4.2 ugródeszkát és tesztelési terepet jelentett a különböző JBoss technológiák számára (példádul a JBoss Transactions), melyek már készen voltak az AS5 előtt is, és ezek megjelenhettek, tehát jó, hogy ezek a komponensek hamarabb kikerültek a közösségbe.
Másrészt szerintem még senki sem látta előre, hogy valójában mit is foglal majd magában az AS5, amikor a projekt kb. 3 éve elkezdődött. A nulláról indulva egy teljesen új rendszermagot hoztunk létre, Mbeans-ről POJO-kra váltottunk, az AOP-t a legmélyebb szinten integráltuk, egységesítettük a metaadatok kezelését az alrendszerek között, megváltoztattuk az osztálybetöltő rendszereket, aspektusokra bontottuk az alkalmazási folyamatot (a deployereket), mászóval megváltoztattuk a belső architektúrát és lecseréltük az alkalmazásszerver lényegi elemeit, mialatt fenntartottuk a visszafelé kompatibilitást a meglévő szolgáltatások nagy részével. Ez egy kihívásokkal teli, kemény munka volt.
Egy másik logisztikai probléma az igazi SPI-k (szolgáltatásnyújtó interfészek) megjelenésével merült fel a különböző alrendszerek számára. Ez hosszútávon jó, mivel lehetővé teszi a rendkívüli hordozhatóságot és a JBoss projekt „á la carte” használatát a különböző futásidejű környezetekben (pl. a különálló EJB3-ban vagy pedig beágyazva egy másik alkalmazásszerverbe). Azonban, ha több tucat kis projektet kell folyamatosan karbantartani, ez jelentős többletmunkával jár. Ehhez adjuk hozzá egy ilyen nagy kódbázis átmozgatását maven2-re, és akkor láthatjuk valójában milyen nagy munkáról is van szó.
Természetesen a JBoss-t használni akaró végfelhasználók és fejlesztők számára a fentiek belső implementáció részletek és a teljesen minősített Java EE5-ös JBoss késése zavaró, ezért köszönjük a türelmüket, illetve reméljük, hogy amint megjelenik az AS5 és megoldjuk a kezdeti problémákat, akkor az eredmények önmagukért beszélnek majd.
A JBoss AS5 nem csupán egy Java EE 5 alkalmazásszerver, hanem egy innovatív szerver-oldali futásidejű környezet vízióját is megtestesíti a JBoss projektek következő generációja számára.
Februárban megjelent a végső béta változat. Mikor jelenik meg a CR1? Mikor jelenik meg a végső verzió?
A CR1 hamarosan megjelenik majd, várhatóan a napokban. Ezt pedig a CR2 követi augusztus elején. A CR megjelenések közösségi hozzájárulásai alapján pedig majd eldöntjük, hogy mi lesz a végső megjelenés időpontja. Jelenleg a JBoss AS5 megjelentetése a legfőbb prioritásunk.
Jelenleg a Java EE 6 jellemzőivel kapcsolatban zajlanak megbeszélések, különösen a profilok tekintetében. Mik a JBoss tervei ezzel kapcsolatban?
Személyszerint vegyes érzéseim vannak a Java EE 6 profil-javaslataival kapcsolatban. A Java EE specifikáció fő célja, hogy a fejlesztőknek az EE technológiák átfogó készletét nyújtsa, így nagyobb az esély arra, hogy az alkalmazások a megfelelő futásidejű környezetek között mozgathatóak. Azáltal, hogy a technológiák készletét egy nagyon kis alkészletre szűkítjük (pl. egy A profil), a fejlesztők arra kényszerülnek, hogy nem a specifikációnak megfelelő kiterjesztéseket adjanak hozzá, ez pedig az EE alkalmazások hordozhatóságát csökkentik.
Az egy teljesen más dolog, hogy ha összehangolt konfigurációink vannak, akkor elkerülhető a futásidőben az olyan technológiák terhe, amiket nem használunk. A JBoss AS-t a kezdetektől fogva három előre meghatározott profillal nyújtjuk (minimális, alapértelmezett és teljes, és néhány egyéb profil, ha a jems telepítőt használjuk), és mindig is jellemző volt az a szabadság, hogy tovább szűkíthetjük a szerverkonfigurációt a használatnak megfelelően. Ha nincs szükségünk JMS-re, akkor csak távolítsuk el az adott alrendszert. Ez azonban csak a platform szolgáltatójának implementációs részletkérdése.
Ami fontos a Java EE technológiák szélesebb készlete számára, az az, hogy átfogóak, általánosságban hasznosak és kurrensek legyenek. Az EJB3, a JPA, a JAX-WS bevezetése a platform számára nagy előrelépést jelentettek. A „tisztítási” folyamat szintén egy újabb lépés a cél felé. A Java EE specifikáció bizonyos részei, melyek igazán nem általános esetek (például a CSIv2) vagy elavultak (például a CMP), nem kellene, hogy továbbra is a platform részei legyenek. Azonban az nem vezet sehová, ha arról beszélünk, hogy egy alapvető profil JSP-t vagy JSF-et kellene, hogy ajánljon, hiszen mindkét technológiának megvannak a maga felhasználási esetei.
Nem igazán látom a lényegét annak, ha a tomcatre (A profil) rányomjuk az EE bélyegét, ahelyett, hogy lehetővé tennénk, hogy néhány kisebb szereplő kiterjesztéseket fejlesszen ki a tomcathez és azt Java EE-ként reklámozza. Vagy ha egy inkább feljavított tomcat konfigurációval rendelkezünk (B profil), ami nem teszi lehetővé a webszolgáltatásokat. Így általánosságban szerintem a profilok többet ártanak, mint használnak a Java EE közösségnek.
A SpringSource nemrég megjelentette a SpringSource Application Platformot. Ez egy modulokra épülő Java alkalmazásszerver, amit Spring alkalmazások futtatására terveztek. Szerepel a JBoss tervei között egy különálló alkalmazásszerver fejlesztése a JBoss technológiák (Hibernate, Seam, Messaging stb.) használatával, ahogy azt a SpringSource is tette?
A JBoss AS konfiguráció leszűkíthető szolgáltatások olyan készletére, melyekre valóban szükségünk van, ez mindig is lehetséges volt a JBoss-szal. Ha egy előre meghatározott webes konfigurációval rendelkezünk, ez inkább egy marketing, nem pedig technikai döntés. A különböző funkciók és jellemzők eltávolítása könnyebb, mint újak hozzáadása. Jelenleg a bővítésen dolgozunk azáltal, hogy bevezetjük a JBoss Enterprise SOA Platformot, ami a JBoss ESB, a JBoss jBPM és a JBoss Rules funkcionalitását ötvözi a JBoss EAP-ra építve. Azonban, ha valós piaci igény merül fel, vagy a Java EE 6 profilok tovább fejlődnek, akkor valószínűleg támogatjuk majd a webplatform csomag létrehozását.
Manapság gyakori az OSGi használata szerver-oldali alkalmazások esetén. Ez valójában azt jelenti, hogy mind a GlassFish-t, mind a Spring Application Platformot választjuk. A JBoss 5 ehelyett egy olyan architektúrával rendelkezik majd, ami lehetővé teszi a komponens modell számára, hogy hordozható legyen, ami elősegíti a kompatibilitást a régi kódbázisokkal, valamint a fejlesztett komponens-modellek jövőbeli belefoglalását is. Ez szerinted egy stratégiai előnyt jelent a versenytársakkal szemben?
Igen, mindenféleképpen azt jelenti. Visszatekintve, a JBoss volt az első olyan Java alkalmazásszerver, ami egy dinamikus mikrorendszermag architektúrára épül, már 2001 óta. Rendszermagként a JMX MbeanServer szolgált, az Mbeans pedig a komponens-modell szerepét töltötte be a rendszermag plugin-alapú szolgáltatásaihoz. Ez egy nagyszerű választás volt akkoriban, de később, ahogy a POJO és az AOP a domináns programozási modellekké váltak, szembesültünk a JMX mag korlátaival. A JBoss 3 első refaktorálási lépésében megírtuk a saját JMX rendszermag-helyettesítőnket (JBossMX), ami POJO és interceptor támogatást nyújtott az XMBeansen keresztül, de hamar nyilvánvalóvá vált, hogy a helyes út a teljesen ellenőrzés alatt tartott POJO rendszermag.
A JBoss 5 három éves K+F munkája után megtanultuk, hogy a rendszermagok és a komponens modellek felváltása, egy nagyon nagy munkát igénylő folyamat. Egyértelműen rossz döntés, ha a szerver belső felépítését egy adott komponens-modellhez kapcsoljuk. A versenytársak is ugyanezt tapasztalják majd, amikor az OSGi kimegy a divatból, vagy ha egy jobb komponens modell jelenik meg. Bizonyos szempontból úgy néznek ki, mint a JBoss 7 évvel ezelőtt.
Azonban a JBoss számára az új komponens-modell támogatása ugyanolyan egyszerű lesz, mint egy Facade fejlesztése a JBoss mikrokonténerre. Ugyanúgy, ahogy a POJO-kat, a régi MBeans-eket, és hamarosan az OSGi csomagokat is támogatjuk, támogatni fogunk bármilyen más jövőbeli komponens modellt is. Ez az absztrakció legnagyobb előnye.
A fejlesztők meg tudják majd osztani az információt a hordozható komponensmodellek között, valamint képesek lesznek majd arra, hogy ezeket együttműködésre bírják?
Igen, és ez benne a szép. Mivel az összes JBoss komponens a típustól függetlenül (tehát POJO, MBean, Spring Bean, OSGi csomagok stb.) ugyanazon a szubsztráton helyezkedik el, megadva a lehetőségét az összekapcsolásnak mikrokonténerek segítségével, valamint olyan aspektusokkal, mely az összes különböző komponensmodellen keresztül érvényes. Még mindig a nagyon elején járunk annak, hogy teljesen kihasználjuk a MicroContainer technológia működését, amit a lángelme Adrian Brock tervezett, azonban a lehetőségek nagyon érdekesnek tűnnek.
Mit tudsz mondani a JBoss AS jövőbeli irányairól? Mi következik az 5-ös verzió után?
A legfőbb célunk jelenleg az, hogy megjelentessük az AS5-öt. Így nem szívesen bocsátkozom jóslásokba. Amit tudok az az, hogy az AS5 megfelelő alapot nyújt majd és egy teljesen kiterjeszthető, komponenseken átívelő modellt, valamint egy aspektus integrációs futásidejű környezetet, amin sokkal gyorsabban megvalósítható az innováció. Így az AS6 fejlesztési ideje sokkal rövidebb lesz, mint az AS5-é.
Vannak olyan területek, melyekre jobban koncentrálunk majd, mint például az OSGi támogatása és a szerverek menedzsment jellemzőinek fejlesztése, különösen a nagy alkalmazások kontextusában. A különböző JBoss projekteket nagy innováció jellemzi, a Java megnyitásával pedig várható, hogy a JVM maga is fejlődik majd, és nagyobb integrációt láthatunk majd az alkalmazásszerver szempontjából, különösen a Linux-oldalon.
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.