, jak je naznačeno v následujícím úryvku z pom.xml naší vzorové aplikace.
<project>
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
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
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
5. MAYEN 2
-Dartifactld=ear.
Ve vygenerovaném pom.xml potřebujeme definovat moduly, ze kterých se má výsledný archív sestavovat. <project>
63
5. MAYEN 2 <artifactld>maven-ear-plugin
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,
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