J2EE keretrendszerek vizsgálata

Önálló laboratórium, 2008 tavaszFarkas Gábor, OTX0QRKonzulens: Imre Gábor

Kiindulás

• Üzleti alkalmazásaink:– Törzsadatok és kapcsolataik (CRUD)– Tranzakcionális adatok kezelése, importok,

exportok– Reportok

• Architektúra: JSF, Facelets, EJB3

JBoss SEAM - 1

• Faces backingek használatát kényelmesebbé teszi

@Name("example")@Scope(SESSION)public class

ExampleBacking {

@InOtherBacking otherBacking;

• Név és scope annotálva, nem kell xml-t írni• Másik backingre való referencia annotációval

JBoss SEAM - 2

• Faces és EJB kontextusok összevonása

@Name("example")@Scope(SESSION)public class

ExampleBacking {

@PersistenceContextEntityManager em;

• EnityManagert használhatunk, tranzakcionáltak vagyunk• Session Bean is lehet backing

JBoss SEAM – 3

• UI-BL rétegek összemosása. Hátrány? Lehetőség!

• JSR 299 – Web Beans néven szabványosul az megoldás.

• A dependency injection még többre képes, a Google Guice-hoz mérhető, a Spring IoC-t messze veri.

JBoss SEAM – jPDL – 1

• Faces navigáció:– Action outcome (pl success/fail)– Beégetett, vagy backing metódus adja vissza– (view, outcome) -> view hozzárendelés– A navigációs rendszer állapota tehát a nézet

• jPDL: workflow diagram mintára pageflow „állapotgépek” – outcome-ok és EL-re épülő decision node-ok vezérlik.

JBoss SEAM – jPDL – 2

• jBPM-hez jól kapcsolható• Bonyolult pageflow-k jól olvasható, összefüggő

leírása• Egyszerű navigációs szerkezetekhez túl sok

XML, sok copy-paste• Navigációs szerkezetek specializációja –

templatezése – nem megoldott

AJAX – Motiváció

• Üzleti alkalmazásaink felületei elég sablonosak• HTML tartalomra nincs igény• Kicsit speciális dolgokkal (popup ablakok,

fájlfeltöltés) sok időt el lehet tölteni• Túl sokat kell foglalkozni javascripttel,

technológiai sajátosságokkal• A JSF mégsem volt jó választás, nem weboldalt

fejlesztünk

GWT - 1

• Kényelmesen fejleszthetünk javascriptben futó UI-t

• Szerverrel való kommunikáció RPC-n• Alapvetően stateless service-okra csatlakozunk• Más megközelítésben kell a szerveroldalt

fejleszteni, migráció nem triviális.

GWT - 2

• Imperatív UI fejlesztés– Kompozíciókor (kész részek összeállításakor egy

felületté) tetszőleges feltétellel dönthetünk, használhatunk factory patternt, stb..

– Specializáció: hasonló felületek fejlesztésekor OO nyelvi eszközzel élhetünk

GWT - 3

• Dinamikus UI– Nem töltjük mindig az egész oldalt újra -> hálózati

és szerver CPU terhelés is csökken– Pl tranzakció rögzítésekor annak altípusától

függően kérünk be paramétereket– Entitásválasztó felnyíló ablak nem okoz technikai

problémát

GWT – Hátrányok – 1

• EJB3 entitásokhoz DTO-k használatát gyakorlatilag nem tudjuk megkerülni.

• Minden szolgáltatáshívásunk aszinkron– Keresési eredmények táblázatát, entitás nézeti

oldalak feltöltését még egész jól tudjuk kezelni, viszont

– Ha bármilyen kódunknak szerveroldalról származó információra van szüksége, nem tudjuk szekvenciálisan programozni

GWT – Értékelés

• Entitáskezelő alkalmazáshoz önmagában nem jó választás

• Mit tudunk tenni?

Új modell – 1

GWT Widget Tree

Client- Side

Engine

Server- Side

Engine (servlet)

Application(session scope)

Component Tree

Events / update

messages

Új modell – 2

• Mintha AWT-Swing-el fejlesztenénk– Millstone (2000, 2002, 2007)– AjaxSwing (1999)– Thinwire– Echo– …

Szerveroldali UI kód

• Annotációk, genericitás, reflection minden előnyével élhetünk UI fejlesztéskor

• HTML, forms, HTTP, Javascript … mindezzel nem kell időt töltsünk

• Tudunk adni egy egyszerű szerkezetűUI keretet, de a kiegészítése sem ütközik nehézségekbe

Kérdések?