Technologie a nástroje vývoje Java EE aplikací

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

•P

%, \J/

&

Technologie a nástroje vývoje Java EE aplikací DIPLOMOVÁ PRÁCE

Stanislav Hybášek

Brno, jaro 2007

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Tomáš Pitner, Ph.D. 11

Poděkování Rád bych na tomto místě poděkoval zejména svým kolegům Mgr. Petru Matulíkovi a Mgr. Tomáši Páralovi za cenné rady, kterých se mi od nich během realizace této práce dostávalo; RNDr. Tomáši Pitnerovi, Ph.D. za vstřícnost a ochotu, kterou projevil při výběru zadání a během vypracovávání diplo mové práce a v neposlední řadě své přítelkyni Tereze za její podporu a pochopení.

m

Shrnutí Trh si v dnešní době vyžaduje stále větší a větší podporu internetově a intranetově zaměřených aplikací, jejichž výhoda oproti desktopovým řeše ním spočívá v dostupnosti produktu, nezávislosti na konkrétním stroji a platformě a jednoduššímu způsobu sdílení informací. Jedním z nejrozšíře nějším jazyků, které jsou používány k tvorbě takto zaměřených aplikací je Java, konkrétně její enterprise edice 0ava Enterprise Edition, JEE) určená pro tvorbu webových a komplexních aplikací. Tento text si klade za cíl seznámit čtenáře s některými vybranými nástroji a metodikami vývoje a správy JEE aplikací. Práce navazuje na diplomové práce Mgr. Petra Matulíka[ll] a Mgr. Tomáše Párala[12].

IV

Klíčová slova Java, Java 2 SE, Java 5.0, Java EE 5, J2EE, JEE, EJB 3.0, JPA, webové aplikace, Maven 2, Hibernate, anotace, testování, JMeter

v

Obsah 1 2

3

4

5

Úvod 1.1 Vzorová zvebová aplikace Java 5 2.1 Auto (un)boxing primitivních typů 2.2 Generické datové typy 2.3 Výčtové typy 2.4 Rozšíření příkazu for 2.5 Anotace 2.6 Závér JavaEE5 3.1 OblastiJEE 3.2 Vývoj Java EE aplikací 3.2.1 EJB3.0vakci 3.2.2 Definice komponent 3.2.3 Perzistence Hibernate a anotace 4.1 Aktualizace projektu 4.2 Konfigurace 4.3 Mapování 4.3.1 Entitní třída 4.3.2 Atributy 4.3.3 Asociace mezi třídami 4.3.4 Kolekce 4.3.5 Polymorfizmus a dědičnost 4.4 Závér Maven2 5.1 Instalace 5.2 Nastavení 5.3 Základní příkazy 5.4 Struktura 5.5 Závislosti 5.5.1 Potřeba nejnovější verze knihovny

3 4 5 5 6 6 9 10 12 13 13 17 18 18 24 26 26 27 28 29 30 34 37 44 48 49 50 51 54 55 56 57 1

6

7 A B

5.5.2 Správa úschoven 5.6 Pluginy 5.7 Vývoj JEE aplikací Testování 6.1 Druhy testů 6.1.1 Jednotkové testování 6.1.2 Integrační testování 6.1.3 Akceptační testování 6.2 Testovaní výkonu JEE aplikací 6.2.1 JMeter Závěr Vzorové aplikace Elektronický formát této práce

57 58 60 66 66 67 67 67 68 68 71 73 74

2

Kapitola 1

Úvod Jelikož tato práce navazuje a zastřešuje dvě již obhájené diplomové práce a vzorová aplikace, které se budeme v průběhu seznamování se s prezentova nými technologii držet, byla již částečně popsána v těchto dvou předchozích pracech, seznámíme se v následující podkapitole s motivací tvorby právě této doprovodné aplikace. Základní technologie Java je k dispozici ve dvou distribucích. První z nich je Java Platform Standard Edition[6], zkráceně J2SE. My se ve druhé kapitole této práce zmíníme o nejznámějších nových možnostech verze 5.0 této platformy. Třetí kapitola je zaměřena představení druhé distribuce balíku Java, totiž sadě nazvané Java Platform Enterprise Edition[5] a jeji verzi 5 (zkráceně na zývané Java EE 5). Upřesníme si, že pod pojmem Java EE se neskrývá pouze distribuční balík, jak tomu bylo v případě SE verze, ale zmapujeme si jed notlivé oblasti a technologie, které vývoj JEE aplikací zahrnuje. Budeme se zabývat zejména základním prvkem pro tvorbu komplexních aplikací, technologií EJB 3.01. Tímto krokem se tato práce odklání od původního technologického směru (Spring framework + Hibernate), kterých bylo vyu žito pro tvorbu vzorové aplikace. Máme-li ovšem podat dostatečně široké zázemí pro tvorbu Java EE aplikací, je zmínka o novém standardu EJB 3.0 nezbytná. Ve čtvrté kapitole navážeme na jedno z rozšíření Javy 5 - anotace. Anotace představují nové možnosti, které využívá většina moderních frameworků a technologií. V našem případě si popíšeme použití anotací u ORM 2 nástroje Hibernate [2]. Pátá kapitola popisuje způsob práce s technologií Maven 2. Tutoriálovou formou se čtenář seznámí s možností rychlého vývoje aplikace pomocí Mavenu 2 založeného na standardu EJB 3.0. V šesté kapitole se seznámíme s některými možnostmi testování webo1. EJB - Enterprise Java Beans 2. ORM - technika objektově-relačního mapování tříd na databázové tabulky

3

1. ÚVOD

vých aplikací. Kromě přehledu možností, které můžeme v oblasti testování webových aplikací využít, si krátce představíme nástroj určený zejména pro testování výkonu webových aplikací. Sedmou kapitolou pak uzavřeme téma této práce shrnutím nově naby tých vědomostí. 1.1

Vzorová w e b o v á aplikace

Vzorová aplikace, která vznikala v průběhu této a dvou předcházejících diplomových prací, je nazvána SportPortal. Jak sám název napovídá, jde o sportovní portál, jehož vytvořením a spuštěním jsme chtěli pokrýt me zeru v současném trhu s nabízenými sportovními informačními portály. Aplikace totiž ve svém návrhu nabízí správu jakékoliv soutěže či závodu v jakémkoliv sportovním odvětví. Jedinečnost aplikace spočívá v možnosti tvorby uživatelů s administrátorskými právy pro každou datovou entitu systému. Každá soutěž, závod, tým či sportovec může tedy mít svého vlast ního administátora z řad návštěvníků portálu. Tím je nutnost aktualizace dat distribuována mezi více na sobě nezávislých zdrojů. Sportovní portál navíc není primárně určet pro sběr výsledků z našich nejvyšších soutěží (ačkoliv systém je navrhut tak, že může obsahovat i zahraniční a mezinárodní soutěže), ale jeho ambice jsou oslovit zejména zájemce sportovního dění, kteří sledují nižší, např. regionální či okresní soutěže, neboť se domníváme, že sportovní portál s právě tímto druhem informací doposud na našem trhu chyběl. Aplikace je k současnému dni téměř hotova. Zbývá dokončit nově vy víjený modul, který bude agregovat RSS z některých dalších sportovních portálů českého internetu, a grafickou podobu stránek a nasadit aplikaci do ostrého provozu.

4

Kapitola 2

Java 5 Ačkoliv verze 5 1 programovacího jazyka Java byla uvolněna již někdy v prů běhu roku 2004, představíme si krátce některé hlavní rysy vývoje programů v nové verzi, neboť v kontextu této práce je nutné porozumět inovacím, které s sebou revoluční verze 5 přinesla. K jednotlivým novinkám se lze samozřejmě rozepsat mnohem podrob něji, není však záměrem této práce rozebírat detailně specifikaci Java 5 SE, ale pouze definovat některé nejvíce používané rozšíření nové verze jazyka Java. 2.1

Auto (un)boxing primitivních typů

Tato vlastnost nové verze jazyka Java usnadňuje práci vývojářům. Jde o automatický převod mezi primitivními a obalovými typy. Odstiňuje pro gramátory od nutnosti explicitního instanciování objektů při práci s pri mitivními typy. Tedy například volání metod s parametry vyžadujícími objektových typů. (Těmi můžou být typicky dynamické kolekce - třídy implementující rozhraní j a v a . u t i l . C o l l e c t i o n , které akceptují pouze objektovou reprezentaci typů.) Lepší pochopení této vlastnosti zajišťuje následující ukázka. Jednoduchý kód napsaný nejprve v Jávě, verzi 1.4: I n t e g e r v a l u e = new I n t e g e r ( 3 * 5 ) ; i n t i = v a l u e . i n t V a l u e ( ) * 2; Následuje ten samý fragment kódu využívající autoboxingu: Integer value = 3 * 5 ; int i = value * 2; 1. Java 5 - dle zavedeného číslování měla mít tato verze číslo 1.5, ale společnost Sun Micro systems zavedla změnu v číslování, která je odůvodňována snahou vyzdvihnout vysokou úroveň programovacího jazyka. Java je tedy nazývána Java 2 Platform Standard Edition, zkráceně Java 5

5

2. JAVA 5 Důsledkem zavedení této funkcionality je jistě zpřehlednění programo vého kódu a, jak jsme si již řekli výše, usnadnění vývoje aplikací programá torům. 2.2

Generické datové typy

Generické, neboli parametrizované datové typy jsou nejvýznamnější ino vací Javy 5. Jejich použití přesouvá kontrolu nad typovou správností napsa ného kódu z běhu programu, tedy z virtuálního stroje Javy, do překladače. Nesprávné pretypovaní je rozpoznáno již během překladu a chybový pro gram se nám vůbec nepodaří spustit. Obvyklým příkladem použití této funkcionality je práce s dynamickými kontejnery (libovolnou implementací rozhraní j ava . u t i 1. C o l l e c t i o n ) nebo například s poli. Následující ukázka nám názorně způsob a výhodu použití generických typů. Nejprve kód, který projde překladačem Javy 1.4, ale následné spuštění zhavaruje s výjimkou j a v a . l a n g . C l a s s C a s t E x c e p t i o n na posledním řádku při pokusu přetypovat objekt typu I n t e g e r na objekty typu S t r i n g . L i s t l i s t = new A r r a y L i s t O ; list.add(new Integer (2)); String s = (String)list.get(0); Oproti tomuto při použití generických typů můžeme deklarovat typ objektů vkládaných do kontejneru, jak je vidět v následující ukázce: L i s t < S t r i n g > l i s t = new A r r a y L i s t < S t r i n g > ( ) ; list.add(new Integer(2)); String s = list.get(O); Překladač v tomto případě zahlásí chybu při překladu a daný kód nebu deme schopni vůbec moci spustit. Jak již bylo řečeno výše, typová kontrola je v případě použití generických typů přesunuta z běhu programu ve vir tuálním stroji do fáze překladu, samotný virtuální stroj Javy se o používání parametrických typů nedozví, s překladem pracuje stejným způsobem, jako v předchozích verzích. 2.3

Výčtové typy

Absence výčtových datových typů byla v předchozích verzích programova cího jazyka Java jednou z velmi kritizovaných věcí. Jelikož programátorovi 6

2. JAVA 5

přijde použití výběru z několika diskrétních hodnot často vhod, byla nee xistence výčtových typů řešena obvykle statickými proměnnými typu i n t . Díky tomu mohlo být v kódu programu použito přepínače s w i t c h , který rozhoduje o větvi pokračování programu na základě hodnoty parametru jemu předaného. Definice těchto celočíselných proměnných se obvykle na cházely v rozhraní, které třída, která potřebovala využít konstanty, imple mentovala. Tento způsob nahrazení výčtových typů je nesprávný ze dvou důvodů. První z nich je celkový špatný návrh takového řešení, který není v souladu se zásadami správného a efektivního programování 2 . Třída totiž imple mentuje rozhraní aniž by ve skutečnosti opravdu implementovala nějakou funkcionalitu. Pouze tímto způsobem získává nějakou vnitřní strukturu, což ovšem také odporuje výše zmíněným zásadám. Druhým důvodem pro kritiku tohoto řešení byla faktická nepřesnost. Ačkoliv jsou hodnoty nahra zující výčet definované, jsou to stále jen i n t hodnoty a mohou tudíž být v programu nahrazeny jinou číselnou hodnotou. Tento fakt sám o sobě stojí proti vlastní myšlence výběru z výčtu možných hodnot. Joshua Bloch ve své knize [10] popsal, jak by správně měly výčtové typy vypadat a na základě jeho doporučení se od verze 5 v Jávě setká váme s novým typem e num. Pomocí tohoto klíčového slova definujeme výčtový typ a zároveň mu nastavujeme všechny přípustné hodnoty. Pře kladač při svém spuštění vytvoří z tohoto speciálního typu třídu rozšiřující třídu j a v a . l a n g . Enum. To tedy znamená, že se hodnota výčtového typu stává řádným objektem a může být použita například v kolekcích. Na dru hou stranu jde o velmi specifický druh, který je možné v Jávě 5 použít v přepínači s w i t c h . Celou situaci kolem výčtových typů v Jávě ilustrují následující dva pří klady. Na prvním příkladu můžeme vidět typické použití výčtů (náhradu výčtových typů prostřednictvím definice v rozhraní) v dřívějších verzích programovacího jazyka Java. public interface BarvyNaSemaforu { public static final int red = 0; public static final int green = 1;

}

2. Velice kvalitní knihou pro získání znalostí o správném a efektivním programování je bezpochyby kniha Joshua Bloche [10]

7

2. JAVA 5 p u b l i c c l a s s Semafor implements BarvyNaSemaforu {

p u b l i c String getPokyn(int barva) { switch (barva) { case red : return " S t ů j ! " ; case green : return "Volno!"; default : r e t u r n "CHYBA! Neznámá b a r v a ! " ; } } } Následující příklad nám ilustruje elegantní řešení, které poskytuje pro středí Java od verze 5. Všimněte si, že do větve programu uvozené klíčovým slovem d e f a u l t se ve vykonávání programu nemůžeme nikdy dostat, neboťmáme definováno chování pro všechny hodnoty výčtového typu. p u b l i c enum BarvaSemaforu { green, red } public class Semafor { public String getPokyn(BarvaSemaforu barva) { switch (barva) { case red : return "Stůj!"; case green : return "Volno!";

} default : // Sem se ve vykonávání programu již nedostaneme. return "CHYBA!";

} } } Z příkladů uvedených výše je zřejmé, že zatímco v prvním případě se provedení volání g e t P o k y n (5) provede a vrátí nám definované chybové 8

2. JAVA 5 hlášení, ve druhém programu se nám toto stát nemůže, neboťpřípustnými hodnotami argumentu barva jsou pouze hodnoty BarvaSemaf o r u . g r e e n a BarvaSemaforu.red. 2.4

Rozšíření příkazu for

K procházení dynamických kontejnerů bylo až do verze 1.4 nutností použít pomocný objekty typu j a v a . u t i l . I t e r a t o r . Verze 5 přišla s vylepše ním kontinuálního procházení objektů v kolekci. Tímto vylepšením je všeo becně známý cyklus f o r - e a c h . Protože však autoři nechtěli zavádět další nové klíčové slovo, došlo k rozšíření příkazu f o r . Syntaxe příkazu je nyní f o r ( t y p e v a r : a r r a y ) kde a r r a y značí kolekci, nebo pole, v a r je název proměnné, která se budu postupně v cyklu odkazovat na objekty z kolekce a t y p e definuje typ této proměnné. V následujících porovnávacích příkladech je patrné usnadnění, které přichází s tímto rozšířením příkazu. List list = new ArrayListO; list.add(new Integer (1)); list.add(new Integer(2)); list.add(new Integer (3)); int hodnota = 0; for (Iterator i = list.iterator (); i.hasNext(); ) { hodnota += ((Integer)i.next()).intValue();

} Toto je kód jak jej znají programátoři z Javy verze 1.4. Následuje ten samý fragment s vylepšeným for cyklem, který navíc ještě využívá autoboxingu (kapitola 2.1) a generik (2.2). List list = new ArrayList(); list.add(1) ; list.add(2); list.add(3) ; int hodnota = 0; for (Integer i : list ) { hodnota += i;

} Vylepšený for cyklus je jedním z hlavních prvků, který usnadňuje pro gramátorovi jeho práci a výsledný kód je pak čitelnější a přehlednější. Při 9

