Programrendszerek fejlesztése Bevezető Dr. Bilicki Vilmos Szegedi Tudományegyetem Informatikai Tanszékcsoport Szoftverfejlesztés Tanszék

Programrendszerek fejlesztése Tartalom Követelmények Bemutatkozás Célok Nem funkcionális/rendszer követelmények Skálázhatóság A félév áttekintése 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Követelmények Gyakorlat 50% (20 %) ZH előadáson 50% (20%) (Tavaszi szünet utáni első előadás) Vizsga az osztályzat 60%-át adja Jegyzet: http://tananyagfejlesztes.mik.uni- pannon.hu/index.php?option=com_content& view=article&id=58&Itemid=71#Programrend szerek%20fejleszt%C3%A9se 2017.04.04. Programrendszerek fejlesztése

SZTE – Szoftverfejlesztés Tanszék R&D Oktatás Ipari Projektek Számok: ~ 130 munkatárs (80% projekt állás) ~ 3500 hallgató Fókusz területek: Szoftver Minőség Nyílt forráskódú fejlesztés Nagy rendszerek fejlesztése 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése M2M Csoport 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Célok Startégiai szintű áttekintés: Nagy skálázható rendszerek fejlesztése Problémák JEE alapú megoldások Milyen rétegeket használjunk? Hogyan fejlesszünk produktívan skálázható alkalmazást? 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése 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. (Hibernate, EJB2.1, EJB3.0, …) Web Szolgáltatások Tervezési minták Programrendszerek fejlesztése

Programrendszerek fejlesztése Alkalmazás rétegelés Az alkalmazás kompnensek feladatának elválasztása Megjelenítés réteg A kérés/válasz objektuomkra koncentrál Megoldja a modell alapján a GUI renderelést Formázási és nem üzleti logika alapú validálási logikát tartalmaz A más rétegek által dobott kivételeket kezeli Perzisztencia réteg A tárolókkal kommunikál Lekérdezés nyelvet biztosít ORM képesség JDBC, Hibernate, iBATIS, JDO, Entity Beans, … Domén réteg Az üzleti objektumokat tárolja, ezek a többi rétegben is felhasználhatóak Kezeli az üzleti objektumok közötti komplex relációat Gazdag üzleti logika ORM A domén objektumok csak egymástól függhetnek Programrendszerek fejlesztése

Programrendszerek fejlesztése Szolgáltatás réteg? Hogyan pozicionáljuk a lazán csatolt üzleti logikát? Mi a szolgáltatás logika? Hogyan kell a konténer szintű szolgáltatásokat megvalósítani? Hogyan kezeljük a POJO alapú alkalmazásokban a tranzakciókat? Hogyan kommunikáljunk a megjelenítési rétegből a perzisztencia rétegbe? Hogyan kapunk üzleti logikát megvalósító szolgáltatásokat? Hogyan kommunikálnak az üzleti objektumok a perzisztencia téteggel? Hogyan adjuk át a prezisztencia rétegben található objektumokat a UI rétegnek? Programrendszerek fejlesztése

Programrendszerek fejlesztése Alkalmazás rétegek Szolgáltatás réteg Egy átjáró amely segítségével az üzleti logikát biztosítjuk a külvilág számára Kezeli a tároló szintű szolgáltatásokat (tranzakciók, biztonság, …) Sok alkalmazásban nincs megfelelően definiálva Programrendszerek fejlesztése

Alkalmazás architektúra 3 Rétegű Vs. MVC 2017.04.04. Programrendszerek fejlesztése

Minta rendszer 2017.04.04. M2M Statusreport

Programrendszerek fejlesztése 2. Elosztott rendszerek Problémák Átteszőségek Architektúrák Programrendszerek fejlesztése

