Osztott rendszerek. Krizsán Zoltán 1 Ficsór Lajos 1. Webalkalmazások fejlesztése tananyag. Miskolci Egyetem. Bevezetés A múlt - történelem A jelen

Átírás

1 Osztott rendszerek Krizsán Zoltán 1 Ficsór Lajos 1 1 Általános Informatikai Tanszék Miskolci Egyetem Webalkalmazások fejlesztése tananyag

2 Tartalom Bevezetés A múlt - történelem A jelen

3 Denition Distributed computing is a eld of computer science that studies distributed systems. A distributed system consists of multiple autonomous computers that communicate through a computer network. The computers interact with each other in order to achieve a common goal.

4 Osztott rendszerek szükségessége Feladatok elosztása Számítási teljesítmény növelése Adatok (kódok) elosztása Desktop gépek használata duplikált (és inkonzisztens) adatok nélkül A rendszer funkcionalitásának elosztása Komponensek Internet alapú alkalmazások

5 Osztott rendszerek tulajdonságai El nyök Biztonságosabb, duplikálás Gyorsabb, párhuzamos elemek Gyorsabb, mert zikailag közelebb elemek szolgálnak ki Gyorsan építhet, vannak kész elemek Hátrányok Bizonytalanabb, egy feladat több részfeladat különböz helyen Nehézkesebb kongurálás Plussz feladatok (szinkronizáció, hibat rés, mentés,...)

6 Mainframe - kezdetek Klasszikus kliens/szerver architektúra Az adatok kezelése a szerver feladata A feladatok megoszlanak a kliens és a szerver között A felhasználói felület kezelése a kliens dolga

7 Többrészes kliens-szerver architektúra. Multi-tier architecture (nem réteg - layer) Egy alkalmazás több részb l állhat Tipikus: három rész Felhasználói interface Üzleti logika Adatbázis kezelés

8 Middleware koncepció Általános, alkalmazás független szolgáltatások. Lehet vé teszi a felhasználó és az alkalmazás kommunikációját a hálózaton keresztül. A hálózati és az alkalmazói program között helyezkedik el.

9 Alkalmazás modellek

10 Middleware-ek osztályozása Egy szabvány nem elég, mert a különböz jelleg alkalmazások kommunikációs igénye eltér. A middleware-eket osztályozhatjuk abból a szempontból, hogy milyen más, ismert mechanizmus kiterjesztéseként tekintik a modulok közötti kommunikációt. (Milyen metaforát használnak.) A legalacsonyabb szint middleware a socket mechanizmus.

11 Middleware-ek osztályozása II File-kezelés: Socket Távoli eljáráshívás: RPC, DCE RPC, XML RPC, SOAP Adatbázis lekérdezés: RDA Üzenet küldés: MOM Távoli metódushívás: ICE, CORBA, Java RMI (Microsoft WCF?)

12 Socket mechanizmus A metafora a le kezelés Valójában egy API a TCP/IP protokoll verem szolgáltatásaihoz (TCP és UDP) Alkalmas nagyon speciális alkalmazásokhoz (Mindent megtehetek) (I can do everything) Nem alkalmas nagy, bonyolult rendszerek fejlesztésére (Mindent nekem kell megcsinálnom) (I must do everything) protokoll deniálása m ködés

13 Socket mechanizmus II Valójában egy csatornára byte-sorozat tehet ki ("write") és onnan byte sorozat olvasható be ("read"). Nem biztosított, hogy a csatornára kitett információt valaki el is olvassa => valamilyen protokollal össze kell hangolni a kommunikáló feleket. Gyakorlatilag minden plattformra és programozási nyelvhez van implementációja.

14 Socket mechanizmus III A kommunikáló felek futhatnak különböz plattformokon és készülhetnek különböz programozási nyelveken. Számos magasabb szint middleware implementációs eszköze.

15 Távoli eljárás hívás (RPC) Remote procedure call Teljesen homogén rendszereken futó alkalmazások közötti komunikációra lett tervezve: azonos processzor UNIX operációs rendszer C-ben írt programok Ma már közvetlenül ritkán használt middleware, de egy alapötlet, ami a korszer bb middleware-ek is alkalmaznak, már itt megjelenik.

16 Távoli eljárás hívás (RPC) II

