UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 2. Elosztott rendszerek Dr. Bilicki Vilmos Szegedi Tudományegyetem.

Az előadások a következő témára: "UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 2. Elosztott rendszerek Dr. Bilicki Vilmos Szegedi Tudományegyetem."— Előadás másolata:

1 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 2. Elosztott rendszerek Dr. Bilicki Vilmos Szegedi Tudományegyetem Informatikai Tanszékcsoport Szoftverfejlesztés Tanszék

2 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Tartalom  Bevezető  Felmerülő problémák  Alkalmazás architektúrák  Elosztott rendszer architektúrák  SOA koncepció  Virtualizációs szintek  Összefoglaló 2014. 07. 15.2Programrendszerek fejlesztése

3 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Valós nagy rendszerrel kapcsolatos tapasztalatok (Inktomi) 2014. 07. 15.3 Összeomlások/Merevlemez hibákÓránként Adatbázis frissítésekNaponta Szoftver frissítésekHetente/Havonta OS frissítésekKétszer Energetikai hibáknéhány Hálózat hibák11 Az egész infrastruktúra fizikai átköltöztetése 2 Programrendszerek fejlesztése

4 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Motiváció – nem funkcionális követelmények  Rendelkezésre állás: azon idő amely alatt a komponens képes kielégíteni a funkcioná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 a 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 viszonylag 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 komponensekkel 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áltatá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.: backup)  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. 2014. 07. 15.4Programrendszerek fejlesztése

5 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Rendelkezésre állás  Az alábbi paraméterektől függ ■Megbízhatóság: –Annak az esélye, hogy egy rendszer adott ideig hibamenetesen működik ( meghibásodási ráta) ■Karbantarthatóság:  –Annek az esélye, hogy egy meghibásodás után egy adott időtartam alatt visszaáll a működőképes állapot (  megjavítási ráta) ■A rendelkezésre állás a rendszer működőképes ideje és a teljes idő hányadosa 2014. 07. 15.5Programrendszerek fejlesztése R(t) = e - t M(t) = 1 - e-mt A = Up-Time Up-Time + Down-Time

6 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Fogalmak  MTTF Mean Time To Fail:  MTBF Mean Time Between Failure:  MTTR Mean Time To Repair: 2014. 07. 15.Programrendszerek fejlesztése6 MTTF = B1 + B2 + B3 3 Up Down A1A3A2 t B1B2B3 MTBF = (A1 + B1) + (A2 + B2) + (A3 + B3) 3 MTTR = A1 + A2 + A3 3

7 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Fürdőkád görbe 2014. 07. 15.Programrendszerek fejlesztése7 Burn-In Useful Life Note: Failure Rate is constant Wear-Out Time Failure Rate

8 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Megoldás: redundancia  Aktív redundancia ■Elem/komponens duplikálás ■Rendszer duplikálás  Passzív redundancia ■Hot Standby ■Warm Standby ■Cold Standby  Soros rendszer:  Párhuzamos rendszer: 2014. 07. 15.8Programrendszerek fejlesztése R s = p 1. p 2 ……. p n R s = 1 - q 1 q 2 ……q m q 1 = 1 - p 1 q 2 = 1 - p 2

9 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Példa  Amazon EC2: ■99.95% átlagos rendelkezésre állás egy év alatt ■Évi 4,38 óra leállás  Google Apps: ■99.9% havi alapon ■Évi 8,76 óra leállás, havi 0,73 óra leállás  Serveloft: ■Hálózat: 99,9%, 4 órás helyreállítási idő ■Gép: 4 órás helyreállítási idő  Rackspace: ■Hálózat: 100% (karbantartáson kívül) ■Infrastruktúra: 100% havonta (karban tartáson kívül) ■Gép: 1 órán belül csere 2014. 07. 15.Programrendszerek fejlesztése9