Valós nagy rendszerrel kapcsolatos tapasztalatok (Inktomi) Összeomlások/Merevlemez hibák Óránként Adatbázis frissítések Naponta Szoftver frissítések Hetente/Havonta OS frissítések Kétszer Energetikai hibák néhány Hálózat hibák 11 Az egész infrastruktúra fizikai átköltöztetése 2 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Skálázhatóság Adat tárolás/Feldolgozás Vertikális (Scale up) Fizikai korlátai vannak (processzorok száma, JVM szemétgyűjtő, …) Közös memória mint kommunikációs médium Horizontális (Scale out) Elosztott rendszer (Leslie Lamport: „Elosztott rendszer az ahol egy addig teljesen ismeretlen számítógép hibája teszi használhatatlanná a gépünket”) Elvileg korlátlan (elosztottságból fakadóan nem lehet ACID) Távoli hozzáférés problematikája (érték szerint vs. referencia szerint) 2017.04.04. Programrendszerek fejlesztése

Határok – CAP tétel (Brewer tétele) Internet méretű elosztott rendszerek C – Konzisztencia (Minden csomópont ugyanazt az adatot látja adott időben) A – Atomi C - Konzisztens I - Elkülönítés D - Tartósság A - Rendelkezésre állás (csomópontok kiesése nem akadályozza meg a maradókat a működéstől) X % időben elérhető P - Partíció tűrés (tetszőleges üzenetvesztést tolerál) Gilber és Lynch definíciója szerint „A teljes rendszer (hálózat) hibáján kívül semmilyen hiba kombináció sem okozhatja azt, hogy a rendszer hibásan válaszol”. Ezek közül csak kettő teljesülhet 2017.04.04. Programrendszerek fejlesztése

3. Átszövődő vonatkozások Kontextusok Tranzakciós kontextus Biztonsági kontextus Perzisztencia kontextus, … 2017.04.04. Programrendszerek fejlesztése

Kontextus 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése 4. Köztesréteg Szolgáltatásai Konkrét példák: P2P középréteg (PECES) Adatközpontú köztesréteg : Apache Hadoop Feldolgozás központú köztesréteg: JEE konténer 2017.04.04. Programrendszerek fejlesztése

Motiváció – nem funkcionális követelmények Rendelkezésre állás: azon idő amely alatt a komponens képes kielégíteni a funkcionális követelményekben meghatározott funkciókat azon időhöz viszonyítva amikor ezt nem tudja megtenni. Kapacitás/Skálázhatóság: A komponens a terhelés növekedésével is képes ellátni a funkcionális követelményekben megfogalmazott feladatokat. Párhuzamosság: A komponens a több egymással párhuzamos terhelés hatására is képes ellátni a funkcionális követelményekben megfogalmazott feladatokat. Fejleszthetőség: A komponens új funkcionális követelményeket is el tud látni viszonylag szerény fejlesztési ráfordítással. Együttműködési képesség: A komponens képes környezetével és a szükséges komponensekkel aránytalan plusz terhelés okozása nélkül is együttműködni. Késleltetés: A komponens az adott funkcionális követelményben szereplő szolgáltatását adott terhelés mellett adott időtartamon belül kiszolgálja. Karbantarthatóság: A komponensnek támogatnia kell az adott szervezetben definiált karbantartási feladatokat (pl.: backup) Menedzselhetőség: A komponensnek támogatnia kell a megfelő konfigurálhatósági szintet. Monitorozhatóság: A komponensnek monitorozhatónak kell lennie. Visszaállíthatóság: Hibás adat esetén a komponensnek támogatnia kell a megfelelő állapot visszaállítását. Biztonság: A komponensnek a helyi biztonsági előírásoknak megfelelően kell működnie. Konzisztencia: A komponens az adatot konzisztens állapotban tartja. 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Infinispan Memória alapú adat rács (data grid) Nagy heap (a redundanciától függően) Nem kell viszony tartás (bárhonnan elérhető) Cache interfész ->Map-et terjeszti ki A Jboss gyorsítótáron alapul (Jboss cache) Tranzakció támogatás (XA) 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlkesztése Architektúra 2017.04.04. Programrendszerek fejlkesztése

