Bevezető

A szoftverfejlesztés mint tudomány már több mint 30 éves múltra tekint vissza. Ezen életút alatt a módszertanok, megközelítések, eszköztárak számos paradigmaváltáson esetek át. A paradigmaváltások mozgatórugója a legtöbb esetben a szoftverfejlesztők produktivitásának a növelése volt. A különböző paradigmák nem feltétlenül szekvenciálisan, egyértelműen sorbarendezhetően követik egymást, hanem inkább egy fa struktúrában ábrázolhatóak.

Adott típusú problémára, adott kontextusban a különböző paradigmák nem nyújtanak azonos teljesítményt sem a szoftver performanciájában, sem a fejlesztők produktivitásában.

A szoftverfejlesztőknek így ismernie kell a különböző paradigmák korlátait ahhoz, hogy adott kontextusban legjobban alkalmazható paradigma mentén valósítsák meg a szoftvert.

A szoftverekkel szemben támasztott nem funkcionális – más néven rendszerszintű – követelmények szintén fejlődtek, egyre nagyobb kihívásokat jelentenek. A Julian Browne által kiválasztott 15 követelményből néhány legfontosabb nem funkcionális követelmény:

· Rendelkezésre állás: azon idő, amely alatt a komponens képes kielégíteni a funkcio-nális követelményekben meghatározott funkciókat azon időhöz viszonyítva, amikor ezt nem tudja megtenni

· Kapacitás/skálázhatóság: a komponens a terhelés növekedésével is képes ellátni a funkcionális követelményekben megfogalmazott feladatokat

· Párhuzamosság: a komponens több, egymással párhuzamos terhelés hatására is ké-pes ellátni a funkcionális követelményekben megfogalmazott feladatokat

· Fejleszthetőség: a komponens új funkcionális követelményeket is el tud látni vi-szonylag szerény fejlesztési ráfordítással

· Együttműködési képesség: a komponens képes környezetével és a szükséges kompo-nensekkel aránytalan plusz terhelés okozása nélkül is együttműködni

· Késleltetés: a komponens az adott funkcionális követelményben szereplő szolgálta-tását adott terhelés mellett adott időtartamon belül kiszolgálja

· Karbantarthatóság: a komponensnek támogatnia kell az adott szervezetben definiált karbantartási feladatokat (pl.: biztonsági mentés)

· Menedzselhetőség: a komponensnek támogatnia kell a megfelelő konfigurálhatósági szintet

· Monitorozhatóság: a komponensnek monitorozhatónak kell lennie

· Visszaállíthatóság: hibás adat esetén a komponensnek támogatnia kell a megfelelő állapot visszaállítását

· Biztonság: a komponensnek a helyi biztonsági előírásoknak megfelelően kell mű-ködnie

· Konzisztencia: a komponens az adatot konzisztens állapotban tartja

A produktivitás növelését tehát ezen követelmények betartása mellett kell elérni. Emiatt nem véletlen, hogy nem csak programozási nyelvekről és azok képességeiről kell

beszél-nünk, hanem egyes nyelvekhez köthető vagy független futtató- és fejlesztői környezetekről, amelyek magas szintű szolgáltatásokkal lehetővé teszik ezen nem funkcionális követelmé-nyek hatékony, produktív kielégítését. Ezen keretrendszerekből, megközelítésmódokból azonban igen sok van és nehéz közöttük eligazodni. (pl. Melyik a jobb a Spring vagy a JEE?) Ahhoz, hogy egy ilyen kérdésre válaszolni tudjunk (ha egyáltalán lehet), meg kell is-mernünk azokat az absztrakt képességeket amelyeket ezek a fejlesztő/futtató környezetek nyújtanak a fejlesztőknek. (pl. Inversion Of Control vagy bijekció) Ezen képességek meg-értéséhez viszont az alapoktól célszerű kiindulni. Esetünkben ez az úgynevezett menedzselt kód. Ilyen a Java és a .NET környezet. A menedzselt kód elsősorban a memóriakezelés ki-szervezését jelenti: a programozónak nem kell a memória allokációjával és felszabadításá-val foglalkoznia, megteszi ezt helyette a szemétgyűjtő. Ezen alapszolgáltatáson túl azonban jóval komplexebb szolgáltatások is megjelennek a menedzselt környezetben (a továbbiak-ban a Java környezetet értjük menedzselt környezet alatt, a legtöbb esetben a megálla-pításaink igazak a .NET világra is). Egy ilyen például az alkalmazás-tartományok kezelése, amikor a menedzselt környezet átveszi az operációs rendszertől az alkalmazások elkülöníté-sének a feladatát, és megvalósítja azt a szálak szintjén. Az alkalmazás-tartományokon belül pedig szerepkör alapú hozzáférés-vezérlés lehetséges, (amennyiben ezt külön beállítjuk és használjuk) amely segítségével adott kódrészek csak adott szerepkör tulajdonosai futtathat-nak (Java esetén ezt a JAAS API segítségével tudjuk elérni). Ezen megoldások bár álta-lánosak, nehezen illeszthetőek bele közvetlenül egy vállalat AAA (Azonosítás, Jogosultság-kezelés, Naplózás – Authentication, Authorization, Accounting) környezetébe. Egy másik fontos alapszolgáltatás a párhuzamosság támogatása. A Java nyelv és a legtöbb JVM alkal-mas párhuzamos futtatásra és az alap problémák (zárolás, megszakíthatatlan kódrész, stb.) kezelésére, bár ez az operációs rendszer képességeitől is függ. Ezzel az eszköztárral azon-ban a programozóra hárul a különböző versenyhelyzetek (holtpontok) kezelése, a párhuza-mos programozás teljes problémaköre. Ez az egyik fő mozgatórugó azon magasabb szintű menedzselt környezetek (ún. vállalati/enterprise környezetek) használata mögött, amelyek elrejtik a párhuzamosság problémáit a programozó elől. A tranzakciók támogatása teljes mértékben hiányzik az alap JVM képességeiből, ezt is különböző vállalati környezetek biz-tosítják. Az alap nyelv és környezet által biztosított objektum-orientált adat- és algoritmus-absztrakció adott méretig megfelelő, azonban nem teszi lehetővé modulok megfelelő meg-fogalmazását, ezen modulok megfelelő menedzsmentjét. A sima procedurális alapú logika-megvalósítást szintén nem célszerű alkalmazni magasabb absztrakciós szinten. Az alkalma-zás menedzselhetősége, tesztelhetősége szintén gyenge lábakon áll. Ezen és még számos probléma (pl. skálázhatóság, web-alkalmazás, integrálhatóság, stb.) miatt az egyszerű me-nedzselt környezet nem igazán nyújtja a kívánatos produktivitást azon szoftverfejlsztők részére, akik a fenti problémákkal szembesülnek. Természetesen minden probléma orvosol-ható sima JVM fölött is, mindent le lehet programozni, a kérdés a produktivitás.

