Programrendszerek fejlesztése Bilicki Vilmos

Bemutatkozás  Bilicki Vilmos  Dugonics tér 13, első emelet 14-es szoba  6781 mellék 

Követelmények  Előadás:  év végi vizsga (80 pont)  Gyakorlat:  Egy projekt (20 pont)  Mindkét esetben el kell érni az 50%-ot

Források  G. Alonso, H. Kuno, F. Casati and V. Machiraju, Web Services: Concepts, Architectures and Applications, Springer,   Wolfgang Emmerich: Engineering Distributed Objects  Martin L. Shooman: Reliability of computer systems and networks.  Floyd Marinescu: Advanced Patterns, Processes and Idioms  Microsoft: Enterprise Solution Patterns Using.NET ( =/library/en-us/dnpatterns/html/esp.asp ) =/library/en-us/dnpatterns/html/esp.asp  Microsoft: Data Patterns ( AEB4CD-E10C-4CAF ED61EA&displaylang=en ) AEB4CD-E10C-4CAF ED61EA&displaylang=en

A tantárgy tematikája  Az Információs rendszerek architektúrája  Középrétegek, ezek szolgáltatásai  Üzenet alapú rendszerek  Alkalmazásszerverek és szolgáltatásaik  J2EE  Web Szolgáltatások  Terheléselosztás, Replikáció  Objektum perzisztencia.  Különböző perziszetencia rendszerek bemutatása. (Hybernate, EJB2.1, EJB3.0, …)  Tervezési minták  Biztonság. Támadás típusok. Titkosítás. Magas szintű biztonsági szolgáltatások. Biztonsági szolgáltatások az Objektum Orientált középrétegben.

6 Számítógép rendszerek  1950 katonai célok  Titkosítás, visszafejtés  1960 kötegelt feldolgozás  Nem interaktív  1970 Mainframe  Időosztásos interaktív  1980 PC  Az asztali gép felé irányult a figyelem  Elosztott információ feldolgozás (Autonóm rendszerek)  1990 Vállalati információs rendszerek (Enterprise Computing)  Megbízható adatátvitel (sávszélesség, válaszidő)  Központi fájl, Adatbázis, Alkalmazás szerverek + PC-k  Elosztott rendszerek

7 Elosztott rendszer  Az elosztott rendszer ismérvei:  Skálázhatóság – a rendszer tetszőlegesen bővíthető  Nyílt rendszer – képes más rendszerekkel is együttműködni, a régi elemekkel is  Heterogén – Több különböző alkalmazás, platform is képes az együttműködésre  Erőforrás megosztás  Hibatűrés – kritikus komponensek többszörözése, …  …  Definíció:  Autonóm gépek olyan halmaza melyek számítógép hálózattal vannak összekötve. Minden gép szoftver komponenseket futtat és egy olyan középréteget üzemeltet mely lehetővé teszi a különböző komponensek koordinálását úgy, hogy a felhasználók számára a rendszer egy gépnek tűnik. (Áttetszőség)  Leslie Lamport:  „Olyan rendszer melyben a munkám olyan komponensek hibája érinti melyek létezéséről nem is tudtam”

8 Elosztott rendszer User Node B Node C Node F Node E Node A Node D Komponens … Hálózati Operációs Rendszer Hardver HOST Komponens … Hálózati Operációs Rendszer Hardver HOST Középréteg (Middleware)

9 Elosztott vs. Központosított rendszer  Központosított rendszer  A komponensek nem autonómok  Homogén technológia (hatékony kommunikáció)  Több felhasználó is használhatja egy időben  Akár egy processzben és egy szálban futó alkalmazás  Egy központi vezérlés, hiba pont (ritka a kommunikációs hiba)  Elosztott rendszer  Autonóm komponensek, nincs mester komponens  Heterogén technológia  Komponensek között eloszlik a terhelés, a komponensekhez exkluzív használati jog is tartozhat  Párhuzamos végrehajtás (komponensenként vagy ezeken belül is)  Több meghibásodási pont

