Programrendszerek fejlesztse Bilicki Vilmos bilickivinf uszeged hu Bemutatkozs

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

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

Követelmények Előadás: Gyakorlat: év végi vizsga (80 pont) 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, 2004. http: //www. cs. cornell. edu/courses/cs 530/2004 sp/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. asp x? pull=/library/en-us/dnpatterns/html/esp. asp ) Microsoft: Data Patterns (http: //www. microsoft. com/downloads/details. aspx? familyi d=F 2 AEB 4 CD-E 10 C-4 CAF-8068 -

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 J 2 EE Web Szolgáltatások Terheléselosztás, Replikáció Objektum perzisztencia. Különböző perziszetencia rendszerek bemutatása. (Hybernate, EJB 2. 1, EJB 3. 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.

Számítógép rendszerek � 1950 katonai célok � Titkosítás, � 1960 kötegelt feldolgozás � Nem � 1970 visszafejtés interaktív Mainframe � Időosztásos � 1980 interaktív 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 6

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

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

Elosztott vs. 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 �Elosztott hiba) 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 9

Példák: � � SZTE – Lan. Store: 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 Main. Frame 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 10

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, B 2 C, … 11

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 12

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 13

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 14

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ó 15

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) 16

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 17

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 18

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 19

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 20

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) 21

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 22

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 23

Középréteg �Tranzakció orientált középréteg � Tranzakciók integrálása több különböző adatbáziskezelő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 �… 24

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

Az ACID tulajdonságok Atomiság Konzisztencia A párhuzamos tranzakciók sorbarendezhetőek (Serializable) Mint ha külön életet élnének (Konzisztencia+Izoláció) Tartósság Jó állapotból jó állapotba kerüljön Izoláció Minden vagy semmi (Bank, Rakéta), kompenzálás 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 Kliens Megjelenítés réteg Erőforrás kezelő réteg Információs rendszer Alkalmazás logika réteg

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

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

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

Top-down tervezés 1. 2. 4. Kliens Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Információs rendszer 3. 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

Bottom-up tervezés 1. 2. 4. Kliens Megjelenítés réteg Alkalmazás logika réteg Erőforrás kezelő réteg Információs rendszer 3. 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.

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

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

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

Három rétegű architektúra 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 Erőforrás kezelő réteg Információs rendszer Skálázható az alkalmazás logika réteg Több alkalmazásszerver Alkalmazás integráció

N rétegű architektúra Kliens Megjelenítés réteg W 1 R 1 W 2 R 2 Erőforrás kezelő réteg Információs rendszer Alkalmazás logika réteg Középréteg C 2 W 1 R 1