J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavasz Farkas Gábor, OTX0QR Konzulens: Imre Gábor.

Az előadások a következő témára: "J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavasz Farkas Gábor, OTX0QR Konzulens: Imre Gábor."— Előadás másolata:

1 J2EE keretrendszerek vizsgálata Önálló laboratórium, 2008 tavasz Farkas Gábor, OTX0QR Konzulens: Imre Gábor

2 Kiindulás Üzleti alkalmazásaink: – Törzsadatok és kapcsolataik (CRUD) – Tranzakcionális adatok kezelése, importok, exportok – Reportok Architektúra: JSF, Facelets, EJB3

3 JBoss SEAM - 1 Faces backingek használatát kényelmesebbé teszi @Name("example") @Scope(SESSION) public class ExampleBacking { @In OtherBacking otherBacking; Név és scope annotálva, nem kell xml-t írni Másik backingre való referencia annotációval

4 JBoss SEAM - 2 Faces és EJB kontextusok összevonása @Name("example") @Scope(SESSION) public class ExampleBacking { @PersistenceContext EntityManager em; EnityManagert használhatunk, tranzakcionáltak vagyunk Session Bean is lehet backing

5 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.

6 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.

7 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

8 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

9 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.

10 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

11 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

12 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

13 GWT – Értékelés Entitáskezelő alkalmazáshoz önmagában nem jó választás Mit tudunk tenni?

14 Új modell – 1

15 Új modell – 2 Mintha AWT-Swing-el fejlesztenénk – Millstone (2000, 2002, 2007) – AjaxSwing (1999) – Thinwire – Echo – …

16 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

17 Kérdések?