Mint ahogyan már írtuk a megoldást a különböző vállalati környezetek jelentik. Ezen környezetek a menedzselt alapkörnyezet (itt JVM) szolgáltatásaira építve nyújtanak magasabb szintű szolgáltatásokat. Gyakran nevezik ezeket a környezeteket konténereknek.

Két nagy csoportot különböztetünk meg: az első csoportba az alkalmazásokat támogató konténerek tartoznak. Ezekre az jellemző, hogy egy alkalmazás működését támogatják akár fizikailag elosztott környezetben is (ilyenek pl. a Spring, az EJB, a web konténerek, részben az OSGi). A másik az alkalmazás-rendszereket támogató konténerek amelyek több alkalmazás együttműködését támogatják (ilyen pl. az ESB, az SCA, részben az OSGi).

A Java nyelvi környezet egyik meghatározó szabványosító mechanizmusa a Java Community Process (JCP), mely JSR-ek (Java Specification Request) segítségével teszi egységessé a különböző területek problémáit kezelő Java API-k és ezeken keresztül a különböző konténerek interfészeit, telepítés-leíróit és az egyéb kapcsolódó, nem szorosan az implementációval összefüggő kérdéseket. Ezen mechanizmuson túl jelentős befolyása van még a Spring mögött álló VMware cégnek és az OASIS, valamint az OSGi testületek-nek is. Jegyzetünkben igyekszünk az adott problémánál és az arra adható megoldásoknál megemlíteni a kapcsolódó szabványokat is.

A terjedelmi korlátok nem teszik lehetővé, hogy egy-egy problémakört/megoldást olyan részletességgel ismertessünk, amely az adott megoldás hatékony alkalmazásához szükséges lenne. Ehelyett jegyzetünk célja az, hogy bemutassa azokat a problémákat és megoldásokat, amelyekkel a programozó szembesül, amikor egy úgynevezett vállalati alkalmazást fejleszt.

Az első három fejezet egy széleskörű áttekintést nyújt az elosztott rendszerek alkalmazása mögött álló motivációkról, az elosztott viselkedésnél követhető paradigmákról és az elosztottságot elfedő szoftver rétegről. Ezen széles repertoárból a klaszter és SOA alapú elosztott rendszerekre koncentrál a jegyzet. A következő rész (4., 5. fejezet) a nyelvi paradigmák oldaláról közelíti meg a témát és felvillantja azokat a lehetőségeket, melyek adott paradigmák alkalmazásával válnak elérhetővé.

1. ábra

A jegyzet háromnegyedét kitevő 3. és 4. rész pedig a technológia szintjére ereszkedve mutatja be azokat a napjainkban használt megoldásokat, keretrendszereket, melyek az alkalmazások és alkalmazásrendszerek fejlesztése során leggyakrabban előkerülnek.

A 2. ábra egy tipikus elosztott rendszert szemléltet, mely jól demonstrálja a jegyzet megközelítését is. Be szeretnénk egyrészt mutatni a skálázható klaszter alapú alkalmazások fejlesztését (az ábrán a webshop), másrészt a jegyzet célja a SOA alapú rendszerek ele-meinek bemutatása is. Ez a képen a különböző meglévő szoftverrendszerek együtteseként látható.

2. ábra

A következő fejezetben az elosztott rendszerek absztrakt problémáival és az azok elrejtésével foglalkozó köztesréteggel ismerkedünk meg.