Přeskočit na hlavní obsah

Java EE5 - stand-alone client

V minulém článku jsem nastínil, jakým způsobem se dá vyvíjet enterprise aplikace psaná v Jave. Samozřejmostí je využití různých metodik, podle kterých se řídí celý vývojový tým. Dříve, než mohu řešit rozsáhlé aplikace, musím ovšem míti dostatek zkušeností a znalostí. Já se chci více zaměřit na menší problémy, na které začátečník (stejně jako já) může narazit.

Budu předpokládat, že máte již základní znalosti o tom, co je to EJB, JPA a k čemu jsou enterprise aplikace určeny. Pokud by někdo hledal zdroj informací, osobně doporučuji tento tutoriál. Samotné čtení není nijak náročné. Předpokladem je základní znalost OOP, Javy, popřípadě databázových systémů typu Oracle, MySQL, .....

Osobně jsem si po přečtení celého tutoriálu udělal obrázek o tom, co je to vlastně Java EE 5 a k jakým účelům mohu něco tak rozsáhlého využít. V dnešní době je velký boom webových aplikací, které na nás srší ze všech stran. U samotné Javy se domnívám, že to není zrovna nejjednodušší oblast, kterou by se mělo začínat. Osobně jsem se raději více zaměřil na desktop, kde pomocí Swingu jsem schopen vytvořit "sexy" aplikaci, která bude splňovat základní podmínky. Každému, kdo s Javou začíná, doporučuji právě desktop.

Nyní již k samotné stand-alone aplikaci:

Přístup k EJB se dělí na dvě části:

  • Lokální (@Locale)

  • Vzdálený (@Remote)



O tom, který přístup daná EJB využívá se definuje anotací nad samotným interfacem, který samotná beana implemetuje:
@Remote
public interface UzivateleFacadeRemote {
public List findAll();
}


Rozdíl mezi Locale a Remote je ten, že Remote může volat aplikace, která běží v jiné VM. To se samozřejmě hodí ve chvíli, kdy potřebujeme napsat desktopovou aplikaci, která poběží na klientovi, který má vlastní instalaci JRE. Jiná VM není podmínkou pro běh Remote EJB.
Možná někoho napadne, proč tedy všude nevyužít Remote, když mohu volat tuto EJB kdekoli. Důvodem je výkon. Proto, pokud volám EJB uvnitř glassfishe (aplikační server), využiji k tomu Locale. Dost často mi z toho vychází, že implementuji obě interface na beanu. Navíc je také rozdílný způsob volání Locale a Remote EJB.

To by bylo k business logice. Vytvoříme si jednoduchou EJB, která bude mít Remote interface, kterou poté vystavím (deploy) na glassfish.

Nyní, se pustím do desktopové aplikace, která poběží na klientech a bude vzdáleně volat EJB ze serveru.

Prvním předpokladem je přidání celého EJB projektu v podobě distribuovaného jar souboru do aplikace. Jinými slovy, musí být někde, kde na něj samotná aplikace uvidí. V netbeans stačí do library includovat náš "projekt-ejb". Automaticky se hledá distribuovatelný jar soubor, který se defaultně nachází v adresáři dist.
Dále je potřeba přilinkovat tyto soubory:

  • appserv-admin.jar

  • appserv-deployment-client.jar

  • appserv-ext.jar

  • appserv-rt.jar

  • javaee.jar



Všechny uvedené soubory naleznete v adresáři instalovaného glassfishe (GLASSFISH_PATH/lib).

Tím bychom měli připravenou stand-alone aplikaci k tomu, aby nám byla schopna vzdáleně volat EJB.

Nyní již k samotnému kódu:
Properties properties = System.getProperties();
properties.setProperty("org.omg.CORBA.ORBInitialHost", );
properties.setProperty("org.omg.CORBA.ORBInitialPort", );
Context ctx = new InitialContext(properties);
// po pripravene inicializaci vzdalene zavolam EJB
UzivateleFacadeRemote facade = (UzivateleFacadeRemote) ctx.lookup("RemoteName");


