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

A VIK Wikiből
Ugrás a navigációhoz Ugrás a kereséshez
a
 
1. sor: 1. sor:
{{GlobalTemplate|Valaszthato|J2EEVizsga2008}}
 
 
 
 
==1. Sorolj fel néhány middleware szolgáltatást! (darabonként 1 pont, max. 5 pont) Explicit és implicit middleware fogalma, előnyök, hátrányok. (12 pont)==
 
==1. Sorolj fel néhány middleware szolgáltatást! (darabonként 1 pont, max. 5 pont) Explicit és implicit middleware fogalma, előnyök, hátrányok. (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:
112. sor: 109. sor:
  
 
-- [[MajorPeter|aldaris]] - 2009.06.22.
 
-- [[MajorPeter|aldaris]] - 2009.06.22.
 
  
  
 
[[Category:Valaszthato]]
 
[[Category:Valaszthato]]

A lap jelenlegi, 2014. augusztus 21., 20:21-kori változata

1. Sorolj fel néhány middleware szolgáltatást! (darabonként 1 pont, max. 5 pont) Explicit és implicit middleware fogalma, előnyök, hátrányok. (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? (12 pont)

  • 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. Mire szolgálnak és hogyan működnek a szervlet szűrők és a tag libraryk? (2*6 pont)

A szervlet szűrők célja megfigyelni, módosítani, közbeavatkozni a kérés, illetve a válasz alapján.

  • A szűrőket láncba szervezhetjük
  • Használati esetek:
    • Hozzáférés biztosítása, blokkolása
    • Cache, tömörítés, loggolás, titkosítás
    • Tartalom transzformációja (pl. XSLT)
    • Company name replacement filter

A szűrő tevékenysége:

  • Headerek vizsgálata
  • Request objektum átalakítása
  • Response objektum átalakítása
  • Következő szűrő meghívása
  • Szűrő lánc megszakítása (blokkolás), hívás átirányítás
  • Kivétel dobása

A szűrők végrehajtási sorrendje a web.xml-ben lévő <filter> tag-ek sorrendjét követi. Az elsőt a konténer hívja, az utolsó a szervletet (service())hívja.

Tag library-k:

  • JSP oldalak között megosztható, újrafelhasználható komponens, amely saját akció elemeket (tageket) definiál (custom tag)
  • az egyes tag-eket leíró fájlokból és azok feldolgozását végző Java fájlokból áll, általában .jar fájlok formájában
  • Egyedi URI tartozik hozzájuk, erre kell hivatkozni JSP oldalról

Szolgáltatások:

  • Attribútumok segítségével testreszabható
  • Visszatérési értékeket is adhat a hívó félnek
  • JSP oldal környezete, változói elérhetőek
  • Kommunikáció és egymásba ágyazhatóság a többi tag library-vel

4. Mi az objektum-relációs leképezés? Mik a tipikus megfeleltetések a relációs és OO fogalmak között? Ismertesse az EJB 3 entitások életciklusát! (12 pont)

Objektum-relációs leképezésnél egy relációs adatbázis szerkezetét képezzük le objektumokba, méghozzá a következő megfeleltetésekkel:

  • relációs tábla <-> entity bean osztály
  • relációs tábla oszlopai <-> entity bean attribútumai, melyek getterekkel, setterekkel érhetők el
  • relációs tábla sorai <-> entity bean példányai

Kapcsolatok leképezése:

  • 1-1 és 1-N kapcsolatokat lehet leképezni
  • N-N kapcsolatnál már kapcsolótáblára van szükség

Az entitások állapotai:

  • new: new-val létrehozva kerül ide, csak a memóriában létezik, a módosítások nem mennek adatbázisba
  • managed: létezik az adatbázisban, és hozzátartozik egy perzisztencia kontextushoz. Ez azzal jár, hogy a módosítások tranzakció commit végén, vagy explicit flush() hívással bekerülnek az adatbázisba
  • detached:adatbázisban megvan, de nem tartozik perzisztens kontextushoz -> ebben az állapotban olyan mint egy DTO -> nem kell külön DTO osztály
  • removed: még perzisztencia kontextushoz tartozik, de már ki van jelölve, hogy törölve lesz az adatbázisból

Az EJB3 entitások életciklusa:

Ezen a helyen volt linkelve a entitylifecycle.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

5. Mik az üzenetorientált köztesrendszerek (MOM) jellemzői? Ismertesd a JMS által nyújtott kommunikációs modelleket! Mik a message-driven bean jellemzői? (12 pont)

MOM jellemzői:

  • aszinkron, lazán csatolt, rendelkezésreállástól független, de tranzakcióbiztos feldolgozás
  • közvetített üzenetek biztos, egyszeri de csakis egyszeri továbbítása
  • egyes alkalmazások eseményvezérelt üzemeltetése
  • áttekinthető rendszer
  • egységes, platformfüggetlen, egyszerű programozási API felület

Kommunikációs modellek:

  • Point-to-point
  • Publish-subscribe

Message-driven bean jellemzői

  • aszinkron üzenetfeldolgozást végez
  • nincs local / remote interfésze, csak egyetlen fájl már EJB 2.x esetén is
  • szinkron módon, közvetlenül nem meghívható
  • állapotmentes
  • fogadhat üzeneteket: Queue-ból, Topic-ból
  • implementálja a javax.jms.MessageListener interfészt
  • ennek onMessage metódusában kapja meg az üzeneteket

-- palacsint - 2008.06.18.

-- aldaris - 2009.06.22.