Programrendszerek fejlesztése

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 • Wolfgang Emmerich: EngineeringDistributedObjects • Martin L. Shooman: Reliability of computer systems and networks. • Floyd Marinescu: Advanced Patterns, Processes and Idioms • Microsoft: EnterpriseSolutionPatternsUsing .NET (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=F2AEB4CD-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. 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. HOST HOST Komponens … Komponens Komponens … Komponens Hálózati Operációs Rendszer Középréteg (Middleware) Node E Hálózati Operációs Rendszer Hardver Node F Hardver Node D Node A Node C Node B Elosztott rendszer User

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 • 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. 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 DistributedProcessing • 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 (middlewaremé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 • …

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 Kliens Megjelenítés réteg Alkalmazás logika réteg Információs rendszer Erőforrás kezelő réteg

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 Kliens Megjelenítés réteg Alkalmazás logika réteg Információs rendszer Erőforrás kezelő réteg

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

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

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

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

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

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

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

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 Középréteg Információs rendszer Erőforrás kezelő réteg

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

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