EJB 2.x – role a ich zodpovednosti pri vývoji EJB

Ako som už spomenul v úvodnom článku, Enterprise JavaBeans je chápaná ako komponentovo orientovaná architektúra pre distribuovaný computing. Samotné Enterprise Beans (EB) sú jednoznačne najdôležitejšou súčasťou tejto architektúry. Sú určitým spojivom medzi ostatnými prvkami komplexného celku. Napriek tomu, že ostatné komponenty architektúry spolupracujú na celkovom výsledku, EB sú to, čo nesie najväčší podiel zodpovednosti.

V tomto článku sa budeme trochu bližšie venovať samotným EB ako časti veľkého celku. Enterprise Beans sú jednoznačne nasadzované ako komponenty distribuovaných transakčne orientovaných enterprise systémov. Môžeme ich popísať nasledovnými charakteristikami:

• Ich životný cyklus je zabezpečovaný EJB kontajnerom, ktorý zabezpečuje príslušné služby.
• Obsahujú biznis logiku, ktorá sa vykonáva nad podnikovými dátami.
• Inštancie sú vytvárané a spravované EJB kontajnerom.
• Ich správanie môže byť dodatočne upravované prostredníctvom XML deskriptora.
• Transakcie a zabezpečenie sú definované oddelene od EB.
• Klient nikdy nepristupuje k EB priamo, iba prostredníctvom rozhrania EJB kontajnera.
• Koncepcia EB je vytvorená tak, aby bola prenositeľná medzi rôznymi EJB servermi.

Špecifikácia EJB rozoznáva tri typy enterprise bean komponentov:

• Entity Bean
  • Container-Managed Persistence Entity Bean (CMP Entity Bean)
  • Bean-Managed Persistence Entity Bean (BMP Entity Bean)
• Session bean
  • Stateful Session Bean
  • Stateless Session Bean
• Message-Driven Bean

Použitie jednotlivých typov EB

Každý typ EB sa používa na iný účel. Stručne si teraz popíšeme využitie jednotlivých typov EB.

Entity Bean

Entity bean obvykle reprezentuje riadok v databázovej tabuľke. Nie je to síce jediné využitie, ale je najčastejšie. Tak ako máte v tabuľke pre každý záznam jeden riadok, tak môžete mať pre každý riadok vytvorenú inštanciu entity bean. Ak napríklad máte tabuľku objednávok, tak pre každú objednávku budete mať samostatnú entity bean. I keď táto záležitosť býva implementovaná v jednotlivých EJB kontajneroch rôzne.

Toto však vôbec neznamená, že kontajner po štarte vytvorí v pamäti inštancie entity beans pre každý riadok v databáze. To by bolo neuveriteľné plytvanie prostriedkami. Napriek tomu je to tak, že v prípade, že to klient potrebuje, je mu k dispozícii riadok tabuľky ako samostatná inštancia entity bean. Všetci klienti, ktorí pristupujú k tomu istému riadku v databáze, využívajú tú istú inštanciu entity bean.

Entity bean je perzistentný komponent, pretože dokáže prežiť aj reštart serveru. Stav entity bean je ukladaný do databázy, takže po nábehu servera môže byť obnovený. Avšak nie každá tabuľka musí byť mapovaná na samostatnú entity bean. Môžete mať entity beans, ktoré sú namapované na niekoľko tabuliek súčasne. Tiež platí, že nie každý perzistentný objekt musí byť automaticky entity bean.

Rozoznávame dva typy entity beans, podľa spôsobu riadenia perzistencie. CMP alebo Container-Managed Persistence je typ, pri ktorom je perzistencia objektu riadená EJB kontajnerom, v závislosti od nastavenia deployment deskriptora. Pri tomto type beanu bude každá zmena stavu inštancie, kontajnerom automaticky prenesená do databázy. Čiže programátor sa nemusí starať o realizáciu perzistencie vrátane databázovej konekcie. BMP čiže Bean-Managed Persistence je druhý typ entity beanu, pri ktorom si musí programátor sám zabezpečiť realizáciu perzistencie.

Session Bean

Session bean typicky zapuzdruje biznis logiku aplikácie. Obvykle obsahuje niekoľko operácií, ktoré sa musia vykonať ako takzvaná atomická jednotka. Atomická znamená, že všetky kroky tejto jednotky sa buď vykonajú až do konca, alebo sa nevykoná ani jedna z nich. Napríklad ak máte metódu na spracovanie objednávky, ktorá vykonáva rôzne kroky (vykonať e-platbu, zapísať objednávku do systému a nakoniec vygenerovať e-mail pre oddelenie distribúcie), môžete ju umiestniť do session beanu. Pretože buď budú vykonané všetky operácie, alebo ani jedna z nich.

