Programrendszerek fejlesztése Bilicki Vilmos

Az előadások a következő témára: "Programrendszerek fejlesztése Bilicki Vilmos"— Előadás másolata:

1 Programrendszerek fejlesztése Bilicki Vilmos bilickiv@inf.u-szeged.hu

2 Bemutatkozás  Bilicki Vilmos  Dugonics tér 13, első emelet 14-es szoba  6781 mellék  www.inf.u-szeged.hu/~bilickiv

3 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

4 Források  G. Alonso, H. Kuno, F. Casati and V. Machiraju, Web Services: Concepts, Architectures and Applications, Springer, 2004.  http://www.cs.cornell.edu/courses/cs530/2004sp/lect.html http://www.cs.cornell.edu/courses/cs530/2004sp/lect.html  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 (http://msdn.microsoft.com/practices/patterns/default.aspx?pull =/library/en-us/dnpatterns/html/esp.asp )http://msdn.microsoft.com/practices/patterns/default.aspx?pull =/library/en-us/dnpatterns/html/esp.asp  Microsoft: Data Patterns (http://www.microsoft.com/downloads/details.aspx?familyid=F2 AEB4CD-E10C-4CAF-8068-442670ED61EA&displaylang=en )http://www.microsoft.com/downloads/details.aspx?familyid=F2 AEB4CD-E10C-4CAF-8068-442670ED61EA&displaylang=en

5 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 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 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 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 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 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  90000 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 10000 mezei PC  Napi 200 millió keresés  Több 100 millió weboldal (tömörítve, …)  Nagyfokú redundancia

11 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 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 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 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 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 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 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 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 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 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 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 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 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 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  …

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 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

37 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

38 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 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

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