A tranzakció fogalma többféleképpen értelmezhető, azonban általában, amikor az emberek tranzakciókról beszélnek, akkor az adatbázisok ACID (Atomicity, Consistency, Isolation, Durability) tulajdonságára utalnak, mely azt garantálja, hogy ezeknek az adatbázis-tranzakcióknak a feldolgozása megbízható módon történik. Egy SOA környezetben, mely alapulhat webes szolgáltatásokon vagy csupán HTTP-n, valószínű, hogy minden szolgáltatás (vagy rendszer, illetve webes alkalmazás) implementációja kommunikál olyan adatbázisokkal, melyek támogatják a tranzakciókat: ez nem jelent nagy változást, eltekintve attól, hogy valószínű, hogy explicit módon, magunk hozzuk létre a tranzakciót (hacsak a szolgáltatásunk nem EJB konténerben vagy egy olyan más környezetben fut, mely elvégzi számunkra a tranzakciók létrehozását). Ugyanez a tranzakcionalitást jellemző akkor is, ha több mint egy erőforrással kommunikálunk.
A különbség akkor jelenik meg, ha elkezdjük a tranzakciókat nagyobb egységekbe ötvözni (vagy szerkeszteni). Webes szolgáltatási környezetben legalább van egy olyan lehetőség, hogy úgy alakítsuk a dolgokat, hogy azok a szokásos módon viselkedjenek, mint például ahogy ahogy azt 2PC (kétfázisú commit) esetén Java EE környezetben megszoktuk. Ilyen példul a WS-Atomic Transaction (WS-AT), ami a WS-Coordination szabvány család tagja. A WS-AT implementációja alapvetően nagyon hasonló az XA által specifikált 2PC protokollhoz. Ez azt jelenti, hogy a tranzakciós kontextus a SOAP (Simple Object Access Protocol) fejlécben továbbítódik, az implementáció pedig biztosítja majd, hogy az erőforrás menedzserek egy meglévő tranzakcióhoz kapcsolódjanak. Ez ugyanaz a modell, mint amit az EJB fejlesztők már megszoktak: az elosztott tranzakciók ugyanolyan atomikusan viselkednek, mint a helyiek.
Van az atomikus tranzakcióknak néhány hátránya a SOA környzetben.
SOA vagy REST környezetben az ACID tranzakciók iránti igény a tervezésre vezethető vissza: a szolgáltatásainkat vagy erőforrásainkat valószínűleg rosszul modelleztük. Az atomikus tranzakciók természetesen a tranzakciók csak egy fajtáját képezik, vannak azonban olyan kiterjesztett tranzakciós modellek, melyek lazán csatolt rendszerekhez jobban illeszkedhetnek. Ezeket a modelleket még nem sokan alkalmazzák, még a webes szolgáltatások fejlesztőinek körében sem.
Már sokan rámutattak, hogy a WS-ReliableMessagingnek nincs megfelelője RESTesített HTTP esetén. Ebből sokan azt a következtetést vonják le, hogy ezért ez nem alkalmazható olyan esetekben, ahol a megbízhatóság kritikus kérdés (ez pedig gyakorlatilag minden olyan rendszerre vonatkozik, mely bármilyen fontossággal bír az üzleti környezetben). Azonban gyakran nem elegendő néhány, az üzenetek szállítását kezelő infrastruktúra komponens használata, hanem azt is tudni akarjuk, hogy egy adott üzenet kézbesítve lett-e vagy sem.
Ha egy válaszüzenetet kapunk, mint például az egyszerű 200 OK üzenetet HTTP esetén, akkor ez tipikusan azt jelenti, hogy a kommunikációs partnerünkhöz megérkezett a kérés. A problémák akkor merülnek fel, ha nem kapunk választ, és nem tudjuk, hogy a kérésüzenet veszett el útközben, vagy a válaszüzenet.
A legegyszerűbb módja annak, hogy biztosítsuk azt, hogy a kérés eléri a címzettet az az, ha újból elküldjük azt, ami természetesen csak akkor lehetséges, ha a címzett a duplikátumokat kezelni tudja (például figyelmen kívül hagyással). Ezt a képességet idempotenciának hívjuk. A HTTP biztosítja, hogy a Get, a Put és a Delete idempotensek, és ha az alkalmazásunk helyesen van implementálva, akkor a kliens egyszerűen csak újból küldi ezeket a kéréseket, ha nem kapott választ. A Post üzenet azonban nem idempontens, legalábbis a HTTP specifikációban nincs olyan utalás, mely garantálná, hogy az lenne. Több lehetőségünk is van: az egyik, hogy a Put használatára váltunk (ha a szemantika leképezhető rá), a másik, hogy az általános bevált módszereket alkalmazzuk, vagy pedig a meglévő ajánlások egyikét alkalmazzuk ennek szabványosítására (mint például Mark Nottingham POE-je, Yaron Goland SOA-Rity-je, vagy Bill de hÓra HTTPLR-je).
Míg ezen megoldások a megbízhatósági kihívás jó részére választ adnak, semmi sincs, ami a kézbesítés bizonyos tulajdonságait garantálná, mint például a HTTP kérések és válaszok egymásutánjának sorrendiségét. Fontos azonban rámutatni, hogy számos meglévő SOAP/WSDL forgatókönyv jól alkalmazható WS-Reliable Messaging, vagy annak számos elődje nélkül is.
A REST alapjában véve kliens-szerver modellre épül, a HTTP pedig mindig egy kliensre és egy szerverre hivatkozik a kommunikáció két végpontjaként. A kliens a szerverrel úgy kommunikál, hogy kérést küld és választ kap. A pub/sub modellben az érdekelt fél egy adott információ-kategóriára előfizet, és minden alkalommal, amikor valami új megjelenik, erről értesítést kap. A pub/sub modell hogyan támogatható RESTesített HTTP környezetben?
Nem kell messzire mennünk, hogy meglássuk ennek a tökéletes példáját, melyet szindikációnak nevezünk. A szindikációra jó példa az RSS és az Atom Syndication. A kliens úgy kérdezi le az új információt, hogy egy HTTP parancsot ad egy olyan erőforrásra vonatkozóan, amely erőforrás a változásokat gyűjteményét reprezentálja, például egy adott kategóriára vagy időtartamra szűkítve. Ez egy rendkívül kevéssé hatékony megoldás lenne, de mégsem az, mivel a Get a leginkább optimalizált művelet a weben. Sőt, könnyen elképzelhetjük, hogy egy népszerű webes blog szerver sokkal méretezhetőbb lenne felfelé, ha nem kellene minden előfizetett klienst egyenként, minden változásról értesítenie. Az értesítést helyettesítő pollozás hihetetlenül jól méretezhető.
A szindikációs modellt kiterjeszthetjük az alkalmazási erőforrásainkra, például kiajánlhatunk egy Atom feedet az ügyfelek erőforrásainak változására, vagy például foglalások audit naplójára. Amellett, hogy egy alapjában véve korlátlan számú előfizető alkalmazást ki tudunk elégíteni, ezeket a feedeket egy feed olvasóban is megtekinthetjük, ahhoz hasonlóan, ahogy a HTML reprezentációt megtekintjük a böngészőnkben.
Természetesen ez néhány forgatókönyv számára nem nyújt megfelelő megoldást. Például „puha” valósidejűségi követelmények esetén más technológia megfelelőbbnek bizonyulhat. Azonban sok esetben a laza csatolás, a méretezhetőség, illetve az értesítés ötvözése, melyet a szindikációs modell lehetővé tesz, kitűnő megoldás.
Ha figyelembe vesszük a HTTP kérés/válasz modelljét, felmerül a kérdés, hogy hogyan tudunk aszinkron kommunikációt megvalósítani? Ismét fontos megjegyezni, hogy aszinkronitás alatt több mindent értenek. Néhányan a programozási modellre utalnak, mely lehet blokkoló vagy nem blokkoló függetlenül az alacsonyabb szintű információáramlás típusától. De nem ez a fő kérdésünk, hanem az, hogy hogyan szállítunk egy kérést a klienstől (fogyasztó) a szerverhez (szolgáltató) olyan esetekben, amikor a feldolgozás órákba is telhet? A fogyasztó hogyan értesül arról, hogy a feldolgozás megtörtént?
A HTTP rendelkezik egy specifikus válaszkóddal, a 202-vel (Accepted – elfogadott), melynek jelentése a következő: „A kérés be lett fogadva feldolgozáshoz, de a feldolgozás még nem fejeződött be.” Na, mi pont ezt keressük. Az eredményt illetően több lehetőség van: a kérés a szervertől visszatérhet egy erőforrás URI-jával, melyen a kliens egy Get parancsot hajthat végre annak érdekében, hogy az eredményhez hozzáférjen (habár, ha kimondottan e kérés miatt hozták volna létre, egy 201 Created válaszkód valószínűleg jobb lenne). A másik mód az, hogy a kliens csatolhat egy URI-t, melyen majd a szerver POST műveletet hajt végre, amikor kész lesz.
Végül, gyakran panaszkodnak a REST-esített HTTP fejlesztésének támogatására szolgáló eszközök hiányáról. Ahogy azt a kettes pontban taglaltuk, ez az adatok szempontjából nem igaz, mivel az összes adat kapcsolati módszert és más adat API-kat is használhatunk, melyekhez hozzászoktunk. Ez egy olyan aggodalom, mely ortogonális a módszerek és az eszközök számára, valamint a meghívásuk módjára. A sima HTTP ésURI támogatás minden programozási nyelvben, keretrendszerben és eszköztárban benne van, használatra készen. Végül pedig, a gyártók egyre több és feltehetően egyszerűbb, jobb támogatást hoznak létre a REST-esített HTTP fejlesztéséhez a keretrendszerükben. Erre példa a Sun JAX-RS (JSR 311) vagy a Microsoft REST támogatása a .NET 3.5-ben vagy az ADO.NET Data Services keretrendszerben.
Tehát arra a következtetésre jutottunk, hogy a REST és a legáltalánosabb implementációja, a HTTP, tökéletes? Természetesen nem. Semmi sem tökéletes, főleg nem minden forgatókönyv esetén, és a legtöbbször még egyetlen forgatókönyv számára sem. Nem vettünk számba jópár nagyon logikus problématerületet, melyek sokkal összetettebb válaszokat kívánnak, mint például az üzenet-alapú biztonság, a részleges frissítések és a kötegelt feldolgozás.
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.