Existujú dva druhy session beans – stavové (stateful) a bezstavové (stateless). Stavové session beans sú navrhnuté tak, aby dokázali spravovať a pamätať si stav konverzácie s klientom medzi jednotlivými volaniami metód. Inými slovami, stavové session beans dokážu spravovať a držať stav inštančných premenných konkrétneho klienta. Naproti tomu bezstavové session beans zdieľajú stav inštančných premenných medzi rôznymi klientmi.

A to je jeden z najčastejších omylov, že bezstavové session beans nedokážu uchovávať stav. Dokážu uchovávať stav, ale nie špecifický pre konkrétneho klienta. Pretože zo špecifikácie EJB nie je garantované, že ten istý klient použije vždy tú istú inštanciu stateless session bean pri rôznych volaniach metód. EJB kontajner má v tomto slobodu, lebo môže podľa potreby prepínať jednotlivé inštancie medzi klientmi. Tento aspekt umožňuje zvýšiť škálovateľnosť, menšie množstvo inštancií môže obslúžiť väčšie množstvo klientov.

Všetky inštancie stateless session beans sú z pohľadu klienta rovnaké, a to je možno jeden z dôvodov, prečo sa často využívajú. Naproti tomu stateful session beans nie sú, a ani nemôžu byť rovnaké, pretože uchovávajú stav. Napríklad nákupný košík, implementovaný ako stateful session bean, musí byť unikátny pre konkrétneho klienta, pretože každý môže obsahovať iné položky.

Message-Driven Bean

Ide o novší typ (od verzie 2.0) EB, ktorého účelom je asynchrónne spracovávať JMS (Java Message Service) správy. Tento typ EB je v zásade veľmi odlišný od dvoch predchádzajúcich, a to v dvoch ohľadoch. Po prvé, message-driven bean nie je viditeľný z pohľadu klienta, a po druhé, message-driven bean očakáva správy poslané prostredníctvom JMS, pričom tieto správy spracováva anonymne.

Pri tomto type EB to funguje tak, že EJB kontajner deleguje prijatú správu buď na existujúcu inštanciu beanu, alebo vytvorí novú, ktorá danú správu spracuje. Message-driven beans sú bezstavové, a preto ktorákoľvek inštancia obslúži prijatú správu úplne totožne. Podobne ako stateless session beans, aj message-driven beans sú anonymné, teda nie sú priradené ku konkrétnemu klientovi.

Role pri tvorbe EJB a ich zodpovednosti

Pretože nikto nie je expertom na všetky oblasti používané pri tvorbe enterprise systémov, EJB špecifikácia rozdeľuje vývoj, nasadenie a management enterprise aplikácií na šesť odlišných rolí. Každá jedna rola hrá v celom životnom cykle aplikácie svoju nezastupiteľnú úlohu. Ide o tieto role:

• Enterprise bean provider
• Application assembler
• EJB deployer
• EJB server provider
• EJB container provider
• System administrator

Schválne som názvy rolí neprekladal, pretože je ťažké nájsť vhodný slovenský ekvivalent, ktorý by presne vystihoval ich obsah. Nechám na vás, či sa rozhodnete akceptovať originálne anglické názvy, alebo si pre seba vytvoríte svoju verziu.

Bean Provider

Tvorca enterprise java beans komponentov je Java vývojár, zodpovedný za riešenie a implementáciu biznis problémov. Spravidla môže vytvárať všetky tri typy EB a mal by sa dobre vyznať v doméne, nad ktorou pracuje. Okrem samotných EB, vytvára bean provider aj potrebné rozhrania na prepojenie jednotlivých komponentov, ďalšie Java triedy potrebné pre EB a XML súbor, ktorý sa použije na vyjadrenie toho, ako budú jednotlivé komponenty prepojené a akým spôsobom budú nasadené.

Bean provider obvykle dodá vytvorené komponenty vo forme ejb-jar súboru, obsahujúceho všetky potrebné položky na integráciu a nasadenie EB do celkovej aplikácie. Samotný ejb-jar je štandardný JAR súbor, obsahujúci okrem spomínaných enterprise beans aj deployment informácie.

Application Assembler

