Enterprise JavaBeans

A Wikipédiából, a szabad enciklopédiából

Az Enterprise JavaBean-ek (EJB) moduláris vállalati alkalmazásokban használt szerveroldali komponensek. Általában az üzleti logika implementációját tartalmazzák. Az EJB specifikáció eredetileg 1997-ben lett kifejlesztve az IBM által, később,1999-ben, a Sun Microsystems is elfogadta, alkalmazta(EJB 1.0 és 1.1). és tovább terjesztették a Java Community Process alatt mint JSR19, JSR152, JSR220 és JSR318.[1]

Története[szerkesztés | forrásszöveg szerkesztése]

Az EJB 1.0 specifikációt az IBM fejlesztette ki 1997-ben, majd a Sun Microsystems 1999-ben adoptálta.[2] A Java Community Process keretében fejlesztették tovább specifikációt és Java Specification Request dokumentumokként kerültek nyilvánosságra az újabb verziók:

Verzió Specifikáció Kiadás éve
EJB 1.0 1998
EJB 1.1 1999
EJB 2.0 JSR 19 2001
EJB 2.1 JSR 153 2003
EJB 3.0 JSR 220 2006
EJB 3.1 JSR 318 2009
EJB 3.2 JSR 345 2013

EJB Specifikáció[szerkesztés | forrásszöveg szerkesztése]

Az EJB specifikációt arra tervezték, hogy fejlesszen egy alapvető utat, amelynek teljesítenie kell a back-end business kódot, ami a vállalkozói alkalmazásokban található(és az ellentéte a front-end interfésznek). Az ilyen kódok gyakran ugyanazokat a hibákkal rendelkeztek, és a megoldásokat ezekre a problémákra a programozók újra és újra keresztül vitték. Az EJB arra hozták létre, hogy kezelje perzisztenciát, a tranzakció integritást és a védelmet egy alapvető úton úgy, hogy a programozók szabadon koncentrálhassanak a megoldandó problémákra.

Az EJB specifikáció részletezi egy alkalmazás szolgáltatásait:

Mi több, az EJB specifikáció azokat a kötelességeket írja le, amit az EJB konténer és maga az EJB tartalmaz, mint ahogy azt is, hogy hogyan kell telepíteni az EJB konténert. Megjegyzendő, hogy a jelenlegi EJB specifikáció nem részletezi többet, hogy egy alkalmazás hogyan gondoskodik a perzisztenciáról(egy olyan feladatról, ami a JPA specifikáció meghatalmazottja), de ehelyett részletezi, hogy az üzleti logika könnyedén egybeolvasztható a perzisztencia szolgáltatásokkal, amiket a kiszolgáló alkalmazás állít.


A megjelenés utáni csalódás[szerkesztés | forrásszöveg szerkesztése]