2. JAVA 5 použití generických datových typů nám navíc přímo překladač kontroluje správnost použitých typů odkazovaných objektů, což v dnešní době moder ních vývojových prostředí se zabudovanými překladači a automatickými překlady znamená velké ušetření času. 2.5

Anotace

Kapitolou o anotacích se již dostáváme blíže tématům, které nás v rámci této práce nejvíce zajímají, tedy technologie a nástroje vývoje Java EE aplikací. Na anotace lze nahlížet jako na metadata, která nám zajišťují přítomnost dodatečných informací v kódu. Tyto informace není snadné zachytit přímo ve vlastním kódu, přesto si programátor - či typicky nějaká technologie přeje zajistit přítomnost těchto metainformací. S podobnou funkcionalitou jsme se mohli setkat již dříve, v případě JavaDoc komentářů. Ty byly gene rovány pomocí open source nástroje XDoclet3, avšak anotace jsou mnohem silnější a mnohem dále. Podívejme se nyní na typickou strukturu anotace. Anotace je možné naprogramovat jako jiné typy v Jávě. Deklarace anotace je dána klíčým slovem @ i n t e r f a c e . Stejně, jako například u klasické třídy, je možné de klarovat anotaci různé přístupy, jako např. p u b l i c. Chování anotace může být definováno tzv. meta-anotacemi. To jsou anotace, které jsou definovány v balíku j a v a . l a n g , a n n o t a t i o n . Z těchto si uveďme dvě nejznámější meta-anotace: •

@Retention - určuje, jak dlouho se budou metainformace udržovat. Jedna z možností je zahodit anotaci ihned po kompilaci, tzn. zpraco vání anotace se provádí ve fázi překladu, nebo si ji může virtuální stroj ponechat přístupnou po dobu běhu programu. V takovém případě se k anotaci přistupuje pomocí reflexe.

•

S T a r g e t - definuje, pro který prvek programu může být anotace použitelná. Díky této meta-anotaci můžeme určit anotaci jako vy užitelnou pro deklaraci typu, konstruktoru, balíku, metody, pole či proměnné. Všechny prvky jazyka, které mohou být anotovány, mají, kvůli nutnosti zjištění metadat, metodu pro čtení pomocí reflexe.

V následující ukázce si demonstrujeme tvorbu velmi jednoduché ano tace, která k deklaraci třídy přidává metainformaci - řetězec definovaný atributem info. 3. http: / /xdoclet.sourceforge.net/

10

2. JAVA 5 import

Java.lang.annotation.*;