10 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Skálázhatóság  Adat tárolás/Feldolgozás ■Vertikális (Scale up) –Fizikai korlátai vannak (processzorok száma, JVM szemétgyűjtő, …) –Közös memória mint kommunikációs médium ■Horizontális (Scale out) –Elosztott rendszer (Leslie Lamport: „Elosztott rendszer az ahol egy addig teljesen ismeretlen számítógép hibája teszi használhatatlanná a gépünket”) –Elvileg korlátlan (elosztottságból fakadóan nem lehet ACID) –Távoli hozzáférés problematikája (érték szerint vs. referencia szerint) 2014. 07. 15.10Programrendszerek fejlesztése

11 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Virtualizációs rétegek 2014. 07. 15.11Programrendszerek fejlesztése

12 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS IaaS - Infrastruktúra mint Szolgáltatás  Valós vagy virtualizált HW ■Processzor ■Memória ■I/O ■Hálózat  Függ a fizikai eszközöktől  Példák: 2014. 07. 15.Programrendszerek fejlesztése12

13 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Virtualizáció  Absztrakt fizikiai komponensek logikai objektumok segítségével  A fizikai és logikai objektumok dinamikus kötése  Példa: ■Hálózat: VLAN, VPN, P2P ■Tárhely: SAN ■Számítógép: Virtuális Gép 2014. 07. 15.Programrendszerek fejlesztése13

14 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Fizikai vs. Virtuális gép  Fizikai HW: ■Processzor, memória, chipset, I/O busz ■A fizikai erőforrások gyakran üresjáratban vannak  Szoftver: ■Szorosan kapcsolódik a HW-hez ■Egy aktív OS kép ■Az OS vezérli a HW-t  Hardver szintű absztrakció: ■Virtuális HW: processzor, memória, chipset, I/O eszközök, … ■Magában foglalja az OS és alkalmazás állapotot  Virtualizációs SW: ■Elválasztja a HW-t és az OS-t ■A vendég OS-ek felé multiplexálja a HW-t ■Erős szeparáció ■Kezeli a fizikai erőforrásokat 2014. 07. 15.Programrendszerek fejlesztése14

15 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Típusai  Type 2: Hosztolt architektúra: ■Befogadó Oprendszer felett van futtatva ■Kicsi kontextus váltó meghajtó  Type 1: Csupasz fém architektúra ■A Hypervisort közvetlenül a HW-re telepítik  Paravirtualizáció ■Az operációs rendszer tud a Hyervisorról 2014. 07. 15.Programrendszerek fejlesztése15

16 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Magas rendelkezésre állás 2014. 07. 15.Programrendszerek fejlesztése16

17 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Konszolidált mentés 2014. 07. 15.Programrendszerek fejlesztése17

18 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Probléma: 2014. 07. 15.Programrendszerek fejlesztése18

19 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS PaaS - Gartner 2014. 07. 15.Programrendszerek fejlesztése19

20 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS PaaS Felmerülő problémák  Leslie Lamport egy igen frappáns definíciót adott az eloszotott rendszerekre:  “A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable” azaz „Elosztott rendszer az, ahol egy olyan számítógép hibája teszi használhatatlanná a saját gépünket, amiről azt sem tudtuk, hogy létezik.”  Egy szabatosabb definíció Wolfgang Emmerichtől: „Elosztott rendszernek nevezzük az autonóm, egymással hálózaton együttműködő számítógépeket, amelyek közös együttműködésén alapuló szolgáltatását a felhasználó úgy érzékeli, mintha azt egy integrált eszköz szolgáltatta volna.” 2014. 07. 15.20Programrendszerek fejlesztése

21 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Határok – CAP tétel (Brewer tétele)  Internet méretű elosztott rendszerek ■C – Konzisztencia (Minden csomópont ugyanazt az adatot látja adott időben) –A – Atomi –C - Konzisztens –I - Elkülönítés –D - Tartósság ■A - Rendelkezésre állás (csomópontok kiesése nem akadályozza meg a maradókat a működéstől) –X % időben elérhető ■P - Partíció tűrés (tetszőleges üzenetvesztést tolerál) –Gilber és Lynch definíciója szerint „A teljes rendszer (hálózat) hibáján kívül semmilyen hiba kombináció sem okozhatja azt, hogy a rendszer hibásan válaszol”.  Ezek közül csak kettő teljesülhet 2014. 07. 15.21Programrendszerek fejlesztése

