J2EE keretrendszerek vizsgálata

J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavaszFarkas Gábor, OTX0QR Konzulens: 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 • Facesbackingek használatát kényelmesebbé teszi @Name("example") @Scope(SESSION) publicclass ExampleBacking{ @In OtherBackingotherBacking; • 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 • EnityManagert használhatunk, tranzakcionáltak vagyunk • Session Bean is lehet backing @Name("example") @Scope(SESSION) publicclass ExampleBacking { @PersistenceContext EntityManagerem;

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 dependencyinjection még többre képes, a GoogleGuice-hoz mérhető, a Spring IoC-t messze veri.

JBoss SEAM – jPDL – 1 • Faces navigáció: • Action outcome(plsuccess/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ő decisionnode-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 factorypatternt, 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

Ú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?

J2EE keretrendszerek vizsgálata