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




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



Kliens

Info

rmáció

s rendsze

r

Erőforrás kezelő réteg A domain modell




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




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.




Kliens

Info

rmáció

s rendsze

r

Egy rétegű architektúra Monolitikus Nagyon hatékony

lehet A régi rendszerek

problémája




Kliens

Info

rmáció

s rendsze

r

Kliens

Két rétegű architektúra Felxibilis

megjelenítési réteg

Stabil, publikált API




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


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




Info

rmáció

s rendsze

r

Középréteg

N rétegű architektúra



Info

rmáció

s rendsze

rKözépréteg

Kliens

R1

W1

R2

W2

R1

W1

R1

W1


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

Documents

Programrendszerek fejlesztése