EJB 2.x – Entity Beans (deklarácia component rozhraní 1.)

V predchádzajúcom článku sme si vysvetlili, že klient pristupuje k entity alebo session beans prostredníctvom ich component rozhraní. Toto rozhranie pozostáva buď z lokálneho rozhrania, remote rozhrania alebo oboch rozhraní súčasne. Keďže klient nemôže pristupovať k EJB priamo, všetky služby, ktoré majú byť pre klientov dostupné, musia byť sprístupnené práve cez component rozhranie.

Metódy deklarované v lokálnom, respektíve remote rozhraní sú obvykle označované ako Bean’s Business Methods (BBM). Keď deklarujete remote rozhranie, tak toto rozhranie musí rozširovať javax.ejb.EJBObject, a podobne pri lokálnom rozhraní je to javax.ejb.EJBLocalObject.

Ako tvorcovia komponentov EJB sa touto podmienkou nemusíte až tak veľmi trápiť (iba ak by ste na ňu úplne zabudli), pretože vy sami nemusíte vytvárať priamu implementáciu component rozhrania. Hoci každý bean musí implementovať biznis metódy deklarované v component rozhraní, nemusí implementovať komplet celé rozhranie. Je totiž na EJB kontajnery, aby zabezpečil kompletnú implementáciu component rozhrania a aby správne delegoval volania na biznis metódy vašej EJB triedy. To znamená, že sa nemusíte starať napríklad o kódovanie metód getPrimaryKey alebo remove, pri vytváraní entity beans (EB). Toto si treba veľmi dobre uvedomiť, pretože sa to môže zdať na prvý pohľad zvláštne.

Enterprise bean implementuje svoje component rozhranie, ale nie doslovne tak, ako ste to doteraz poznali pri klasických rozhraniach v Jave.

Môžete deklarovať entitnú triedu, ktorá bude implementovať local alebo remote rozhranie tým, že uvediete klauzulu „implements“ v deklarácii triedy. Ak tak urobíte, mali by ste vytvoriť prázdnu implementáciu EJBObject alebo EJBLocalObject metód, pretože kontajner nikdy tieto metódy nezavolá (použije vlastnú implementáciu).

Entity Bean z pohľadu klienta

Komponenty EB podporujú široké množstvo rôznych klientov. Najčastejšie môže byť klientom Session Bean, prípadne Message-Driven Bean alebo iná Entity Bean komponenta. Ak je EB vzdialene dostupná, klientom môže byť napríklad desktop Java aplikácia, applet, JSP, servlet, respektíve akákoľvek aplikácia využívajúca CORBA rozhranie. V prípade vzdialených klientov je pohľad na EB vždy rovnaký, nezávislý od typu a umiestnenia klienta. Tento pohľad na EB je definovaný jej remote rozhraním. JSP stránka bežiaca nad Web vrstvou použije na prístup k EB to isté API, ako vzdialená session bean v rámci EJB kontajnera. Toto je charakteristické pre distribuovanú architektúru.

Na rozdiel od vzdialeného klienta, lokálny klient musí byť enterprise bean nachádzajúci sa v tej istej JVM ako EB ku ktorej pristupuje. Tento typ klienta použije lokálne rozhranie na prístup k beanu, ale pohľad na bean už nie je nezávislý na umiestnení klienta. Najväčší rozdiel v porovnaní s remote rozhraním je v tom, že argumenty metód predávané prostredníctvom lokálneho rozhrania sú predávané prostredníctvom referencie a nie vo forme hodnoty.

Napríklad majme EB s názvom Customer, ktorá poskytuje lokálne aj remote rozhranie pre svojich klientov. Obidve rozhrania obsahujú metódu getAddress, ktorá vráti objekt triedy Address. Tento objekt obsahuje niekoľko rôznych reťazcov triedy String. Ak vzdialený klient požiada o objekt Address a nejakým spôsobom modifikuje jeho obsah, vôbec sa to neprejaví u entity Customer. Aby sa však táto zmena prejavila aj na jej úrovni, musí EB poskytnúť nejakú metódu na modifikáciu objektu Address. Inými slovami, každý z nich referencuje iný objekt Address. Na druhej strane, ak spomínanú zmenu vykoná lokálny klient, túto zmenu uvidí aj EB, pretože v tomto prípade obidvaja referencujú už ten istý objekt Address.