A problémák gyorsan előkerültek, ennek következtében az EJB hírneve megkopott. Néhány API fejlesztő úgy gondolta, hogy az EJB alapjai sokkal összetettebbek, mint amihez hozzá voltak szokva. Az ellenőrzött kivételek jelentős részének interfészre volt szüksége. A bean osztály kivitelezése, mint absztrakt osztály, szokatlan és természetellenes volt a legtöbb programozó számára. Ismert, hogy a problémák, amit az EJB standard megkísérelt megnevezni, összetettek. Ilyen pl. az objektum-relációs mapplés vagy a transactional integrity. Ennek ellenére sok programozó az API-t is hasonló, vagy még nehezebbnek vélte, így alakult ki az a széleskörű felfogás, miszerint az EJB által bemutatott összetettség nem nyújt igazi hasznot. Mi több, a cégek úgy találták, hogy az EJB-t arra használva, hogy betokozzák az üzleti logikát, teljesítményi hátrány keletkezett. Ez azért történhetett, mert az eredeti specifikáció csak a CORBA-n keresztül engedte az irányított invokációs utat(és opcionálisan minden más eljárást is), annak ellenére, hogy a legtöbb üzleti pályázatnak nincs is szüksége az elosztott számítások funkcióra. Az EJB 2.0 specifikáció ennek az aggodalomnak a megszüntetésesre jött létre. Ezt úgy akarták kivitelezni, hogy egy helyi interfész koncepcióját adják hozzá, amelyet egyenes úton lehetett hívni anélkül, hogy a többszörös szervereken eloszló applikációk által előadott probléma megjelenne. Széles körben lett bemutatva, mint az EJB 1.0 által felmerült problémák megoldása. Az összetettségi eredmény azonban továbbra is megakadályozta az EJB elfogadását. Habár a magas minőségű fejlesztői eszközök azzal, hogy automatizálták az ismétlődő feladatokat megkönnyítették az EJB létrehozását és használatát, ugyancsak ezek az eszközök nem könnyítették meg a technológia megtanulásának a folyamatát. Ezen felül egy ellenálló művelet is elkezdett kibontakozni a programozók között. A fő gyártmánya ennek az ellenállásnak a 'lightweight technology of Hibernate' és a Spring keretrendszer lett. (A lightweight összehasonlítás az EJB-vel, a Hibernate az object-relational mappinggel. A framework egy alternatív és kevésbé "bőbeszédű" út az üzleti logika kódolásához). Annak ellenére, hogy a nagyobb cégek nem támogatták, ezek a technológiák ismertek lettek, és sok olyan cég kezdte használni őket, akik csalódtak az EJB-ben. Az EJB-t a Java BluePrints, és a Sun Java Pet Store demója támogatta. Az EJB használata vitatható és befolyásoló volt. A Java EE programozók, mint például Rod Johnson, aki megkísérelt egy olyan választ létrehozni a Java Pet Store-ra, ami megkísérli kihangsúlyozni az EJB használatának a fontosságát. Sun létrehozott egy alternatívát, amit Plain Old Java Objects-nek neveztek. Az EJB 3.0 könnyebb volt az EJB 2.0-nál és több lehetőséget is nyújtott a fejlesztőknek.

Az EJB újraalkotása[szerkesztés | forrásszöveg szerkesztése]

Egy gyári megegyezés fokozatosan sürgette az eredeti EJB specifikáció elsődleges előnyét-képessé téve a transactional integrity-t az elosztó alkalmazásokkal szemben-ami az volt, hogy korlátolt használatot engedélyezett a szórakoztató applikációknak. A funkciója, ami az egyszerű váz miatt alakult ki, sokkal hasznosabb lett. Példa erre a Spring, vagy a Hibernate. Ennek megfelelően az EJB 3.0 (JSR 220) egy radikális indulópont volt az ősöktől az új mintát követve. Nyilvánvaló hatást mutat a Springben a POJO használatában, és támogatja a dependency injection-t, hogy leegyszerűsítse a heterogén rendszer felépítését és egyesülését. Gavin King a Hibernate megalapítója, valamint részt vett a az EJB 3.0 folyamatában is, és köztudott szószólója a technológiának. A Hibernate sok jellegzetessége egyesül a Java Persistence API-ben, ami az entity beans helyettesítése az EJB 3.0-ban. Az EJB 3.0 erősen az annotációkon alapul. Ezek az annotációk a Java nyelvhez lettek hozzáadva az 5.0-ás megjelenésével, hogy egy kevéssé bőbeszédű kódoló stílust hozzanak létre. Ennek megfelelően a gyakorlatban az EJB 3.0 egy majdnem teljesen új API kicsi hasonlóságot mutatva a megelőző EJB specifikációkkal.

Példa[szerkesztés | forrásszöveg szerkesztése]

A következő példa azt mutatja be, hogy hogyan is néz ki egy EJB gyakorlatban:

@Local
public interface CustomerServiceLocal {
   void addCustomer(Customer customer);
}
 
@Stateless 
public class CustomerService implements CustomerServiceLocal { 
 
