Enterprise Java

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ó:

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License