„Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28.” változatai közötti eltérés
A VIK Wikiből
a Hryghr átnevezte a(z) Szoftverfejlesztés J2EE platformon - 2009.05.28 vizsga lapot a következő névre: Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28.: pontosabb |
aNincs szerkesztési összefoglaló |
||
1. sor: | 1. sor: | ||
==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)== | ==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: | A middleware szolgáltatások olyan szolgáltatások, melyeket általában a középső réteg valósít meg, ilyenek pl: | ||
137. sor: | 134. sor: | ||
-- [[MajorPeter|aldaris]] - 2009.06.22. | -- [[MajorPeter|aldaris]] - 2009.06.22. | ||
[[Category:Valaszthato]] | [[Category:Valaszthato]] |
A lap jelenlegi, 2014. augusztus 21., 21:19-kori változata
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 <transport-guarantee> 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
-- JoE - 2009.05.31.
-- aldaris - 2009.06.22.