Fő kategória: Java.
Az alapprobléma
Ha egy tipikus vállalati program Java program elér egy bizonyos méretet, akkor szinte törvényszerű, hogy az alábbi problémák nagy többségébe belefutunk:
- többszálúság, ill. leginkább az ezzel kapcsolatos problémák orvoslása,
- skálázhatóság, magyarán az, hogy kis és nagy igénybevétel mellett is megbízhatóan működjön a rendszer,
- perzisztencia, azaz az adatok tartós tárolása, ill. az ezzel kapcsolatos problémák kezelése (pl. kapcsolódás az adatbázishoz, a Java objektumok relációs adattáblákra való leképezése stb.),
- tranzakció kezelés, tehát mikor történjen commit ill. rollback, és mi történjen mondjuk ez rollback esetén,
- távoli elérés, ill. általánosabban megfogalmazva bármiféle kommunikáció két távoli rendszer között, az ezzel kapcsolatos problémák kezelése,
- névszolgáltatás, azaz az erőforrások kezelése, a lekérdezés biztosítása,
- üzenetkezelés, ami az üzenetek küldését és fogadását is jelenti, általában többféle módon,
- biztonság, tehát annak a biztosítása, hogy illetéktelenek ne férhessenek hozzá az adatokhoz
- és a sort még hosszan lehetne sorolni.
Az Enterprise Java (magyarul kb. nagyvállalati Java) ezekre a problémákra nyújt megoldást. Az elkészített program nem önmagában fut, hanem egy futtató környezetben, amely kezeli a fenti problémákat, vagy teljesen elfedve azt a fejlesztő elől (pl. a többszálúsággal kapcsolatos problémák kezelése), vagy arra a minimumra csökkentve a szükséges kódot, amit feltétlenül muszáj megadni (pl. az adatbázis kapcsolat felépítéséhez többnyire elég megadni az alap elérési adatokat, és mondjuk a kapcsolat létrehozásának a részleteivel általában nem kell törődnie a programozónak).
Szerintem nem egyértelmű a határ a Standard és az Enterprise Java között. Szigorú értelemben az Enterprise Java nem más mint egy specifikáció halmaz, amelyet a Java Community Process gondoz, és megtalálható a https://www.jcp.org oldalon. E szerint tehát az Enterprise Java az, ami megfelel a specifikációknak (ill. annak egy részének). Kevésbé szigorú értelemben viszont (szerintem) ide lehet sorolni mindazt, amely a fenti problémákra (vagy azok egy részére) igyekszik megoldást találni mégpedig úgy, hogy a program nem önmagában fut, hanem egy keretrendszerben. Ezen az oldalon e tágabb értelmezést használom, sőt, ide gyűjtöm azokat a rendszereket is, melyek önálló alkalmazásokként futnak, és interfészt nyújtanak a tőlük függetlenül futó Java alkalmazások felé.
Az Enterprise Java közös jellemzője tehát az, hogy a program nem önmagában fut, hanem bele kell tenni egy "konténerbe" és a futtató rendszer futtatja. Itt tipikusan nem a public static void main(String[] args) függvény indul el, hanem a belépési pont a konténertől (és egyéb eseményektől) függ. Klasszikusan kétféle konténert különböztetünk meg: a web konténert és az EJB konténert, és ez alapján különböztetjük meg a webszervereket és alkalmazás szervereket.
Architektúrák
Mielőtt belemennénk a részletekbe, érdemes kicsit áttekinteni az architektúra típusokat, és az ezekkel kapcsolatos általános tudnivalókat. Alapvetően a szoftverarchitektúrákat a következő csoportokba soroljuk:
- 1 rétegű: ebben az esetben minden egy helyen van: az adatforrás, az üzleti logika és a megjelenés is. Egyrétegű architektúrának tekinthető az összes, személyi számítógépen futó alkalmazás, melyhez nem szükséges hálózati kapcsolat.
- 2 rétegű: ezeket hívjuk vastag kliens architektúráknak. Az üzleti logika és a megjelenítés a kliens számítógépeken fut, az adatforrás viszont közös. Ez az architektúra üzemeltetési nehézségekhez vezethet, ugyanis ha frissíteni szeretnénk a központi komponenst, akkor egyszerre kell frissítenünk az összes klienst. Ilyen architektúrájúak a hálózatot használó alkalmazások.
- 3 rétegű: ezek az úgynevezett vékony kliens architektúrák. Az előzővel ellentétben itt tipikusan elkülönül az üzleti logika és a megjelenítés: az üzleti logika egy központi szerveren fut, míg a grafikus felület a leggyakrabban egy böngésző. Ez jelentősen megkönnyíti a frissítést, mert nem szükséges frissíteni a kliens gépeken az alkalmazást.A webalkalmazások képezik ennek az architektúrának egy jelentős hányadát.
- N rétegű: elkülönül a webes réteg és az üzleti logika réteg. Ebben az esetben 4 vagy 5 rétegről beszélünk, melyek az alábbiak:
- Kliens réteg: leggyakrabban ez itt is a böngésző, de vastag kliens is lehetséges.
- Web réteg: megfelel a 3 rétegű alkalmazások webes rétegének, viszont ez kevesebb üzleti logikát tartalmaz, a fő feladata a felhasználói interakciók kezelése és a megjelenítés. Az adatforráshoz általában nem közvetlenül nyúl, hanem az alatta levő rétegen keresztül.
- Üzleti logika réteg: ide konténer által vezérlet komponensek kerülnek, melyek többnyire skálázhatóak, távolról elérhetőek, többféle módon.
- Integrációs réteg: ebbe kerülnek azok a komponensek, amelyek az adatok összegyűjtéséért felelősek, pl. amelyek az adatbázis kapcsolatért felelősek. (Ami miatt N rétegű architektúráról beszélünk, és nem 4 vagy 5 rétegűről, az emiatt van: ez ugyanis logikailag része lehetne az előzőnek, de el is különülhet attól)
- Erőforrás réteg: itt található a tényleges adat, pl. egy adatbázisban.
Az Enterprise Java két nagy területre osztható: