Elosztott rendszer-architektúrák

Az elosztott rendszereket megvalósító szoftver-architektúrák esszenciális típusait architek-túra mintaként szokták emlegetni. Ezen architekarchitek-túra minták nem ortogonálisak, azaz pl. egy megoldás lehet kliens-szerver és lazán vagy szorosan csatolt egyszerre. A következőkben felsorolt architektúra minták sokszor inkább kiegészítik mint kizárják egymást.

3.2.1. Kliens-szerver

A kliens-szerver architektúra minta elsősorban a szerepkörök alapján határozza meg a rendszerben résztvevő entitások helyzetét. A szerver oldal birtokolja az erőforrásokat, míg a kliens oldal használja azokat. Ezen elvek mentén működnek napjaink legnépszerűbb proto-kolljai (HTTP, SMTP, DNS, stb.). A megközelítés előnyei közé tartozik a könnyebb kar-bantarthatóság, és a központosítás miatt elvileg könnyebb biztonságos rendszert készíteni.

A megközelítés hátránya a skálázhatóság és a robosztusság kérdése, mivel ez csak a szerver oldalon múlik.

3.2.2. P2P

A kliens szerver architektúra ellentétje a P2P architektúra, ahol egyenrangú vagy nem egyenrangú, de az erőforrások megosztásában egyaránt részt vevő entitások alkotják a rendszert. Napjaink legnépszerűbb VoIP alkalmazása, a Skype vagy a legtöbb fájlcserélő protokoll ezen az elven működik. Ami viszont kevésbé látható, hogy a későbbiekben említett felhő architektúrák, de még a klaszter megoldások alatt is gyakran P2P algorit-musokon alapuló replikációs megoldások vannak. A kliens-szerver megoldással szemben a hátránya a komplexitásában és elosztottságában rejlik, viszont cserébe extrém skáláz-hatóságot nyújt. (Vegyük észre, hogy ezek nem merőleges területek: a JBoss klaszter alatt lehet P2P gyorsítótár, azaz a rendszer egy része megvalósítja a P2P paradigmát, míg a kiszolgált kliensek HTTP protokollon férnek hozzá a tartalomhoz, megvalósítva a kliens-szerver paradigmát).

3.2.3. Többrétegű architektúrák

A szerepkörökön túllépve egy másik rendezőelv a logika lehetséges szeparálásának módja.

Erre jó példa a 3- vagy többrétegű architektúra. Ez esetben a konkrét erőforrás megosztásá-nak részleteit vizsgáljuk. Az alkalmazást/rendszert skálázhatóság, robosztusság, menedzsel-hetőség és sok más szempont miatt is érdemes rétegekre bontani. A leggyakrabban alkal-mazott rétegelés a háromrétegű architektúra, melynél az alábbi rétegeket definiáljuk:

· Megjelenítés: a társ rendszer felé nyújt interfészt (gyakran ez a felhasználói inter-fész), és az ehhez kapcsolódó eseményeket kezeli le. Ennek a leggyakoribb megva-lósítása a weboldal és az előállító logika.

· Üzleti logika: ezen réteg feladata az üzleti folyamatok futtatása, hosszú életű tranzakciók kezelése. Itt kerül sor az adatok szélesebb hatókört, több adattípust átölelő szabályainak kikényszerítése is.

· Perzisztencia: az adatok tartós tárolásával foglalkozik. Itt történik meg a szűkebb hatókörrel rendelkező adatszabályok kikényszerítése és gyakran az objektum és relációs adatmodellek közötti leképezés is.

A háromrétegű architektúrát gyakran keverik a megjelenítésben használatos MVC (Model-View-Controller) architektúrával. Fontos megemlíteni, hogy míg az MVC-nél a View és a Controller egyaránt kommunikál a Modellel addig a három rétegű architektúránál ez nem történik meg. A megjelenítés réteg csak az üzleti logikán át érheti el a perzisz-tenicát. A három réteg jelenti alapesetben azokat a választóvonalakat, amelyek mentén a horizontális skálázás megoldható. Lehet például egy olyan RIA (Rich Internet Application), ahol a megjelenítés rétegen nagy terhelés van de ez az alatta lévő rétegekre nem terjed át, mivel hatékony gyorsítótárazást alkalmaz. Ekkor a megjelenítés réteget kell skálázni több gép bevonásával, míg az üzleti logika és a perzisztencia réteg megmaradhat egy-egy gépen.

Amennyiben skálázhatóság, robosztusság vagy egyéb szempontok miatt nem elegendő a három réteg, akkor a három réteget újabb rétegekre lehet bontani. Ennek egy gyakori példá-ja, amikor a perzisztenica réteget két rétegre bontjuk: az egyik az ORM (objektum-relációs leképezés) által megvalósított DAO (Data Access Objects) tervezési minta mentén meg-valósított réteg, míg alatta a hagyományos – esetenként heterogén – adatbázis réteg helyez-kedik el.

3.2.4. Szorosan csatolt rendszerek