  @PersistenceContext 
  private EntityManager entityManager; 
 
  public void addCustomer(Customer customer) { 
    entityManager.persist(customer); 
  } 
}

A fenti kód egy lokális interfész implementációja egy egyszerű alkalmazás osztálynak, melynek segítségével állandó customer objektumot hoz létre (az O/R mapping-en keresztül). Az EJB a perzisztencia összefüggésre koncentrál és az addCustomer() mód tranzakcinális és szálbiztos a beállítások miatt. Ahogy azt láthattuk, az EJB csak egy üzleti logikára koncentrál, más egyéni bemutatást nem ismer.

Az EJB-t osztályokban is lehet használni mint a következő példában is:

@Named
@RequestScoped
public class CustomerBacking {
 
   @EJB CustomerServiceLocal customerService;
 
   public String addCustomer() {
      customerService.addCustomer(customer);
      context.addMessage(...); // abbreviated for brevity
      return "customer_overview";
   }
}

A fenti kódolás egy JSF backing bean-t mutat be, amiben az EJB eszközökkel lett injektálva a @EJB annotációba. Az addCustomer mód tipikusan a határt jelenti néhány UI komponensnek, mint például a gomb. Ellenkezve az EJB-vel, a backing bean nem tartalmaz semmilyen üzleti logikát vagy persistence kódot, de felhatalmaz néhány aggodalomra az EJB-vel szemben. A backing bean tud olyan egyéni bemutatásokról is, amiről az EJB-nek nincs tudomása.

EJB típusok[szerkesztés | forrásszöveg szerkesztése]

Az EJB-k három csoportra oszthatók: [3]

Session bean[szerkesztés | forrásszöveg szerkesztése]

A session bean-ek lehetnek:[4]

Állapot mentesek (stateless)[szerkesztés | forrásszöveg szerkesztése]

Az állapotmentes viszony bean nem perzisztens bean. Állapota ugyan lehet, de miután a hívott művelete végrehajtódott, az állapot többé nem determinisztikus, és nem is releváns. Mivel az állapotmentes viszony bean példányainak nincs állapota, így a metódusainak végrehajtásához szükséges összes adat a metódusok paramétereiből származik.

Állapottartók (stateful)[szerkesztés | forrásszöveg szerkesztése]

Egy objektum állapota magába foglalja a példány tagváltozóinak értékét. Egy állapottartó viszony bean (stateful session bean) példánya egy egyedi kliens munkamenetet reprezentál. Az állapotát a kliens viszony (session) ideje alatt őrzi meg. Ha a kliens eltávolítja a bean-eket vagy befejezi a futását, a munkamenet véget ér és az állapot elvész. Az állapot effajta tranziens viselkedése nem jelent problémát, mivel a viszony végeztével nincs szükség az állapot további megőrzésére.

Üzenet vezérelt bean[szerkesztés | forrásszöveg szerkesztése]

Az üzenet vezérelt babok (MDB) olyan vállalati bean-ek, amelyek üzenetek aszinkron feldolgozását teszik lehetővé Java EE alkalmazások számára.

Entity bean[szerkesztés | forrásszöveg szerkesztése]

Ebből is két fajta van: BMP (Bean Management Beans) és CMP (Container Managed Beans). Míg az első esetben a fejlesztőnek magának kell gondoskodnia a perzisztencia megoldásáról betartva az EJB szabványt, addig a második esetben a perzisztencia vezérlést teljes egészében a konténerre bízható, és ténylegesen csak az üzleti logika megvalósítására lehet összpontosítani.

Jegyzetek[szerkesztés | forrásszöveg szerkesztése]

  1. Enterprise JavaBeans Technology. (Hozzáférés: 2010. február 5.)
  2. J2EE Design and Development, © 2002 Wrox Press Ltd., p. 5.
  3. Types of Enterprise Beans. (Hozzáférés: 2010. február 5.)
  4. State Management Modes. (Hozzáférés: 2010. február 5.)