17 Távoli eljárás hívás (RPC) III Forgatókönyv 1. A kliens meghívja a csonkeljárást (stub), ami lokális függvénynek látszik. A stub a paramétereket a hálózaton átvihet csomagokba pakolja és meghatározza a szerver címét. 2. Az üzenet átvitelre kerül a hálózati átviteli szolgáltatáson (network transport service) keresztül. 3. Az üzenet átvitelre kerül a hálózaton és a szerver gép hálózati rétege fogadja. 4. A hálózati szolgáltatás értesíti a szerver csonkot hogy egy kérés érkezett. 5. A szerver csonk fogadja az üzenetet, lefordítja a lokális eljáráshívás formátumára és meghívja az eljárást. 6. A szerver végrehajtja az eljárást és visszaadja az eredményt a csonknak.

18 Távoli eljárás hívás (RPC) IV Forgatókönyv 7. A csonk a választ átalakítja hálózati üzenetté és elküldi a hálózati rétegnek. 8. A szerver hálózati rétege visszaküldi a választ a kliens hálózati rétegének. 9. A kliens hálózati rétege elküldi a választ a kliens csonknak. 10. A kliens csonk fogadja a választ, átalakítja eljárás visszatérési értékének és átadja a kliensnek.

19 Távoli eljárás hívás (RPC) Szerepl k kliens oldali csonk (stub) egy funkcionális interface-t mutat a kliens programnak, de valójában a funkciókat egy middleware szolgáltatásait igénybe véve mással (egy remote szolgáltatóval) végezteti el. Kommunikál a szerver oldali csonkkal. Szerver oldali csonk kéréseket fogad, aktivizálja a remote szolgáltatót, és átveszi t le az eredményeket. A kliens oldali stub-al kommunikál. Szokásos elnevezése még: skeleton, proxy Remote szolgáltató Funkcionális interface-e egyezik a kliens stub-éval, és ténylegesen implementálja is azt. Önmagában nem futásképes elem, a szerver oldali stub aktivizálja.

20 XML RPC A klaszikus RPC "újraélesztése" Távoli eljáráshívást valósít meg, de az "eljárás" tetsz leges szolgáltató egység lehet, ami implementálja az adott interface-t. A hagyományos RPC-vel ellentétben HTTP protokoll felett zajlik a kommunikáció. Az adatokat a hagyományos RPC-vel ellentétben XML formátumban küldi át a hálózaton. Miután szabványos, platform és implementációs eszköz független. Az XML RPC HTTP POST metódus segítségével XML-be kódolt kérést küld a szervernek. A szerver elemzi a kérést, meghívja a megfelel metódust, a választ pedig XML-be kódolva visszaküldi. A kliens kikódolja a választ. Az XML RPC támogatja az "ésszer " adatformátumokat.

21 Jelen: valódi osztott rendszer többrészes (multi-tier) architectúra objektum orientált, komponens alapú megközelítés (object-oriented, component based approach) további szolgáltatások rugalmasság directory services tranzakció monitor újrahasznosítható komponensek egy komponens egyszerre lehet kliens és szerver internet - alapú alkalmazások mobil kliensek "szép graka

22 SOAP Simple Object Access Protocol UserLand, Developmentor és Microsoft együttm ködés terméke Jelenleg a W3C felügyeli ezt a szabványt Jóval összetettebb, mint az XML RPC Komplex adatstruktúrák támogatása Az XML namespacek használata globálisan egyértelm vé teszi az átvitt adatot

23 SOAP tulajdonságok Az XML RPC és a SOAP nagy el nye, hogy könnyen átmegy a t zfalakon. Széleskör támogatottság. Az XML RPC és a SOAP nagy hátránya, hogy könnyen átmegy a t zfalakon. Jóval nagyobb er forrás igény ek, mint a hagyományos RPC.

24 Üzleti alkalmazás (forrás:

25 Alacsony szint middleware-ek ICE (Internet Communication Engine) sok nyelvet támogat (.net-et is) modern vannak még hibák könny programozás CORBA (Common Object Request Broker Architecture) bombabiztos elavult nagyon gyors cpp, java bonyolult programozás

26 WCF WCF programozói modell (forrás:

27 WCF II

28 Webalkalmazás fejlesztés gyors php sok adatbázis m velet platform független (tényleg) kis rendszerekhez hatékony sok ingyenes szolgáltató sok munka java platform független (tényleg) széleskör támogatottság, elfogadottság lassabb asp.net Gyors fejlesztés WCF + WPF + felh hatékony elemek kényelmes fejlesztés gyors lehet

29 Összefoglalás Osztott alkalmazások elterjedtek, divatosak. Több jó megoldás van. Ha valami sokat ad, lassú is. Kis projektek esetén jó megoldás a php. Nagyobb projekteknél javasolt a java vagy asp.net. Ha nem kell szerver oldal platform függetlensége, akkor asp.net.