J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavasz Farkas 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 Faces backingek használatát public class ExampleBacking OtherBacking 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 public class ExampleBacking EntityManager 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

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