Szia! Majoros Attila, alias Majki vagyok. Öt éve dolgozom a mostani munkahelyemen, és kb. akkor ismerkedtem meg a Javaval is. Jelenlegi projektem során szükségessé vált, hogy az eddiginél mélyebben ássam bele magam a Java EE-be.
Nem mondom, hogy nem voltak rossz napjaim, minden kezdet nehéz, de így utólag nem olyan szörnyű ez, mint állítják róla. :D Meg szeretnék veletek osztani pár tapasztalatot.
Azért összetett ez, mert ahhoz, hogy egy EE alkalmazást összerakjunk, több mindenre van szükségünk, mint SE esetén. El kell indulnunk valahol az EE megismerésével, és utána folyamatosan bővíteni kell az ismereteket.
Mi is az a Java EE?
A Java EE, azaz Enterprise Edition egy olyan platform, avagy specifikáció, amely több olyan szabványt, API-t definiál, melyeket különböző gyártók implementálnak. Az internet tele van mindenfele leírásokkal, hogy épp melyik EE verzióba milyen API-k vannak, mi mit támogat…
Én inkább gyakorlatias úton szeretném megközelíteni ezt az egész EE világot. Jelenleg Weblogic 12c-vel kell dolgoznom, amely Java EE 6 specifikációt támogat, tehát leginkább a 6-os adta lehetőségekről lesz szó.
API, implementációk
A Java EE több API-ból áll, ezeket fogja össze. Az alábbi lista pár fontosabb szabványt tartalmaz, és bár korántsem teljes, ad egy képet arról, hogyan is néz ki, és mit ad nekünk egy alkalmazásszerver.
- EJB (Enterprise Java Beans)
- CDI (Context & Dependency Injection)
- JPA (Java Persistence API)
- JTA (Java Transaction API)
- JMS (Java Message Services)
- JAXP (Java API for XML Processing)
- JAXB (Java API for XML Binding)
- JAX-RS (Java API for XML – REST Services)
- JAX-WS (Java API for XML – Web Services)
- JDBC (Java Database Connectivity)
- JavaMail API
- JNDI (Java Naming and Directory Interface)
- JAAS (Java Authentication and Authorization Service)
- JSP (Java Server Pages)
- BeanValidation
- EL (Expression Language)
- JSF (Java Server Faces)
- JSTL (Java Server Pages Standard Tag Library)
Ha nem szereted a listákat, mutatok egy architektúradiagramot, a szürke sávok az új API-kat jelölik.
Egy tipikusnak mondható EE alkalmazás
A gyakorlatban mondhatjuk azt, hogy van egy webes konténerünk, amelyet frontendként használunk, és benne szerver oldali JAAS oldja meg a form autentikációt. A weblapokat JSF-el állítjuk elő, amelyben EL használatával érjük el az EJB-ket, ebben más EJB-k, illetve resource-ok CDI-vel injektálódnak, ahonnan JNDI-vel érünk el egy másik konténerben lévő EJB-t , mondjuk RMI-vel, amelyben JPA-entitásokkal használunk adatbázist JTA tranzakciókban, JMS-en keresztül küldünk valamilyen eseményt, amelyet elkapva JAX-WS-en, SOAP-on keresztül küldünk valahova adatot, az pedig JavaMail API-val e-mail-t küld.
Nos, ebben az esetben az alkalmazásszerverre feltöltött alkalmazás moduljainknak semmiféle függőséget nem kell tartalmazniuk, mert mindent az alkalmazásszerver biztosít számunkra. Tipikusan elég, ha az API-k fordítási időben megvannak. Természetesen használhatunk más implementációkat is, amelyeket nem az alkalmazásszerver biztosít számunkra.
Hogy az alkalmazásunkat telepíteni (deploy) tudjuk egy alkalmazásszerverre, csomagot, archívumot kell létrehoznunk. Az EAR az Enterprise Archive rövidítése. Ha olyan csomagot szeretnénk, amely tartalmaz jar fájlokat, EJB modulokat – ezek szintén jar fájlok –, és opcionálisan egy war fájlt is (Web Archive), akkor mindezt egy EAR-ba csomagolva már telepíthetjük is a szerverre, akár telepítési leírókkal (deployment descriptors) megfűszerezve. :)
Alkalmazásszerverek
Az alkalmazásszerver biztosítja számunkra az API-k implementációját, menedzsmentfelületet ad, és még sok minden mást is. :)
A következő felsorolás nem teljes, igyekszem azokat az alkalmazás szervereket megemlíteni, amelyek teljes mértékben támogatják a Java EE 6-ot.
- Glassfish
A Glassfish alkalmazásszerver a Java közösség által fejlesztett referencia implementáció. Sok esetben lassú, de mindent tartalmaz. A 3.x verziótól kezdve támogatja a Java EE6-ot. Jelenlegi 4.1 verziója pedig az EE 7 – t.
- JBoss
A RedHat által fejlesztett alkalmazásszerver. A szabadon használható verziók közül a jelenleg legújabb WildFly 8.2 már a Java EE 7-et is támogatja.
- IBM WebSphere
IBM által fejlesztett alkalmazás szerver.
- Apache Geronimo
Nyílt forrású.
- Oracle Weblogic
Az Oracle Weblogic 12c támogatja a Java EE 6-ot. Sőt, ebben már Spring konténert is használhatunk. :)
Beszéltem arról, hogy az alkalmazásszerverek különböző implementációkat tartalmazhatnak. Nézzük meg, mire is gondoltam:
JPA implementációra a Glassfish és a Weblogic az EclipseLink-et használja, míg a JBoss a Hibernate-et, a Geronimo pedig az OpenJPA-t. JMS implementációra a Geronimo ActiveMQ-t, a Glassfish OpenMQ-t, a Weblogic pedig Oracle AQ-t használ. CDI implementációra tudomásom szerint jelenleg a referencia implementációt, a Weld-et használja az összes felsorolt alkalmazásszerver. Létezik ugyan egy Apache OpenWebBeans CDI implementáció is, de jelenleg ez még nem kiforrott, viszont ígéretes.
Hogyan tovább?
Mindaz, amiről itt beszéltem, sok-sok oldal hivatalos dokumentációt jelent, tehát van mit olvasgatni a témában. :)
Igyekszünk a legtöbb említett dolgot kifejteni kicsit bővebben. Természetesen nem ígérjük, hogy mindent érintünk, de azért lesznek jó részek. ;-)
Egy tipikus EE alkalmazás, avagy mi az az EAR?
Ahhoz, hogy az alkalmazásunkat deployolni tudjuk egy alkalmazásszerverre, csomagot, archiv-ot kell létrehoznunk. Az EAR az Enterprise Archive rövidítése, és ha olyan csomagot szeretnénk, ami tartalmaz jar fájlokat, EJB modulokat – ezek szintén jar fájlok –, és opcionálisan egy war (WEB archive) fájlt is , akkor mindezt egy EAR-ba csomagolva már deployolhatjuk is a szerverre, akár deployment descriptorokkal megfűszerezve. :)
Példa:
Létrehozunk egy maven modul-t, legyen a neve example-shared. Ez a modul fogja tartalmazni azokat az interfészeket, amelyeket a későbbi backend és frontend moduljaink használni fognak. Például JPA-entitások, szolgáltatások interfészei. Egyedüli függősége a javax.javaee-api:6.0 legyen, provided scope-ban. Ezzel fordítás időben rendelkezésünkre áll majd minden Java EE 6 API. A provided scope azért kell, mert futásidőben az alkalmazásszerver szolgáltatja majd az alkalmazásunk részére az implementációt , így csak a fordításnál van rá szükségünk.
A következő lépésben hozzunk létre egy example-backend nevű modult. A modul függősége az example-shared modul lesz, így rendelkezésre állnak a JPA-entitásaink és a szolgáltatásinterfészek. Ebben a modulban implementáljuk a szolgáltatásokat, amelyek például az entitásokon keresztül az adatbázissal kommunikálnak. Itt programozzuk le az üzleti logikát.
Hozzunk létre egy example-frontend modult, amelynek szintén az example-shared lesz a függősége. Itt hozhatunk létre saját EJB-ket, amelyek majd a backendben implementált szolgáltatásokat injektálják és használják fel a megjelenítésre.
Tegyük fel, hogy szeretnénk skálázhatóvá tenni az alkalmazásunk üzleti logikáját. Ekkor létrehozunk egy EAR-t, amely csak az example-shared és az example-backend-et tartalmazza, majd először ezt egy cluster-be deployoljuk, az example-frontend-ünket pedig külön.
Egyszerűen hangzik, de nem minden esetben az. Sok a lehetőség, de sok a buktató is. A lényeg, hogy JavaEE alkalmazásokkal könnyebben tudunk nagy, robusztus, skálázható, többrégetű (multi-tier) alkalmazásokat létrehozni.
A következő részben, ígérem, már kód is lesz. :)
