Szoftverfejlesztés J2EE platformon - Vizsga, 2009.06.23.

Ez az oldal a korábbi SCH wikiről lett áthozva.

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. Hogyan lehet EJB rétegben Timer-t megvalósítani? Rajzoljon szekvenciadiagramot a szemléltetéséhezt! Mikor van szükség EJB rétegre az alkalmazásokban?

Timer megvalósítás

• Nem használható a Standard Java-ban jellemző megoldás, mert az EJB-kben nem ajánlott új szál létrehozása (EJB konténer nem fog tudni róla)
• EJB 2.1 óta Timer Service, konténer indítja a timer szálat

Szekvenciadiagram

• :EJB Client
  • meghívja az EJB egy metódusát, ami létrehoz egy timer-t
• :EnterpriseBean
  • calls getTimerService() in :EJBContext
    • :EJBContext gets an instance of TimerService from :TimerService
  • :EJBContext returns TimerService
  • calls the appropriate createTimer() method in :TimerService
    • Timer starts ticking
  • callback to ejbTimeout() from :TimerService
• :EJBContext
• :TimerService

3. A szervletek milyen életciklusaihoz lehet Listener-eket csatlakoztatni? Mi a scope szerepe? Milyen scope-ok vannak? Írjon a session szerepéről!

Servlets & listeners

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/Servlets4.html

You can monitor and react to events in a servlet's life cycle by defining listener objects whose methods get invoked when life cycle events occur. To use these listener objects, you must define the listener class and specify the listener class.

Servlet Life-Cycle Events

• Web context: Initialization and destruction
• Web context: Attribute added, removed, or replaced
• Session: Creation, invalidation, and timeout
• Session: Attribute added, removed, or replaced

Scope

Scope Object

• Információ megosztása komponensek között
• getAttribute()/setAttribute(), hashtábla jelleggel, név-objektum párosok
• Figyelem! Nem egyezik meg az oldalnak küldött paraméterekkel: getParameter()

Szintek:

• Page – javax.servlet.jsp.PageContext
• Request – javax.servlet.ServletRequest
• Session – javax.servlet.http.HttpSession
• Web-context – javax.servlet.ServletContext

(HTTP) Session scope

Kérések sorozata közötti állapot megőrzése (pl. belépett felhasználóazonosítója)

• Ugyanakkor a HTTP állapotmentes
• Megoldások:
  • HTTP cookie
  • URL rewrite (response.encodeURL())
  • Hidden FORM fields
• Session timeout

* Általában 30 perc

• Lejárat: időlimit vagy session.invalidate()
• A session fontos erőforrás, csak azt rakjuk bele, ami feltétlen szükséges
• eseményekhez eseményfigyelőket lehet rendelni
• Amire ügyelni kell
  • A Session objektum megosztott, több szálon is kezelhetik
  • Elosztott környezet esetén csak szerializálható objektumokat tegyünk bele, különben elveszik
  • Átgondolandó: Session HA-cluster

4. Milyen izolációs szintek vannak? Ezek melyik problémákat oldják meg? Java EE környezetben hogyan lehet beállítani az izolációs szinteket?

Izolációs szintek

• Az adatbázis izolációs szint befolyásolja, hogy ezen problémák közül melyik léphet fel
• minél több problémát küszöböl ki egy szint, annál több sor/tábla szintűzárat alkalmaz, így annál rosszabb a teljesítménye
• READ UNCOMITTED: más által írt, de nem komittált adatot is tudok olvasni
• READ COMITTED: csak komittált adatot tudok olvasni, ez a default pl. Oracle, MS SQL Server esetén
• REPEATABLE READ: ha kiolvasok egy sort, majd a tranzakción belül újraolvasom, az adat nem változik
• SERIALIZABLE: a konkurens tranzakciók sorosítva futnak

Izolációs szintek beállítása

• Ha én nyitom a JDBC kapcsolatot: java.sql.Connection.setTransactionIsolation(int)
• JPA használataesetén generált a JDBC kód, így nem a fejlesztőnyitja a kapcsolatot
  • az EJB specifikációnem követeli meg, hogy definiálni lehessen az izolációs szintet, alkalmazásszerver-függő, hogy lehetőséget ad-e ennek bekonfigurálására

5. Messagedrivenbean-eknél telepítésleíróval/annotációval miket lehet konfigurálni? Messagedrivenbean-nél milyen lehetőségek vannak válaszküldésre? Több példát is írjon!

Telepítésleíróban vagy annotációban állítható:

• Tranzakcionalitás
  • Beanmanaged
  • Container managed
• MessageSelector
• Acknowledge mode (bean managed tranzakcióesetén)
• Destinationtype
  • Queue
  • Topic (durable / non durable)

Válaszadás lehetősége

• Több kliens szólít meg egy alkalmazást
• Minden kérés azonos queue-bamegy
• Minden alkalmazás csak a saját kéréseinek válaszát szeretnémegkapni
• Megoldás:
  • Egy válasz-queue, minden kliens messageselector-ralolvassa (bizontság?)
  • Minden kliens saját queue-bavárja a választ

* Adminisztrált (permanens queue-k) * Temporális(dinamikus queue-k)

-- aldaris - 2009.06.23.

-- Katus - 2010.06.08.