Bevezetés
A múlt - történelem
A jelen
Osztott rendszerek Krizsán Zoltán 1
1
Ficsór Lajos
1
Általános Informatikai Tanszék Miskolci Egyetem
Webalkalmazások fejlesztése tananyag
Bevezetés
Tartalom
Bevezetés
A múlt - történelem
A jelen
A múlt - történelem
A jelen
Bevezetés
A múlt - történelem
De nition
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.
A jelen
Bevezetés
A múlt - történelem
Osztott rendszerek szükségessége I Feladatok elosztása I
Számítási teljesítmény növelése
I Adatok (kódok) elosztása I
Desktop gépek használata duplikált (és inkonzisztens) adatok nélkül
I A rendszer funkcionalitásának elosztása I I
Komponensek Internet alapú alkalmazások
A jelen
Bevezetés
A múlt - történelem
Osztott rendszerek tulajdonságai El®nyök I Biztonságosabb, duplikálás I Gyorsabb, párhuzamos elemek I Gyorsabb, mert zikailag közelebb elemek szolgálnak ki I Gyorsan építhet®, vannak kész elemek
Hátrányok I Bizonytalanabb, egy feladat több részfeladat különböz® helyen I Nehézkesebb kon gurálás I Plussz feladatok (szinkronizáció, hibat¶rés, mentés, ...)
A jelen
Bevezetés
A múlt - történelem
Mainframe - kezdetek
Klasszikus kliens/szerver architektúra I Az adatok kezelése a szerver feladata I A feladatok megoszlanak a kliens és a szerver között I
I
A felhasználói felület kezelése a kliens dolga
A jelen
Bevezetés
A múlt - történelem
A jelen
Többrészes kliens-szerver architektúra.
I Multi-tier architecture (nem réteg - layer)
I Egy alkalmazás több részb®l állhat
I Tipikus: három rész I I I
Felhasználói interface Üzleti logika Adatbázis kezelés
Bevezetés
A múlt - történelem
Middleware koncepció I Általános, alkalmazás független szolgáltatások.
I Lehet®vé teszi a felhasználó és az alkalmazás kommunikációját a hálózaton keresztül.
I A hálózati és az alkalmazói program között helyezkedik el.
A jelen
Bevezetés
Alkalmazás modellek
A múlt - történelem
A jelen
Bevezetés
A múlt - történelem
A jelen
Middleware-ek osztályozása
I Egy szabvány nem elég, mert a különböz® jelleg¶ alkalmazások kommunikációs igénye eltér®.
I 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.)
I A legalacsonyabb szint¶ middleware a socket mechanizmus.
Bevezetés
A múlt - történelem
Middleware-ek osztályozása II
I File-kezelés: Socket I Távoli eljáráshívás: RPC, DCE RPC, XML RPC, SOAP I Adatbázis lekérdezés: RDA I Üzenet küldés: MOM I Távoli metódushívás: ICE, CORBA, Java RMI (Microsoft WCF?)
A jelen
Bevezetés
A múlt - történelem
A jelen
Socket mechanizmus A metafora a le kezelés
I Valójában egy API a TCP/IP protokoll verem szolgáltatásaihoz (TCP és UDP)
I Alkalmas nagyon speciális alkalmazásokhoz (Mindent megtehetek) (I can do everything)
I Nem alkalmas nagy, bonyolult rendszerek fejlesztésére (Mindent nekem kell megcsinálnom) (I must do everything) I I
protokoll de niálása m¶ködés
Bevezetés
A múlt - történelem
A jelen
Socket mechanizmus II
I Valójában egy csatornára byte-sorozat tehet® ki ("write") és onnan byte sorozat olvasható be ("read").
I Nem biztosított, hogy a csatornára kitett információt valaki el is olvassa => valamilyen protokollal össze kell hangolni a kommunikáló feleket.
I Gyakorlatilag minden plattformra és programozási nyelvhez van implementációja.
Bevezetés
A múlt - történelem
Socket mechanizmus III
I A kommunikáló felek futhatnak különböz® plattformokon és készülhetnek különböz® programozási nyelveken.
I Számos magasabb szint¶ middleware implementációs eszköze.
A jelen
Bevezetés
A múlt - történelem
Távoli eljárás hívás (RPC) Remote procedure call
I Teljesen homogén rendszereken futó alkalmazások közötti komunikációra lett tervezve: I I I
azonos processzor UNIX operációs rendszer C-ben írt programok
I 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.
A jelen
Bevezetés
A múlt - történelem
Távoli eljárás hívás (RPC) II
A jelen
Bevezetés
A múlt - történelem
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.
A jelen
Bevezetés
A múlt - történelem
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.
A jelen
Bevezetés
A múlt - történelem
A jelen
Távoli eljárás hívás (RPC) Szerepl®k I
kliens oldali csonk (stub) I
I
I
Szerver oldali csonk I
I I
I
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. 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ó I
I
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.
Bevezetés
A múlt - történelem
XML RPC I I I I I I I I I I
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.
A jelen
Bevezetés
A múlt - történelem
Jelen: valódi osztott rendszer I többrészes (multi-tier) architectúra I objektum orientált, komponens alapú megközelítés (object-oriented, component based approach)
I további szolgáltatások I I
directory services tranzakció monitor
I rugalmasság I újrahasznosítható komponensek I egy komponens egyszerre lehet kliens és szerver I internet - alapú alkalmazások I mobil kliensek I "szép gra ka
A jelen
Bevezetés
A múlt - történelem
A jelen
SOAP
Simple Object Access Protocol
I UserLand, Developmentor és Microsoft együttm¶ködés terméke I Jelenleg a W3C felügyeli ezt a szabványt I Jóval összetettebb, mint az XML RPC I Komplex adatstruktúrák támogatása I Az XML namespacek használata globálisan egyértelm¶vé teszi az átvitt adatot
Bevezetés
A múlt - történelem
A jelen
SOAP tulajdonságok
I Az XML RPC és a SOAP nagy el®nye, hogy könnyen átmegy a t¶zfalakon.
I Széleskör¶ támogatottság. I Az XML RPC és a SOAP nagy hátránya, hogy könnyen átmegy a t¶zfalakon.
I Jóval nagyobb er®forrás igény¶ek, mint a hagyományos RPC.
Bevezetés
A múlt - történelem
Üzleti alkalmazás
(forrás: http://encyclopedia2.thefreedictionary.com/middleware)
A jelen
Bevezetés
A múlt - történelem
Alacsony szint¶ middleware-ek I ICE (Internet Communication Engine) I I I I
sok nyelvet támogat (.net-et is) modern vannak még hibák könny¶ programozás
I CORBA (Common Object Request Broker Architecture) I I I I I
bombabiztos elavult nagyon gyors cpp, java bonyolult programozás
A jelen
Bevezetés
A múlt - történelem
WCF
WCF programozói modell (forrás: http://msdn.microsoft.com/en-us/library/ms733128.aspx)
A jelen
Bevezetés
WCF II
A múlt - történelem
A jelen
Bevezetés
A múlt - történelem
A jelen
Webalkalmazás fejlesztés php
gyors sok adatbázis m¶velet I platform független (tényleg) I kis rendszerekhez hatékony I sok ingyenes szolgáltató I I
I
sok munka
java
platform független (tényleg) I széleskör¶ támogatottság, elfogadottság I
I
lassabb
asp.net
Gyors fejlesztés WCF + WPF + felh® hatékony elemek I kényelmes fejlesztés I I
I
gyors lehet
Bevezetés
A múlt - történelem
Összefoglalás
I Osztott alkalmazások elterjedtek, divatosak. I Több jó megoldás van. I Ha valami sokat ad, lassú is. I Kis projektek esetén jó megoldás a php. I Nagyobb projekteknél javasolt a java vagy asp.net. I Ha nem kell szerver oldal platform függetlensége, akkor asp.net.
A jelen
