Szoftverfejlesztés J2EE platformon - Vizsga, 2009.05.28.

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.