Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28. forrásának megtekintése

==1. Sorolj fel néhány middleware szolgáltatást! (darabonként 1 pont, max. 5 pont) Magyarázd meg az explicit és implicit middleware fogalmát, ismertesd előnyeit, hátrányait. (Összesen 12 pont)==
A middleware szolgáltatások olyan szolgáltatások, melyeket általában a középső réteg valósít meg, ilyenek pl:
* Távoli eljáráshívás
* Szálkezelés
* Terheléskiegyenlítés
* Átlátszó hibakezelés
* Perzisztencia
* Tranzakciókezelés
* Objektumok életciklusa
* Aszinkron üzenetkezelés
* Biztonság

'''Explicit middleware:'''
* Amikor az elosztott objektum felelős az egyes middleware szolgáltatásokért

Hátrányai:
* felduzzad a forráskód
* nem rugalmas a middleware (ha eladjuk a komponenst, ki kell adni a forráskódot, ha a vevő pl. más tranzakciókezelést akar)

'''Implicit middleware:'''
* Amikor az elosztott objektum előtt van egy kérésmegszakító, és ez felelős az egyes middleware szolgáltatásokért
* Külön leíró fájl tartalmazza, milyen middleware szolgáltatásokat veszünk igénybe
* A kérésmegszakító a leíró fájl alapján generálódik
Előnyei:
* A forráskód valóban csak üzleti logikát tartalmaz
* A leíró fájlt módosíthatja a vevő, a forráskódot nem kell kiadnunk

==2. Mire jó és hogyan működik a Java EE szerep alapú biztonsági modellje? Hogyan szabályozható Java EE webalkalmazásokban az adatforgalom biztonsága?==
* A telepítésleírókban absztrakt szerepeket definiálunk
* Telepítéskor kell megadni, hogy mely csoportok/felhasználók tartoznak az adott szerepbe
* Úgy írható meg az alkalmazás, jogosultságkezeléssel együtt, hogy azt sem tudjuk milyen lesz az autentikációs mechanizmus

Adatbiztonságot a &lt;transport-guarantee&gt; tag-ek között adjuk meg milyen legyen:
* NONE: semmi
* INTEGRAL: nem módosítható az adatforgalom
* CONFIDENTIAL: nem is hallgatható le az adatforgalom

==3. Mi a JSF, mik az előnyei? Ismertesd részletesen egy JSF oldal életciklusának lépéseit! (12 pont)==
Java Server Faces egy szerver oldali, komponens alapú felhasználói felület-keretrendszer, webes és általános környezetre.

Előnyei:
* MVC, UI-koncepció webes környezetben, a korábbi tapasztalatokra építve
* komponens alapú, támogatást biztosít a kliens megjelenítéstől független viselkedésre
* Finomabban hangolható, mint a JSP, a felületi elemek állapottal rendelkeznek a szerver oldalon
* Konkrét megjelenítési technológiától független, de úgy tervezték meg, hogy JSP környezetben és annak hiányában is tudjon működni
* A felületi komponensek állapota, eseménymodellje, rendering környezet jól specifikált
* Java EE 5 része, minden webkonténer tartalmaz implementációt

Az életciklus lépései:
# A komponensfa (Nézet, View) felépítése
** Objektum-hierarchia (újra)felépítése
** Eseménykezelő validátorok bedrótozása
** View elmentése a FacesContext-en belül
** nem-postback esetben ugrás a 6. fázishoz
# A request értékek beállítása
** Minden komponens (kivéve rendered="false") a beépített decode metóduson keresztül nyeri ki a request-ből az új értékét
** Ez az érték megfelelő típusra konvertálódik, és a komponensben lokálisan tárolódik
** A konverziós hibák a FacesContext-ben tárolódnak
** Az immediate="true" komponensekre a validáció és az alkalmazásesemények meghívása is itt történik
# Validáció
** A JSF implementáció minden regisztrált bemeneti validátort meghív a komponensfán
** A hibaüzenetek a FacesContext-be kerülnek
** Hiba esetén rögtön a 6. pontra ugrik a feldolgozás
** ValueChange események meghívása
# Modell frissítése
** A JSF implementáció végigmegy a komponensfán, és a komponensek lokális értékeit beírja a value attribútummal a komponensekhez kötött alkalmazásspecifikus objektumokba
** Típuskonverzió illetve konverziós hiba is történhet itt
# Alkalmazás-események meghívása
** A JSF implementáció minden alkalmazásszintű eseményt kezel, pl form elküldése vagy új oldal megnyitása
# Válasz renderelése
** Az implementáció a komponensek beépített encode metódusán keresztül felépíti a komponensfa megfelelő leírását
** Ha itt hiba történik, akkor még elő tudja szedni a korábbi renderelt állapotot, és azt egészíti ki a jelenlegi hibakóddal
** Itt minden esetben a megfelelő RenderKit kerül meghívásra
** Az állapotot elmenti, és a következő kérések feldolgozásakor el tudja érni az 1.-es fázisban

==4. Milyen módokon lehet EJB3 entitások öröklését megvalósitani, mik ezek előnyei/hátrányai? (12 pont)==

'''Egy tábla egy osztályhierarchiához:'''
* egy táblában minden gyermekosztály
* diszkriminátor oszlop írja le a típust

Előnyök:
* hatékony (nem kell join)
* polimorfizmust támogatja

Hátrányok:
* mély hierarchia esetén sok oszlop
* a gyermekosztályok attribútumainak megfelelő oszlopoknak nullázhatóknak kell lenniük

'''Külön tábla gyermekosztályonként:'''
* az ősosztályban definiált oszlopok egy táblában
* a gyermekosztályban definiált oszlopok külön táblákban, + idegen kulcs az ősre

Előnyök:
* nincsenek fölösleges oszlopok
* definiálható nem nullázható oszlop
* polimorfizmust támogatja

Hátrány:
* mély hierarchia esetén a sok join rontja a teljesítményt

'''Egy tábla egy konkrét osztályhoz:'''
* külön tábla minden altípushoz
* minden tábla tartalmazza az ősosztály attribútumait is

Előny:
* hatékony

Hátrány:
* polimorfizmus támogatása nehézkes

==5. Mik a Java Connector Architecture megoldandó feladatai? Milyen irányokba kell egy Resource Adapternek interfészt nyújtania? Sorold fel a lehetséges System Contractokat! (3+3+6 pont)==
* Léteznek speciális rendszerek, melyek csak natív hívásokkal (JNI) vagy socketeken keresztül érhetők el -> ezeket az együttműködési formákat biztonságossá, robusztussá kell tenni
* Együttműködés az alkalmazásszerver szolgáltatásaival (connection pooling, tranzakciók, biztonság)
* alkalmazásszerverek közötti hordozhatóság
** M*N integrációs probléma megoldása
** nagyobb esély, hogy készmegoldást találunk egy elterjedt EIS-hez (Enterprise Information System) történő kapcsolódáshoz

Resource Adapter:
* kliens felé
* alkalmazásszerver szolgáltatásai felé
* az EIS felé

A lehetséges System Contract-ok:
* Life Cycle Management
* Connection Management
* Security Management
* Transaction Management
* Work Management
* Transaction Inflow
* Message Inflow

-- [[BanJozsef|JoE]] - 2009.05.31.

-- [[MajorPeter|aldaris]] - 2009.06.22.

[[Category:Valaszthato]]