Egy újabb rendezőelv lehet a rendszert alkotó modulok csatolásának módja. A szorosan csatolt rendszerekben a komponensek (vagy ha ilyenek nincsenek, akkor az osztályok, objektumok) aszinkron módon kommunikálnak egymással, szorosan követve a klasszikus függvényhívás szemantikáját. Ebbe a kategóriába tartoznak a távoli eljárásokon alapuló rendszerek is. A megközelítés előnye az, hogy a rendszer a klasszikus, egy processzen belül is megtalálható interkaciós paradigmákra épít, egyszerűvé téve ezzel a megvalósítást. Ezzel a megoldással viszont nehéz robosztus, skálázható rendszereket létrehozni.

3.2.5. Lazán csatolt rendszerek

A lazán csatolt rendszerek a szorosan csatolt rendszerekkel ellentétben üzenet alapú kom-munikációra építenek és e kommunikáció mentén az aszinkron interakció az alapértelme-zett. Ezen paradigmák mentén jóval nehezebb egy rendszert megvalósítani, mivel az aszinkronitás, többutas végrehajtás végig ott lebeg a fejlesztők szeme előtt, azonban ez a leginkább járható út a robosztus, skálázható rendszerek megvalósítására. Ebbe a kate-góriába tartozik még az eseményalapú szoftver architektúra is (EDA – Event Driven Software Arhictecture), mely az eseményeket tekinti a komponensek közötti interakció alapjainak. Az események feldolgozása az alábbi kategóriákba csoportosítható:

· Egyszerű események feldolgozása: ez esetben egy atomi esemény beérkezése indít el egy feldolgozási folyamatot. Egy példa erre a különböző felhasználói interakciókat támogató keretrendszerek eseménykezelése (pl. SWING JSF, stb.)

· Eseményfolyamok feldolgozása (Event Stream Processing – ESP): ez esetben eseményfolyamokat szűrnek egyszerű feltételek alapján, és az érdekes eseményekre feliratkozott vevőknek küldik ki a szűrt eseményeket. Példa lehet erre, amikor a naplózásnál csak adott szintet elérő eseményeket továbbítunk.

· Komplex esemény feldolgozás (Complex Event Processing - CEP): ez esetben a valós idejű eseményfolyamon értékelünk ki olyan szabályokat, melyek figyelembe vehetik az események sorrendiségét, bekövetkeztét, számosságát és számos egyéb tulajdonságát. Erre a későbbiekben majd látunk példát a Drools-szal kapcsolatban.

3.2.6. Tér alapú architektúrák (Space Based Architectures - SBA)

A tér alapú elosztott architektúrák lényege az, hogy a rendszert olyan egymástól független egységekre osztják, amelyeket tetszőleges számban lehet hozzáadni, elérve ezzel a lineáris skálázódást. Ezeket az egységeket feldolgozó egységeknek (Processing Unit - PU) nevezik, és tipikusan egy olyan szoftver rétegen ülnek, amely elrejti előlük az elosztottság problémáit. Ez a réteg – a későbbiekben bővebben kifejtett – köztes réteg. Ennek három alapvető formája van:

· Klaszter alapú (Cluster): a feldolgozásra koncentrál, az adattárolásra különböző tervezési minták vannak, a tipikusan olvasás jellegű alkalmazásoknál igen jó skálázódást tud elérni a CAP kompromisszumai nélkül. Le tudja kezelni az írási ütközést is. Példák erre a különböző alkalmazásszerverek által nyújtott klaszterezési lehetőségek (pl. JBoss Cluster)

· Felhő alapú (Cloud): a CAP paradigma mentén a skálázható adattárolást is biztosítja, tipikusan a konzisztencia rovására. Példa erre a Google App Engine.

· Rács alapú (Grid): főleg a feldolgozásra koncentrál, nincs igazán írási ütközés, így a feldolgozás tetszőlegesen párhuzamosítható. Ezt leginkább munkafolyamatok (Job) formájában szokták megtenni.

· Elosztott objektum alapú (Distributed Objects): az elosztott objektumok gyakran a fenti architektúrák alapjait képezik. Ekkor egy-egy objektum vagy replikánsa (replikált objektum – replicated object) megjelenik azokon a helyeken, ahol használják, és a háttérben egy keretrendszer (köztes réteg) gondoskodik arról, hogy konzisztens maradjon, vagy pedig egy helyen van tárolva (élő objektum – live object), és azokon a helyszíneken, ahol szükséges megfelelő proxy objektumok képviselik az objektumot. A megosztott objektumok gyakran objektumterekbe (object spaces) vannak szervezve, melyet valamilyen köztes réteg tart karban, virtualizál (pl. Java Spaces).

A különböző szoftver-architektúrák nem egymást kizárják, hanem igen gyakran egy-másra épülnek. Egy-egy komplex rendszerben számos szoftver-architektúra megtalálható.

A következő fejezetekben az elosztott rendszerek megvalósítása mögött álló legnépszerűbb paradigmát, a Szolgáltatás-orientált paradigmát (Service Oriented Architecture Para-digm) mutatjuk be.