Programrendszerek fejlkesztése Apache Hadoop Nem valós idejű feldolgozásra Nagyon nagy adatmennyiségek kezelésére Elemei: Elosztott fájlrendszer Elosztott feldolgozó keretrendszer Számos kiegészítő keretrendszer Zookeper Hbase Hive Pig Latin … 2017.04.04. Programrendszerek fejlkesztése

5. Nyelvi trendek, paradigmák: logika megvalósítása OO és azon túl Tartomány specifikus nyelvek Szabály és folyamat alapú tartomány specifikus nyelvek 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Folyamat nyelvek WFMS – Munkafolyamat Kezelő Rendszerek (Workflow Management System) 80-as évek adatközpontú világnézet az adatok voltak a fejlesztők fókuszában és nem a folyamatok Ma már kellő intelligencia található a különböző keretrendszerekben -> a folyamatok álljanak a fejlesztők, sőt az adott tartomány szakértői azaz a nem szoftver fejlesztők figyelmének központjában. Munkafolyamat leíró nyelvek grafikus megjelenítéssel is rendelkeznek magát a folyamatot megfelelő fejlesztő eszközök segítségével nem programozó is meg tudja tenni. Alkalmazási területek üzleti folyamatok modellezése hagyományos üzleti folyamatok koordinálása Komponens keretrendszerek Munkafolyamatok közötti interakciók B2B interakciók felhasználói folyamatok A logika dinamikusan változtatható akár futásidőben is. 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Folyamat nyelvek Felhasználói folyamatok -> pageflow (JSF/SEAM) Üzleti folyamatok -> BPLE4WS 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Szabály nyelvek A tudás ábrázolásának egy módja a szabályokkal történő ábrázolás. Az erre épülő rendszereket Produkciós Szabály Alapú rendszereknek nevezik (Production Rule Engine). bemeneti adatok (tényeknek nevezik ebben a körben – Facts) szabályok (Rule) eredmények/események 2017.04.04. Programrendszerek fejlesztése

Következtető Motor – Inference Engine A szabály motorok központi eleme A tényeket és a hozzájuk tartozó szabályokat párosítja minta illesztés segítségével Elemei: Munka memória (tények) Produkciós memória (szabályok) Minta illesztő Konfliktus feloldás Programrendszerek fejlesztése

6. Nyelvi megoldások, paradigmák: ontológia OO és azon túl XML és azon túl Ontológia alapú leírások OWL, típusai, … Következtetés Ontológia illesztés 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése 1. A tartalom fogyasztók és a tartalom gyártók közötti megkülönböztetés elmosása Wiki, Blog-ok, és a Twiter a szöveges publikálást tömeges jelenséggé tették a flickr és a youtube hasonló eredményt ért el a multimédia területén Programrendszerek fejlesztése

Programrendszerek fejlesztése 2. Az egyedek számára készített médiától elmozdult a közösségek számára készített média felé A szociális web oldalak: del.icio.us, facebook, FOAF, linkedin, myspace és Xing lehetővé teszik a közösségeknek, hogy gördülékenyen információt cseréljenek és együttműködjenek Programrendszerek fejlesztése

Programrendszerek fejlesztése 3. A szolgáltatás gyártók és a szolgáltatás fogyasztók közötti különbség elmosása Mashups-ok segítségével a felhasználók mások által készített szolgáltatásokat integrálhatnak weboldalaikba Programrendszerek fejlesztése

RDF: közvetlenül csatol irányított gráf Programrendszerek fejlesztése

6. Rest/Web Szolgáltatások Programrendszerek fejlesztése

Programrendszerek fejlesztése REST architektúra Programrendszerek fejlesztése 35

Programrendszerek fejlesztése A SOA fő elemei XML SOAP WSDL WSIL UDDI Programrendszerek fejlesztése 36

