Enterprise JavaBeans
|
|
Ezt a szócikket egy, a témában jártas személynek vagy szakértőnek át kellene olvasnia, ellenőriznie a szövegét, tartalmát – részletek a cikk vitalapján. |
| Ez a szócikk sürgős javításra/bővítésre szorul, mert ahhoz képest, amilyen fontos témát tárgyal, vállalhatatlan, katasztrofális állapotban van. |
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]
Tartalomjegyzék |
Története [szerkesztés]
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 Specifikáció [szerkesztés]
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:
- Tranzakciókezelés
- Integráció a Java Persistence API által nyújtott Persistence services-zel
- Konkurencia kezelés
- Események kezelés a Java Message Service-zel, és a Java EE Connector Architecture használatával
- Aszinkron metódus hívás
- Feladat ütemezés
- Elnevezési- és könyvtár szolgáltatások (JNDI)
- Távoli eljárás hívás RMI-IIOP és webszolgáltatásokon keresztül
- Biztonság(Java Cryptography Extension (JCE) és JAAS)
- Szoftver komponensek telepítése alkalmazásszerverre
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]
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]
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]
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]
Az EJB-k három csoportra oszthatók: [3]
Session bean [szerkesztés]
A session bean-ek lehetnek:[4]
Állapot mentesek (stateless) [szerkesztés]
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]
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]
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]
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]
- ↑ Enterprise JavaBeans Technology. (Hozzáférés: 2010. február 5.)
- ↑ J2EE Design and Development, © 2002 Wrox Press Ltd., p. 5.
- ↑ Types of Enterprise Beans. (Hozzáférés: 2010. február 5.)
- ↑ State Management Modes. (Hozzáférés: 2010. február 5.)

