Programrendszerek fejlesztése

Az előadások a következő témára: "Programrendszerek fejlesztése"— Előadás másolata:

1 Programrendszerek fejlesztése
Bilicki Vilmos

2 Bemutatkozás Bilicki Vilmos Honvéd tér, 14-es szoba 6781 mellék

3 Követelmények Előadás: Gyakorlat:
év végi vizsga (80 pont) ZH ( ) (20 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. Wolfgang Emmerich: Engineering Distributed Objects Martin L. Shooman: Reliability of computer systems and networks. Floyd Marinescu: Advanced Patterns, Processes and Idioms

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 Objektum perzisztencia. Különböző perziszetencia rendszerek bemutatása. (Hybernate, EJB2.1, EJB3.0, …) Web Szolgáltatások Tervezési minták

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

7 2. XML XSD XPath XSLT

8 3. JDBC JDBC Típusai Kapcsolat típusok Statement objektumok RecordSet
Tranzakciók

9 4. Hibernate Object serialization API ORM Perzisztencia 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

10 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

11 6. Alkalmazás szerverek Az alkalmazászerverek szerepe Jboss Ear
Felépítése Elemei Ear Klaszterezés

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

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

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

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

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

17 12. Magas szintű üzleti folyamatok
BPEL Absztrakt modell Futtatható modell Elemei Tervezési minták

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

19

20 ECOSPACE

21 PECES

22 Egy példa rendszer

23 Szoftver architektúra

24 Egy példánya

25 Egy másik példa

26 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: Definíció:
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 Node E Node F Node D User Node A Node C Node B
Komponens … Hálózati Operációs Rendszer Hardver HOST Komponens … Hálózati Operációs Rendszer Hardver HOST Középréteg (Middleware)

30 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 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 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
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 Üzenet 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 …

46 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

47 Az ACID tulajdonságok Atomiság Konzisztencia Izoláció Tartóssá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

48 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

49

50

51 Adat vs. Logika

52 Absztrakciós szintek

53

54 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

55 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

56 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

57 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

58 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

59 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

60 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

61 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

62 Erőforrás kezelő 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 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

63 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

64 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

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

66 Második előadás XML XSD XPath XSLT