Programrendszerek fejlesztése Bevezető

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

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

3. 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#Programrendszerek%20fejleszt%C3%A9se

4. Programrendszerek fejlesztése R&D Oktatás Ipari Projektek SZTE – Szoftverfejlesztés Tanszék • 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

5. Programrendszerek fejlesztése M2M Csoport

6. 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?

7. 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 A tantárgy tematikája

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

9. 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?

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

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

12. M2M Statusreport Minta rendszer

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

14. Programrendszerek fejlesztése Valós nagy rendszerrel kapcsolatos tapasztalatok (Inktomi)

15. Programrendszerek fejlesztése Skálázhatóság • Adat tárolás/Feldolgozás • Vertikális (Scaleup) • 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 (LeslieLamport: „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)

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

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

18. Programrendszerek fejlesztése Kontextus

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

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

21. Programrendszerek fejlesztése Infinispan • Memória alapú adat rács (datagrid) • 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 Jbossgyorsítótáron alapul (Jboss cache) • Tranzakció támogatás (XA)

22. Programrendszerek fejlkesztése Architektúra

23. 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 • …

24. Programrendszerek fejleszté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

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

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

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

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

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

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

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

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

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

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

35. Programrendszerek fejlesztése REST architektúra 35

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

37. Programrendszerek fejlesztése 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

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

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

40. Java EnterpriseEdition EJB specifikáció (3.0) EJB komponensek Injection Scope Transaction EJB Session Bean Stateless Statefull EntityBean (Miért nem) BMP CMP MessageDrivenBean Durable Non Durable Programrendszerek fejlesztése 8. Háttér logika

41. Programrendszerek fejlesztése

42. 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 Entity EJB JSF Page Automatically wrapped in Managed Bean

43. Perzisztencia Objectserialization 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 9. Adatkezelés

44. 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 dirtychechking-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.

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

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

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

48. Programrendszerek fejlesztése JBoss ESB

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

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