„Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28.” változatai közötti eltérés

A VIK Wikiből
Hryghr (vitalap | szerkesztései)
Szikszayl (vitalap | szerkesztései)
aNincs szerkesztési összefoglaló
 
1. sor: 1. sor:
{{GlobalTemplate|Valaszthato|J2EEVizsga20090528}}
==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:

  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.