EJB 2.x – Entity Beans (základné informácie)

Entity Bean (ďalej aj ako EB) reprezentuje perzistentný objekt, ktorý obvykle korešponduje s jedným alebo viacerými (v prípade previazaných tabuliek) riadkami relačnej databázovej tabuľky. Vlastnosť dlhodobej perzistencie je črta, ktorá najviac odlišuje EB od ostatných dvoch typov, pretože napríklad Session Bean dokážu tiež uchovávať stav, ale na relatívne krátku dobu. Ak si odmyslíme totálne poškodenie databázy, EB by mali prežiť aj pád aplikačného servera.

Keďže v podstate každá enterprise aplikácia využíva dáta fyzicky uložené v databázach a veľké množstvo operácií je určené práve na ich získavanie a aktualizáciu, potom vytvorenie kategórie EJB pracujúcej s perzistentnými dátami dáva zmysel. Na druhej strane je pravda, že toto nie je ich jediný účel. Ich najväčšia hodnota spočíva v tom, že predstavujú kľúčové biznis objekty, opakovane využiteľné cez celú enterprise aplikáciu. Obvykle sa jedná o objekty reprezentujúce zákazníkov, objednávky, faktúry, lekárske záznamy, kmeňové záznamy materiálov, dodávateľov a podobne.

Jedna z prvých vecí, ktoré sa musíte naučiť, je, ako sa správne rozhodnúť, či daný biznis objekt má byť reprezentovaný vo forme EB. A následne, čo musíte ako bean provider všetko vykonať, aby ste vytvorili EB vrátane jej rozhraní, podporných tried a deployment deskriptorov.

Entity Beans a implementácia biznis logiky

Ak ste niekedy pracovali s klasickými JavaBeans, tak viete, že obvykle implementujú rôzne GUI elementy alebo jednoduché dátové štruktúry. Viete, že sú primárne zamerané na poskytovanie svojich vlastností triedam, ktoré ich využívajú, a nie na implementáciu dôležitej aplikačnej logiky. JavaBeans sú primárne client-side alebo web-tier komponenty, takže by mali byť používané iba na tento účel.

Entity Beans majú spoločné s JavaBeans to, že zdieľajú myšlienku komponentovo orientovaného vývoja aplikácií. Ale tu sa všetka podobnosť končí. EB respektíve EJB všeobecne sú výlučne server-side komponenty, ktorým je daná podstatne väčšia zodpovednosť ako ich vzdialeným príbuzným. Od EB sa obvykle očakáva, že bude obsahovať biznis logiku vzťahujúcu sa výlučne na dáta, ktoré reprezentuje. Minimálne by sa malo jednať o rôzne validačné techniky, definujúce, akým spôsobom môže byť menený stav objektu EB. Stále musíme mať na mysli, že EB sú znovupoužiteľné objekty, a preto umiestnenie biznis logiky do týchto komponentov znamená, že aj táto logika bude znovupoužiteľná. Toto je inak aj črta správneho objektovo orientovaného návrhu. Čo sa týka ostatnej biznis logiky, táto býva obvykle umiestnená v objektoch typu session bean.

Napriek tomu, že EB často obsahujú netriviálnu biznis logiku, nie vždy je práve toto dôvodom ich existencie. Prítomnosť perzistentného mechanizmu, asociovaného s EB a kontajnerom riadeného mechanizmu viacnásobného súčasného prístupu, býva často dôvodom implementácie EB, ktoré sú významné viac z pohľadu spravovaných dát ako nejakej špecifickej biznis logiky. Služby, poskytované EJB kontajnerom, umožňujú relatívne jednoducho spravovať dáta zdieľané viacerými klientmi. Ak spomenuté možnosti sú životne dôležité pre budovanú EJB aplikáciu, potom práve toto môže byť dôvodom nasadenia Entity Beans.

Entity Beans a závislé objekty

Ako som už spomenul, EB sú perzistentné objekty, ktorým kontajner poskytuje rôzne nizkoúrovňové služby. Avšak často sa stáva, že bean provider potrebuje vytvoriť triedu, ktorá bude tiež perzistentná, ale nevyžaduje spomínané služby. Inými slovami nechceme túto triedu implementovať ako EB. Takéto triedy sa zvyknú formálne označovať ako závislé triedy (dependent class).

