Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28.

A VIK Wikiből
A lap korábbi változatát látod, amilyen Hryghr (vitalap | szerkesztései) 2013. május 19., 21:48-kor történt szerkesztése után volt. (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)
Ugrás a navigációhoz Ugrás a kereséshez

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót


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:

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