22 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Nem partíció tűrő  Minden a tranzakció által érintett adat egy gépen van  Következmények: ■Vertikális skálázás 2014. 07. 15.22Programrendszerek fejlesztése

23 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Nincs rendelkezésreállás  Partíció esetén megvárjuk míg megszűnik: megáll az élet  Adatbázis klaszterek, elosztott zárolási protkollok  Van ahol ez elkerülhetetlen: ■Pl: Google bigtable zárolások -> Paxos szavazásos algoritumos 2014. 07. 15.23Programrendszerek fejlesztése

24 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Gyenge konzisztencia  Sok helyen az ACID nem kritikus  Erős konzisztencia – ACID  Inkonzisztencia-ablak ■Nem a legfrissebb adat kerül visszaadásra  Végső fokon konzisztens ■A rendszer mérete határozza meg az inkonzisztencia ablakot (replikák száma, a rendszer terhelése, hálózati késleltetés, stb.) ■Ezt valósítja meg a BASE (Basically Available Soft-state Eventually consistent) megközelítés (pl.: DNS) 2014. 07. 15.24Programrendszerek fejlesztése

25 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS ACID vs BASE ACIDBASE Erős konzisztenciaGyenge konzisztencia (a régi adat is megengedhető időnként) IzolációRendelkezésreállás Commit-ra fókuszálLegjobb szándék szerinti Beágyazott tranzakciókA megközelítőleges válasz OK Rendelkezésreállás? Konzervatív (Pesszimista)Agresszív (optimista) Lassú evolúcióGyors evolúció 2014. 07. 15.25Programrendszerek fejlesztése

26 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Architektúra típusok  Monolit ■Tipikusan eljárás szintű struktúrálás  Objektum orientált ■Objektum szintű struktúrálás ■Skandináv vs. Amerikai iskola (domain model vs. újrahaszonosíthatóság) ■Alap granularitás / rétegek építőelemei  Komponens orientált ■Üzleti funkciók mentén több objektumot magába foglaló egységek. Nagyobb lépték. ■Fontos, hogy hozott anyagból is jól tudjon dolgozni (ritka a zöldmezős beruházás) ■Kritikus fontosságú a laza csatolás figyelembevétele (az OO-nál ez nem szempont) ■Gyakran saját perzisztencia megoldással bírnak az egyes komponensek.  Szolgáltatás orientált ■Futó kód az építőkő 2014. 07. 15.26Programrendszerek fejlesztése

27 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS A határ  Interfész két modul között ■P2P, …  Az alapvető határ: ■Metódus/Függvény hívás  A szál átlépi a határt  A két oldal azonos címtérben van 2014. 07. 15.27Programrendszerek fejlesztése

28 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Más címtér  Mi van akkor ha ez nem igaz? ■IPC/RPC, ….  Nem használhat referencia szerinti átadást  Mi van akkor, ha a memória egy része osztott? ■Nem minden pointerre igaz ez ■Szinkronizálni kell a kliens és a szerver között 2014. 07. 15.28Programrendszerek fejlesztése

29 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Megbízunk a másik oldalban?  Nincs bizalom?  Meg kell vizsgálni az argumentumokat  Nincs pointer átadás  A kernelekben ez meg van valósítva  A legtöbb rendszerben nincs ■TCP ■Web ■…. 2014. 07. 15.29Programrendszerek fejlesztése

30 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Részleges hiba  Meghibásodhat a két rész függetlenül?  Új kivételek  Helyi erőforrások felszabadítása  Bérletek használata 2014. 07. 15.30Programrendszerek fejlesztése

31 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Kliens Muliplexelés  Nagyszámú konkurens hozzáférés  SLA – belépés vezérlés  Kliensek kiegyensúlyozott kezelése  Audit, számlázás  Kliens elkülönítés  Határ definíció 2014. 07. 15.31Programrendszerek fejlesztése