@Retention(RetentionPolicy.RUNTIME) @Target(value=ElementType.TYPE) public Qinterface MojeAnotace { String info() default "Defaultní zpráva.";

} Nyní si uveďme příklad třídy, která bude tuto anotaci používat a typický způsob zjištění metadat pomocí reflexe. @MojeAnotace(info="Ahoj

světe!")

p u b l i c c l a s s MojeTrida {

M o j e T r i d a mt = new M o j e T r i d a O ; Annotation a = mt.getClass() .getAnnotation(MojeAnotace.class) ; System.out.println(a) ; Po spuštění tohoto kódu bychom dostali na standardní výstup tuto hlášku: MojeAnotace(info=Ahoj

světe!)

Toto byla opravdu jen jednoduchá ukázka použití anotací. Jak již bylo zmíněno výše, pomocí reflexe je možné přistupovat k anotacím definova ných typů, či poli všech anotací na libovolném prvku jazyka. V praxi se pak na základě metainformací vykonají například přípravné procesy nezbytné pro běh aplikace (to v případě kompilačního obsloužení anotací), nebo se informace využívá k dalšímu obsloužení potřeb programu. Použití anotací na reálných příkladech si ještě ukážeme v kapitole 4. Ačkoliv málokterý programátor bude v budoucnu vytvářet vlastní ano tace, je třeba o tomto prostředku mít jisté základní znalosti. Vývoj s pomocí mnoha současných technologií, které anotace využívají, vyžaduje znalost anotační syntaxe, neboťmnohdy programátor nemá jinou možnost, než na hlédnout do zdrojového kódu anotace, aby zjistil, co přesně ta která definice znamená. 11

2. JAVA 5

2.6

Závěr

V předcházejících kapitolách jsme si vytáhli ty nejzajímavější novinky v oblasti tvorby aplikací v programovacím jazyce Java 5. Pro zhodnocení rozšíření musíme říci, že Sun Microsystems, Inc.4 se při vývoji verze 5.0 nezaměřila pouze na usnadnění vývoje aplikací, ale zabývala se i dalšími dvěma podstatnými směry vývoje jazyka. Prvním z nich je otázka škálovatelnosti a výkonu. Snahou nové verze bylo dosáhnout nižší paměťové náročnosti a celkově vyšší rychlosti aplikací napsaných v Jávě. V tomto du chu byla implementována řada vylepšení na úrovni virtuálního stroje (Java Virtual Machine), ve kterém jsou všechny Java aplikace spouštěny. Druhým podstatným směrem vylepšení týkajících se Javy 5 je oblast monitoringu a řízení běhu aplikací. Pro tuto potřebu byla vyvinuta sada rozhraní, která umožňuje virtuální stroj a aplikace v něm běžící monitorovat a řídit. V rámci standardního balíku Javy mají programátoři k dispozici grafický ná stroj JConsole, který tuto funkcionalitu umožňuje. Ačkoliv o novinkách a vylepšeních, které přibyly v Jávě 5, či aktuálně by se dalo napsat mnohem více, nebylo toto povídání primárním cílem této práce, proto jsme vyzdvihli jen ty pro nás nejpodstatnější vylepšení, které tato verze přinesla.

4. Sun Microsystems, lne je firma, která vyvvíjí jazyk Java a s ním spojené technologie. 12

Kapitola 3

Java EE 5 Java EE je standardizovaná platforma určená pro vývoj přenosných, robustních, škálovatelných a dobře zabezpečených serverových aplikací v jazyce Java. Toto je oficiální definice citovaná z domovnské stránky[5] Java EE1. Jeli kož jde o souhrn standardizovaných aplikačních rozhraní (API), které jsou využívány při vývoji aplikací výše vyjmenovaných vlastností (enterprise aplikací), tedy oblastí velmi širokou, nebudeme se jednotlivým oblastem detailně věnovat, uvedeme si pouze jejich souhrn, abychom si nastínili jak široký pojem představuje Java EE. Protože Java EE je vystavěna nad platformou Java SE2, jejímiž rozšíře ními ve verzi 5 jsme se zabývali v kapitole 2, shrneme si v této kapitole hlavní přínosy revolučních novinek verze 5 na platformě Java EE, nově nazývané Java EE 5 3.1

Oblasti JEE

JEE tvoří široká škála různých standardů a technologií. Tuto širokou oblast lze ale rozdělit do pěti logických celků, jež si nyní představíme. •

Java EE 5 SDK

•

technologie pro tvorbu webových aplikací

•

technologie komplexních (enterprise) aplikací

•

technologie webových služeb

•

technologie managementu a zabezpečení

1. Java EE - Java Platform Enterprise Edition 2. Java SE - Java Platform Standard Edition 13

3. JAVA EE 5

Java EE 5 SDK Java EE 5 SDK (Java EE 5 Standard Development Kit) je tvořen několika částmi, mezi nimiž je podstatnou položkou aplikační server SJSAS (Sun Java Sys tem Application Server) včetně rozšířených distribučních balíčků knihoven jazyka Java EE. Ty ve spojení s knihovnami Java SE tvoří základní výbavu programátora potřebnou pro realizaci JEE projektu. Tvorba webových aplikací Do této oblasti zapadají technologie nezbytné pro vývoj prezentační vrstvy aplikací určených pro použití v internetovém či intranetovém prostředí. Tvoří ji čtyři základní technologie: •

Java Serviet - specifikace programových komponent běžících v rámci servletového kontejneru (speciálního webového serveru). (http://java.sun.com/products/servlets/)

•

JavaServer Pages 0SP) - skriptovací jazyk na bázi Javy (http://java.sun.com/products/jsp/)

•

JavaServer Faces 0SF) - komponentová technologie pro prezentační vrstvu webových aplikací. Jde o MVC 3 webový aplikační rámec po stavený nad Java Serviet a JSP technologiemi. (http://java.sun.com/javaee/javaserverfaces/)

•

JavaServer Pages Standard Tag Library 0STL) - knihovna definující rozšiřující prvky použitelné při práce s JSP technologií. (http://java.sun.com/products/jsp/jstl/)

Komplexní (enterprise) řešení Do této kategorie spadají technologie týkající se zejména aplikační logiky. Můžou to být frameworky poskytující různé funkcionality využívané at'již přímo aplikacemi, nebo aplikačními servery, ve kterých aplikace běží. •

Enterprise JavaBeans (EJB) - komponentová architektura běžící na serveru server-side určená pro snadný vývoj přenosných, robustních aplikací. (http://java.sun.com/products/ejb/)

3. MVC - Model-View-Controller - architektura software, která definuje rozdělení aplikace do tří vrstev : prezentační, aplikační a datovou.

14

3. JAVA EE 5

•

J2EE Connector Architecture - technologie řešící problém propojení mezi aplikačními servery, databázemi a dalšími systémy. (http://java.sun.com/j2ee/connector/)

•

Java Message Service 0MS) API - standard poskytující komponentám JEE aplikací možnost komunikace prostřednictvím zasílání zpráv. (http://java.sun.com/products/jms/)

•

Java Persistence API 0PA) - specifikace byla vyvinuta v souladu se standardem EJB 3.0. Poskytuje model pro perzistenci entitních tříd, založený na principech objektově relačního mapování. (http://java.sun.com/javaee/technologies/entapps/persistence.jsp)

•

Java Transaction API 0TA) - definice standardních rozhraní mezi transakčním manažerem (třída či komponenta starající se o transakční operace) aplikace a transkačním managementem, který poskytuje pro středí využívané aplikací. (http://java.sun.com/products/jta/)

•

JavaMail - aplikační rozhraní poskytující emailové služby. (http://java.sun.com/products/javamail/)

Povšimněme si, že jsme ve výčtu zmínili i specifikace EJB či JPA. Na tuto dvojici se budeme často odkazovat v kapitole 4 věnující se anotacím a nástroji Hibernate. Důvodem k tomu je fakt, že zde zmiňované techno logie tvoří skutečně standard pro vývoj komplexních aplikací. Hibernate a mnoho dalších nástrojů, které tvoří alternativu ke standardizovaným tech nologiím, určených pro vývoj JEE aplikací, dodržují standard definovaný specifikacemi4. Protože model EJB 3.0 je jednou ze základních komponent vývoje Java EE aplikací, dotýkají se změny provedené v této specifikaci programátora mno hem více, než např. implementační aktualizace standardu JTA, či JMS, jež jsou využívány aplikačním serverem. V následující kapitole si ukážeme změny, kterým technologie dostála s příchodem verze 5 jazyka Javy do JEE aplikací. Webové služby Technologie okolo webových služeb zažívá v poslední době svůj velký roz voj. Představují velmi populární směr, jímž se zabývá mnoho odborníků v 4. Paradoxem je, že to byly právě „alternativní" nástroje (zejména Spring, Hibernate), jejichž principy se staly vzorem pro řešení používané technologiemi EJB 3.0 či JPA.

15

3. JAVA EE 5 IT sféře. Použití webových služeb umožňuje využití funkcionality nabízené apli kací jinými systémy Komunikace mezi aplikacemi je založena na standar dech XML a HTTP, což umožňuje platformově nezávislé využití webových služeb. Klíčovými slovy pro technologii webových služeb jsou pojmy SOAP (Simple Object Access Protocol) - protokol, který je používán pro komunikaci mezi aplikacemi, WSDL (Web Services Description Language) - definovaný formát popisu webové služby, a UDDI (Universal Description, Discovery and Integration) - mechanizmus umožňující registraci a vyhledávání webových služeb. Hlavními technologiemi zabývajícími se tvorbou webových služeb v jazyce Java jsou: •

Java API for XML-based RPC 0AX-RPC) - technologie podporuje vývoj webových služeb a webových aplikací založených na specifikaci SOAP verze 1.1 s využitím starší verze jazyka Java (1.4). (http://java.sun.com/webservices/jaxrpc/)

•

Java Architecture for XML Binding 0AXB) - technologie nabízí poho dlnou transformaci XML dokumentů na reprezentaci v jazyku Java. (http://java.sun.com/webservices/jaxb/)

•

SOAP with Attachments API for Java (SAAJ) - specifikace SAAJ de finuje standardní způsob posílání XML dokumentů přes internet, im plementuje tedy protokol používaný pro webové služby, SOAP (http://java.sun.com/webservices/saaj/)

•

Streaming API for XML (StAX) - technologie nabízí možnosti prou dového zpracování XML dokumentů - zpráv. StAX nabízí alternativu ke známějším standarům SAX a DOM. (http://java.sun.eom/webservices/docs/l.6/tutorial/doc/SJSXP.html)

•

Java API for XML Web Services 0AX-WS) - specifikace definuje archi tekturu webových služeb implementovaných v jazyce Java. Společně s technologiemi JAXB 2.0, a SAAJ 1.3 tvoří základní technologie pro tvorbu webových služeb. Specifikace JAX-WS má nahradit doposud používaný standard JAX-RPC. (http://java.sun.com/webservices/jaxws/) 16

3. JAVA EE 5

Management a zabezpečení Poslední „kategorií" je oblast managementu a správy zabezpečení. Ob sahuje specifikace definující spolupráci JEE aplikací s jinými prostředími, např. aplikačními servery. •

J2EE Application Deployment - specifikace definuje standardní roz hraní umožňující zavedení JEE aplikací či komponent do prostředí zajištující běh programů (aplikačních serverů). (http://java.sun.com/j2ee/tools/deployment/)

•

J2EE Management - definice rozhraní zajišťujícího možnost sledování a správy běžící aplikace v systémech zabývající se touto činností. (http://java.sun.com/j2ee/tools/management/)

•

Java Authorization Contract for Containers 0ava ACC) - specifikace definuje možnosti autorizace a bezpečnostní politiky, které aplikační kontejnery využívají. (http://java.sun.com/j2ee/javaacc/)

3.2

Vývoj Java EE aplikací

Technologie, které jsme si vyjmenovali, tvoří základ komplexní platformy pro vývoj enterprise a webových aplikací v Jávě, zvané Java Enterprise Edition. Představme si situaci, kdy stojíme před úkolem vývoje netriviální webové aplikace. Máme v takovém případě možnost volby mezi standardem, který představují výše vyjmenované technologie, a alternativy představující po užití rámců specializujících se na určitou část problematiky, jež vývoj JEE aplikací představuje. Vzorová aplikace, která byla vyvíjena v průběhu všech tří souvisejících publikací (diplomová práce Mgr. Petra Matulíka [11], Mgr. Tomáše Párala [12] a tato práce), vznikala s využitím zmíněných alternativních technologií, jakými jsou aplikační rámec Spring a ORM nástroj Hibernate. Tyto technolo gie, stejně jako mnoho dalších, byly vyvinuty s cílem usnadnit proces vývoje aplikací, neboťpráce se standardními technologiemi znamenala donedávna v mnoha případech nutnost pochopení velmi složitých architektur (případ technologie EJB) a akceptování faktu, že zpětné odezvy programátorů ne byly vyslyšeny vůbec, nebo až s dlouhým časovým odstupem, neboťkaždá změna je doprovázena zdržením, které reflektuje standardizační proces. 17

3. JAVA EE 5 Pokud bychom ale měli programovat opravdu robustní aplikaci, pak bychom zřejmě ocenili podpory, kterou nabízí plný aplikační server a vy užili standardních technologií, které jsou přímo pro takovýto typ aplikací navržené. 3.2.1 EJB3.0vakci Jak jsme si již uvedli, programátorů se nejvíce dotknou změny implemen tované na základě rozšíření Javy 5, které byly aplikovány ve specifikacích Enterprise JavaBeans a Java Persistence Api. Jde totiž o dva stěžejní stan dardy, které tvoří klasický model vývoje JEE aplikací. Specifikace EJB dostála ve verzi 3.0 velmi výrazným změnám, které mají ve svém důsledku usnadnit práci s touto technologií. Předchozí verze (EJB 2.x) velmi často čelila ostré kritice ze stran vývojářů a architektů pro velkou náročnost použití při vývoji. My si v následujících oddílech ukážeme hlavní změny implementované v EJB 3.0. 3.2.2 Definice komponent Ve specifikaci EJB 2.x byly definovány 3 druhy komponent Enterprise Java Beans. •

Session Beans - komponenty provádějící aplikační logiku a poskytující služby klientským voláním.

•

Message-Driven Beans - komponenty, které jsou schopny mezi sebou komunikovat pomocí asynchronního předávání zpráv. Neposkytují možnost volání přímo klientskými aplikacemi.

•

Entity Beans - komponenty reprezentující perzistentní data a jejich chování.

Specifikace EJB 3.0 vypustila entitní komponentu (Entity Bean) a nahra dila ji POJO5 objekty, o jejichž perzistenci se stará specifikace JPA s využitím ORM6 přístupu. Deklarace Session Bean Komponenty Session Beans mohou existovat ve dvou podobách. Bezstavová varitanta (Stateless Session Beans) definuje komponentu, která si neuchovává 5. POJO - Pure Old Java Object (třída vyhovující specifikaci JavaBean) 6. ORM - objektově relační mapování

18

3. JAVA EE 5 žádný svůj vnitřní stav. Komponenta je typicky použita na provedení nějaké akce. Druhou variantou je Stateful Session Beans která byla naopak vyvinuta za účelem uchovávání různých vlastností a tedy k použití v případech, kdy po komponentě požadujeme stavové chování. V tabulce 3.1 uvádíme přehled hlavích rozdílů komponent Session Beans dle specifikace EJB 2.x a EJB 3.0. EJB 2.x Session Beans nutnost deklarace business rozhraní (remote, local) a home rozhraní se spe cifickými požadavkami při určení komponenty na vzdá lený přístup nutnost existence re mote rozhraní při určení komponenty pro lokální přístup nutnost existence local roz hraní komponenta implementuje SessionBean rozhraní, musí tedy deklarovat všechny metody typ komponenty je definován v po pisném konfiguračním souboru kom ponenty obsluha zpětného volání je zajiš ťována metodami deklarovanými rozhraním S e s s i o n B e a n komponenta musí být konfiguro vána pomocí 2 XML popisovačů standardního ejb-jar.xml a druhého specifického pro použitý aplikační kontejner klientský kód vyhledává kompo nenty pomocí JNDI lookup techniky

EJB 3.0 Session Beans pouze business rozhraní

deklarace pomocí @Remote ve třídě

implicitní deklarace, možnost pou žití anotace @Local ve třídě implementuje pouze business roz hraní typ je dán anotacemi @ S t a t e l e s s , SStateful metody můžeme anotovat pomocí SPostConstruct, @PreDestroy, @Init apd. žádná XML konfigurace není nutná, může být použit jeden soubor pro překrytí anotací

vyhledání požadované kompo nenty je zajištěno pomocí anotací a techniky dependency injection aplikačním kontejnerem

Tabulka 3.1: EJB 2.x Session Beans versus EJB 3.0 Session Beans Aby čtenář získal lepší představu, jak velké usnadnění práce s modelem EJB verze 3.0 přinesla, ukážeme si na příkladě deklaraci jednoduché Stateless 19

3. JAVA EE 5 Session Bean komponenty tak, jak nám předepisovala specifikace EJB 2.x a jak nám to nyní předepisuje specifikace EJB 3.0. Každá komponenta, která byla určena pro vzdálené použití, musela být definována dvěma rozhraními. Prvním z nich bylo Remote (popřípadě Local) rozhraní a muselo rozšiřovat j a v a x . e j b .EJBOb j e c t (E jbLocalOb j e c t ) . Toto rozhraní definovalo business metody komponenty a muselo striktně splňovat definované zásady (všechny metody musí být deklarované jako „public", nesmí být „statické" či „final" a další). p u b l i c i n t e r f a c e H e l l o e x t e n d s EJBObject { public String sayHelloO

throws R e m o t e E x c e p t i o n ;

} Druhým rozhraní, které bylo nutné deklarovat, je home rozhraní. Toto rozhraní definuje metody, které jsou použity v klientském programu pro vytvoření, vyhledání či zrušení komponenty. Typicky toto rozhraní obsaho valo alespoň metodu potřebnou k vytvoření komponenty, tak to je vidět na názorné ukázce. p u b l i c i n t e r f a c e HelloHome e x t e n d s EJBHome { p u b l i c H e l l o c r e a t e () throws C r e a t e E x c e p t i o n ,

RemoteException;

} Samotná implementace třídy komponenty musela rozšiřovat rozhraní j a v a x . e j b . Ses s ionBean, přičemž programátor nesměl zapomenout na definici tříd deklarovaných v „business" rozhraní (remote či local rozhraní). p u b l i c c l a s s H e l l o B e a n implements S e s s i o n B e a n { private SessionContext

ctx;

public void setSessionContext(SessionContext t h i s . c t x = ctx;

ctx) {

} public void ejbCreateO {} public void ejbActivate() {} public void ejbPassivate() {}

20

3. JAVA EE 5 public void ejbRemoveO {} public String sayHelloO { return "Hello, world!";

} } K takto vytvořenému kódu nyní ještě programátor musel vytvořit tzv. deployment descriptor, neboli popisovač - XML konfiguraci komponenty. <ejb-jar> <enterprise-beans> <session> <ejb-name>HelloEJB cz.morosystems.ejb.HelloHome cz.morosystems.ejb.Hello <ejb-class>cz.morosystems.ejb.HelloBean <session-type>Stateless Container Budeme-li vycházet ze specifikace EJB 3.0, bude stejný příklad o poznání kratší a přehlednější, jak je vidět z následujícího kódu.

import javax.ejb.Remote; @Remote public interface Hello { public String sayHelloO;

} import javax.ejb.Stateless;

21

3. JAVA EE 5 SStateless public class HelloBean implements Hello { public String sayHello(){ return "Hello, world!";

} } Žádný další konfigurační soubor již není třeba vytvářet. Komponenty jsou vytvářeny a spravovány kontejnerem, ve kterém jsou umístěny. Vy tváření závislostí mezi jednotlivými komponentami či zdroji je také úloha kontejneru, který k tomu používá techniky zvané dependency injection (injektáž závislostí). Pokud bychom chtěli výše uvedenou komponentu publikovat jako sta vovou (stateful), jediná změna oproti uvedenému příkladu by byla v anotaci komponenty. Použili bychom anotaci @ j avax . e j b . S t a t e f u l . Uveďme si ještě rozdíl mezi klientským kódem využívajícím technolo gii EJB dle specifikace 2.x a programovým kódem, který využívá technik nabízených specifikací EJB 3.0. V původní verzi se komponenty musely vyhledávat pomocí JNDI vyhledávání:

public s t a t i c void main(String arg[]) { try { I n i t i a l C o n t e x t c o n t e x t = new I n i t i a l C o n t e x t ( ) ; O b j e c t objRef = c o n t e x t . l o o k u p ( " H e l l o H o m e " ) ; HelloHome homeObj = (StockQuoteHome) PortableRemoteObject.narrow(objRef, HelloHome.class); Hello helloObj = homeObj.create (); System.out.printIn(helloObj.sayHello()); } c a t c h ( E x c e p t i o n ex) { System.out.printIn(ex.getMessage());

} }

Podle specifikace EJB 3.0 se nám o vyhledání postará sám kontejner. Programátorovi stačí pouze deklarovat požadovanou komponentu pomocí anotace j a v a x . e j b . EJB. 22

3. JAVA EE 5

@EJB private s t a t i c Hello helloObj; public s t a t i c void main(String arg[]) { System.out.printIn(helloObj.sayHello ());

}

Deklarace Message-Driven Bean Tvorba komponenty Message-Driven Bean dle specifikace EJB 3.0 se stala také podstatně jednodušší záležitostí. Již není třeba implementovat roz hraní j a v a x . e j b . M e s s a g e D r i v e n B e a n a konfigurovat komponentu po mocí XML popisovacího souboru, podobně jako Session Bean. Zdroje (ano tace @ j a v a x . a n n o t a t i o n . R e s o u r c e ) a reference na jiné komponenty (@ j a v a x . e j b . EJB) mohou být do objektu injektovány stejným způsobem, jako u komponent typu Session Bean. Z následující ukázky klasického vzoru tvorby Message-Driven Bean vi díme, že komponenta je deklarována anotací @ j a v a x . e j b . Me s s ageDr i ven a implementuje rozhraní j a v a x . jms . M e s s a g e L i s t e n e r , t ř í d a tedymusí obsahovat metodu onMe s s age ( j a v a x . jms . M e s s a g e ) , která zajišťuje zpra cování zprávy a reakci na ni.

@MessageDriven public class SampleMessageBean implements MessageListener{ SResource private MessageDrivenContext mdc; public void onMessage(Message msg) {

try { if (msg instanceof TextMessage) { System.out.println(((TextMessage)msg).getText());

} } catch (JMSException e) { e.printStackTrace (); mdc.setRollbackOnly ();

} 23

3. JAVA EE 5

} }

Komponenty typu Message-Driven Bean by dle specifikace neměly po skytovat rozhraní klientskému kódu. Všimněte si, že tento fakt je podpořen absencí business rozhraní, které je pro tento účel používáno. 3.2.3 Perzistence Třetím typem komponent definovaných specifikací EJB 2.xbyla Entity Bean entitní komponenta, která představovala perzistentní data a jejich uchování. Tento přístup byl při vývoji EJB 3.0 radikálně změněn, tvůrci specifikace se do značné míry inspirovali principy perzsitence dat nástroji, které využívají techniku objektově-relačního mapování, mezi nimiž patří rámec Hibernate mezi nejznámější. Současný přístup tedy vychází z POJO objektů, které jsou pomocí ano tací mapovány na tabulky relační databáze. Pro operace nad těmito objekty je definováno rozhraní j a v a x . p e r s i s t e n c e . E n t i t y M a n a g e r , jejíž im plementace zajišťuje interakci s perzistentním kontextem. Jak můžete vidět na následujícím příkladu, tento objekt je injektován do EJB komponenty pomocí anotace @ j a v a x . p e r s i š t e n c e . P e r s i s t e n c e C o n t e x t .

SStateful public class HelloBean implements Hello { @PersistenceContext(unitName="testDB") private EntityManager manager;

Perzistentní kontext musí být nakonfigurován pomocí XML souboru persistence.xml. Příklad takovéto konfigurace uvádíme v následjící ukázce. <jta-data-source>jdbc/ default <properties/>

24

3. JAVA EE 5 Pro úplnost bychom měli ještě opomenout deklaraci entitní třídy Nebu deme se tím však na tomto místě zabývat, protože v kapitole 4 je uvedeno mnoho příkladů zobrazujících, jak by měla entitní třída vypadat, neboť Hibernate dodržuje specifikaci EJB 3.0/JPA a tudíž využívá k mapování anotací definovaných standardem. Závěr Tato kapitola si nekladla za úkol vylíčit detailně všechny možnosti, které nám technologie EJB 3.0 nabízí, ale nastínit způsob vývoje aplikací s pomocí tohoto konceptu. Pro bližší seznámení se se specifikací EJB 3.0, potažmo vývojem JEE aplikací pomocí standardních technologií obecně, odkazujeme čtenáře na tutoriál[4] publikovaný na stránkách firmy Sun Microsystems Inc.

25

Kapitola 4

Hibernate a anotace Tato kapitola se zabývá využíváním anotací na reálném projektu. Veškeré zdrojové kódy uvedené v této kapitole se nacházejí i na přiloženém CD jako součást vzorové aplikace. Jelikož celá aplikace byla realizována v technologiích Spring[8] (viz. diplomová práce Mgr. Petra Matulíka[ll]) a Hibernate[2] (diplomová práce Mgr. Tomáše Párala[12]), i my se budeme v tomto textu již existující navržené struktury držet a budeme vycházet z již existujících zdrojových kódů aplikace, která vznikala v průběhu všech tří souvisejících prací. Rámec Hibernate je nástroj, který programátorovi poskytuje techniku objetově-relačního mapování tříd jazyka Java na tabulky relační databáze. Pro další text je předpokládána alespoň základní znalost této technologie. V případě absence vědomostí odkazujeme čtenáře na výše zmíněnou lite raturu. 4.1

Aktualizace projektu

Pro zavedení mapování entitních tříd pomocí anotací musíme nejprve aktu alizovat a přidat knihovny zajišťující tuto funkcionalitu. Ve vzorové aplikaci je využito následujících knihoven týkajících se problematiky anotací. •

hibernate-3.2.0.ga.jar - standardní prvky rámce Hibernate. Jak lze vidět z názvu knihovny, je použita současná verze 3.2.0.ga.

•

ejb3-persistence.jar - anotace definované standardem Java EE 5, resp. EJB 3.0/JPA.

•

hibernate-annotations-3.2.0.ga.jar - rozšíření Hibernate o podporu ma pování anotacemi. Knihovna přináší jak třídy nezbytné pro konfi guraci mapování, tak vlastní Hibernate anotace, které doplňují stan dardní balík ejb3-persistence.

Všechny knihovny jsou veřejně dostupné na stránkách rámce Hibernate. Knihovna ejb3-persistence.jar je součástí balíku hibernate-annotations. Protože 26

4. HIBERNATE A A N O T A C E

jde o open-source technologie, je možné si tamtéž stáhnout i zdrojové kódy jednotlivých knihoven. 4.2

Konfigurace

Konfigurace perzistentní vrstvy, stejně tak jako celé aplikace, v našem pří padě zajišťuje aplikační rámec Spring. Definice SessionFactory či DataSource se tak nachází v konfiguračních XML souborech Springu. Ten se poté již sám stará o inicializaci příslušných struktur a jejich integraci s aplikačním rámcem. Struktura projektu bude detailněji rozebrána později, v kapitole 5, která se zabývá nástroji usnadňující vývoj aplikací. Poznamejme však, že veškeré konfigurační soubory rámce Spring se v naší vzorové aplikaci nachází v adresáři / src /main / webapp / WEB-INF / spring Pro přehlednost a lepší orientaci mezi jednotlivými částmi systému je celá konfigurace aplikace rozložena do více XML souborů. Pro přidání pod pory mapování pomocí anotací potřebujeme změnit tu část, která se týká nastavení perzistentní vrstvy, v našem případě jde o soubor applicationContext-hibernate.xml Původní nastavení továrny sezení (SessionFactory), která obsahuje infor mace o mapování tříd na tabulky databáze, vypadalo takto: <property name="mappingLocations" value="classpath: /cz/morosystems/sportportal/pojo/*.hbm.xml"/> Podporu mapování anotacemi docílíme zaměněním implementace Sessi onFactory. Jedinou změnu, kterou musíme ve fungující aplikaci udělat, je tedy dosazení a správné nastavení jiné třídy implementující zmíněné roz hraní. Spring vnitřně podporuje Hibernate anotace, jak je vidět z následující ukázky: 27


<property name="annotatedClasses"> <list> cz.morosystems.sportportal.pojo.User

Drobným nedostatkem tohoto řešení je fakt, že musíme explicitně všechny mapované třídy vypsat do konfiguračního souboru. Hibernate při spuštění aplikace (při inicializaci továrny sezení) prochází jednotlivé třídy a jejích zá vislosti uvedené v konfiguraci a pomocí reflexe čte anotace a vytváří spojení tříd s tabulkami, stejně jako je tomu u XML mapování. Touto jednoduchou změnou jsme docílili záměny zajištění OR mapování z XML popisů na anotace. Následujícím krokem je logicky přidání anotací do jednotlivých POJO tříd.

4.3

Mapování

Hibernate zajišťuje automatickou konverzi dat mezi databázovými tabul kami a Java třídami. Aby ale Hibernate mohl tento převod provádět, musí vědět, která tabulka odpovídá dané třídě a jak který atribut správně na databázovou strukturu převést. Pomocí anotací zapisujeme přímo do tříd informace, které pak Hibernate k převodu využívá. Pohybujeme-li se v ob lasti autmatické zajištění perzistence dat, říkáme tomuto způsobu propojení tříd s databázemi mapovaní. V této kapitole se budeme věnovat převážně anotacím definovaných standardem EJB 3.0/JPA, kterého se Hibernate drží. Tyto standardní ano tace jsou umístěny v balíku j a v a x . p e r s i s t e n c e , pro zpřehlednění dal šího textu budeme u všech zmíněných anotací předpokládat toto defaultní umístění, pokud nebude explicitně řečeno jinak. Na některé speciálních ano tace, které vyvinul Hibernate nad rámec standardu a které jsou použity v naší vzorové aplikaci, upozorníme v relevantních částech textu. 28


4.3.1 Entitní třída Jako první si představíme anotace, které určují, že právě třída, ve které jsou použity, je určena k procesu automatické konverze na databázové tabulky. K tomuto účelu existuje anotace @ E n t i t y , která se používá na úrovni de klarace třídy. Další velmi často používaná anotace je definice databázové tabulky, která odpovídá dané třídě. Touto anotací je STable. Kromě parametru name, který je použit k upřesnění názvu tabulky, můžeme ještě nepovinně defino vat například databázové schéma (parametr schema) nebo omezení na jedi nečný výskyt hodnot přes více sloupců (parametr u n i q u e C o n s t r a i n t s ) . Typická deklarace entitní třídy vypadá však následovně: package import import import

cz.morosystems.sportportal.pojo; java.io.Serializable; javax.persistence.Entity; javax.persistence.Table;

@Entity @Table(name="OUSER")

p u b l i c c l a s s User implements S e r i a l i z a b l e { } Jak je patrné ze způsobu zápisu, Hibernate bude objekty třídy User ukládat jako řádky do tabulky OUSER. Poznámka Velmi důležitou informací, kterou si musíme před započnutím práce s ano tacemi uvědomit, je fakt, že současná verze Hibernate anotací neumožňuje, narozdíl od XML definic, mapovat tabulky na rozhraní. Nemůžeme tedy anotovat žádné rozhraní, ačkoliv ve vzorové aplikaci dodržujeme, kvůli složité hierarchii většiny datových struktur, důsledně programování do rozhraní a veškeré vztahy mezi jednotlivými POJO třídami jsou udržo vány taktéž přes rozhraní. Anotacemi jsou proto v hirarchii dědičnosti na nejnižší úrovni opatřeny abstraktní třídy, které zpravidla implementují zá kladní funkcionalitu danou rozhraními ve smyslu zajištění identifikátoru a uchovávání atributů, pro něž rozhraní definuje getter/setter metody. 29


4.3.2 Atributy Deklarování třídy jako entitního objektu určeného pro automatickou per zistenci jsme si tedy objasnili. Nyní se zaměříme na mapování jednotlivých vlastností tříd. Základní atributy Každý atribut či tzv „getter" 1 metoda třídy, je defaultně považována za kandidáta na perzistenci. Hibernate bude tedy hledat anotaci pro takovýto případ a pokud žádnou nenalezne, pokusí se proměnnou asociovat se stej nojmenným sloupcem v dané tabulce. To ovšem někdy může vést k chybě mapování, neboť ne vždy chceme uchovávat každou vlastnost třídy. Existují tři možnosti, jak určit, že daná vlastnost nemá být mapována na žádný sloupec v databázi: 1.

pokud je daný atribut statický, pak je vynechán při zajištění mapování na třídě.

2.

použitím klíčového slova t r a n s i e n t v případě atributů. Jde je stan dardní slovo jazyka Java, které říká, že si přejeme vypuštění daného atributu v případě serializace objektu. Definice by pak vypadala ná sledovně:

p r i v a t e t r a n s i e n t S t r i n g temp; 3.

pokud naše entitní třída obsahuje pomocné metody, pak je můžeme vyjmout z mapováním použitím klíčového slova @ T r a n s i e n t . Ty pické použití tohoto případu vidíme na následujícím příkladu: @Transient public String getFullName() { return name + " " + surname;

} Víme tedy, jak z mapování vynechat atributy, které si nepřejeme uklá dat do databáze. Nyní se podívejme, jak zajistit atypické mapování těchto atributu (např. na neodpovídající názvy sloupců v tabulce či se speciálními požadavky). Existu několik variant, díky nimž se dá ovlivnit anotovanou vlastnost pro perzistenci: 1. název metody začíná písmeny „get", nebo v případě Boolean písmeny „is'

30

4. H I B E R N A T E A A N O T A C E

•

jak už jsme se zmínili výše, neuvedeme žádnou anotaci u atributu ani jeho „getter" metody Pak se předpokládá přítomnost sloupce v tabulce, který bude mít stejný název jako vlastnost. V tomto případě nemůžeme logicky definovat žádná omezení na daném sloupci.

•

@Bas i c - dle standardu základní anotace určena pro mapování atri butů na databázové sloupce. Anotace může být využita např. pro atributy primitivních typů, jejich obalové třídy, časové údaje, tedy ob jekty typu j a v a . u t i l . D a t e a j a v a . u t i l . C a l e n d a r , nebo i jaké koliv jiné třídy implementující rozhraní j a v a l . i o . S e r i a l i z a b l e . Díky dvěma paramterům této anotace můžeme definovat líné na plnení atributu daty z databáze ( f e t c h ) nebo možnost uchovávání „žádné hodnody" - n u l l (parametr o p t i o n a l ) .

•

@Column - anotace je určena pro mapování rozšiřujících atributů. Anotace obsahuje několik nepovinných parametrů, díky nimž jsme schopni definovat např. název sloupce v tabulce (parametr name), jeho délku ( l e n g t h ) , jedinečnost dat ve sloupci (unique) a další.

•

@Version - bezparametrická anotace, jejíž význam spočívá v mož nosti uchování „verze" 2 nějakého objektu. Tato informace může být užitečná při aktualizaci objektu a optimistickém uzamkykání tabulky.

•

@Temporal - rozšiřující anotace definuje, která z možných variant 1.

Java . sql .Date

2.

java . sql. Time

3.

java . sql. Timestamp

má být použita k uchování časového údaje. •

@ Lob - anotace nám dovoluje použití extrémně velkého formátu sloupce. Příkladem takového použití může být mapování sloupců Lob a Clob u databáze Oracle.

Objekty Nezřídka se programátor dostane do situace, kdy potřebuje z několika data bázových sloupců tabulky vytvořit samostatný objekt, i když takto získané údaje jsou neustále logicky spojeny s původní entitou. Možným příkladem 2. verze ve smyslu například časové známky

31


této situace je například adresa. Ačkoliv v databázovém schématu máme ad resu uloženou přímo v tabulce nadřazeného objektu, v objektovém pohledu je nejlepším řešením vytvoření třídy A d r e s a , která v sobě nese adekvátní údaje týkající se tohoto celku. Následující ukázka je vyňata ze zdrojových kódů vzorové aplikace a demonstruje použití anotace @Embedded, jejímž úkolem je právě označení takového objektu, jehož atributy se ukládají přímo do tabulky odpovídající „nadřazenému objektu". package

cz.morosystems.sportportal.pojo.competitors;

@Entity @Table(name="COMPETITOR") public class AbstractCompetitor

implements C o m p e t i t o r {

p r o t e c t e d A d d r e s s a d d r e s s = new A d d r e s s ( ) ;

@Embedded public Address getAddress() { return address;

} public void setAddress(Address address) { this.address = address;

} } Z předchozího příkladu lze vysledovat i typický způsob zápisu anotací v třídách. Tzn. ačkoliv je akceptováno i anotování přímo atributů, častěji se pravděpodobněji setkáte s mapováním přes getter metody. Třída A d d r e s s musí být uvozena anotací @Embeddable. Deklarace této třídy vypadá při bližně takto:

@Embeddable public class Address {

32


...

a t r i b u t y a j e j i c h g e t t e r / s e t t e r metody

...

} Při použití @Embedded na některý atribut ve třídě můžeme defaultní mapování definované v inkriminovaném objektu překrýt pomocí anotace @ A t t r i b u t e O v e r r i d e s . Toto je nám obzvláště užitečné, pokud bychom například již zmíněný objekt A d d r e s s používali jako vlastnost ve více ob jektech, ale u každého bychom atributy potřebovali namapovat na jiné slou pečky v databázi. Primární klíč Zvláštní kapitolkou mezi mapováním vlastností tříd je mapování identifi kátoru třídy. Pro tuto funkci používáme speciální bezparametrovou anotaci @ Id. Doplňující anotací je S G e n e r a t e d V a l u e , díky které můžeme nastavit jednu z možných strategií generování klíčů. Toto duo definované standar dem EJB 3.0 doplňuje Hibernate anotace @org.hibernate.annotations.GenericGenerator, která nám dává ještě větší možnosti při výběru vhodné strategie generování primárních klíčů. Hibernate tak navazuje na definici generátoru, která byla využívaná v původním XML mapování. Pro automatickou tvorbu identifikátorů ve všech POJO objektech naší vzorové aplikace využíváme rozšíření Hibernate generátoru a jako primární klíč používáme 40 znakový řetězec. Takto tedy vypadá definice primárního klíče doprovodné webové aplikace: import import import

javax.persistence.GeneratedValue; javax.persistence.Id; org.hibernate.annotations.GenericGenerator;

private String

id;

@Id @GeneratedValue(generator="system-uuid") SGenericGenerator(name="system-uuid", strategy="uuid") public String getld() { return id;

} public void setld(String id) {

33


this.id

=

id;

}

4.3.3 Asociace mezi třídami Pojmem asociace mezi třídami rozumíme stav, kdy v jedné třídě, resp. objektu, držíme odkaz na jiný objekt, přičemž objekty nejsou na perzistentní úrovni ukládány do jednoho řádku jedné tabulky. Situace, která vznikne, vypo vídá o dvou různých stavech, které odpovídají různým způsobům zápisu v databázi a tedy i definování pomocí anotací. Asociace one-to-one Vztah one-to-one značí, že objekty, které si na sebe vzájemně drží reference (jde tedy o obousměrnou asociaci3), nemůžou být již odkazovány jinými objekty v rámci stejné proměnné. Překlad názvu asociace nám přesně od povídá stavu, který nastane. Objekt může být odkazován právě jedním objektem určitého typu, se kterým má definovanou asociaci. Tento stav vy stihuje anotace SOneToOne. Ta může obsahovat několik parametrů, které si nyní popíšeme. •

c a s c a d e - definuje operace, které se kaskádově provádí i na aso ciovaných objektech v případě vyvolání operace na řídícím objektu. P o d p o r o v a n ý m i o p e r a c e m i j s o u ALL, MERGE, P E R S I S T , REFRESH,

REMOVE dle standardu EJB 3.0/JPA. •

f e t ch - rozhoduje o líném vytváření asociovaných objektů z databáze (objekt se vytváří až v momentě, kdy jej v aplikaci potřebujeme)

•

mappedBy - v případě obousměrné asociace je tento parametr použit ve třídě, která je v daném vztahu podřízená. Definuje vlastnost řídícího objektu, která je spojena s objektem.

•

o p t i o n a l - definuje, zda je možné mít daný objekt nedefinovaný null.

•

t a r g e t E n t i t y - parametr definuje třídu, která je ve skutečnosti im plementací anotované vlastnosti. Tento parametr je velmi užitečný v

3. Ačkoliv v pokročilých technikách lze docílit i jednosměrného mapování one-to-one asociace.

34


případě používaní rozhraní, Hibernate ve své aktuální verzi neumí pracovat s anotacemi na rozhraních. Asociace one-to-one může být použita ve třech možných podobách. První z nich popisuje standardní situaci - dva objekty, které mohou být v daný okamžik odkazovány pouze jedním objektem druhé strany. Řídící entitu ve takového vztahu jedna ku jedné označujeme anotací @ Jo i nCo lumn, u které je pro nás v tuto chvíli nejzajímavější parametr name. Fyzicky se totiž tato asociace ukládá do databáze tak, že v tabulce řídícího objektu vztahu musí existovat sloupec, cizí klíč, který ukazuje na položku do tabulky spravované třídy. Parametr name nám určuje tento databázový sloupec. Následující ukázka pochází ze vzorové aplikace, kde je tento vztah po užit pro definici sportovní soutěže a hracího systému. public abstract class AbstractSportEvent implements SportEvent { @OneToOne(cascade=CascadeType.ALL, targetEntity=BasicPlayingSystem.class) SJoinColumn(name="PLAYING_SYSTEM_ID") public PlayingSystem getPlayingSystem() { return playingSystem;

} Jak bylo již zmíněno dříve, ve vzorové aplikaci kvůli složité struktuře POJO objektů velmi často používáme programování do rozhraní, proto se nám hodí zejména parametr t a r g e t E n t i t y , s jehož pomocí jsme schopni přenést definice anotacemi na následující úroveň hierarchie objektů, abs traktní třídy. V předchozí ukázce jsme si názorně ukázali definici řídícího objekt ve vztahu jedna ku jedné. Nyní si ukažme protějšek této asociace, díky které vzniká podřízený objekt vztahu. public abstract class BasicPlayingSystem implements PlayingSystem { @OneToOne(mappeďBy="playingSystem" targetEntity=AbstractSportEvent.class)

35


public SportEvent getSportEvent() return sportEvent; }

{

Drouhou často využívanou možností asociace one-to-one je použití pri márního klíče řídícího objektu. Anotací @PrimaryKey JoinColumn nahra díme použitou anotaci @ JoinColumn, čímž říkáme, že vztah mezi dvěma objekty je dán shodným primárním klíčem entit, které se asociace účastní. Dalším důsledkem tohoto způsobu mapování je fakt, že podřízený objekt už nemusíme nijak anotovat. Máme totiž již dostatečné informace pro vy tvoření vztahu jedna ku jedné. Výše uvedený příklad by s použitím tohoto způsobu definice vypadal následovně: public abstract class AbstractSportEvent implements S p o r t E v e n t { @OneToOne(cascade=CascadeType.ALL, targetEntity=BasicPlayingSystem.class) @PrimaryKeyJoinColumn public PlayingSystem getPlayingSystem() { return playingSystem; }

public class BasicPlayingSystem implements PlayingSystem { public SportEvent getSportEvent() { return sportEvent;

} Třetí možnou cestou, jak definovat one-to-one vztah je využití spojo vací tabulky. V tom případě bychom u řídícího objektu využili anotaci @ Jo i n T a b l e , o které si povíme více, jakmile se dostaneme k jednosměrné vazbě one-to-many nebo many-to-many vztahu. Tento způsob definice aso ciace jedna ku jedné není totiž příliš rozšířený a existuje jen jako alternativní řešení pro případy, jako je např. nemožnost změny existujících tabulek v databázi. 36


Asociace many-to-one Vztah many-to-one značí, že inkriminovaný objekt může být asociován s více než jedním objekem daného typu. Tomuto vztahu odpovídá anotace @ManyToOne a v praxi je využívána jako protějšek vztahů, kde jeden z objektů spravuje kolekci jiných objektů. Odpovídá to tedy přesně filozofii použitého výrazu. Mnoho objektů typu, ve kterém je použita tato anotace, může být ve vztahu s jedním objektem, který pomocí anotace definujeme. Anotace @ManyToOne je velmi podobná anotaci SOneToOne, o které jsme mluvili v předchozích odstavcích. Obsahuje shodné parametry až na jednu odlišnost - nemá definován parametr mappe dBy. Principiálně by totiž nebylo ani možné takový parametr použít způsobem, který zajišťovala oneto-one asociace. Typické použití mapování mnoho ku jedné můžeme vidět v následující ukázce, která je vyňata ze vzorové aplikace a značí vztah mezi sportovními soutěžemi a sportovním odvětvím (druhem sportu). Ve spor tovním odvětví může existovat celá řada soutěží. Jako příklad si uveďme fotbal jako typ sportu a 1. a 2. ligu jako zástupce sportovních soutěží.

p u b l i c abstract c l a s s A b s t r a c t S p o r t E v e n t implements S p o r t E v e n t { @ManyToOne SJoinColumn(name="SPORTBRANCH_ID") public SportBranch getSportBranch() return sportBranch;

{

}

4.3.4 Kolekce V předchozích podkapitolách jsme si ukázali, jak správně namapovat vazbu s objektem, jehož referenci drží anotovaný objekt. Nyní postoupíme o krok dopředu a budeme se věnovat problematice správného mapování kolekcí objektů. Existují dva druhy vztahů, které můžeme při mapování kolekcí vy užít. První z nich, vztah typu many-to-one,je protějšek asociace, kterou jsme si ukázali v předchozí kapitole. Tou druhou je pak použití oboustranných kolekcí, tedy vztah many-to-many. 37


Asociace one-to-many Mapování one-to-manyJe používáno třídou, která si drží další objekty v ko lekci. Taková třída bývá obvykle vlastníkem asociace, tzn. při perzistentních operacích se vyvolané akce provádějí i na závisejících objektech umístěných ve spravované kolekci. Anotace odpovídající tomuto druhu asociace se nazývá @OneToMany a pro její použití existují dva různé scénáře, přičemž anotační mapování a potažmo i databázové schéma tabulek odpovídají použité variantě. Jednosměrné vazby Prvním možným způsobem mapování jsou tzv. jednosměrné vazby, tedy stav, kdy bychom v anotované kolekci objektů neuchovávali referenci na objekt, jenž si drží entitu ve své kolekci. Tohoto stavu můžeme docílit dvojím použitím anotace @OneToMany. Změny odráží různou databázovou strukturu, která musí být použita při mapování. Jednosměrné vazby a spojení přes cizí klíč Použitím této anotace ve spolupráci s anotací @ JoinColumn říkáme rámci Hibernate, že reference na objekt, který drží dané objekty v kolekci, jsou uloženy jako cizí klíče přímo v tabulce odpovídající objektům z kolekce. Sami jistě cítíte, že právě použitá definice je těžkopádná a velmi špatně pochopitelná, ukažme si proto celou situaci na příkladu. Použijeme nám již známou asociaci sportovního odvětví a kolekce soutěží. p u b l i c c l a s s S p o r t B r a n c h implements S e r i á l i z a b l e { @OneToMany(fetch=FetchType.LAZY, targetEntity=AbstractSportEvent.class) @JoinColumn(name="SPORTBRANCH_ID") public Set<SportEvent> getEvents() { return e v e n t s ; }

U takto mapované kolekce nemůže být ve třídě A b s t r a c t S p o r t E v e n t žádná reference na třídu S p o r t B r a n c h . Asociace je tedy uchovávána pouze v jednom směru a to u objektu, který drží kolekci. Co se týče databázové 38


struktury, tak u takto definovaného mapování by tabulka SPORTEVENT (od povídá objektu A b s t r a c t S p o r t E v e n t ) musela nutně obsahovat sloupec SPORTBRANCH_ID cizí klíč d o tabulky SPORTBRANCH.

Jednosměrné vazby a spojení přes asociativní tabulku Druhým, preferovanějším způsobem, jak vytvořit jednosměrnou vazbu, je na hrazení anotace @ JoinColumn anotací @ J o i n T a b l e . Jak napovídá sám název, anotace zaručuje (jednosměrné) spojení mezi objekty v kolekci a vlastníkem této kolekce pomocí asociativní (spojovací) tabulky Jak by výše uvedená třída po aplikaci tohoto přístupu vypadala, můžete vidět v násle dujícím příkladu. public class SportBranch implements Seriálizable { @OneToMany(fetch=FetchType.LAZY, targetEntity=AbstractSportEvent.class) @JoinTable(name="SPORTBRANCH_HAS_SPORTEVENT", joinColumns=@JoinColumn(name="SPORTBRANCH_ID"), inverseJoinColumns=@JoinColumn(name="SPORTEVENT_ID")) public Set<SportEvent> getEvents() { return events;

} Atributy anotace @ J o i n T a b l e jsou dle pojmenování všeříkající. Pomocí parametru name definujeme název asociativní tabulky, j o i n C o l u m n s od povídá sloupci určenému pro definici objektu S p o r t B r a n c h - cizí klíč do tabulky asociované s objekty tohoto typu a parametr i n v e r s e J o i n C o l umn s nám definuje sloupec určený pro uchování cizích klíčů do tabulky odpoví dající třídě S p o r t E v e n t . Obousměrné vazby Pro případ obousměrných vazeb bychom i asociovaný objekt museli anotovat tak, jak jsme si uvedli v předcházející kapitole. Na dalším příkladu je zobra zeno mapování stejných tříd, jako v předchozích případech, tentokrát však zachycuje obousměrnou vazbu, jejíž používání je dle doporučení Hibernate upřednostňováno před asociacemi jednosměrnými. public class SportBranch implements Seriálizable {

39


@OneToMany(fetch=FetchType.LAZY, mappedBy="sportBranch", cascade=CascadeType.ALL, targetEntity=AbstractSportEvent.class) @org.hibernate.annotations.Cascade({ org.hibernate.annotations.CascadeType.ALL, org.hibernate.annotations.CascadeType.DELETE_ORPHAN}) public Set<SportEvent> getEvents() { return events;

} public abstract class AbstractSportEvent implements SportEvent { @ManyToOne SJoinColumn(name="SPORTBRANCH_ID") public SportBranch getSportBranch () { return sportBranch;

} Takto definované mapování je skutečně použité v naší vzorové aplikaci. Všimněme si, že mapování obsahuje i rozšířené anotace typické pro Hi bernate. Anotace @ o r g . h i b e r n a t e , a n n o t a t i o n s . C a s c a d e je použito ve spojení se standardní EJB 3.0/JPA definicí kaskádového chování vyvo laných operací a její význam je nám znám z předchozích poznatků spoje ných s rámcem Hibernate (viz. související diplomová práce Mgr. Tomáše Párala[12]). Řekli jsme si, že obvykle je vlastníkem asociace objekt, který spravuje ko lekci. Někdy nám ovšem nemusí tento přístup vyhovovat a my potřebujeme zacházet s objekty uvnitř kolekce jako s vlastníky daného vztahu. Ve vzorové aplikaci využíváme několikero mapování s tímto „opačným přístupem". Jako příklad si uveďme mapování tříd S i g n P o s t a G u i d e P o s t C a t e g o r y , obě z balíku cz . m o r o s y s t e m s . s p o r t p o r t a l .po j o . První třída z uve dených reprezentuje položku katalogu seznamu odkazů, kterým je právě třída G u i d e P o s t C a t e g o r y . Systém definování odkazů byl v aplikaci vytvořen kvůli potřebě zajistit zobrazení relevantních odkazů spojených s určitým sportovním odvětvím 40


a regionem. Pro náš účel je důležitější objekt, který zastupuje samotný od kaz, před jeho kategorií. Při vytváření nebo editaci odkazu (poté, co objekt přiřadíme některé kategorii) nám totiž tento způsob rozvržení vlastnických práv asociace dovoluje volat Hibernate operaci - zápis do databáze - pouze jednou, na samotném editovaném objektu. Zbytek zajistí již sám Hibernate. Kdybychom kolekci anotovali výše uvedeným typickým způsobem, mu seli bychom po samotném uložení objektu-odkazu explicitně aktualizovat i kategorii. Vlastní použití anotací uvádíme v následujícím příkladě, který je ukáz kou mapování právě pro zmiňovaný příklad. p u b l i c c l a s s S i g n P o s t implements S e r i a l i z a b l e { @ManyToOne @JoinColumn(name="GUIDEPOST_ID", insertable=false, updatable=false) public GuidePostCategory getGuidePostCategory() return guidePostCategory;

{

}

p u b l i c c l a s s G u i d e P o s t C a t e g o r y implements @OneToMany(fetch=FetchType.LAZY) @JoinColumn(name="GUIDEPOST_ID") @org.hibernate.annotations.OrderBy( clause="SIGNPOST_ORDER") public List<SignPost> getSignPosts() return s i g n P o s t s ; }

Serializable{

{

Všímavý čtenář jistě zpozoroval změny, které zajišťují „převrácený pří stup" k určení vlastníka kolekce. Tvoří je na straně objektu S i gnP o s t nově definované parametry i n s e r t a b l e = f a l s e a u p d a t a b l e = f a l s e u ano tace @ JoinColumn. Zjednodušeně řečeno, těmito parametry říkáme, že ne chceme využít implicitního nastavení vlastníka asociace. Na druhé straně, při mapování kolekce ve třídě G u i d e P o s t C a t e g o r y , musíme znovu po užít anotaci @ JoinColumn s názvem databázového sloupce s cizími klíči tak, jak bychom ji použili u objektu S i g n P o s t při standardním přístupu. 41


V jazyce Java existují tři základní typy dynamických kontejnerů, které můžeme využít. Jsou jimi implementace rozhraní S e t , L i s t a Map z balíku j a v a . u t i l . V tomto příkladě jsme potřebovali mít možnost definovat i pořadí, v jakém se budou odkazy ve finále zobrazovat. Proto jsme jako dynamickou kolekci použili implementaci kolekce L i s t . Standardní anotace @ j a v a x . p e r s i s t e n c e . OrderBy nám sice dovo luje mapovat uspořádané kolekce, ale pouze tím způsobem, že si v pa rametru anotace určíme sloupec, podle kterého chceme kolekci implicitně uspořádat. Tento přístup našemu záměru nevyhovuje, proto jsme zvolili alternativní variantu, kterou nabízí Hibernate. Pomocí anotace @org.hibernate.annotations.OrderBy můžeme pro uspořádání určit databázový sloupec (parametr c l a u s e ) , ve kterém se bude uchovávat index objektu v kolekci. Pro úplnost uvedeme ještě příklad mapování implementace rozhráni j a v a . u t i l .Map. Standard EJB 3.0/JPA nám poskytuje anotaci pro ma pování map, je jí anotace SMapKey s jediným parametrem name, který nám definuje název vlastnosti - klíč mapy. Protože ale vývojáři Hiber nate nebyli spokojeni s tímto jediným poskytnutým nástrojem pro mapo vání map (existuje několik scénářů, podle kterých se perzistence neprovede podle všeobecného očekávání - např. vlastnosti reprezentující klíč v mapě), byly vyvinuty vlastní anotace @ o r g . h i b e r n a t e . a n n o t a t i o n s .MapKey a @org. h i b e r n a t e . a n n o t a t i o n s .MapKeyManyToMany jejichž použí vání je doporučeno při práci s mapami v rámci Hibernate. Použití takovéto anotace by bylo velmi podobné předchozímu příkladu, pouze v anotace @OrderBy by byla nahrazena anotací SMapKey. Takové hoto mapování je v přiložené aplikaci použito na jednom místě, ve třídě A b s t r a c t S p o r t E v e n t R e s u l t Item v balíku cz.morosystems.sportportal.pojo.events.results. Tam naleznete v případě zájmu typické mapování mapy. Asociace many-to-many Posledním typem asociací, se kterým se seznámíme, je many-to-many aso ciace. Vystihuje situaci, kdy objekty obou stran mohou být drženy v kolekci druhé strany. V databázi tomuto stavu odpovídá typická asociativní (spojo vací) tabulka, kde se záznam skládá z primárních klíčů obou zúčastněných entit. Jak již jistě tušíte, anotace vystihující tento stav se nazývá @ManyToMany a svými možnými parametry se nikterak neliší od asociace @ManyToOne (stejná dispozice parametrů je logickým důsledkem faktu, že z pohledu 42


objektu, který drží kolekci, je použití těchto anotací do jisté míry shodné). Pro názornou ukázku si vyberme situaci, která ve vzorové aplikaci za chycuje vztah mezi soutěžemi (rozhraní S p o r t E v e n t ) a účastníky soutěží (rozhraní C o m p e t i t o r ) . Soutěžící - aťjiž jde o celek, nebo jednotlivce - se můžou účastnit více různých sportovních soutěží, přičemž do každé soutěže se hlásí více soutěžících. public abstract class AbstractSportEvent implements SportEvent, Serializable { @ManyToMany( fetch=FetchType.LAZY, cascade=CascadeType.PERSIST, CascadeType.MERGE, targetEntity=AbstractCompetitor.class) @JoinTable( name="COMPETITOR_ATTEND_SPORTEVENT", joinColumns=@JoinColumn(name="COMPETITOR_ID"), inverseJoinColumns=@JoinColumn(name="SPORTEVENT_ID")) public Set getCompetitors() { return competitors;

} Takto namapovaná kolekce je námi označena jako řídící, tedy vlastník vzájemného asociativního vztahu mezi oběma stranami, které se asociace účastní. Toho jsme docílili zejména anotací @ J o i n T a b l e , která definuje aso ciativní tabulku (v našem případě COMPETITOR_ATTEND_SPORTEVENT) pro určení vazby mezi objekty typu S p o r t E v e n t a C o m p e t i t o r . Vazba druhé strany, tedy z pohledu třídy A b s t r a c t C o m p e t i t o r vy padá následnovně:

p u b l i c abstract c l a s s A b s t r a c t S p o r t E v e n t implements S p o r t E v e n t ,

Serializable {

@ManyToMany( fetch=FetchType.LAZY, mappedBy="competitors", targetEntity=AbstractSportEvent.class) public Set<SportEvent> getSportEvents() { return s p o r t E v e n t s ; 43


}

Všimněte si absence anotace @ Jo i n T a b l e - asociativní tabulka je defi nována pouze na řídícím objektu asociace, naopak v této anotace definujeme parametr mappedBy, který nám určuje, která vlastnost řídícího objektu se týká definované vazby many-to-many. Přítomnost tohoto parametru je ne zbytná, protože ve třídě A b s t r a c t S p o r t E v e n t nebo v některém jejím potomku může existovat další kolekce objektů typu C o m p e t i t o r . 4.3.5 Polymorfizmus a dědičnost Polymorfizmus a dědičnost jsou klíčové objektové vlastnosti, jejichž pod chycení moderními systémy zajišťujícími perzistenci dat je pro objektový programovací jazyk Java naprostou nezbytností. EJB 3.0/JPA specifikace definuje 3 způsoby, jak pomocí anotací mapovat polymorfizmus a dědičnost. 1.

polymorfní mapování podle strategie hierarchie tříd mapovaných na jednu tabulku

2.

polymorfní mapování podle strategie podtřídy mapované do jedné tabulky

3.

polymorfní mapování podle strategie konkrétní třídy hierarchie ma pované na jednu tabulku

My se budeme v dalším textu zabývat zejména prvními dvěma mož nostmi, protože ty jsou využívány ve vzorové aplikaci. U třetí strategie si pouze objasníme způsob takového mapování. Pro namapování polymorfizmu existuje několik anotací. Tou základní je anotace @ I n h e r i t a n c e s parametrem strategy. Tento parametr může nabývat některé ze tří hodnot odpovídající výběru způsobu mapování po lymorfizmu výčtového typu j a v a x . p e r s i s t e n c e . I n h e r i t a n c e T y p e . Anotace týkající se mapování polymorfizmu a dědičnosti používáme na úrovni deklarace třídy. Strategie mapování hierarchie tříd na jednu tabulku Všeobecně zřejmě nejvyužívanější způsob používání polymorfního mapo vání, které nám Hibernate nabízí. Ve vzorové aplikaci přiložené k této práci 44

4. H I B E R N A T E A A N O T A C E

používáme právě tohoto způsobu polymorfního mapování na většině enti tách, které mapujeme na databázové tabulky K základní anotaci @ I n h e r i t a n c e (pro niž zvolíme pro tento pří pad strategii I n n e r i t a n c e T y p e . S INGLE_TABLE), musíme ještě defino vat diskriminátor 4 - databázový sloupec, který bude uchovávat informaci o typu entity Pro tyto účely použijeme anotaci @ D i s c r i m i n a t o r C o l u m n a její parametry name (název sloupce) a d i s c r i m i n a t o r T y p e (definice jednoho z povolených typů diskriminačního slouce - jsou jimi S t r i n g , I n t e g e r a Char). A konečně třetí anotací, kterou používáme pro mapo vání této strategie, je anotace @ D i s c r i m i n a t o r V a l u e , která nám určuje samotný identifikátor entity My si pro ukázku této strategie vybereme jednu z mírně komplikova nějších struktur POJO objektů, kterou jsou třídy implementující rozhraní cz . m o r o s y s t e m s . s p o r t p o r t a l .po j o . C o m p e t i t o r . Celou hierarchii můžete vidět na obrázku 4.1. Jelikož, jak jsme již poznamenali ze začátku této kapitoly (str. 29), sou časná verze Hibernate anotací neumožňuje anotovat přímo rozhraní, defi nujeme polymorfizmus na další úrovni v hierarchii - abstraktní třídě, která implementuje základní funkcionalitu danou rozhraním. Deklaraci této abs traktní třídy základní abstraktní třídy popisuje následující ukázka. @Entity @Table(name="COMPETITOR") @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @DiscriminatorColumn(name="COMPETITOR_TYPE", discriminatorType=DiscriminatorType.STRING)

p u b l i c abstract c l a s s AbstractCompetitor implements C o m p e t i t o r {

Základní definici entity tedy máme, ukažme si nyní, jak vypadá mapo vání dvou konkrétních tříd, jejíž instance se budou do tabulky ukládat. @Entity @DiscriminatorValue("INDIVIDUAL") public class SimplelndividualCompetitor extends AbstractlndividualCompetitor {

4. diskrimininátor - identifikátor, díky němuž budeme schopni rozlišit, o jaký typ entity se ze struktury dané dědičností jedná.

45


O Competitor

O Tea m Cam petitor

O In d ivid u a IGpm petitor

AbstractCompetitor

AbstractTeamCompetttor

AbstractlndividualCompetitor

Z Sim pleTea m Com petitor

Sim pleln d ivid u a IC o m petitor

Obrázek 4.1: Hieararchie Competitor

@Entity @DiscriminatorValue("TEAM") public class SimpleTeamCompetitor extends AbstractTeamCompetitor {

Jak je vidět z příkladu, mapování již finálních tříd, určených k perzistenci do deklarované tabulky, je velmi jednoduché a není třeba je více popisovat. Zmiňme se však o abstraktních třídách, které třídy rozšiřují. Tyto abstraktní třídy, kromě toho, že rozšiřují základní třídu A b s t r a c t C o m p e t i t o r im plementují ještě každá své rozhraní, které definují vlastnosti jednotlivých 46


potomků v hierarchii. Aby byly zohledněny i anotace (např. další atri buty) vyskytující se v abstraktních třídách I n d i v i d u a l C o m p e t i t o r či TeamCompetitor, musíme tyto abstratní třídy mapovat pomocí anotace @MappedSuperclass. Ukázku mapování takové abstraktní třídy (ale i ja kéhokoliv předka, který není přímo entitou) vidíme v následující ukázce. @MappedSuperclass public abstract class AbstractIndividualCompetitor extends AbstractCompetitor implements IndividualCompetitor {

Strategie mapování podtříd na jednu tabulku Ve vzorové alikaci se vyskytuje i jeden případ využívající tento způsob polymorfizmu. V XML deklarovaném mapování odpovídá této situaci pou žití elementu < j o i n e d - s u b c l a s s > , pomocí kterého definujeme potomka a jeho rozšiřící atributy. Tento přístup spočívá ve vytvoření doplňující ta bulky, která je používána pro nové atributy definované potomkem. Pomocí anotací docílíme tohoto mapování poměrně snadno. Ukažme si to názorně na příkladu. @Entity @Table(name="SIGNPOST") @Inheritance(strategy=InheritanceType.JOINED) p u b l i c c l a s s S i g n P o s t implements S e r i a l i z a b l e {

Tímto zápisem mapujeme třídu S i g n P o s t na tabulku SIGNPOST. Všim něte si strategie definované jako I n h e r i t a n c e T y p e . JOINED (parametr s t r a t e g y anotace @ I n h e r i t a n c e ) . Toto mapování nám dává možnost namapovat potomka základním způsobem, který již známe. @Entity @Table(name="SIGNPOST_SHOP") public c l a s s SignPostShop extends SignPost {

Objekt třídy S i g n P o s t S h o p se po provedení operace perzistence uloží do tabulek SIGNPOST a S IGNPOST_SHOP přičemž záznamy budou spojeny 47


primárním klíčem (primární klíč tabulky SIGNPOST_SHOP je zároveň cizí klíč do tabulky SI GNP OS T). Při použití tohoto způsobu jsme schopni rozšiřovat aplikaci, resp. hierar chii objektů o další potomky, aniž bychom museli jakkoliv měnit strukturu původní databázové tabulky Strategie mapování konkrétní třídy hierarchie na tabulku Jak napovídá již samotný název, tento způsob mapování polymorfizmu spočívá v tvorbě nová tabulky na každou implementaci definovaného roz hraní. Využijeme-li této strategie při mapování naší objektové struktury, Hibernate zajišťuje perzistenci stejným způsobem, kterého bychom dosáhli použitím elementu < u n i o n - s u b c l a s s > v XML deklaraci. Tento přístup jistě najde své využití, nicméně není tak rozšířený, jako předcházející dvě strategie, které jsme si popsali. 4.4

Závěr

V průběhu této kapitoly jsme se seznámili s reálným použitím anotací v praxi. Novým trendem vývoje webových aplikací je minimalizace počtu konfiguračních souborů. Použitím mapování pomocí anotací jsme doká zali, kromě snížení počtu potřebných XML souborů, zvýšit přehlednost a usnadnit orientaci v perzistenčním procesu. Pro zjištění způsobu perzis tence dané entity jsme totiž ušetřeni od hledání jeho deklarací a otevírání dalších souborů. Množina anotací, které jsme si představili, bohatě pokrývá potřeby při vývoji středně velkého systému. Uvedli jsme si i některé speciální rozší ření standardních anotací, jejichž autory jsou programátoři týmu Hibernate. Přesto existuje mnoho dalších rozšiřujících anotací a speciálních možností, na jejichž pokrytí nemáme v této práci prostor, proto čtenářům se zájmem o prohloubení znalosti Hibernate anotací doporučujeme zejména referenční příručku[3] publikovanou na stránkách Hibernate, která posloužila i jako zdroj informací pro tuto kapitolu.

48

Kapitola 5

Maven 2 Maven je nástroj umožňující jednoduchou správu projektu. Maven definuje standardní strukturu projektu a vykonává nejen funkcionalitu sestavení aplikace, automatizaci spouštění testů či nasazení aplikace, ale i generování reportů o postupu vývoje či sestavení webových stránek projektu. Maven 2 představuje další logický krok v systémech starajících se o management projektu. Podíváme-li se na způsoby, které byly - a doposud jsou - využívány v minulosti, uvědomíme si, že základem tomuto typu nástrojů byl program Make, který usnadňoval překlad aplikace. Dalším krokem pro automatizovaný překlad a sestavování aplikací byl projekt Ant1, který se dodnes těší velkému zájmu a je rozšířen v mnoha vývojových komunitách. Projekt Maven l 2 přišel s revoluční myšlenkou uchovávání knihoven ve veřejných a lokálních úschovnách (repozitory), což dovoluje další distribuci projektu bez knihoven, které jsou v projektu využívány. Maven představil koncept objektového modelu projektu (projed object model - POM), který vy cházel z existence jediného souboru (project.xml) definujícího celý projekt. Rozdíly mezi použitím technologie Ant a Maven 1 nebyly však zas až tak velké, neboťMaven dovoloval tvorbu souboru maven.xml s definicemi cílů obdobné struktury, která byla podporována nástrojem Ant. Maven 2 je postaven čistě na bázi POM. Tzn. projekt je definován jedi ným souborem (pom.xml) a veškeré informace o způsobu práce s projektem jsou uchovávány v tomto souboru formou definic pluginů. Maven 2 bývá velmi často označován jako „systém pro spouštění pluginů", neboť každý „maven příkaz" vyvolá spuštění definovaného pluginů a vykonání úkonů definovaných tímto pluginem. Z tohoto důvodu vzniká potřeba konfigurace některých pluginů v pom.xml.

1. http://ant.apache.org/ 2. http://maven.apache.Org/maven-l.x/

49

5. MAYEN 2

V následující ukázce můžete vidět základní strukturu Maven 2 konfigu račního souboru projektu - pom.xml:

< p r o j e c t xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2 001/XMLSenema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0 cz.morosystems.thesis <artifactId>TestApp <packaging>jar l.0-SNAPSHOT Testovaci projekt http://adresa.projektu <dependencies> <dependency> junit <artifactld>junit 3 . 8 . K / v e r s i o n > <scope>test Detailní strukturu pom.xml nabízí přímo stránky projektu[l], konkrétně http://maven.apache.org/pom.html. Kromě zmíněných webových stránek projektu doporučujeme čtenářovi se zájmem o technologii Maven 2 publikaci Better Builds with Maven[9]. 5.1

Instalace

Prvním krokem pro využití nástroje Maven pro správu projektů je jeho instalace v lokálním prostředí. Jelikož jde o open-source projekt, spustitelná verze software je široké veřejnosti k dispozici přímo na stránkách projektu[l]. Po zvolení umístění a rozbalení aplikace zbývá pouze doporučený krok přidání adresáře se spustitelnými soubory ($ {MAVEN_HOME} / b i n ) do systémových cest. Tato akce usnadňuje spouštění základního příkazu mvn kdekoliv v systému. Po prvním spuštění příkazu mvn se v systému vytvoří speciální ad resář, ten je typicky umístěn v „home adresáři" přihlášeného uživatele 50

5. MAVEN 2

({home p r i h l á s e n é h o u ž i v a t e l e } / .m2), a v něm soubor využívaný k nastavení specifických lokálních atributů (settings.xml)a adresář využívaný jako lokální repozitory ( r e p o s i t o r y ) . 5.2

Nastavení

Jelikož maven má podporovat snadný vývoj aplikací, je nezbytné, aby byl použitelný v případě týmového vývoje. Ve chvíli, kdy definujeme konfigu raci jednotlivých pluginů (např. použití webového kontejneru) v centrál ním souboru pom.xml, který musí být dle svého zaměření v případě použití některého verzovacího systému3 umístěn v repozitory, potřebujeme mít mož nost, jak ovlivnit některá nastavení v závislosti na použitém prostředí. K docílení dosazení platformově závislých nastavení do projektu mů žeme využít v pom.xml (ale i kdekoliv jinde, jak si ukážeme níže) proměn ných, které jsou při zpracovávání nahrazeny odpovídajícími hodnotami. Proměnná má tvar $ { k l í č . proměnné} a jak jsme si již naznačili, může být využita v libovolném konfiguračním souboru aplikace i v samotném pom.xml. Jako příklad si uveďme obsah konfiguračního verzovaného sou boru conf i g . p r o p e r t i e s , který je v aplikaci umístěn v adresáři /src/main/resources/ a je využíván pro tvorbu aplikace a běh aplikace: hibernate.connection.username=${db.connection.username} hibernate.connection.password=${db.connection.password} mail.smtp.host=${mail.smtp.host}

Abychom mohli využít nahrazování proměnných u jednotlivých konfi guračních souborů, musíme v pom.xml označit složku obsahující dané zdroje tak, jak je naznačeno v následující ukázce: <project> 3. verzovací systém umožňuje správu verzí projektu. Nejrozšířenějšími nástroji tohoto typu jsou CVS - http://www.nongnu.org/cvs/ a subversion - http://subversion.tigris.org/

51

5. MAYEN 2

true src/main/resources true src/test/resources Tímto nastavením definujeme, že nahrazení parametrů má být prove deno ve všech standardních zdrojích aplikace a zdrojích užitých pro testo vání. Existuje několik způsobů, jak nakonfigurovat správný obsah použitých proměnných, my si ukážeme nejpoužívanější možnosti. •

definice proměnných při volání příkazu mvn - proměnnou můžeme definovat pomocí přepínače ,,-D", nahrazení výše uvedených použi tých proměnných by tedy vypadalo následovně: mvn i n s t a l l " - D d b . c o n n e c t i o n . u s e r n a m e = s p o r t " "-Ddb.connection.password=sport" "-Dmail.stmp.host=smtp.netlife.cz" použití dodatečného souboru definujícího proměnné pro daný pro jekt - pro uchování hodnot použitých proměnných můžeme použít „properties" soubor, který umístíme v nejvyšší úrovni projektu (stejné umístění jako pom.xml) a učiníme jej „neverzovaným". Tento přístup je použit i u doprovodné vzorové aplikace, náš soubor se jmenuje application.proper ties a abychom jej mohli využít, musíme jej definovat v pom.xml: 52

5. MAYEN 2 <project> application.properties Soubor application.properties sám o sobě je standardním „properties" souborem: db.connection.username=sport db.connection.password=sport mail.smtp.host=smtp.netlife.cz •

definice proměnných v uživatelském konfiguračním souboru settings.xml. V kontextu tohoto souboru se musíme zmínit o maven profilech, pro tože v souboru settings.xml je členění založeno právě na profilech. V každém profilu můžeme definovat různé proměnné, či zdroje a volbu profilu provádíme b u ď implicitním nastavením, nebo použitím pře pínače ,,-P". Struktura souboru settings.xml odpovídající výše použitým proměn ným by vypadala následovně: <settings> <profiles> <profile> sportportal <properties> sport sport

53

5. MAVEN 2

<mail.smtp.host> smtp.netlife.cz sportportal •

využití globálního konfiguračního souboru settings.xml. Jde o tentýž způsob definování proměnných, jako jsme si uvedli v předchozím pří padě, pouze platnost není omezena na jednoho uživatele. Soubor se nacházív{instalační adresář Maven}/conf/settings.xml.

5.3

Základní příkazy

Maven definuje základní fáze procesu managementu aplikace, kterým od povídají i základní příkazy, které nabízí. Následující přehled pokrývá nejpo užívanější fáze „životního cyklu" definovaného správou nástrojem Maven. 1.

validace - mvn validate - validace, zda jsou všechny definice v pro jektu správné (např. správně utvořený pom.xml) a zda jsou všechny definované závislosti dostupné.

2.

překlad - mvn compile - překlad zdrojových kódů aplikace. Defaultním umístěním všech výstupů produkovaných nástrojem Maven je adresář t a r g e t v nejvyšší úrovni projektu.

3.

spuštění testů - mvn test - spuštění testů umístěných v adresáři urče ném pro testy.

4.

sestavení aplikace - mvn package - sestavení cílového distribučního formátu. Mezi nejčastěji používané formáty patří jar (standardní Java aplikace) a war (webová aplikace).

5.

integrační testy - mvn integration-test - sestavení aplikace a vystavení aplikace do prostředí, které je v pom.xml definováno pro integrační testy. 54

5. MAYEN 2

6.

ověření validity sestavené aplikace -mvn verify - ověření sestaveného distribučního balíčku.

7.

instalace do repozitory - mvn install - sestavení aplikace a její nahrání do lokální repozitory. Tento proces je vhodný zejména při použití aplikace jako závislosti v jiném projektu.

8.

nasazení aplikace - mvn deploy - nasazení sestavené aplikace do defi novaného prostředí.

Každá fáze, v pořadí, v jakém jsme si je uvedli, závisí na fázi předchozí. V praxi to znamená, že při volání mvn package musí nejprve proběhnout překlad aplikace a spuštění definovaných testů. Mezi základní příkazy se ještě řadí následující dvě volby, které nebylo možné spojit s žádnou fází. •

mvn clean - smazání všech výstupů generovaných pluginy systému Maven.

•

mvn site - vygenerování webových stránek projektu.

Toto byl výčet těch nejznámějších fází, samotný cyklus obsahuje ještě doplňující fáze jimiž jsou zejména rozdělení některých fází na pre-íáze a posř-fáze. 5.4

Struktura

Maven definuje základní strukturu aplikace, kterou defaultně předpokládá a kterou doporučuje používat. Dodržovat standardní strukturu není po vinností, umístění zdrojových adresářů se dá nastavit pomocí elementu < b u i I d / > v pom.xml, nicméně je výhodné na nabízenou strukturu projekty převést a dodržovat ji, protože při používání Maven 2 jakožto nástroje za jišťujícího správu managementu našich projektů, budeme mít všechny naše projekty stejně vystavěné a budeme moci plně využít nabízených výhod, jakými jsou například generování kostry nového projektu. Z těchto (a demonstativních) důvodů je i naše vzorová aplikace vysta věna na struktuře definované standardem Maven 2. Umístění zdrojové kódů aplikace se standardně předpokládá v adre sáři s r c / m a i n / Java, umístění konfiguračních souborů a jiných zdrojů je s r c / m a i n / r e s o u r c e s . Stejné použití předpokládá i testovací adresář, 55

5. MAVEN 2

s r c / t e s t . U webových aplikací je nezbytnou součástí adresář obsahu jící kontext standardní webové aplikace napsané v Jávě. Tomuto adresáři odpovídá lokace s r c / m a i n / w e b a p p . Výše vyjmenovaná struktura je zachycen i na následujícím náhledu struktury kostry typické webové aplikace spravované nástrojem Maven 2, v našem případě struktury vzorové aplikace, Sportovního portálu. sportportal | — src | | -- main I I I — Java | | | — resources | | ' — webapp | ' — test | | — java | '-- resources |-- application.properties '-- pom.xml 5.5

Závislosti

Každý netriviální projekt, zejména webová aplikace, závisí na použití ne malého počtu knihoven třetích stran. Maven, jak jsme si řekli v úvodních odstavcích této kapitoly, přišel s revolučním řešením distribuce knihoven pomocí veřejných úschoven (repozitory). Principem této myšlenky je zanesení požadované závislosti v objekto vém modelu aplikace (pom.xml). Nástroj Maven v první fází cyklu spouštění příkazů (viz. kapitola 5.3) zjistí, zda má v lokální repozitory všechny po žadované závislosti. Pokud se některá požadovaná knihovna v repozitory nevyskytuje, zajistí její stáhnutí a instalaci do lokální úschovny. Tímto způ sobem si Maven vytváří vlastní repozitory, takže při dalším volání některého z příkazů nástroje Maven je použita knihovna umístěna na lokálním disku. Následující fragment převzatý z pom.xml naší vzorové aplikace názorně ukazuje způsob, jakým jsou závislosti definovány. <project> <dependencies> <dependency> springtramework

56

5. MAYEN 2 <artifactld>spring 2.0-m3 Umístění jednotlivých knihoven aťjiž v lokální či veřejné repozitory je dáno specifikovanými atributy závislosti. Pro tento uvedený případ by byla knihovna umístěna v následující struktuře úschovny: /springframework/spring/2.0-m3/spring-2.0-m3.jar Další usnadnění definování závislostí na knihovnách přináší různé pluginy jednotlivých vývojových prostředí, které tímto způsobem nabízí i „kli katí nástroje" určené pro hledání a přidávání knihoven do projektu. 5.5.1 Potřeba nejnovější verze knihovny Výše popsané řešení nám nemusí vždy vyhovovat, protože někdy pracu jeme s projekty, jejíž vývoj je aktuální záležitostí a knihovny s novými ver zemi jsou publikovány poměrně často. Pro takový případ se nám nabízí po užití označení verze dané závislosti jako „SNAPSHOT". Toto klíčové slovo zajišťuje, že se Maven pokusí vždy vyhledat aktuálnější verzi knihovny, než je ta, kterou disponuje v lokální repozitory. 5.5.2 Správa úschoven Maven 2 má v sobě zabudovanou podporu standardní repozitory: http://repol.maven.org/maven2/ Protože jde ale o standardní repozitory, nemůže pokrývat požadavky všech programátorských komunit všude po světě. Je například téměř ne možné dostat nějaký vlastní framework do této repozitory. Z tohoto důvodu vzniká mnoho dalších úschoven nabízejících další knihovny. Mnoho firem a komunit využívá možnosti definice vlastních, interních úschoven se svými projekty. Ve chvíli, kdy nám vznikají nové úschovny, potřebujeme i způsob, jak říct Mavenu, že má tyto úschovny prohledávat. K tomuto účelu slouží již zmiňovaný konfigurační soubor settings.xml. Zanesení nové repozitory je snadnou záležitostí: 57

5. MAVEN 2

<settings> <profiles> <profile> sportportal java.net http://download.java.net/maven/K/url> legacy sportportal Poznámka k uvedené repozitory O repozitory uvedené v předchozím příkladě si řekněme, že řeší doposud velmi palčivý problém s knihovnami podléhajícími licenčním ochranným podmínkám. Tento problém se týkal zejména některých z dílny firmy Sun Microsystems, který se tímto krokem uvolnil k distribuci takových kniho ven.

5.6

Pluginy

Jak jsme si již řekli dříve, technologie Maven 2 je postavena na spouštění pluginů. Veškeré příkazy, tedy i ty základní, jsou ve skutečnosti napro gramované pluginy, které Maven spouští. Při prvním spuštění jakéhokoliv příkazu můžeme tedy pozorovat, že Maven stahuje knihovny, které sám potřebuje k provedení požadovaného příkazu. Existuje mnoho standardních i rozšířených pluginů. Pro přehled základ ních pluginů si uveďme odkaz na kapitolu obsahující souhrn standardních podporovaných pluginů 4 na stránkách projektu, ostatní bohužel nejsou cen tralizovány na jedné přehledné stránce a programátor musí často hledat, než narazí na plugin, který splňuje jeho kritéria. Tento fakt o současné ne4.

http://maven.apache.org/plugins/

58

5. MAYEN 2

dostatečné dokumentaci a nabízené podpoře je nejsilnější zbraní odpůrců technologie Maven 2. Protože podpora existujícíh pluginů zdaleka nepokrývá všechny po žadavky, které mohou v různých situacích nastat, vždy existuje možnost tvorby vlastního pluginů řešící naše potřeby. Stěžejní třídu každého plu ginů představuje komponenta nazvaná Mojo, třída rozšiřující abstraktní třídu o r g . a p a c h e .maven . p l u g i n . A b s t r a c t M o jo. Ta definuje potřebu implementace metody e x e c u t e () a vyžaduje znalost speciálních anotací, jež jsou zaznamenávány v javadoc komentářích. Problematika tvorby vlast ních pluginů sahá nad rámec této práce a zájemci si ji můžou osvojit studiem tutoriálu 5 vystaveného na stránkách projektu. Pluginy, které chceme využít v projektu a potřebujeme nakonfigurovat jejich podporu v objektovém modelu projektu, jsou v souboru (pom.xml) de finované v elementu
, jak je naznačeno v následujícím úryvku z pom.xml naší vzorové aplikace.

<project> <artifactId>maven-compiler-plugin <source>l.5 l.5

Jak je jistě zřejmé přímo z ukázky, tento plugin definuje použití verze 1.5 jazyka Javy 0avy 5.0) při překladu.

5.

http://maven.apache.org/guides/plugin/guide-java-plugin-development.html

59

5. MAYEN 2

5.7

Vývoj JEE aplikací

Nástroj Maven 2 byl použit pro správu vzorové aplikace Sportovní portál. Jeho použití na tomto menším projektu demonstruje snadnou použitelnost nástroje na zejména webových aplikacích menšího a středního rozsahu. Nyní si ukážeme tutoriálovou formou, jak využít Maven 2 pro manage ment a tvorbu klasické JEE aplikace využívající komponent definovaných standardem EJB 3.0. Prvním krokem při tvorbě aplikace je tvorba kostry. Jelikož se chystáme vytvořit JEE aplikaci, předpokládáme rozdělení projektu do více modulů. Hlavní adresář S p o r t P o r t a l bude pouze zastřešovat jednotlivé moduly aplikace. Bude tedy obsahovat pouze pom.xml následující struktury: <project> <modelVersion>4.0.0 cz.morosystems.sportportal2 <artifactId>SportPortal <packaging>pom l.0-SNAPSHOT SportPortal <artifactId>maven-compiler-plugin <source>l.5 l.5 <dependencies> <dependency> javaee <artifactld>javaee-api 5 <scope>provided

60

5. MAYEN 2

Důležitou roli hraje obsah elementu < p a c k a g i n g / > . Hodnota porn de finuje projekt jako pouze „rodiče" dalším projektům. Definovaná závislost na knihovně javaee-api-5.jar nám dovoluje použití této knihovny ve všech podprojektech. Tuto knihovnu se podaří stáhnout díky umístění speciální úschovny do lokálního konfiguračního souboru settings.xml, jak jsme si již poznamenali dříve (str. 58). Dalším krokem je tvorba jednotlivých modulů. Pro tvorbu kostry těchto podprojektů můžeme využít pluginu archetype, který generuje kostru pro jektů. V našem případě začneme například webovou aplikací. Využijeme ná sledujícího příkazu, který voláme v právě vytvořeném adresáři S p o r t P o r t a l : mvn a r c h e t y p e : c r e a t e - D a r t i f a c t l d = w e b a p p -DarchetypeArtifactld=maven-archetype-webapp V adresáři se po vykonání příkazu vytvoří podprojekt nazvanľ webapp. Za povšimnutí rozhodně stojí, že vygenerovaný pom.xml obsahuje odakz na „rodiče" projektu definovaný následujícím způsobem: <project> <parent> <artifactId>SportPortal cz.morosystems.sportportal2 l.0-SNAPSHOT A naopak do pom.xml na nejvyšší úrovni adresářové struktury přibyl nový element definující moduly projektu: <project> <modules> <module>webapp V této kapitole nám jde o demonstraci vývoje rozsáhlé JEE aplikace, proto zvolíme striktní modulární přístup a každý aplikační modul budou ve skutečnosti moduly 3: 61

5. MAYEN 2

•

entity - entitní třídy aplikačního modulu.

•

app - projekt určen přímo pro EJB 3.0 komponenty. Tento projekt musí mít závislost na entitní modul, protože EJB komponenty s entitními třídami pracují.

•

ui - uživatelské rozhraní. Třídy a zdroje definující uživatelské rozhraní přístupu k jednotlivým komponentám. V našem případě využijeme pouze serviety.

Pro lepší přehlednost si vytvoříme v základním adresáři S p o r t P o r t a l podprojekt modules, který bude mít definovaný element < p a c k a g i n g / > opět jako porn a bude držet jednotlivé aplikační moduly jako svoje podprojekty Automatické deklarace „rodičovského" projektu a přidání nového projektu do výčtu modulů tohoto „rodiče" zajistíme opět pomocí pluginu archetype. Připomeňme, že při volání následujícího příkazu se musíme na cházet na úrovni projektu, pro který chceme „podprojekt" vytvořit. mvn a r c h e t y p e : c r e a t e

-DartifactId=modules

a jeho následnou drobnou úpravou vygenerovaného pom.xml. Nyní se již dostáváme ke tvorbě samotných modulů. Vytvoříme 2 kom pletní aplikační jednotky, každá z nich bude obsahovat entitní komponentu: mvn a r c h e t y p e : c r e a t e

-Dartifactld=entity

u níž předefinujeme vygenerovaný název (obsah elementu < a r t i f a c t Id>) na SportPortal-modulel-entity (resp. SportPortal-module2-entity). Dalším krokem je tvorba komponenty (respektive modulu s komponen tami) EJB 3.0: mvn a r c h e t y p e : c r e a t e

-Dartifactld=app

u které potřebujeme kromě úpravy jména projektu definovat plugin pro správu projektu jako EJB a závislost na vytvořené entitní třídě: <project> <artifactId>SportPortal-modulel-app <packaging>ejb 62

5. MAYEN 2 <artifactld>maven-ejb-plugin <ejbVersion>3.0 <dependencies> <dependency> cz.morosystems.sportportal2 <artifactId>SportPortal-modulel-entity l.0-SNAPSHOT Třetím krokem je vytvoření projektu představujícího aplikační rozhraní každého modulu. Princip je opět stejný. Voláním příkazu mvn archetype:create -Dartifactld=ui dostaneme kostru třídy a opět upravím název projektu a přidáme definici závislosti na patřičném EJB modulu. Posledním nezbytným podprojektem celé aplikace je modul vytvářející ear archiv. Tento modul vytvoříme pomocí standardního příkazu mvn a r c h e t y p e : c r e a t e

-Dartifactld=ear.

Ve vygenerovaném pom.xml potřebujeme definovat moduly, ze kterých se má výsledný archív sestavovat. <project> SportPortal 6. ear - enterprise archive. Typ archívu, do kterého bývá zabalena celá JEE aplikace, včetně všech svých modulů. Takto sestavená aplikace je určena k distribuci či nasazení do produkč ního prostředí.

63

5. MAYEN 2 <artifactld>maven-ear-plugin <modules> Nyní už zbývá jen naprogramovat nějakou jednoduchou funkcionalitu. Pro názornou ukázku jsme zvolili jednu EJB komponentu v jednom modulu jako Stateless, která pouze vrací pozdrav a Stateful komponentu v druhém modulu, která využívá třídy definované v entitním modulu a provádí per zistenci uživatelem zadávaných položek do katalogu. Na následující straně můžete vidět výslednou strukturu vzorové apli kace. Poznámka Tutoriálový projekt je k dispozici na přiloženém CD. Aplikace byla napsána pro použití na aplikačním serveru JBoss7, proto je i vyvinutýu kód specifický požadavkům ze strany aplikačního kontejneru.

7. http://labs.jboss.com/

64

SportPortal - ear '-- pom.xml - webapp

ľ

src mam webapp pom.xml

modules modulel - entity | — src ' — pom.xml - app | — src ' — pom.xml - ui | — src ' — pom.xml '-- pom.xml module2 - entity | — src ' — pom.xml - app | — src ' — pom.xml - ui | — src ' — pom.xml '-- pom.xml pom.xml '-- pom.xml

Kapitola 6

Testování Testování je velmi důležitou etapou vývoje jakéhokoliv software. V ob lasti vývoje webových aplikací platí tento konsenzus dvojnásobně, protože, oproti ostatním typům programů, na webové aplikace jsou velmi často kladeny požadavky rozšíření a úprav původního návrhu. Tyto požadavky vychází zpravidla z dodatečných přání uživatelů aplikace. Současný trend by se dal popsat slovy : „Čím více testů, tím lépe." Vzniká celá řada metodik programování, jejichž součástí je definice, jak a kdy psát testy. Jako příklad si uveďme metodiku extrémní programovaní (XP), která bere testování jako základ vývoje. Metodika navrhuje tvorbu sady testů, které jsou spuštěny po každé významné změně v aplikaci, či zapojení zákazníka do procesu testování. Další velmi známou metodikou vývoje je programovaní řízené testy (TDD1). Principy této metodiky říkají, že každá funkcionalita by měla být podložena testy. Testy by měly vznikat ještě před vývojem programového kódu. V praxi to vypadá tak, že programátor nejprve vytvoří testy (ty buď nejsou přeloži telné, nebo vychází z rozhraní, či kostry použitých tříd), díky nimž si ujasní funkcionalitu poskytovanou danou komponentou, a až poté započne vývoj samotných aplikačních modulů. 6.1

Druhy testů

Jelikož testování je, jak jsme si naznačili, nezbytný proces při vývoji soft ware, existují desítky testovacích nástrojů s různou mírou úspěšnosti a oblíbenosti. K dispozici máme mnoho komerčních ale i open-source ná strojů. Na serverujava-source.net můžeme najít přehled nejznámějších z nich (http://java-source.net/open-source/testing-tools). V oblasti vývoje webových aplikací můžeme jednotlivé testovací pří pady rozdělit do tří základních kategorií podle zaměření testů. 1. TDD - Test Driven Development

66

6. TESTOVÁNÍ

•

jednotkové testování - ověřování správné funkčnosti dílčích částí zdro jového kódu.

•

integrační testování - testování správné součinnosti kooperujícíh ob jektů (komponent).

•

akceptační testování - ověření, zda je aplikace v pořádku, vyhovuje požadavkům a je připravena k nasazení.

6.1.1 Jednotkové testování Jednotkové testování neboli testování jednotek aplikace (unit testing) nám dává možnost testovat správnost implementace požadované funkcionality. Za naprostý základ pro jednotkové testování je považován nástroj JUnit 2 , který programátorům poskytuje i grafické rozhraní a umožňuje snadnou tvorbu automatických testů. Ve vzorové aplikaci využíváme jednotkových testů k ověřování správ nosti tvorby herního systému sportovní soutěže. Jde o testovací třídy umís těny v balíku c z . m o r o s y s t e m s . s p o r t . u n i t . 6.1.2 Integrační testování Integrační testování se zabývá kontrolou správné interakce jednotlivých aplikačních jednotek či komponent. Jednou z možností, jak jednoduše a efektivně testovat komunikaci jednotlivých objektů je použití testování po mocí mock objektů. Touto technikou se v jedné z předcházejících souvisejích prací detailně zabýval Mgr. Tomáš Páral[12]. 6.1.3 Akceptační testování Akceptační testování je proces, který má potvrdit připravenost aplikace pro nasazení do produkčního prostředí. Akceptační testy představují sadu scénářů, definicí, jak se má systém v určité situaci zachovat. V případě webových aplikací můžeme tedy říci, že se jedná o testování prezenční vrstvy, ovšem je třeba si uvědomí, že testujeme funkcionalitu, tedy celou aplikaci, nejenom jeji uživatelské rozhraní. Pro automatizaci této činnosti existuje celá řada technologií. Krátce se zmíníme o dvou nejznámějších nástrojích. 2.

http://junit.org

67

6. TESTOVÁNÍ

Prvním z nich je framework JWebUnit3. Testy tvoříme podobným způ sobem jako v případě známého JUnit: 1.

Každá testovací řída rozšiřuje základní třídu pro testovací případ net.sourceforge.jwebunit.junit.WebTestCase.

2.

Nastavíme prostředí (jako například kontext webové aplikace) pomocí metody s e t u p ( ) .

3.

Jednotlivé metody vytvářejí pomocí speciálních zděděných metod ko munikaci se serverem a vyhodnocují odpovědi.

V podstatě stejné funkcionality dosáhneme použitím nástroje Selenium 4 . Jde o technologii založenou na HTML testech. Není tedy nutná znalost pro gramovacího jazyka Java, což je velmi praktické, neboťzákazník lépe rozumí prováděným testům a dokonce si může s použitím pluginu Selenium IDE5 pro internetový prohlížeč Firefox definovat svoje vlastní testy. Ty jsou tvo řeny na způsob pořízení makra, scénáře, který je, v případě spuštění testů, přehrán a zákazník může sledovat průběh testů i chování aplikace. 6.2

Testování v ý k o n u JEE aplikací

Výkon aplikace je, co se týče oblasti webových řešení, velmi podstatná informace. Existuje celá řada nástrojů, které prověřují a testují výkon webo vých aplikací. Nejznámějším takovým nástrojem napsaným v jazyce Java je bezesporu open-source aplikace z dílny Apache Software Foundation: JMeter 6 . 6.2.1 JMeter JMeter je desktopová aplikace napsaná ve Swingu, která velmi jednodu chým způsobem dovoluje uživateli sestavovat, spouštět a vyhodnocovat testovací scénáře. Program dovoluje testování různých druhů serverů. Na prvním místě si uveďme samozřejmě webový server (webovou aplikaci), dále pak FTP server, LDAP server, či databázový server. JMeter rovněž dokáže komunikovat s JMS (viz str. 15) systémy nebo monitorovat provoz a zobrazovat zátěž webového serveru podporujícího 3. http://jwebunit.sourceforge.net/ 4. http://www.openqa.org/selenium/ 5. http: / /www.openqa.org/ selenium-ide/ 6. http://jakarta.apache.org/jmeter/

68

6. TESTOVÁNÍ

JMX7 (aplikace totiž komunikuje se status servletem servletového kontejneru Tomcat 5.x8, který je připojen přes právě přes JMX a je použitelný i na ostatních aplikačních kontejnerech). Kromě testování výkonu a chování aplikace při zvýšené zátěži je JMeter rovněž vybaven prostředky pro otestování funkcionality webové aplikace. K tomuto účelu slouží definice pravidel (Assertions), které můžeme využít při sestavování testovacího schématu. Způsob tvorby scénáře Sestavení testovacího scénáře spočívá ve výběru a nakonfigurování kom ponent představující nastavení, zdroje a prováděné akce při komunikaci se serverem. V aplikaci máme na výběr z několika základních typů komponent: •

Thread Group - jádro scénáře. Definuje zejména, kolik uživatelů (jed notlivých vláken) a v kolika cyklech se bude připojovat na daný server. Komponenta tvoří základ pro další subelementy

•

Logic Controllers - množina nabízí komponenty, které jsou určené k řízení komunikace se serverem. Díky kontrolérům obsaženým v této nabídce můžeme definovat například požadavek (request), který se odešle pouze jednou a bude zajišťovat přihlášení uživatele.

•

Listeners - sada komponent, které zachytávají a zpracovávají odpověď serveru. Můžeme tak dostat například HTTP status odpovědi, celou HTML stránku, či graf zobrazující časovou odezvu.

•

Samplers - množina možných typů požadavků, které můžeme využít. Pro nás je zajímavý zejména HTTP Request, který nám definuje jeden HTTP dotaz na server (request) a který jsme schopni konfigurovat po mocí různých parametrů, definovat protokol, metody (obvykle GET, nebo POST) a konečně i konkrétní stránku, na kterou chceme request poslat.

•

Assertions - sada testů použitelných na odpověď serveru. Díky těmto komponentám můžeme testovat správnost a úplnost odpovědi.

7. JMX -Java Management Extensions (http:/ /java.sun.com/javase/technologies/core/mntrmgmt/Javamanagement/) 8. http://tomcat.apache.org/

69

6. TESTOVÁNÍ

•

Timers - různé druhy časovačů, které můžeme použít pro přesné do sažení požadovaného schémata komunikace, který chceme na serveru testovat.

•

Config Elements - sada konfiguračních prvků, díky kterým můžeme definovat různé vlastnosti spojení a samotné komunikace. Pro pou žití u testování webových aplikací je pro nás zajímavý zejména ele ment HTTP Request Defaults (definuje server, který chceme testovat, abychom nemuseli provádět konfiguraci u každého elementu před stavujícího request) a element HTTP Cookie Manager (pro možnost uchovávání a sdílení cookies).

•

Pre-Processors, Post-Processors - speciální akce spojené s odesláním požadavku a přijetím odpovědi.

Sestavování a spouštění automatizovaných scénářů je jednoduchou zá ležitostí. Intuitivní ovládání aplikace dává programátorům a testerům velmi cenný nástroj při testování zátěže a funkčnosti webové aplikace. Aplikace JMeter by si, stejně jako celé téma testování výkonu, zasloužila mnohem větší pozornosti, než se jí dostalo v této kapitole. My na podrob nější rozebrání této užitečné aplikace již bohužel v této práci nemáme do statek prostoru, proto odkazujeme čtenáře se zájmem o tuto technologii na uživatelský manuál[7] publikovaný na stránkách projektu.

70

Kapitola 7

Závěr V této práci jsme se sblížili s některými nejnovějšími technologiemi, které jsou na vrcholu oblíbenosti v oblasti vývoje JEE aplikací. Pro bližší seznámení se s moderními technikami, které jsou těmito tech nologiemi využívány, jsme si nejprve ukázali největší změny, které s sebou přinesla verze 5.0 jazyka Java. Někdo by mohl namítat, že Java 5 vyšla již před třemi roky a že tudíž nejde o žádnou novinku. Toto tvrzení není tak úplně pravdivé, jde o úhel pohledu, kterým se na věc díváte. Rozšíření Javy 5 se do vývoje JEE aplikací dostávalo jen velmi pozvolna. Důvodem k tomu je fakt, že veškeré aplikace spadající do oblasti označené JEE potře bují pro svůj běh aplikační kontejner (aťjiž odlehčený servletový kontejner, jako je tomu v případě aplikačního rámce Spring a jemu podobných, nebo plnohodnotný aplikační server, jakého je zapotřebí při využití technologie EJB). Přepracování jednotlivých aplikačních kontejnerů a dokonce samotná úprava rozsáhlých specifikací si vyžaduje měsíce příprav a práce velkých týmů programátorů a návrhářů. Z tohoto důvodu vyšla finální specifikace nazývaná Java EE 5 poměrně nedávno. V dnešní době, kdy už byly standardy JEE podporující rozšíření Javy 5 publikovány a většina největších dodavatelů komplexních aplikačních ser verů již podporuje nově definované metody, však existují programátoři, kteří se zabývají pouze programováním v Jávě 1.4. Důvodem k tomu je údržba a rozšiřování již existujících komplexních řešení, které nemůžou být z různých důvodů pretransformovaný do nové verze a chybějící podpora zpětné kompatibility aplikačních kontejnerů. Novinky verze 5.0 jazyka Java, které jsme si představili v úvodní části, nás doprovázely během většiny textu této práce. Blíže jsme si představili rozšíření velmi oblíbeného ORM nástroje Hibernate, kterým je právě využití oněch rozšíření - anotací (a s tím souvisejících generik a výčtových typů) pro tvorbu mapování. Anotace použity v tomto nástroji ještě ovšem nejsou tím pravým příkladem využití Javy 5 v JEE aplikacích, neboť anotace jsou zpracovávány třídami rámce Hibernate. Za velmi přínosnou část této práce považuji kapitolu věnující se tech71

7. ZÁVĚR

nologiím, které jsou souhrnně označovány jako spadající do JEE oblasti. Blíže jsme si představili klíčovou komponentu vývoje Java EE 5 aplikací, architekturu EJB 3.0. Bohužel jsme nebyli schopni v tomto poměrně malém prostoru zachytit všechny „vychytávky", se kterými nové Enterprise JavaBeans přichází, ovšem myslím si, že jsme dokázali názorným způsobem nezasvěcenému čtenáři nové technologie a způsob vývoje s jejich využitím představit a upozornit na hlavní rozdíly, kterými se nová verze liší od staré specifikace. K oblasti vývoje jakéhokoliv software patří neodmyslitelně i nástroje, které mají pomocí při procesu vývoje a sestavování daného produktu. Před stavili jsme si základy práce, potřebné pro vývoj webových aplikací, s ná strojem Maven 2, který se, navzdory doposud poměrně malému množství dokumentace, těší v poslední době stále většímu zájmu komunit programá torů. Důkazem tohoto tvrzení je fakt, že mnoho open-source projektů nabízí distribuci svých zdrojových kódů spravovanou právě tímto moderním ná strojem. K automatizaci procesu sestavování aplikací patří automatické ná stroje testování. V doplňkové kapitole jsme si shrnuli možnosti testování a představili nástroj pro testování výkonu aplikací. Podstatným přínosem pro programátora je fakt, že představený nástroj Maven umožňuje automatické spouštění testů kdykoliv při překladu a sestavení aplikace, čímž přebírá zodpovědnost nad vykonáváním těchto testů a kontrolou jejich správnosti. Důležitou součástí této práce jsou i zdrojové kódy vzorových aplikací na přiloženém CD. Webová aplikace SportPortal, která je souhrným dílem doprovázejícím tři diplomové práce (práce Mgr. Petra Matulíka[ll], Mgr. Tomáše Párala[12] a završena touto prací) představuje zdroj netriviálních řešení prezentovaných zejména v perzistentní vrstvě s využitím rámce Hi bernate. Druhá přiložená aplikace je specifická pro tuto práci a je výstupem tutoriálovéhu představení tvorby JEE aplikace s využitím možností zmíněné technologie Maven 2 a založené na komponentové architektuře EJB 3.0. Věřím, že text této práce si najde čtenáře mezi nově začínajícími Java/JEE programátory, ale svými pokročilejšími oblastmi zaujme i člověka, který se v dané problematice již orientuje.

72

Příloha A

Vzorové aplikace Na přiloženém CD jsou umístěny 2 vzorové aplikace. První z nich je webová aplikace Sportportal, druhou je tutorialový příklad použití technologie Maven při tvorbě JEE aplikace. Aplikace jsou umístěny v adresářích /app/SportPortal

... webová aplikace založená na technologiích Spring + Hibernate /app/SportPortal/dist ... distribuční verze aplikace /app/SportPortal2

... tutoriálová aplikace využíva jící technologii EJB 3.0 /app/SportPortal2/dist... distribuční verze aplikace

73

Příloha B

Elektronický formát této práce Na přiloženém CD je také k dispozici elektronická forma této práce ve formátech PDF a KTgX. Soubory se nachází v adresáři /thesis

74

Literatura [1] Apache Maven. < h t t p : / / m a v e n . a p a c h e . o r g / > . [2] Hibernate, < h t t p : / / w w w . h i b e r n a t e . o r g / > . [3] Hibernate anotace, referenční příručka. < h t t p : / /www . h i b e r n a t e . org/hib_docs/annotations/reference/en/html_single>. [4] Java EE 5 tutoriál, . [5] Java Enterprise Edition, < h t t p : / / j a v a . s u n . c o m / j a v a e e / > . [6] Java Standard Edition, < h t t p : / / j a v a . s u n . c o m / j a v a s e / > . [7] JMeter - User's manual. . [8] Spring framework, < h t t p : / / w w w . s p r i n g f r a m e w o r k . o r g / > . [9] John Casey, Vincent Massol, Brett Porter, Carlos Sanchez, Jason van Zyl. Better Builds with Maven. < h t t p : / / w w w . m e r g e r e . com/m2book_ d o w n l o a d . j sp>, 2006. [10] Joshua Bloch. Java efektivě. 57 zásad softwarového experta. Grada Pub lishing a.s., U Průhonu 22, Praha 7, 2002. [11] Petr Matulík. Moderní rámce pro webové aplikace [diplomová práce]. Ma sarykova univerzita, Fakulta informatiky, 2006. [12] Tomáš Páral. Datová a prezentační vrstva moderních webových aplikací [diplomová práce]. Masarykova univerzita, Fakulta informatiky, 2007.

75

Rejstřík anotace, 10,26 anotace perzistence AttributeOverrides, 33 Basic, 31 Column, 31 DiscriminatorColumn, 45 DiscriminatorValue, 45 Embeddable, 32 Embedded, 32 Entity, 29 GenerateďValue, 33 Id, 33 Inheritance, 44 JoinColumn, 35, 38,41 JoinTable, 36, 39,43 Lob,31 ManyToMany, 42 ManyToOne, 37 MapKey, 42 OneToMany, 38 OneToOne, 34 OrderBy, 42 Primary KeyJoinColumn, 36 Table, 29 Temporal, 31 Transient, 30 Version, 31 Ant, 49 aplikace Sportovní portál, 4 Bloch, Joshua, 7 EJB Entity Bean, 18

Message-Driven Bean, 23 Session Bean, 18 Stateful, 19 Stateless, 18 EJB anotace EJB, 22 MessageDriven, 23 PersistenceContext, 24 Remote, 22 Resource, 23 Stateful, 22 Stateless, 22 enterprise aplikace, 13 Extremní programování, 66 Hibernate anotace, 26 Cascade, 40 GenericGenerator, 33 MapKey, 42 MapKeyManyToMany, 42 OrderBy, 42 Hibernate mapování asociace mezi třídami, 34 jednosměrné vazby, 38 kolekce List, 42 kolekce Map, 42 kolekce Set, 37 many-to-many, 42 many-to-one, 37 obousměrné vazby, 39 one-to-many, 38 one-to-one, 34 primární klíč, 33 vnitřní objekt, 31 76

B. ELEKTRONICKÝ FORMÁT TÉTO PRÁCE

základní atributy, 30 Maven dependency, 56 Hibernate polymorfizmus Maven profily, 53 Maven repozitory, 57 strategie joined-subclass, 47 Maven tvorba pluginů, 59 strategie table-per-class, 48 strategie table-per-class-hierarchy, open-source, 27,50, 66, 68 44 ORM, 18 Java Enterprise Edition, iv POJO, 18, 24, 28 JBoss, 64 programování řízené testy, 66 JEE API, 13 JEE technologie servletový kontejner, 14 EJB 3.0,14 SNAPSHOT, 57 Java Serviet, 14 TDD, 66 JavaMail, 15 testování JAX-RPC, 16 akceptační testování, 67 JAX-WS, 16 integrační testování, 67 JAXB, 16 jednotkové testování, 67 JMS, 15 testování pomocí mock objektů, 67 JPA, 15 testování výkonu, 68 JSF, 14 JSP, 14 verzovací systémy CVS, SVN, 51 JSTL, 14 JTA, 15 XP,66 S A AJ, 16 StAX, 16 JNDI lookup, 19 JUnit, 67 Maven, 49 Maven 2 základní příkazy, 54 mvn clean, 55 mvn compile, 54 mvn deploy, 55 mvn install, 55 mvn integration-test, 54 mvn package, 54 mvn site, 55 mvn test, 54 mvn validate, 54 mvn verify, 55 77

Technologie a nástroje vývoje Java EE aplikací

Recommend Documents