Spomínaná skutočnosť sa môže na prvý pohľad zdať ako čistá výhoda, avšak treba si uvedomiť, že ak EB sprístupní objekt takýmto spôsobom, potenciálne sa zbavuje kontroly nad jeho možnou modifikáciou. Napriek tomu, že EB umožňuje súčasne použiť lokálne aj vzdialené rozhranie, obvykle sa to tak nerobí. Ako tvorca beanov sa zrejme vždy rozhodnete pre podporu konkrétneho rozhrania pre prístup, pričom z pohľadu entity beans to zrejme bude lokálne rozhranie. Bez ohľadu na to aký typ rozhrania použijete, po získaní referencie na toto rozhranie môže klient manipulovať s objektom EB niekoľkými spôsobmi. Konkrétne môže klient vykonať nasledovné:

• Volať biznis metódy objektu entity bean (čo je niečo, čo vás bude najviac zaujímať).
• Volať metódu na odstránenie inštancie EB z kontajnera a zmazať objekt z databázy.
• Požiadať o primárny kľúč objektu EB (getPrimaryKey).
• Požiadať o objekt Handle objektu EB (povolené len pre remote klientov).
• Požiadať o referenciu na home rozhranie objektu EB (getEJBLocalHome alebo getEJBHome).

Entity Beans a implementácia biznis metód

Čo sa týka metód, ktoré plánujete implementovať v rámci EB, tak nie je nutné všetky z nich sprístupniť klientovi prostredníctvom rozhrania. Avšak minimálne by ste mali zahrnúť metódy typu get a set, ktoré umožnia klientovi manipulovať s poliami a hodnotami objektu EB. Samozrejme len s tými poliami, ku ktorým má mať klient prístup. Tento princíp je vhodné dodržať najmä pri lokálnom rozhraní. V prípade remote rozhrania je vhodnejšie použiť metódy, ktoré spoja viaceré polia do jednoduchej dátovej štruktúry. Čoho výsledkom je zníženie množstva vzdialených volaní, za účelom získania alebo zmeny stavu EB. V prípade, že klient nebude mať oprávnenie modifikovať spomínané polia, mali by ste implementovať iba metódy typu get.

Z toho, akým spôsobom sa využíva component rozhranie, vyplývajú určité obmedzenia vzťahujúce sa na deklaráciu metód, ktoré toto rozhranie obsahuje. V podstate si môžete vytvoriť akúkoľvek metódu akú potrebujete, len treba dodržať určité pravidlá:

• Žiadna z vašich biznis metód nemôže začínať s reťazcom „ejb“. Takéto metódy používa kontajner na špeciálne účely.
• Všetky metódy musia byť deklarované ako public a zároveň žiadna z nich nemôže byť označená ako static alebo final. Druhá časť vety platí pre všetky rozhrania v Jave.
• Všetky parametre a návratové typy metód v remote rozhraní musia byť legálne RMI-IIOP typy.
• Všetky metódy remote rozhrania musia zahrnúť do deklarácie vyhodenie výnimky java.rmi.RemoteException. Metódy lokálneho rozhrania zase výnimku javax.ejb.EJBException.

Tvorba rozhraní a pomocných tried pre aukčný server

V predošlej časti ste mali možnosť prejsť si jednoduché komponentové rozhranie. V tejto a nasledujúcej časti si vytvoríme sadu rozhraní a pomocných tried, ktoré by bolo vhodné použiť pre náš príklad aukčného servera. Ako prvé si vytvoríme lokálne rozhranie pre EnglishAuction entity bean.

Lokálne rozhranie pre EnglishAuction entity bean (plná velikost, cca 160 kB)

Uvedené rozhranie obsahuje get a set metódy a približne rovnaký počet biznis metód súvisiacich s manažmentom aukcií a s pridávaním ponúk do aukcie. Deklarované metódy sú zrejme iba podskupinou metód, ktoré by bolo nutné implementovať v reálne nasadenom systéme, ale momentálne nám postačujú. Už tak je kód pomerne dlhý, pričom zatiaľ neobsahuje žiadnu logiku.

Súhrn

Jedna z vecí, ktoré si treba určite všimnúť, je, že vytvorené rozhranie ukrýva implementačné detaily pomocných tried Bid a AuctionOffering navrhnutých v procese dizajnu. Pretože trieda AuctionOffering obsahuje iba množstevnú hodnotu, môže byť manažovaná pomocou biznis metód, ktoré pracujú s referenciou na objekt Item a s objektom Integer.

Trieda Bid je o niečo komplikovanejšia záležitosť. Táto trieda nie je prístupná priamo cez EnglishAuction, ale je použitá ďalšia trieda BidView, ktorá má za úlohu prezentovať jednotlivé ponuky klientom. Tvorí teda určitú prezentačnú medzivrstvu. Tento princíp umožňuje systému zobrazovať informácie o jednotlivých ponukách a aukciách bez toho, aby sa vzdal kontroly nad perzistentnými objektmi, ktoré ich reprezentujú.

V článku popísané rozhranie si môžete stiahnuť.