32 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Határ evolúció  Frissíthetjük-e a rendszereket egymástól függetlenül?  Verziók?  Protokoll frissítés?  Visszafelé kompatibilis? 2014. 07. 15.32Programrendszerek fejlesztése

33 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Protokoll vs. API  A protokoll szemlélet sikeresebb mint az API  Érték szerinti átadás  Hibákra is részben fel vannak készítve  Nem akarnak helyi hívásnak tűnni  Explicit állapotgép a hívás válasz helyett 2014. 07. 15.33Programrendszerek fejlesztése

34 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS XML  Semmit sem old meg  Kiterjeszthető típusú RPC  Közös séma ami figyelmen kívül hagyható  Valós problémákat elfedheti 2014. 07. 15.34Programrendszerek fejlesztése

35 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Elosztott rendszer architektúrák  CS – Kliens szerver  P2P  N rétegű architektúra  Szorosan csatolt rendszer  Lazán csatolt rendszer (EDA) ■Esemény ■ESP ■CEP  SBA (Space Base Architecture) (PU alapú) ■Klaszter ■Felhő ■Rács ■Elosztott Objektum 2014. 07. 15.35Programrendszerek fejlesztése

36 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Kliens - Szerver  Szerepkörök alapján határozza meg a rendszerben résztvevő entitások helyzetét.  A szerver oldal birtokolja az erőforrásokat,  Kliens oldal használja azokat.  Ezen elvek mentén működnek napjaink legnépeszerűbb protokolljai (HTTP, SMTP, DNS, stb.).  A megközelítés előnyei ■ könnyebb karbantarthatóság, és a központosítás miatt elvileg könyebb biztonságos rendszert készíteni.  Hátránya ■a skálázhatóság és a robosztusság kérdése, mivel ez csak a szerver oldalon múlik. 2014. 07. 15.36Programrendszerek fejlesztése

37 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS 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.  Skype vagy a legtöbb fájlcserélő protokoll ezen az elven működik.  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ázhatóságot nyújt.  Típusai: ■Elosztott kivonat tábla (pl.: Kademina) ■Kicsi világ (pl.: Gnutella)  Szolgáltatás primitívek: ■Store ■Load ■Search 2014. 07. 15.37Programrendszerek fejlesztése

38 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS N-rétegű architektúra  Megjelenítés: a társ rendszer felé nyújt interfészt (gyakran ez a felhasználói interfész), és az ehhez kapcsolódó eseményeket kezeli le. Ennek a leggyakoribb megvaló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. 2014. 07. 15.38Programrendszerek fejlesztése

39 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Szorosan csatolt rendszerek  A szorosan csatolt rendszerekben a komponensek (vagy ha ilyenek nincsenek, akkor az osztályok, objektumok) szinkron 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. 2014. 07. 15.39Programrendszerek fejlesztése

40 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Lazán csatolt rendszerek  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): ezesetben 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. 2014. 07. 15.40Programrendszerek fejlesztése

41 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS SBA rendszerek  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 feldologzá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 eloszott 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). 2014. 07. 15.41Programrendszerek fejlesztése

42 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS SOA koncepció 2014. 07. 15.42Programrendszerek fejlesztése

43 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS SOA háromszög 2014. 07. 15.43Programrendszerek fejlesztése

44 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS WS világ 2014. 07. 15.44Programrendszerek fejlesztése

45 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS Összefoglaló  Bevezető  Felmerülő problémák  Alkalmazás architektúrák  Elosztott rendszer architektúrák  SOA koncepció  Virtualizációs szintek  Összefoglaló 2014. 07. 15.45Programrendszerek fejlesztése

46 UNIVERSITY OF SZEGED D epartment of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS A következő előadás tartalma  Kontextus  Biztonsági kontextus  Tranzakciós kontextus  Perzisztencia kontextus 2014. 07. 15.46Programrendszerek fejlesztése