Programrendszerek fejlesztése
-
Upload
melvin-lester -
Category
Documents
-
view
19 -
download
0
description
Transcript of Programrendszerek fejlesztése
Programrendszerek fejlesztése
Bilicki [email protected]
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:
é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, 2004.
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 )
Microsoft: Data Patterns (http://www.microsoft.com/downloads/details.aspx?familyid=F2AEB4CD-E10C-4CAF-8068-442670ED61EA&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 FNode E
Node ANode D
Komponens Komponens…
Hálózati Operációs Rendszer
Hardver
HOST
Komponens 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 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 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
Info
rmáció
s rendsze
r
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
Info
rmáció
s rendsze
r
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
Info
rmáció
s rendsze
r
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
Info
rmáció
s rendsze
r
Top-down tervezés1. Definiáljuk a hozzáférési
csatornákat2. 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
Info
rmáció
s rendsze
r
Bottom-up tervezés1. Definiáljuk a hozzáférési
csatornákat2. 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
Info
rmáció
s rendsze
r
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
Info
rmáció
s rendsze
r
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
Info
rmáció
s rendsze
r
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
Info
rmáció
s re
ndsze
rSzolg.
Szolg.
Szolg.
Szolg.
Szolg.
Szerver APISzolg. Int
Szolg. Int
Szolg. Int
Szolg. Int
Szolg. Int
KliensMR 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
Info
rmáció
s rendsze
r
Középréteg
N rétegű architektúra
Megjelenítés réteg
Alkalmazás logika réteg
Info
rmáció
s rendsze
rKö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