7. Felhasználói interakció Az interakció típusai A HTTP protkoll AJAX alapú megoldások GWT RAP Servlet alapú megoldások JSP alapú megoldások JSF alapú megoldások 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése AJAX Új felhasználói élmény Részleges frissítés Aszinkron háttérben történő frissítés Dinamikus GUI Nagy adatmennyiség kezelése 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése Hogyan működik 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése 8. Háttér logika 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 Programrendszerek fejlesztése

Programrendszerek fejlesztése 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése JSF vs. Seam JSF JSF Page POJO Facade Session EJB Entity EJB POJO Facade JSF Page Managed Bean SEAM JSF Page Session EJB JSF Page Entity EJB Automatically wrapped in Managed Bean 2017.04.04. Programrendszerek fejlesztése

Programrendszerek fejlesztése 9. Adatkezelés 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 Programrendszerek fejlesztése

Programrendszerek fejlesztése Entitás állapotok Tranziens: Az újonnan példányosított (a new operátorral) objektumok még nem perzisztensek. Ezek az objektumok nem lehetnek tranzakcionálisak, azaz a rajtuk végrehajtott bármely módosítási művelet nem lehet része tranzakciónak. Ha egy tranziens objektumot perzisztálni akarunk, vagy más szóval a tranziens állapotból perzisztensbe akarjuk helyezni, a perzisztencia menedzser save függvényét kell meg hívni az objektumra, vagy egy perzisztens objektumból hivatkozni kell a tranziens objektumra. Perzisztens: A perzisztens állapotban lévő objektumpéldány rendelkezik egy elsődleges kulccsal azonosított érvényes adatbázis bejegyzéssel. A tranzakció végeztével csak azok a perzisztens entitások kerülnek szinkronizálásra, amelyek módosultak. Ezt a folyamatot dirty chechking-nek nevezik.. Leválasztott (detached): A perzisztens objektumok a tranzakció végeztével is léteznek és tartalmaznak adatokat, azonban leválasztódnak a viszony bezáródásával. 2017.04.04. Programrendszerek fejlesztése

10. Szolgáltatás integráció Problémák Megközelítés módok SOA koncepció ESB SDO/SCA 2017.04.04. Programrendszerek fejlesztése

Enterprise Service Bus Szolgáltatások közötti üzenetcsere monitorozása és vezérlése Szolgáltatások telepítése és verziózása Gyakori középréteg szolgáltatások biztosítása: Eseménykezelés Adattranszformáció Üzenetsorok kezelése Biztonság- és kivételkezelés Stb. 2017.04.04. Programrendszerek fejlesztése 46

11. Magas szintű üzleti folyamatok BPEL Absztrakt modell Futtatható modell Elemei Tervezési minták Programrendszerek fejlesztése

Programrendszerek fejlesztése JBoss ESB 2017.04.04. Programrendszerek fejlesztése 48

Programrendszerek fejlesztése 12. Ami kimaradt Biztonság: Kerberos OpenID Shibotech Menedzselhetőség JMX OSGi Skálázhatóság Klaszter 2017.04.04. Programrendszerek fejlesztése

13. Kitekintés, összefoglaló A félév áttekintése Merre tart a szoftver fejlesztés Felhasználói programozás Felhő megoldások M2M rendszerek 2017.04.04. Programrendszerek fejlesztése

C@R

ECOSPACE

PECES

Egy példa rendszer

Szoftver architektúra

Egy példánya

Egy másik példa

Példák

Programrendszerek fejlesztése Összefoglaló Motiváció – nem funkcionális/rendszer követelmények Rendszer granularitás paradigmák Skálázhatóság Internet alapú rendszerek Korlátai Lehetőségeink Elosztott rendszer architektúrák Átszövődő vonatkozások Köztesréteg Típusai Megvalósítása Metrikái Példák 2017.04.04. Programrendszerek fejlesztése