Za a dosadíme vlastní parametry pro volání na server. Výchozím portem je 3700. Pokud testuji aplikaci na localhostu pod stejnou VM, jako mám server, není třeba properties nastavovat. Mohu zavolat InitialContext bez properties. Druhou možností je také nastavit parametricky tyto údaje. Pro další informace doporučuji glassfish: EJB FAQ.

Zapoměl jsem zmínit jednu důležitou věc. Pokud vzdáleně volám EJB, musím někde nastavit JNDI (název, pod kterým je vzdálená aplikace schopna nalézt EJB). Existuje několik možností, buď definovat daný název pomocí XML nebo pomocí anotací.

Záměrně jsem některé názvosloví popsal vlastními slovy. Důvodem je to, že při tak ohromném množství nových výrazů nejsem schopen se ihned orientovat. Také jsem ovšem danou problematiku nepsal stylem step-by-step. Zde by se jednalo o neštastné řešení, zejména ve chvíli, kdy se jedná o rozsáhlejší problematiku. Zde bych doporučil použít metodiku (pokus/omyl) :) Jinými slovy, bez přemýšlení není člověk schopen pochopit daný úkol.

Příště se podívám na JPA a FetchType. K čemu slouží LAZY a EAGER. A jak je to vlastně s defaultní hodnotou mimo a uvnitř glassfishe.

Komentáře

Populární příspěvky z tohoto blogu

Jak si v IT vydělat hodně peněz?

Na začátek by bylo dobré, abych objasnil samotný titulek, který může na někoho působit jako červený hadr. Článek nebude o obecných pravidlech, ale bude vyprávět můj vlastní příběh, na kterém vám zkusím ukázat, jak se dá docílit úspěchu, či alespoň správně nastartovat svojí vlastní kariéru v IT.

I když se z názvu článku dá dedukovat, že se vše bude točit kolem peněz, není tomu tak. Alespoň ze dvou třetin určitě ne. Ale to už předbíhám, pojďme to raději vzít hezky popořadě...

Kdybychom měli mluvit o roce 2017 jako o přelomové době, nejspíše to nebude pravda. I když pro někoho to může být rok plný úspěchů a štěstí v podobě narození zdravých dětí, svatby či první velké lásky, tak z pohledu lidstva se jedná o rok, který jen kopíruje předešlé a v oblasti technologií nás posouvá stejným tempem jako rok předtím.

Jsem naprosto přesvědčen o tom, že i když se současná doba tak nenazývá, tak prožíváme dobu, která jednou bude označena za revoluční, a to zejména díky vynálezu internetu, který je st…

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?
K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují. Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.
I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.
Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě ale…

Jak jsem technologicky postavil startup

Tento příběh pojednává o technologiích, nástrojích a vůbec o všem, co jsem potřeboval k tomu, abych byl schopen, postavit startup na zelené louce.

Každý správný příběh začíná stejně: "Jednou jsem...."

Kapitola první: Nápad
Jednou jsem se setkal s člověkem, který měl nápad na produkt, který se v průmyslu zatím nevyskytuje. I přes prvotní skepsi, kdy jsem si říkal: "Tohle už přeci dávno v průmyslu existuje, ne?", jsem došel ke zjištění, že nikoli.

Tím jsem se dostal ke svému prvnímu poučení. Průmysl je technologicky dost zabržděný. Osobně se domnívám, že těch důvodů, proč tomu tak je, je několik. Za prvé je to fakt, že většina lidí, kteří se pohybují v tomto odvětví jsou často konzervativní a za správné považují pouze léty osvědčené věci. Druhým důvodem je to, že jakákoli změna znamená riziko. Ať už z pohledu finanční ztráty tak i z pohledu stability výroby. No a třetím a nejzásadnějším důvodem je to, že ač zde máme spousty technologických vymožeností, narážíme na to,…