EJB 2.x – Session Beans (Stateful a Stateless)

Na rozdiel od entity beans, ktorých cieľom je manipulovať s perzistentnými dátami, úlohou session beans je vykonávať biznis logiku. Session beans si môžete predstaviť ako rozšírenie klienta. Architektúra EJB poskytuje pre session beans rovnakú podporu transakcií, zabezpečenia a manažmentu súčasného prístupu ako pre entity beans. Konzumentom session beans môžu byť vzdialený klient (napríklad Java Servlet, CORBA klient, enterprise bean umiestnený v inom EJB kontajneri), ale aj lokálny klient umiestnený v tom istom kontajneri.

Typická enterprise aplikácia je navrhnutá tak, že klientom entity beanu je iný bean, a to prevažne session bean. A následne sú to práve vaše session beans, ktoré sú k dispozícii non-EJB klientom. Napríklad v bankovej aplikácii budú entitné triedy reprezentovať zákazníkov a ich účty a session objekty budú realizovať všetky operácie nad nimi. Požiadavka na prevod peňazí z bežného na sporiaci účet konkrétneho klienta bude realizovaná session beanom, ktorý zabezpečí potrebné update operácie nad dvoma entitami reprezentujúcimi spomínané dva účty. Všetka logika týkajúca sa prevodu bude vykonaná v rámci aplikačného servera, v rámci ktorého sú implementované potrebné bezpečnostné a transakčné mechanizmy. Session beans sú teda výborné miesto, kde implementovať logiku aplikačného workflow.

Rovnako ako pri entitnej triede, aj pri session beans interaguje vzdialený klient prostredníctvom remote rozhrania, pričom samotný session bean objekt je implementovaný prostredníctvom triedy EJBObject implementujúcej spomínané rozhranie. V prípade lokálneho klienta je session bean objekt implementovaný cez triedu EJBLocalObject implementujúcej local rozhranie danej session bean triedy. Sessions beans môžeme teda jednoducho popísať nasledovne:

• podporujú transakcie
• sú vykonávané v mene jednotlivých klientov
• v porovnaní s entity beans majú krátku životnosť
• nereprezentujú perzistentné dáta uložené v databáze, ale môžu pristupovať k zdieľaným dátam v mene klienta

Stateless a Stateful Session Beans

Vývojári pracujúci na webových aplikáciách musia riešiť problém, ako spravovať stav komunikácie medzi klientom a vzdialeným serverom tak, aby bola známa aj história tejto konverzácie. Vyplýva to z toho, že protokol HTTP je bezstavový. V prípade session beans je situácia rovnaká. Stateful session bean je poverená tým, aby si pamätala stav všetkých akcií vykonaných daným klientom medzi jednotlivými volaniami metód vykonaných týmto klientom. Z pohľadu špecifikácie EJB je toto primárny stav session bean objektu. Špecifikácia tiež definuje stav, kedy session bean objekt neuchováva stav konverzácie medzi klientom a ním samotným, vtedy sa session bean označuje ako stateless.

Bezstavové session objekty sú z pohľadu EJB kontajneru úplne rovnocenné a po vybavení požiadavky od jedného klienta môžu byť okamžite priradené na vybavenie požiadavky celkom iného klienta. Keďže identita bezstavového session objektu nie je dostupná na overenie klientovi, ten nikdy nevie, či jeho požiadavky obsluhuje stále ten istý session objekt alebo nie. Tento fakt spolu s tým, že klient vykonáva niektoré operácie vo vlastnej réžii, dáva EJB kontajneru určitú flexibilitu.

Anonymita bezstavových session beanov spôsobuje hlavný rozdiel medzi oboma typmi session beanov. Všetky inštancie konkrétnej triedy konkrétneho session beanu sú identické, čo neplatí pre inštancie stateful session beanu. Pretože potom, čo je inštancia stateful session beanu aktivovaná a asociovaná s konkrétnym klientom, je pre tohto klienta unikátna a „zostáva“ s ním, až kým ju klient neodstráni, prípadne kým nie je pasivovaná alebo vyprší jej platnosť. (O životnom cykle stavového session beanu si povieme čoskoro.)

Ako som spomenul, bezstavový session bean nespravuje stav konverzácie s klientom, ale to neznamená, že nemá vôbec žiadny stav. Aj stateless session bean môže mať premenné, respektíve polia inštancie, ktoré môžu mať svoj stav rovnako ako každá iná trieda. Rozdiel je však v tom, že klient nemôže automaticky predpokladať, že tento stav je špecifický a viazaný iba na neho. Pretože keď klient nastaví určitú hodnotu niektorej inštančnej premennej, nemá vôbec žiadnu záruku, že táto hodnota stále platí aj pri zavolaní ďalšej metódy. Je to tým, že ďalšia inštancia session beanu mohla byť použitá na obslúženie následných požiadaviek a tie môžu zmeniť hodnotu spomínanej premennej. Z toho dôvodu by mali byť premenné a polia inštancie stateless session beanu používané iba na uchovanie stavu, respektíve hodnoty, ktorá je spoločná pre všetkých klientov. Napríklad by to mohol byť odkaz na connection factory dátového zdroja, ktorý môže byť použitý bez ohľadu na to, ktorý klient ho použije.

Session beany aukčného systému

V predchádzajúcich článkoch tejto série sme identifikovali a vytvárali entitné a rôzne podporné biznis objekty schopné spravovať perzistetné dáta jednoduchého aukčného systému. Tieto entity sú určitým spôsobom zodpovedné za biznis logiku špecifickú pre koncept, ktorý prezentujú. Avšak medzi nich a klientov je vhodné implementovať vrstvu vo forme session beanov realizujúcich workflow biznis logiku. Začali by sme s AuctionHouse session beanom, ktorý bude implementovať funkcionalitu poskytovania informácií o dostupných aukciách a funkcionalitu prijímania jednotlivých ponúk a ich predávanie korešpondujúcemu EnglishAuction entitnému objektu. Operácie potrebné na vytvorenie a spravovanie aukcií predáme do zodpovednosti AuctionManager session beanu, čím vyčleníme jednotlivé oblasti zodpovednosti. Obe triedy AuctionHouse aj AuctionManager reprezentujú oddelené úlohy (napríklad vytvorenie zoznamu otvorených aukcií, zaregistrovanie ponuky, vytvorenie novej aukcie a podobne), čo znamená, že najvhodnejšie bude využiť bezstavové session objekty.

Spravovať stav konverzácie môže byť veľmi užitočné v prípade, keď je víťazný dražiteľ navigovaný skompletizovať objednávku položky, ktorú úspešne vydražil. V tomto prípade s výhodou využijeme stavovú session beanu AuctionCheckout, ktorá bude spravovať celý workflow uzatvárania objednávky.

Nasledovná tabuľka sumarizuje jednotlivé triedy, ktoré budú predstavovať workflow aukcie.

Tým by sme túto tak trochu teoretickú časť ukončili. V budúcej časti sa pozrieme na to, ako definovať potrebné rozhrania, a vytvoríme si vymenované triedy. Chcel by som ešte upriamiť vašu pozornosť na dokument EJB 2.0 Matrix.pdf, v ktorom nájdete v prehľadnej forme všetky rozhrania, ich metódy a podmienky použitia v špecifikácii EJB 2.0.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.