Programrendszerek fejlesztése

Programrendszerek fejlesztése

Bilicki [email protected]

Bemutatkozás Bilicki Vilmos Honvéd tér, 14-es szoba 6781 mellék www.inf.u-szeged.hu/~bilickiv

Követelmények Előadás:

év végi vizsga (80 pont) ZH (2009.03.26) (20 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



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 Objektum perzisztencia.

Különböző perziszetencia rendszerek bemutatása. (Hybernate, EJB2.1, EJB3.0, …)

Web Szolgáltatások Tervezési minták

1. Elosztott rendszerek Mai trendek SOA Jellemzői Átteszőségek Architektúrák

2. XML XSD XPath XSLT

3. JDBC JDBC

Típusai Kapcsolat típusok Statement objektumok RecordSet Tranzakciók

4. Hibernate Perzisztencia Object serialization API ORM Hibernate

Bevezetés Architektúra Hello world

Java File Mapping file Műveletek Konfiguráció

Interfaces Mappelés (Kollekciók,Asszociációk,Leszármazások) Lekérdezések Optimalizálás(fetching and caching) Tesztelés

5. J2EE Fejlesztési modell Szerepkörök Java Enterprise Edition

EJB specifikáció (3.0) EJB komponensek

Injection Scope Transaction EJB

Session Bean Stateless Statefull

Entity Bean (Miért nem) BMP CMP

Message Driven Bean Durable Non Durable

6. Alkalmazás szerverek Az alkalmazászerverek szerepe Jboss

Felépítése Elemei

Ear Klaszterezés

7. WebBean JSF alapok JSF vs. EJB Mi hiányzik? Jboss Seam

8. Üzleti folyamatok Megközelítésmódok Technológiák JBPM Pageflow

9. SOA Koncepció, trendek Elemek Szerepkörök, technológiák

10. Web Szolgáltatások SOAP WSDL WS-* profilok

11. Fontosabb WS profilok WS-Addressing WS-Security WS-Transactions

12. Magas szintű üzleti folyamatok BPEL

Absztrakt modell Futtatható modell

Elemei Tervezési minták

13. SOA- rendszer Biztonság: SSO Szolgáltatás fellelés: UDDI Szolgáltatás leírás: Ontológiák

C@R

ECOSPACE

PECES

Egy példa rendszer

Szoftver architektúra

Egy példánya

Egy másik példa

Példák

27

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

28

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”

29

Elosztott rendszer

User

Node B Node C

Node FNode E

Node ANode D

Komponens Komponens…Hálózati Operációs Rendszer

Hardver

HOSTKomponens Komponens…

Hálózati Operációs RendszerHardver

HOST

Középréteg (Middleware)

30

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

31

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

32

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, …

33

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

34

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

35

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

36

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ó

37

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)

38

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

39

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

40

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

41

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

42

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)

43

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

44

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

45

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

Adat vs. Logika

Absztrakciós szintek

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

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


Alkalmazás logika A program Az üzleti folyamat Az üzleti logika Az üzleti szabályok Megjelenítés réteg



Kliens


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




Kliens


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


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


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

lehet A régi rendszerek

problémájaMegjelenítés réteg



Kliens


Kliens

Két rétegű architektúra Felxibilis

megjelenítési réteg

Stabil, publikált API





2 Rétegű szerver Egy szerver

nem skálázható

A kliens dolga a szolgáltatások integrálása


Információs

rendszerSzolg.

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





Középréteg

N rétegű architektúra




Középréteg

Kliens

R1

W1

R2

W2

R1

W1

R1

W1


C2

65

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 XML

XSD XPath XSLT

Documents

Programrendszerek fejlesztése