Tvorca výslednej aplikácie je rola, ktorej úloha je poskladať jednotlivé prvky do fungujúceho celku. Zostaviteľ výsledného programu prijíma od jednotlivých bean providerov ejb-jar súbory a skladá z nich výsledný celok. Samozrejme, že to nie je tak jednoduché, ako stavať domčeky z Lega. Application assembler musí presne vedieť, čo robí, musí poznať vytváranú aplikáciu, musí detailne vedieť, ako má čo fungovať a spolupracovať.

Okrem toho, že skladá výslednú aplikáciu z jednotlivých komponentov, upravuje jednotlivé deployment deskriptory príslušných ejb-jar súborov tak, že do nich vkladá takzvané assembly inštrukcie. Typ a obsah týchto inštrukcií závisí od typu konkrétnej EB. Pri menších projektoch alebo organizáciách sú často role Bean Provider a Application Assembler spájané do jedného celku.

EJB Deployer

EJB deployer je zodpovedný za nasadenie jednotlivých ejb-jar súborov, poskytnutých bean providerom alebo application assemblerom, do produkčného, prípadne testovacieho EJB prostredia. Toto prostredie sa skladá z EJB kontajnera a aplikačného servera. Deployer obvykle používa špecifické nástroje, ktoré sú súčasťou EJB kontajnera alebo samotného servera. Je dôležité, aby poznal a chápal prepojenia na externé zdroje, ktoré sú vyžadované jednotlivými EB. Môže ísť o databázové zdroje, JMS komponenty a podobne. Rovnako musí poznať a zobrať do úvahy aj spomínané assembly inštrukcie, obsiahnuté v príslušných deployment deskriptoroch.

Nasadenie EB do reálneho prostredia prebieha obvykle vo dvoch krokoch. V prvom kroku sa použijú špeciálne nástroje na generovanie rôznych pomocných tried, používané EJB kontajnerom na zabezpečenie životného cyklu jednotlivých beanov. Konkrétny výstup týchto nástrojov je závislý od konkrétneho dodávateľa kontajnera, ale vo všeobecnosti je to ďalší JAR súbor.

V druhom kroku sa celý set jednotlivých aplikačných komponentov nainštaluje. Vykoná sa to umiestnením príslušných JAR súborov a tried na presne určené miesto, na ktorom je kontajner schopný tieto komponenty nájsť. Aj tento krok sa obvykle vykonáva pomocou špecializovaného nástroja, záleží na dodávateľovi.

EJB Server Provider

V súčasnosti EJB špecifikácia nedefinuje špecifické požiadavky na dodávateľa servera, označovaného ako aplikačný. Špecifikácia síce predpokladá, že dodávateľ servera a EJB kontajnera je ten istý subjekt, ale nemusí to byť pravidlo. Aplikačný server je zodpovedný za rôzne low-level služby, ako je manažment transakcií, vlákien a podobne.

EJB Container Provider

Ako som už spomenul, EJB špecifikácia striktne nedelí zodpovednosti medzi dodávateľa servera a EJB kontajnera. Necháva to na nich, aby sa dohodli. Vo väčšine prípadov však ide o jeden subjekt. Už som spomenul, aké služby zabezpečuje server – obvykle low-level služby. Kontajner je zasa zodpovedný za manažovanie jednotlivých inštancií beanov, manažment transakcií pre tieto inštancie. Kontajner tiež môže obsahovať deployment nástroj, nástroj na monitorovanie inštalovaných beanov. Tieto nástroje by mali umožňovať reinštaláciu komponentov bez nutnosti reštartovania servera (hot-swap, alebo hot-deploy).

System Administrator

Zodpovednosťou systémového administrátora v tomto prípade je v prvom rade zabezpečiť dostupnosť aplikačného servera a potrebných sieťových služieb. Ďalej je jeho úlohou konfigurácia servera tak, aby bol schopný spracovať momentálne aj predpokladané zaťaženie. Administrátor obvykle využíva rôzne monitorovacie a testovacie nástroje, poskytnuté dodávateľom servera alebo EJB kontajnera.

Zhrnutie

V tomto článku sme si povedali pár informácií o troch základných typoch EJB komponentov. (Budeme sa im ešte venovať oveľa podrobnejšie a vysvetlíme si ich použitie na reálnych príkladoch, v kontexte s ostatnými časťami architektúry.) Ďalej sme si prešli a povedali niečo o šiestich pozíciách (rolách), s ktorými sa môžete pri tvorbe enterprise aplikácií v J2EE stretnúť. A podobne ako vo filme, tak aj v reálnom živote môže jeden človek hrať viac postáv a role sa môžu prekrývať. To platí aj pri vývoji EJB.