Závislé triedy respektíve objekty sú obvykle, aj keď nie vždy, vo vlastníctve jedného z EB objektov. Zoberme si ako príklad entitnú triedu Customer. Objekt tejto triedy môže mať asociované napríklad dva objekty triedy Address. Na jednu adresu pôjde faktúra a na druhú dodaný tovar. V zmysle jednotlivých objektov sú tieto adresy vo vlastníctve zákazníka, a prístup k nim je možný jedine cez objekt nadradený. Ak bude zmazaný objekt Customer, spolu s ním by mali byť zmazané aj jeho objekty Address. Z toho vyplýva, že závislé objekty sú také, ktorých životný cyklus je kontrolovaný inými objektmi.

Závislé objekty môžu byť veľmi jednoduché alebo aj poriadne komplexné, ako niektoré EB. Rozhodnutie, či použiť závislý objekt alebo entitný objekt, závisí na tom, aký typ životného cyklu objektu požadujeme a akým spôsobom bude nutné k objektu pristupovať. Či priamo alebo nepriamo. Aj závislé objekty môžu obsahovať svoj podiel biznis logiky. Každý závislý objekt môže byť asociovaný s jednou alebo viacerými databázovými tabuľkami.

Definovanie Entity Beans pre aukčný server

V článku EJB 2.x – analýza problémovej domény II, v časti Identifikácia objektov aplikačnej logiky, sme zadefinovali niekoľko základných objektov, ktoré by mali splniť naše požiadavky na on-line aukčný server. Išlo o triedy EnglishAuction, AuctionOffering, Item, Bid, Bidder a Address. Vtedy sme si ešte nedefinovali, ktoré z týchto objektov implementujeme ako EB. Teraz je vhodný čas pozrieť sa na rolu každej z týchto tried v systéme a vybrať pre ne vhodný spôsob reprezentácie.

Trieda EnglishAuction predstavuje primárny objekt zodpovedný za správu veľkej časti dát asociovaných s aukciou. Táto trieda je jadrom aplikačnej vrstvy a určite bude musieť implementovať veľké množstvo biznis logiky. Z toho, čo sme si doteraz prešli, je myslím jasné, že trieda EnglishAuction bude reprezentovaná vo forme entity bean. Čo sa týka objektu AuctionOffering, tento nebude patriť do skupiny nezávislých biznis objektov, implementujúcich náročnú biznis logiku. Jeho jedinou funkciou je držať hodnotu poslednej ponuky a správne prepojiť konkrétnu aukciu s predmetom dražby. Objekt AuctionOffering označíme ako závislý objekt.

Triedu Bid už nie je tak jednoduché zaradiť. Na jednej strane má vlastnú identitu, ktorú by sme mohli rozvíjať, ale na strane druhej je vo vlastníctve aukcie (respektíve dražiteľa) a je veľmi tesne spätá s biznis logikou obsiahnutou v procese dražby. Za akceptovanie jednotlivých ponúk a vytváranie príslušných objektov bude zodpovedný objekt EnglishAuction, preto podľa môjho názoru bude vhodnejšie označiť objekt Bid ako závislý.

Jednotlivé predmety určené na dražbu môžu byť priradené ku konkrétnej aukcii, ale na druhej strane by nemali byť ovplyvnené jej životným cyklom. Mám na mysli to, že keď bude konkrétna dražba zastavená a následne zrušená, nemalo by sa to zároveň týkať aj predmetov určených na dražbu. Podľa mňa by mali byť nezávislé. To isté sa týka aj dražiteľov. Z pohľadu aplikácie sú objekty Item a Bidder nezávislé, aj keď pravdepodobne nebudú obsahovať príliš veľa komplikovanej biznis logiky. Z toho dôvodu by bolo vhodné ich implementovať ako entity beans.

Zostala nám už len trieda Address pri ktorej nebude pochýb, že pôjde o závislý objekt. Skúsme si teda zosumarizovať jednotlivé objekty a ich formu reprezentácie do prehľadnej tabuľky:

Ako vidíte, na to, aby ste sa mohli správne rozhodnúť či implementovať konkrétny biznis objekt vo forme EB, je nutné dobre poznať problematiku. Ak ste už rozhodnutie spravili, musíte sa ďalej naučiť, ako reálne vykonať implementáciu a nasadenie vašej EB.