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

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: Gyakorlat: é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 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

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

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

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”

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)

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

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

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

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

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

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

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ó

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)

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

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

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

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

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)

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

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

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 …

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

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 Kliens Megjelenítés réteg Alkalmazás logika réteg Információs rendszer Erőforrás kezelő réteg

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

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

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

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

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

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

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

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

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

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

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