5. fejezet, Elosztott redszerek programozása

Ezt a jegyzetet azoknak ajánlom, akik most kezdenek objektum-orientáltan programozni, elosztott rendszert fejleszteni. Nem etalon az objektum-orientált elosztott rendszerek fejlesztéséhez, csupán egy segédlet annak jobb megértéséhez. Az első fejezetben megismerkedünk az osztály fogalmával, az öröklődéssel, az objektumokkal. A második fejezetben az objektumokat egy gépen, egy programban, de több szálon kezeljük, majd több programba osztjuk szét, és ezek kommunikációját figyeljük meg. A harmadik fejezetben hálózatba kötött, elosztott rendszereket építünk. A negyedik fejezetben két külön platformon futtatjuk az alkalmazásainkat. Az alkalmazásokat C++, C#, Python és Java nyelveken készítjük, így tanuljuk meg a négy nyelv használatát. Operációs rendszerként Linux-ot és Windows-t használunk, ezeknek az erőforráskezelését is szükséges megértenünk. Az egy gépen futó alkalmazásainknál megosztott memóriaterületet (shared memory), csöveket (pipe) és üzenetküldést (signal) alkalmazunk a kommunikációhoz, és itt egy kicsit gyakorlatozunk Linux-on az Eclipse IDE és GNU C++ párossal és néhány Bash/TCL szkripttel. XML-RPC, HTTP, SOAP, CORBA, Java-RMI, DCOM és .Net Remoting technikákat alkalmazunk hálózaton futó alkalmazásainknál. Itt megismerkedünk a marshalling/unmarshalling, serialization/deserialization és streaming fogalmával - amik röviden az objektumok és hívások hálózati forgalomnak megfelelő szabványos átalakításait jelentik-, és a stub-skeleton/home-remote párok értelmezéseivel - ami a lokális és távoli objektumok megvalósulását, elérését jelentik. Elosztott memória objektumok kezelésre megvizsgáljuk a memcached és a Jackrabbit projektet.

Ha terhelés elosztásra, redundanciára van szükségünk, elosztott rendszereket építünk. Üzleti inteligenciát is a középső rétegbe teszünk, ha vékony és/vagy vastag klienseket használunk. A felhasználói felület és az adatbázis motor többrétűségét is eredményezheti egy középső réteg. Esetenként összeépíthető a középső réteg az adatbázis és tárház szolgáltatással. Azonban ezeket az összeépítési lehetőségeket igen drágán megfizettetik az üzleti célokra készülő szerverekben, többnyire a létrehozható kapcsolatok számának meghatározásával. Kapcsolatszám alapú licenszeken egy középső réteggel spórolni is lehet, hiszen a modern adatbázis motorok egy kapcsolaton több párhuzamos lekérdezést is futtathatnak. Ezért az alkalmazás read-only kapcsolatait egy tranzakciós csoportba szervezhetjük, mivel azok nem változtatnak az adatbázison. A módosításokat külön tranzakciókba csoportosíthatjuk, vagy akár végrehajtási sorba is szervezhetjük, ha viszonylag kevés módosítást futtatunk párhuzamosan.

Terhelés elosztásra olyan esetben van szükség, amikor egy számítógép teljesítménye kevés a feladat végrehajtására. Ilyenkor a műveleteket több számítógép hálózatba kapcsolva, párhuzamosan hajtja végre. Ezt megtehetik úgy, hogy részfeladatokat oszt ki egy mester a többi szolga gépnek, vagy teljes feladatokat kapnak a szolga gépek, és ezek az eredményt közvetlenül a végrehajtást indító kliensnek küldik vissza.

Redundanciát az adatok biztonságos tárolásakor alkalmaznak. Egy számítógépbe több háttértárat építve azok RAID-be köthetők, így alkalmasak az adatok tükrözésére, hibajavításra, gyorsabb adatelérésre. Hálózatba kötött számítógépek szintén végezhetnek redundáns adattárolást.

A két megoldást együtt is használják, nagy megbízhatóságú rendszerek üzemeltetésénél. Mindezek tükrében a fejlesztések során lényeges sarokpontok a szinkronizáció és a konkurencia kezelés, és ezeknek a technikáit is megismerjük ebben a szakácskönyvben. A fentebb felsorolt kommunikációs szabványok csak egy részét fedik le a hálózatba kötött gépek közötti szinkronizációs csatornáknak, azonban ezek jó bevezetést jelenthetnek további technikák megismeréséhez, mint például a Signal System #7, amit telekommunikációs célokra fejlesztettek ki.