JNDI – lokalizácia EJB objektov

V predchádzajúcich článkoch o Java technológii Java Naming and Directory Interface sme takmer nespomenuli, že JNDI je pomerne často využívané v súvislosti s EJB, respektíve ako tieto dve technológie úzko spolupracujú. Tak trochu to bol aj môj zámer, aby ste mali dosť času a priestoru na pochopenie základných princípov bez toho, aby ste boli zaťažovaný detailmi prepojenia s EJB.

Nadišiel teda čas, aby sme si vysvetlili, ako môže klient použiť JNDI na vyhľadanie objektov EJB. Napriek tomu, že séria EJB 2.x – Enterprise JavaBeans 2.x v dobe vydania tohto článku ešte neprešla cez všetky aspekty tejto technológie, procedúra je úplne rovnaká bez ohľadu na to, či ide o session bean alebo entity bean. (Čo sa týka message-driven beanov, tieto typy nie sú dostupné z klientskej strany, takže ani nie je možné spustiť ich vyhľadávanie a získať na ne referenciu).

Zo série článkov o EJB ste sa mohli dozvedieť, že každý enterprise bean dostupný (vystavený) klientovi má takzvaný home interface. Toto rozhranie (v skutočnosti objekt implementujúci toto rozhranie) vystupuje ako tvorca, ako továreň asociovaná s konkrétnou EJB. Klient potom môže túto továreň vyhľadať pomocou JNDI úplne rovnako, ako keby hľadal akýkoľvek iný objekt v rámci JNDI namespace.

Za dostupnosť týchto objektov je zodpovedný EJB kontajner. Obvykle sa tento proces sprístupnenia deje počas štartu kontajnera. Úlohou klienta je získať referenciu na InitialContext a potom sa pokúsiť lokalizovať objekt implementujúci home rozhranie požadovaného beanu. Akonáhle klient vlastní túto referenciu, môže volať metódu potrebnú na získanie vzdialeného prístupu k EJB.

Rozhranie Context definuje dve rôzne lookup metódy, ktoré môžete využiť na lokalizáciu objektov v rámci JNDI služby. Jedna z nich akceptuje ako parameter objektu implementujúceho rozhranie Name a druhá ako objekt triedy String. Obvykle použijete, respektíve máte možnosť vidieť v EJB aplikáciách použitie druhej metódy, pretože to je jednoduchšie. Použitý argument lookup metódy je názov prepojenia v rámci JNDI kontextu, na ktoré chcete vytvoriť referenciu. Ak použijete názov prepojenia, ktoré nie je zadefinované, výsledkom bude vyhodenie výnimky NameNotFoundException.

Pretože lookup metóda rozhrania Context vracia objekt triedy Object, klientska aplikácia musí tento objekt následne pretypovať na požadovaný tvar. V starších verziách EJB úplne stačilo použiť štandardný pretypovací mechanizmus, avšak od verzie EJB 1.1 musí klient najprv použiť statickú metódu narrow, ktorá sa nachádza v triede PortableRemoteObject. Táto metóda overí, či daný objekt môže byť pretypovaný na požadovaný typ objektu. Tento prístup pomáha zabezpečiť portabilitu medzi rôznymi kontajnermi, ktoré používajú RMI-IIOP ako komunikačný protokol. Nasledovný fragment kódu zobrazuje spôsob, ako použiť túto metódu v spojitosti s objektom, ktorý vráti metóda lookup.

Context initCtx = new InitialContext();
Object o = initCtx.lookup(
         „java:comp/env/EnglishAuctionHome“);
EnglishAuctionHome h = (EnglishAuctionHome)
      javax.rmi.PortableRemoteObject.narrow(
      o,EnglishAuctionHome.class );

Tento prístup musí byť aplikovaný na všetky objekty, ktoré vráti metóda lookup ešte predtým, ako vykonáte pretypovanie.

Prístup k runtime prostrediu EJB objektov

Jeden z problémov, na ktoré môžete naraziť pri práci s EJB, je spôsob ako pracovať s rôznymi konfiguračnými parametrami a ich hodnotami. Keďže EJB komponenty nemôžu pristupovať priamo k súborovému systému, musí existovať spôsob ako tieto parametre ukladať a čítať. Skrátka pracovať s nimi.

Pod konfiguračnými parametrami mám na mysli parametre alebo vlastnosti, ktorými môžeme ovplyvniť biznis pravidlá fungovania aplikácie. Dobrým príkladom môže byť maximálny počet rôznych aukcií, do ktorých sa môže zapojiť jeden registrovaný užívateľ. Určite vás napadne niekoľko rôznych spôsobov, ako to urobiť. Napríklad by sme mohli natvrdo zakódovať požadovaný počet do niektorého beanu, lenže to určite nie je práve flexibilné riešenie.

Druhou možnosťou, ktorá vás asi napadne, je uložiť túto hodnotu niekam do databázy. To je už lepšie riešenie, lebo nám dáva viac voľnosti, avšak určite uznáte, že jeho implementácia by nebola úplne triviálna. Ďalšou možnosťou by bolo uložiť tento parameter ako element deployment deskriptora enterprise beanu, takže by bolo možné ho meniť bez nutnosti rekompilácie. Ak to spravíme práve takto, parameter bude dostupný cez runtime prostredie EJB.

Nasleduje ukážka, ako môžeme vložiť tento element do deployment deskriptora. Samotný element má názov <env-entry>:

<env-entry>
 <description>Maximum aukcii na jedneho usera.</description>
 <env-entry-name>maxAuctionsParticipation</env-entry-name>
 <env-entry-type>java.lang.Integer</env-entry-type>
 <env-entry-value>10</env-entry-value>
</env-entry>

Ako som už spomenul, tento element deklaruje parameter, ktorý môže enterprise bean použiť na limitovanie počtu aukcií, na ktorých sa môže užívateľ zúčastniť. Element musí byť umiestnený pod rodičovským elementom definujúcim konkrétny enterprise bean. Samotný EJB objekt potom získa prístup k hodnote tohto elementu pomocou objektu InitialContext, nad ktorým prehľadáme JNDI namespace, pričom použijeme meno hľadaného elementu.

Chcem upozorniť, že spomínaný element je dostupný iba pre ten EJB objekt, pre ktorý bol definovaný. Nie je dostupný pre ostatné enterprise beany. Nasledovný fragment kódu ilustruje spôsob, ako môže metóda enterprise beanu lokalizovať a použiť konfiguračný parameter maxAuctionsParticipation.

public void submitBid(User user,EnglishAuction auction,Bid bid) {
 // Získame menný kontext objektu
 Context initCtx = new InitialContext();
 Context myCtx = (Context)initCtx.lookup(„java:comp/env“);
 // Získame parameter maximálneho počtu aukcií
 Integer maxAuctionParticipate =
(Integer)myCtx.lookup(„maxAuctionsParticipation“)
 if (user.auctionsAlreadyIn < maxAuctionsParticipate.intValue()) {
  // Umožníme pokračovať
 }else{
  // Informujeme usera, že presiahol maximálny počet
 }
}

Použitie systému konfiguračných parametrov runtime prostredia enterprise bean objektov je dobrý spôsob ako prispôsobiť niektoré biznis pravidlá, ktoré môžu byť vyjadrené ako množina parametrov. Na záver dodám, že jednotlivé parametre môžu byť iba z množiny týchto dátových typov: String, Integer, Boolean, Double, Byte, Short, Long, Float, Character.