10 Példák:  SZTE – LanStore: Elosztott tárolás (.NET C#)  200 gép x 20 Gbyte = 4 TByte  Párhuzamos hozzáférés -> nagyságrendekkel gyorsabb mint egy fájlszerver  Pl.: Video On Demand  Video-on-Demand (Java, C++)  Hong Kong  előfizető  Repülő konfiguráció menedzsment (meglévő komponensekből építette fel)  Boeing  Minden gép minden alkatrésze, javításnál azonnal szükség van az adott dokumentumokra  1,5 milliárd alkatrész évente (3 millió gépenként)  A MainFrame nem bírta a terhelést  Google  Több mint mezei PC  Napi 200 millió keresés  Több 100 millió weboldal (tömörítve, …)  Nagyfokú redundancia

11 Skálázhatóság  Tervezés (pl. elektromos rendszer)  A terhelés mértéke: Online user, tranzakció szám, …  Elektromos rendszer – elvárjuk az állandó szolgáltatást  A szolgáltatás minőség fontos!  A szoftver rendszereket is így kellene tervezni…  Skálázható egy rendszer ha a ma még nem látható terhelésnövekedéseket is elviseli  Internet, e-business, B2C, …

12 Nyílt rendszer  Könnyen bővíthető, módosítható  A tervezésnél szabványos technológiák, megoldások (pl.: tervezési minták,…)  Jól definiált interfészek  Jól definiált szolgáltatások  Együtt fejlődik az intézménnyel  Az egyszer befektetett idő/pénz ne menjen veszendőbe

13 Heterogén rendszer  Külön-külön vásárolt komponensek  Hardver  OS  Hálózati protokoll  Programozási nyelv  Gyakran autonóm egységeknek kell együttműködniük  Heterogén komponensek integrálása

14 Erőforrás hozzáférés és megosztás  Erőforrás  Hardver  Szoftver  Adat  Többen használhatnak egy erőforrást  Biztonsági megfontolások  Ki mikor, hogyan férhet hozzá  Elosztott objektum foglalja magába az erőforrást  N rétegű alkalmazás

15 Hibatűrés  Merevlemez 2-5 év a várható élettartam  Hibatűrő az a rendszer amely hibák fellépése esetén is folytatni tudja működését  Ideális esetben emberi beavatkozás nélkül (pl.: EJB tároló, cluster)  Redundáns elemek, replikáció

16 Az elosztott rendszer tulajdonságai  ANSA 1989, ISO/IEC 1996 International Standard on Open Distributed Processing  Helyszín áttetszőség  Hozzáférés áttetszőség  Replikáció áttetszőség  Hiba áttetszőség  Párhuzamosság áttetszőség  Migráció áttetszőség  Feladat áttetszőség  Teljesítmény áttetszőség  Skálázás áttetszőség  Programozási nyelv áttetszőség  Az elosztott rendszer mérőléce (middleware mérőléce) (Áttetszőség – Transparency)

17 Hozzáférés áttetszőség  A helyi és a távoli hozzáférés interfész azonos  Pl.: NFS – a helyi gépen lévő erőforrásokat ugyanúgy érem el mint a távoliakat (azonosak a függvényhívások is)  Az ilyen komponensekre épülő komponensek könnyen áthelyezhetőek egyik helyről a másikra

18 Helyszín áttetszőség  Nem kell tudnunk a komponens pontos helyét, van egy olyan mechanizmus mellyel megtaláljuk és megcímezzük  Pl.: NFS – a felhasználóknak nem kell tudniuk a szerver IP címét

19 Migráció áttetszőség  A komponensek tetszés szerint mozgathatóak a hostok között anélkül, hogy a felhasználó ezt érzékelné és módosítanunk kellene más komponenseket  Függ helyszín és hozzáférés áttetszőségtől

20 Replikáció áttetszőség  Replikák  Adott komponens több helyen is megtalálható  Replikáció  Ha állapottal rendelkezik akkor ezt szinkronizálni kell minden példányban  A felhasználó és a többi komponens nem veszi észre, hogy másolatot használ  Nagyobb teljesítmény, hibatűrés

21 Párhuzamosság áttetszőség  Az egyes komponensek egy időben használhatják a megosztott erőforrásokat anélkül, hogy ez fennakadást okozna.  A felhasználó nem veszi észre, hogy más ia használja a rendszert  Jó esetben sem az alkalmazás tervező sem a felhasználó sem foglalkozik vele (a middleware feladata)

22 Teljesítmény áttetszőség  Sem az alkalmazás fejlesztő sem a felhasználó nem tudja hogyan éri el a rendszer az adott teljesítményt  Middleware dolga (ma még kevés tudja autómatikusan)  Replikáció  Load Balancing

23 Hiba áttetszőség  Sem a felhasználó sem az alkalmazás fejlesztő nem tudja hogyan kezeli a rendszer a hibákat  Nem veszik észre a hibákat  Pl.: bank automata

24 Középréteg  Tranzakció orientált középréteg  Tranzakciók integrálása több különböző adatbázis-kezelőn, adatbázison át  IBM CISC, Tuxedo  Üzenet orientált középréteg  Megbízható üzenetküldés  IBM MQSeries, MSMQ  Objektum Orientált középréteg  Corba  RMI  COM  …

Tranzakció kezelő rendszerek  Üzleti tranzakciók  Valódi interakció  Leggyakrabb esetei  Vállalat és egy személy között  Vállalat – Vállalat között  Tranzakció kezelő program  Osztott adatokon végez műveleteket  Online Tranzakció Kezelő rendszer  Tranzakció kezelő programok gyűjteményét futtatja

Az ACID tulajdonságok  Atomiság  Minden vagy semmi (Bank, Rakéta), kompenzálás  Konzisztencia  Jó állapotból jó állapotba kerüljön  Izoláció  A párhuzamos tranzakciók sorbarendezhetőek (Serializable)  Mint ha külön életet élnének (Konzisztencia+Izoláció)  Tartósság  Az elfogadott tranzakciók nem vesznek el  Stabil tároló (log)  Nehéz a központosított adatbázisoknál  Még nehezebb az elosztott rendszereknél

Erőforrás kezelő  Hogyan vannak az ACID tranzakciók implementálva  Erőforrás allokálás a programok számára  Zárolás, …  Erőforrások begyűjtése  Erőforrás kezelő réteg

Az információs rendszer 3 rétege Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Megjelenítés  Az információ megjelenítését adja meg  Megadja azt is hogy hogyan fogadjuk el az információt  A társ entitás itt a felhasználó vagy más rendszer Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Alkalmazás logika  A program  Az üzleti folyamat  Az üzleti logika  Az üzleti szabályok Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Erőforrás kezelő réteg  A domain modell Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Top-down tervezés 1. Definiáljuk a hozzáférési csatornákat 2. Definiáljuk a megjelenítés formátumot és protokollt 3. Definiáljuk a funkcionalitást amellyel a fent definiált tartalmat előállíthatjuk 4. Definiáljuk az adat struktúrát és szervezést amely az alkalmazás logikát támogatja Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Bottom-up tervezés 1. Definiáljuk a hozzáférési csatornákat 2. Megvizsgáljuk a erőforrásokat és a szolgáltatásokat 3. Becsomagoljuk a meglévő szolgáltatásokat konzisztens interfészekkel 4. Az alkalmazás logikához adaptáljuk a megjelenítésiréteget. Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Egy rétegű architektúra  Monolitikus  Nagyon hatékony lehet  A régi rendszerek problémája Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Kliens Információs rendszer

Kliens Két rétegű architektúra  Felxibilis megjelenítési réteg  Stabil, publikált API Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Információs rendszer

2 Rétegű szerver  Egy szerver nem skálázható  A kliens dolga a szolgáltatások integrálása Erőforrás kezelő réteg Információs rendszer Szolg. Szerver API Szolg. Int Kliens MR 1

Három rétegű architektúra  Skálázható az alkalmazás logika réteg  Több alkalmazásszerver  Alkalmazás integráció  A középrétegben csináljuk meg  Stabil API az erőforrás kezeléshez Kliens Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Információs rendszer Középréteg

N rétegű architektúra Megjelenítés réteg Alkalmazás logika réteg Információs rendszer Középréteg Kliens R1 W1 R2 W2 R1 W1 R1 W1 Erőforrás kezelő réteg C2

39 Internet, Web alkalmazások architektúrája  N rétegű architektúrák  Vékony kliens  Biztonsági megfontolások  Skálázhatóság

Második előadás  Középrétegek, keretrendszerek  Üzenet alapú középréteg