Návrh a implementace upload serveru

Mendelova univerzita v Brně Provozně ekonomická fakulta

Návrh a implementace upload serveru pro firmu WiFi Ždánice Bakalářská práce

Vedoucí práce: Ing. Petr Jedlička, Ph.D.

Michaela Kotíková

Brno 2012

2 SEM LIST ORIGINÁLNÍHO ZADÁNÍ BAKALÁŘSKÉ PRÁCE

Tímto bych ráda vyjádřila poděkování svému vedoucímu bakalářské práce Ing. Petru Jedličkovi, Ph.D. za cenné připomínky k práci, trpělivost a vstřícný přístup. Mé díky patří také autorům příspěvků diskuzních fór a článků, které mi pomohly vyřešit řadu praktických problémů přesahujících rámec dostupných tutoriálů či knih. Děkuji také svému příteli Hynkovi za jeho podporu a pochopení.

Prohlašuji, že jsem tuto bakalářskou práci vypracovala samostatně pod vedením Ing. Petra Jedličky, Ph.D. za použití odborné literatury a pramenů, které jsou uvedeny v přehledu použité literatury.

V Brně dne 18. května 2012

....................................................

5

Abstract Kotikova, M. Design and Implementation of an Upload Server for the WiFi Zdanice Company. Bachelor thesis. Brno, 2012 The objective of this bachelor thesis is to design and implement a web application according to the requirements of the WiFi Zdanice company’s management. The web application provides a file hosting service. It is implemented using Java EE tools and frameworks, specifically using the Apache Wicket component-based web application framework, the Hibernate object-relational mapping library and the Spring application framework. Tha data is persisted using the PostgreSQL object-relational database management system and the application is intended to be deployed to the Apache Tomcat open source web server. Keywords web application, upload server, Java EE, Apache Wicket, Hibernate, Spring, MVC, three-tier architecture, PostgreSQL, database, Apache Tomcat, web server, HTML, CSS

Abstrakt Kotíková, M. Návrh a implementace upload serveru pro firmu WiFi Ždánice. Bakalářská práce. Brno, 2012. Cílem této bakalářské práce je navrhout a implementovat webovou aplikaci na základě požadavků vedení firmy WiFi Ždánice. Webová aplikace poskytuje file hostingovou službu. Je implementována pomocí nástrojů a frameworků platformy Java EE, konkrétně pomocí komponentně orientovaného webového rámce Apache Wicket, knihovny pro objektově-relační mapování Hibernate a aplikačního frameworku Spring. Perzistence dat je svěřena objektově-relačnímu databázovému systému PostgreSQL a aplikace je určena pro nasazení na webový server Apache Tomcat. Klíčová slova webová aplikace, upload server, Java EE, Apache Wicket, Hibernate, Spring, MVC, třívrstvá architektura, PostgreSQL, databáze, Apache Tomcat, webový server, HTML, CSS

6

OBSAH

Obsah 1 Úvod 9 1.1 Upload servery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2 Firma WiFi Ždánice . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Cíl a metodika práce 12 2.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2 Metodika práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3 Specifikace požadavků 3.1 Obecné požadavky . . . . . . . . . . . . 3.2 Uživatelé . . . . . . . . . . . . . . . . . . 3.2.1 Administrátor . . . . . . . . . . . 3.2.2 Přihlášený uživatel . . . . . . . . 3.2.3 Nepřihlášený uživatel . . . . . . . 3.3 Struktura upload serveru . . . . . . . . . 3.4 Omezující podmínky . . . . . . . . . . . 3.5 Provozní požadavky . . . . . . . . . . . . 3.6 Funkční požadavky . . . . . . . . . . . . 3.6.1 Upload souboru . . . . . . . . . . 3.6.2 Zobrazení souborů . . . . . . . . 3.6.3 Download souboru . . . . . . . . 3.6.4 Správa vláken a souborů . . . . . 3.6.5 Vložení příspěvku do diskuze . . 3.6.6 Správa uživatelů . . . . . . . . . 3.6.7 Zobrazení uživatelských statistik 3.6.8 Autentizace uživatele . . . . . . . 3.6.9 Změna hesla uživatele . . . . . . 3.7 Nefunkční požadavky . . . . . . . . . . . 3.7.1 Bezpečnostní požadavky . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . .

13 13 13 13 13 14 14 14 15 15 15 15 15 16 16 16 17 17 17 17 17

4 Návrh řešení 4.1 Návrh aplikace . . . . . . . . . . . . . 4.2 Návrh uživatelského rozhraní . . . . . . 4.3 Návrh datového modelu . . . . . . . . 4.3.1 Entitně relační diagram (ERD) 4.3.2 Entity a vztahy mezi nimi . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

18 18 18 20 21 21

5 Volba technologií pro implementaci 5.1 Java EE . . . . . . . . . . . . . . . 5.2 Apache Wicket . . . . . . . . . . . 5.2.1 Programovací model . . . . 5.2.2 Wicket komponenty . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

23 23 24 25 27

. . . .

. . . .

7

OBSAH

5.3 5.4 5.5 5.6 5.7

5.2.3 MVC . . . . . . . . . . . . . . . . . . . . . . 5.2.4 Wicket modely . . . . . . . . . . . . . . . . Spring . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Inversion of Control a Dependency Injection Hibernate . . . . . . . . . . . . . . . . . . . . . . . HTML, CSS a JavaScript . . . . . . . . . . . . . . Vývojové prostředí . . . . . . . . . . . . . . . . . . Další vývojové nástroje . . . . . . . . . . . . . . . .

6 Implementace 6.1 Struktura aplikace . . . . . . . . . . . . . . . 6.2 Konfigurace aplikace . . . . . . . . . . . . . . 6.3 Uživatelské rozhraní . . . . . . . . . . . . . . 6.4 Doménové objekty . . . . . . . . . . . . . . . 6.5 Servisní třídy . . . . . . . . . . . . . . . . . . 6.6 Zabezpečení aplikace . . . . . . . . . . . . . . 6.6.1 Autentizace . . . . . . . . . . . . . . . 6.6.2 Autorizace . . . . . . . . . . . . . . . . 6.6.3 Zabezpečení citlivých údajů v databázi 6.7 Validace formulářů . . . . . . . . . . . . . . . 6.8 Lokalizace aplikace . . . . . . . . . . . . . . . 6.9 Optimalizace adres URL . . . . . . . . . . . . 6.10 Vlastní chybová stránka . . . . . . . . . . . . 6.11 Logování . . . . . . . . . . . . . . . . . . . . . 6.12 JUnit testy . . . . . . . . . . . . . . . . . . . 6.13 Nasazení aplikace . . . . . . . . . . . . . . . . 6.13.1 Inicializace dat v databázi . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . .

28 28 29 30 30 31 32 32

. . . . . . . . . . . . . . . . .

33 33 35 37 38 39 40 40 40 41 42 43 44 45 46 46 47 48

7 Závěr

50

8 Literatura

51

Přílohy

52

A Náhledy aplikace

53

B Elektronické přílohy

59

8

SEZNAM ZDROJOVÝCH KÓDŮ

Seznam zdrojových kódů 1 2 3 4 5 6 7 8 9 10 11

Konfigurační soubor pom.xml . . . . . . . . . . . . . . . Konfigurační soubor web.xml . . . . . . . . . . . . . . . Soubor applicationContext.xml . . . . . . . . . . . . . . Doménová třída UploadServerSigninLog . . . . . . Servisní třída UploadServerFilesServiceImpl . . Metoda getHash třídy LogInOutManager . . . . . . Formulář pro registraci nového uživatele . . . . . . . . . Napojení stránek v metodě init() aplikace . . . . . . . Konfigurační soubor log4j.properties . . . . . . . . . . . Metoda pro testování validátorů přihlašovacího formuláře Metoda zajišťující inicializaci dat v databázi . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

35 36 36 38 39 41 42 45 46 47 48

1

ÚVOD

1

9

Úvod

V současné době stále roste potřeba sdílet data s ostatními, ať už se jedná o přátele a známé, o kolegy, nebo o širokou veřejnost. Právě na příjemcích závisí obsah sdílených dat. Středem zájmu tedy mohou být fotografie z dovolené, důležité dokumenty, nebo vtipný videozáznam skotačení domácího mazlíčka. Distribuce nebo poskytování přístupu k digitálně uloženým informacím se označuje jako sdílení dat. To lze řešit mnoha způsoby. Mezi běžné metody patří sdílení pomocí odpojitelných médií (USB flash disk, externí pevný disk, CD, DVD, paměťové karty a další), sdílení prostřednictvím centralizovaných serverů v počítačových sítích nebo pomocí peer-to-peer sítí. Existují dva způsoby distribuce obsahu online: streaming1 a stažení souboru na disk. Při využití streamingu může klientský prohlížeč začít zobrazovat data ještě před přenesením celého souboru. Tímto se streaming liší od stahování souborů na disk. Uživatelům je k dispozici široká řada služeb pro distribuci obsahu online, které jsou zaměřeny na sdílení videa, hudby, fotek, elektronických knih, her a softwaru. Mezi ty nejznámější patří Youtube2 , SoundCloud3 , Last.fm4 , Picasa5 , Ubuntu Software Center6 , Xbox Live Marketplace7 , Google Play8 . Tato bakalářská práce se bude zabývat distribucí digitálního obsahu formou stažení na disk, konkrétně sdílením souborů prostřednictvím upload serveru.

1.1

Upload servery

Upload server zastává roli zprostředkovatele dat mezi jedním uživatelem, který daná data poskytl, a dalšími uživateli, kteří mají zájem o získání těchto dat. Sdílení souborů spočívá v nahrávání (uploadu) souborů do datového úložiště a možnosti jejich následného stažení (downloadu) pomocí odkazu. Uživatelům je toto úložiště dat zpřístupněno provozovatelem serveru (file hostingovou společností). Pojem file hosting označuje internetovou službu, která uživatelům toto sdílení umožňuje. File hostingová služba je v současné době velmi populární a na trhu file hostingových společností je vysoká konkurence, a to jak v rámci České republiky, tak i ve světovém měřítku. Lze se setkat se základními dvěma typy služeb: těmi, které vyžadují registraci (ta je převážně zdarma), a těmi, které umožňují stáhnout/nahrát soubor okamžitě. File hostingové služby jednotlivých poskytovatelů se liší v době 1

Streaming představuje technologii kontinuálního přenosu audiovizuálního obsahu mezi zdrojem a koncovým uživatelem. 2 http://www.youtube.com/ 3 http://soundcloud.com/ 4 http://www.last.fm/ 5 http://picasa.google.com/ 6 http://www.ubuntu.com/ubuntu/features/ubuntu-software-centre 7 http://marketplace.xbox.com/ 8 https://play.google.com/store

1.2

Firma WiFi Ždánice

10

uchování souborů na serveru, v maximální velikosti nahrávaného souboru, v limitu stahovaných dat, v omezení IP adres atd. Někteří poskytovatelé také nabízí odměny pro uploadery za stahování uploadovaného souboru. U velké většiny poskytovatelů jsou uvedená omezení odlišná pro placené a neplacené stahování/nahrávání souborů. Pokud si uživatel zakoupí prémiový účet, nejčastěji se ho netýká omezení rychlosti, ani limit přenesených dat, velikost jednoho nahrávaného souboru může být větší než pro uživatele bez prémiového účtu a má neomezenou jak celkovou kapacitu úložiště pro všechny nahrané soubory, tak dobu uchování jeho souborů na serveru. Při neplaceném stahování a uploadování uživatel většinou nemá přímý přístup k souborům, ale před zahájením stahování musí určitou dobu vyčkat a/nebo z obrázku zobrazujícího zdeformovaný text tento kontrolní kód opsat (CAPTCHA9 ). U neplacených služeb je maximální velikost uploadovaného souboru i maximální kapacita úložiště limitována, stejně tak je omezena i doba uchování souborů. File hostingové společnosti umožňují přístup pomocí protokolů HTTP a FTP. Některé firmy také nabízejí související služby, například vzdálené zálohování, zobrazování obsahu (videa, audia, obrázků) nebo virtuální úložiště. Existují i file hostingové služby využívající síťové úložiště, které uživatelům umožňuje ukládat a sdílet soubory a složky s ostatními uživateli přes Internet pomocí synchronizace souborů (např. služba Dropbox10 ). Uživatelé mohou nasdílet libovolná data, tudíž existuje možnost, že se na server dostanou soubory s nelegálním obsahem. V České republice je právní úprava odpovědnosti poskytovatele za obsah uložených informací zakotvena v zákonu č. 480/2004 Sb., o některých službách informační společnosti. V §5 je uvedeno, že poskytovatel služby, která spočívá v ukládání informací poskytnutých uživatelem, odpovídá za obsah informací uložených na žádost uživatele, jen pokud mohl vědět, že obsah ukládaných informací nebo jednání uživatele jsou protiprávní, nebo dozvěděl-li se prokazatelně o protiprávní povaze obsahu informací nebo o protiprávním jednání uživatele a neprodleně neučinil kroky k odstranění nebo znepřístupnění takovýchto informací. Podle §6 nejsou poskytovatelé služeb povinni dohlížet na obsah ukládaných informací, ani aktivně vyhledávat skutečnosti a okolnosti poukazující na protiprávní obsah informace. (Zákon č. 480/2004 Sb., o některých službách informační společnosti)

1.2

Firma WiFi Ždánice

Společnost WiFi Ždánice svým zákazníkům kromě jiných služeb poskytuje připojení k Internetu, a to buď kabelové připojení Ethernet, optické přípojení FTTH11 , nebo 9

CAPTCHA je Turingův test používaný pro odlišení skutečného uživatele od robotů, domovská stránka http://www.captcha.net/ 10 https://www.dropbox.com/ 11 Fiber-to-the-home – „optické vlákno až do bytuÿ

1.2

Firma WiFi Ždánice

11

bezdrátové připojení WiFi. Zákazníky představují domácnosti a firmy ve městě Ždánice, okres Hodonín, a v okolních obcích (Archlebov, Dražůvky, Lovčice, Žarošice). Dalšími poskytovanými službami jsou servis a prodej výpočetní techniky a příslušenství, VoIP telefonie a svařování optických vláken. Hlavním cílem firmy je zkvalitnění poskytovaných služeb a rozšíření počtu zákazníků. Dosažení tohoto cíle spočívá zejména v modernizaci sítě. Základ modernizace sítě tvoří plán postupného přechodu z bezdrátového na optické připojení založené na technologii FTTH. Toto vysokorychlostní připojení poskytne možnost využití služeb VoIP a IPTV a hraní online her s garantovanou spolehlivostí a stabilitou a bude zároveň představovat jedinou optickou metropolitní síť ve městě a v jeho okolí. Dalšími prostředky k dosažení hlavního cíle firmy jsou zvýšení počtu přípojných bodů, zlepšení pokrytí, ale také poskytování nových služeb, například nasazení a zpřístupnění upload serveru pro sdílení dat, jehož návrhem a implementací se zabývá tato práce.

2

CÍL A METODIKA PRÁCE

2

12

Cíl a metodika práce

V této kapitole se nachází specifikace cíle práce a popis metodiky.

2.1

Cíl práce

Cílem této bakalářské práce je umožnit zákazníkům firmy WiFi Ždánice sdílení souborů mezi sebou. Po předběžné analýze požadavků firmy WiFi Ždánice byl stanoven následující záměr: vytvoření návrhu webové aplikace pro sdílení souborů a implementace tohoto návrhu. Východiskem pro realizaci cíle práce jsou požadavky popsané v kapitole 3. Účelem výsledné aplikace není pouze poskytnutí nové služby zákazníkům, ale i omezení síťového provozu při získávání požadovaných souborů mimo lokální síť na úkor zvýšeného provozu v této síti, neboť webová aplikace bude podle záměru zadavatele dostupná výhradně zákazníkům firmy WiFi Ždánice, a to pouze v lokální síti poskytovatele.

2.2

Metodika práce

K dosažení výše uvedeného cíle vede několik kroků. Nejdříve přichází na řadu sběr a specifikace požadavků firmy. Tento krok je klíčový z hlediska správného návrhu aplikace a její následné implementace. Výstupem následujícího stádia je návrh výsledné aplikace, včetně návrhu uživatelského rozhraní a struktury databáze. V dalším stádiu dochází k volbě vhodných technologií a nástrojů pro implementaci. Požadovanou webovou aplikaci je možné navrhnout v souladu se zásadami rozličných návrhových vzorů, konceptů, technik a přístupů a implementovat ji pomocí řady nástrojů a frameworků. Ve stádiu volby technologií pro implementaci bylo vedením firmy WiFi Ždánice rozhodování o výběru technologií usnadněno pouze jedenkrát – požadavkem na využití programovacího jazyka Java12 . Jak návrh aplikace, tak volba nástrojů pro implementaci a jejich kombinace má zásadní vliv na náročnost vývoje systému a jeho další případnou rozšiřitelnost, proto jsou obě tato stádia velmi důležitá. Po uvedených stádiích následuje samotná implementace webové aplikace pomocí technologií zvolených pro její vývoj. Kapitola 6 popisuje vývoj jednotlivých funkcionalit z implementačního a funkčního hlediska. V závěru této práce budou shrnuty a zhodnoceny výsledky procesu řešení a bude konstatováno, zda byl dosažen vytyčený cíl a požadovaný výsledek, popřípadě v jaké míře k tomuto došlo.

12

www.java.com/

3

SPECIFIKACE POŽADAVKŮ

3

13

Specifikace požadavků

Na základě několika rozhovorů s majitelem firmy vznikla specifikace požadavků. Po každé schůzce se prvotní požadavky mírně měnily, až se nakonec ustálily do následující podoby.

3.1

Obecné požadavky

Firma WiFi Ždánice potřebuje upload server, webovou aplikaci sloužící ke sdílení souborů v rámci úzkého okruhu uživatelů, kterými jsou klienti této firmy. Aplikace bude k dispozici pouze uživatelům v lokální síti poskytovatele. Z tohoto důvodu se nepočítá s vysokou zátěží serveru, bude se jednat řádově o desítky uživatelů souběžně pracujících v systému.

3.2

Uživatelé

Uživatelé se budou dělit do tří tříd: administrátor, přihlášený uživatel a anonymní (nepřihlášený) uživatel. Následuje výčet akcí, k jejichž vykonání budou mít jednotlivé třídy uživatelů oprávnění. 3.2.1

Administrátor

Administrátor bude moci provádět správu systému, a to následujícím způsobem: ˆ správa souborů (v souladu s kapitolou 3.6.4)

– upload nového souboru – úprava informací o všech již nahraných souborech – odstranění všech již nahraných souborů ˆ správa uživatelů

– registrace nového uživatele – úprava informací o stávajících uživatelích (včetně informací o sobě) – odstranění stávajících uživatelů Administrátor bude dále moci soubory stahovat a vkládat příspěvky do diskuze. Také bude mít možnost změnit své přihlašovací heslo a zobrazit uživatelskou statistiku (datum registrace uživatele, datum jeho posledního přihlášení a počet jeho přihlášení). 3.2.2

Přihlášený uživatel

Přihlášený uživatel bude moct stahovat všechny soubory na upload serveru, nahrávat soubory a tyto své soubory poté spravovat (podle pravidel uvedených v kapitole 3.6.4).

3.3

Struktura upload serveru

14

Tento uživatel má mít právo pouze ke změně svého přihlašovacího hesla. Další evidované informace o uživateli (jméno, příjmení, emailová adresa a uživatelské jméno) jsou k dispozici pouze administrátorovi z informativních důvodů, v případě potřeby tyto informace může měnit pouze on. Tento uživatel také může přidávat komentáře do diskuze. 3.2.3

Nepřihlášený uživatel

Nepřihlášený uživatel může pouze zobrazit hlavní sekce upload serveru a vlákna v těchto sekcích (struktura upload serveru je popsána v kapitole 3.3) a informativní stránku s kontakty na firmu WiFi Ždánice, pomocí nichž bude moci kontaktovat majitele firmy za účelem založení uživatelského účtu.

3.3

Struktura upload serveru

Hierarichie struktury upload serveru bude následující: ˆ hlavní sekce

– vlákno * soubory

Hlavních sekcí upload serveru bude pět (Video, Audio, Obrázky, Dokumenty a Ostatní). Při uploadu souborů si uživatel vybere hlavní sekci a v ní vytvoří vlákno, kterého vloží požadované soubory. Nemůže tedy existovat soubor mimo vlákno, ani mimo sekci.

3.4

Omezující podmínky

Vedení firmy WiFi Ždánice požaduje implementaci aplikace v programovacím jazyce Java (při dodržení principů objektově orientovaného programování) a všechny použité frameworky, knihovny a nástroje mají spadat do kategorie svobodného nebo open source softwaru. Webová aplikace má být nasazena na stroj Dell PowerEdge R210 s nainstalovaným webovým serverem Apache Tomcat13 a databázovým systémem PostgreSQL14 . Nahrávaný soubor může mít maximální velikost 700 MB. Toto kapacitní omezení je určeno pro počáteční stádium provozu a bude jej možné v případě potřeby 13

Apache Tomcat je open source aplikační webový server a servletový kontejner, domovská stránka http://tomcat.apache.org/ 14 PostgreSQL je objektově-relační systém řízení báze dat, domovská stránka http://www.postgresql.org/

3.5

Provozní požadavky

15

jednoduše změnit. Celková kapacita na disku vyhrazená pro všechny soubory je 250 GB. Vyčerpání této kapacity bude mít skript kontrolující kvóty – daemon15 . Přístup do aplikace bude možný pouze z lokální sítě poskytovatele, proto není očekávána vysoká zátěž upload serveru. Toto omezení nemá žádný vliv na způsob implementace webové aplikace, neboť jej zadavatel zrealizuje sám, na úrovni síťových prvků. Přístup k webové aplikaci z Internetu bude uživatelům umožněn v případě, že aplikace bude nasazena na serveru bez použití zmíněných opatření na úrovni síťových prvků.

3.5

Provozní požadavky

Aplikace má využívat HTTP protokol jako webové komunikační rozhraní; z tohoto důvodu uživatelé musí mít webový prohlížeč s podporou HTML16 , kaskádových stylů17 a JavaScriptu18 .

3.6 3.6.1

Funkční požadavky Upload souboru

Přihlášený uživatel může na server nasdílet soubor. Do formuláře pro upload souboru je nutné zadat název vlákna a sekce, do které vlákno náleží, a bude také možné zadat i nepovinný popis daného vlákna. Do vlákna může uživatel nahrát více než jeden soubor. 3.6.2

Zobrazení souborů

Přihlášení uživatelé budou moci procházet hlavní sekce a jejich příslušná vlákna, v nichž budou zobrazovány jednotlivé soubory s odkazem ke stažení. 3.6.3

Download souboru

Všichni přihlášení uživatelé budou moci stahovat veškeré soubory uložené na upload serveru. Po kliknutí na odkaz pro stažení souboru se pro daný soubor zvýší položka evidující počet stažení o jedno. Díky této položce bude každý uživatel schopen zjistit počet stažení jím nahraného souboru. 15

Démon je program, který je spuštěn dlouhodobě a jehož úkolem je vyčkávat v nečinnosti na nějakou událost. 16 HyperText Markup Language je základním značkovacím jazykem pro definici webových stránek, http://en.wikipedia.org/wiki/HTML 17 CSS je jazyk pro popis způsobu zobrazení dokumentu napsaného ve značkovacím jazyce, domovská stránka http://www.w3.org/Style/CSS/ 18 JavaScript (JS) je multiplatformní, objektově orientovaný skriptovací jazyk používaný primárně pro vylepšení grafického uživatelského rozhraní a přidání interaktivity do webových stránek, http://en.wikipedia.org/wiki/JavaScript

3.6

Funkční požadavky

3.6.4

16

Správa vláken a souborů

Administrátor bude oprávněn spravovat všechna vlákna, avšak uživatel pouze vlákna, která sám vytvořil. U vlákna bude možné editovat následující položky: ˆ název vlákna ˆ popis vlákna ˆ sekci, do které vlákno přísluší ˆ soubory, jež náleží danému vláknu následovným způsobem:

– nahrát další soubory – smazat vybrané soubory (vlákno však nemůže zůstat prázdné – z tohoto důvodu je v případě, že vlákno obsahuje pouze jeden soubor, možné odebrat pouze celé vlákno) Také bude možné vlákno odstranit – při odstranění vlákna se smažou i všechny soubory náležící danému vláknu. 3.6.5

Vložení příspěvku do diskuze

Na úrovni vlákna bude přihlášeným uživatelům přístupná diskuze, do níž bude možné vkládat příspěvky. 3.6.6

Správa uživatelů

Tato funkcionalita bude dostupná pouze administrátorovi. Správa uživatelů zahrnuje následující položky: ˆ registrace nového uživatele

– Administrátor vytvoří účet pro nového uživatele pomocí registračního formuláře, kam zadá jeho křestní jméno a příjmení, emailovou adresu a uživatelské jméno a heslo. Poslední dva údaje poté sdělí novému uživateli, který si po přihlášení může heslo změnit. ˆ úprava informací o stávajících uživatelích (včetně informací o sobě)

– Administrátor je oprávněn změnit křestní jméno a příjmení, emailovou adresu a uživatelské jméno stávajícího uživatele. ˆ odstranění stávajících uživatelů

– Při odstranění uživatele nedojde k jeho odstranění z databáze, neboť mají jeho vlákna se soubory i jeho příspěvky v diskuzích zůstat přístupné pro ostatní. U tohoto uživatele se tedy pouze nastaví příznak aktivity na hodnotu FALSE.

3.7

Nefunkční požadavky

3.6.7

17

Zobrazení uživatelských statistik

Administrátor má možnost zobrazit uživatelské statistiky informující o datu registrace, posledním datu přihlášení a počtu přihlášení pro jednotlivé uživatele. 3.6.8

Autentizace uživatele

Registrovaný uživatel provede přihlášení do systému pomocí přihlašovacího formuláře. Při přihlášení se zaloguje aktuální datum a čas a zvýší se počet přihlášení o jedno. Zaznamenané informace může administrátor prohlížet v uživatelských statistikách. 3.6.9

Změna hesla uživatele

Jak administrátor, tak běžný uživatel může změnit své stávající heslo pro přihlášení do systému.

3.7

Nefunkční požadavky

3.7.1

Bezpečnostní požadavky

Přihlašovací hesla uchovávaná v databázi mají být dostatečně zabezpečená proti získání (přečtení) z databáze. Každá důležitá provedená akce se má evidovat v logovacím souboru. Tento požadavek logování se týká přihlášení a odhlášení uživatele, vytvoření vlákna a nahrání nového souboru, smazání vlákna a odstranění souboru, registrace nového uživatele, smazání uživatele. U uvedených akcí se kromě aktuálního data a času mají zaznamenávat další klíčové položky (např. uživatel, který provedl akci).

4

NÁVRH ŘEŠENÍ

4

18

Návrh řešení

Z požadavků vyplývá, že výstupem řešení má být webová aplikace, což je aplikace dostupná z Internetu nebo z intranetu. Tento typ aplikace je v současné době velmi oblíbený díky několika výhodám. Hlavní výhoda webových aplikací oproti desktopovým spočívá v dostupnosti produktu. Data se ukládají vzdáleně a uživatel nemusí instalovat, ani aktualizovat žádný software (stačí nainstalovaný webový prohlížeč a přístup k Internetu); webové aplikace jsou tedy platformě nezávislé. Vývojáři mají usnadněnu podporu a údržbu, integraci s webovými službami, tvorbu mobilní verze aplikace (při použití technologií HTML a JavaScript) a monitorování uživatelských akcí (získání obsáhlé statistiky a zpětné vazby). Nevýhodou webových aplikací je požadavek připojení k Internetu a také možnost úniku soukromých informací ze vzdáleného serveru. Dále v této kapitole bude popsán návrh vytvářené webové aplikace, včetně návrhu jejího uživatelského rozhraní a datového modelu.

4.1

Návrh aplikace

Zadavatel specifikoval požadavek na implementaci aplikace v programovacím jazyce Java. Tento jazyk je objektově orientovaný, samozřejmostí při implementaci tedy bude dodržování zásad objektově orientovaného programování. Vzhledem k požadavkům a charakteru aplikace je vhodné aplikovat princip třívrstvé architektury. Jedná se o architekturu, ve které prezentace, aplikační logika a správa dat představují logicky oddělené procesy. Třívrstvá architektura vývojářům poskytuje model pro tvorbu flexibilní a znovupoužitelné aplikace – rozdělením aplikace do vrstev je v případě potřeby možné upravit pouze konkrétní vrstvu namísto refaktoringu celého kódu. Prezentační vrstva komunikuje s uživatelem, zobrazuje mu informace v uživatelsky čitelné podobě prostřednictvím grafického uživatelského rozhraní a umožňuje mu interagovat s aplikací. (Hartman, 2011, s. 23) Logická (business) vrstva obsahuje aplikační business logiku (veškerou funkcionalitu) aplikace. Zahrnuje také doménové objekty, které reprezentují objekty reálného světa. Rozhraní aplikační vrstvy je obvykle tvořeno servisní vrstvou, která získává data z databáze. (Hartman, 2011, s. 24) Datová vrstva (vrstva perzistence dat) zprostředkovává přístup k perzistentnímu úložišti dat (typicky relační databáze). Pro mapování doménových objektů na tabulky v databázi se nejčastěji využívá některý z nástrojů pro objektově-relační mapování. (Hartman, 2011, s. 25)

4.2

Návrh uživatelského rozhraní

Realizovaná webová aplikace by měla mít jednoduchý, sjednocený design s důrazem na uživatelsky přívětivé prostředí, zejména na bezproblémovou orientaci v rámci

4.2

Návrh uživatelského rozhraní

19

webových stránek. Z toho důvodu by obsah webové prezentace měl mít informační architekturu s logickým rozdělením jednotlivých podkategorií v rámci hlavních kategorií (viz obrázek 1). K usnadnění navigace by bylo vhodné do aplikace zabudovat drobečkovou navigaci19 .

Obrázek 1: Informační architektura webové aplikace

Drátěný model na obrázku 2 zobrazuje rozvržení jednotlivých elementů na stránce. Bylo zvoleno klasické rozvržení elementů, které je pro návštěvníka intuitivní. K vytvoření drátěného modelu byl využit software Balsamiq20 . 19

Breadcrumb trail je navigační prvek znázorňující pozici aktuálně zobrazené stránky v hierarchii informační architektury webu. 20 http://www.balsamiq.com/

4.3

Návrh datového modelu

20

Obrázek 2: Drátěný model podstránky webové aplikace pro přihlášeného uživatele

Pro grafickou šablonu vytvořenou podle výše uvedených zásad je důležité použít jednoduchý způsob sdílení této šablony všemi stránkami webové aplikace bez nutnosti vkládat celý kód do každé z nich. Uživatelé budou s aplikací komunikovat prostřednictvím řady formulářů, u nichž bude potřeba provést validaci některých vstupních polí. Bude nutné provádět formální a logickou kontrolu správnosti zadaných informací (např. kontrolu správně zadané emailové adresy, kontrolu vyplnění požadovaného pole atp.) a kontrolu unikátnosti (např. kontrolu unikátnosti uživatelského jména při registraci nového uživatele).

4.3

Návrh datového modelu

Pro uchování dat má být využit databázový systém PostgreSQL. Na základě stanovených požadavků na vytvářenou aplikaci vznikla nutnost evidovat řadu údajů, proto musí být navržen datový model s optimalizovanou strukturou pro zamezení vzniku redundancí a zajištění rychlého a co možná nejméně komplikovaného přístupu k datům.

4.3

Návrh datového modelu

4.3.1

21

Entitně relační diagram (ERD)

Pro aplikaci byl vytvořen návrh datového modelu v podobě entitně relačního diagramu na obrázku 3. K vytvoření daného diagramu byl použit online softwarový nástroj Gliffy21 .

Obrázek 3: ER diagram datového modelu webové aplikace

4.3.2

Entity a vztahy mezi nimi

U každé entity je primárním klíčem atribut ID. Cizí klíče jsou představovány vtahy mezi tabulkami. Entita Sekce (uploadserver section) má povinné atributy ID, název a popis. Entita Vlákno (uploadserver thread) má taktéž povinné atributy ID a název, atribut popis je však nepovinný (může nabývat hodnoty NULL). Vztah sekce a vlákna je typu 1:M. Sekce může obsahovat více vláken, vlákno musí náležet právě jedné sekci. Entita Soubor (uploadserver file) eviduje ID, název souboru, adresu URL pro stažení, počet stažení souboru a typ obsahu (content type). Vláknu musí náležet jeden nebo více souborů, soubor vždy musí být zahrnut právě v jednom vláknu. 21

www.gliffy.com/

4.3

Návrh datového modelu

22

Entita Uživatel (uploadserver user) povinně zaznamenává všechny své atributy: ID, uživatelské jméno, heslo (v dostatečně chráněné podobě), křestní jméno a příjmení, emailovou adresu a také dva příznaky, atributy typu boolean, které jsou popsány v dalších odstavcích. Uživatel může být autorem více vláken, vlákno musí patřit právě jednomu uživateli. Tento vztah je typu 1:M. První příznak je atribut is admin. Pokud je nastaven na hodnotu TRUE, aplikace takovému přihlášenému uživateli umožní přístup k funkcím, které jsou k dispozici administrátorovi. V opačném případě bude aplikace k přihlášenému uživateli přistupovat jako k běžnému uživateli. Tento příznak nelze v prostředí aplikace změnit. Druhým příznakem je atribut is active. Po registraci nového uživatele se tento atribut vždy nastaví na hodnotu TRUE. Změna na hodnotu FALSE nastane po „smazáníÿ uživatele administrátorem, kdy nedojde přímo k odstranění uživatele (ani jeho vláken, souborů a komentářů), ale dojde pouze ke změně zmiňovaného příznaku kontrolovaného při autentizaci uživatele – daný uživatel se pak již nebude moci přihlásit. Entita Záznam o přihlášení (uploadserver signin log) povinně eviduje položky ID, počet přihlášení a datum registrace. Atribut datum posledního přihlášení je nepovinný, neboť po registraci nového uživatele, který ještě neměl možnost se do systému přihlásit, se tato hodnota nastaví na NULL. Atributy zaznamenávající datum a čas budou datového typu timestamp (časové razítko). Vztah mezi entitou Uživatel a entitou Záznam o přihlášení je typu 1:1; uživatel musí mít právě jeden záznam o přihlášení a záznam musí patřit právě jednomu uživateli. Entita Komentář (uploadserver comment) má tři povinné atributy: ID, obsah komentáře a časové razítko. Vztah entity Uživatel s entitou Komentář je typu 1:M; uživatel může být autorem více komentářů, komentář musí náležet právě jednomu uživateli. Existuje také vztah mezi entitou Vlákno a entitou Komentář. Tento vztah je taktéž typu 1:M; vlákno může mít více komentářů v diskuzi, komentář musí náležet právě jednomu vláknu.

5

VOLBA TECHNOLOGIÍ PRO IMPLEMENTACI

5

23

Volba technologií pro implementaci

Realizovaná aplikace má být implementována pomocí programovacího jazyka Java. Platforma Java od Sun Microsystems22 je rozdělena na tři hlavní edice: ˆ Java ME (Micro Edition)

– Java ME poskytuje API pro vývoj softwaru pro zařízení s omezenými prostředky (např. mobilní telefony). ˆ Java SE (Standard Edition)

– Tato edice se používá při vývoji a provozu portable (přenositelných) aplikací pro obecné použití. ˆ Java EE (Enterprise Edition)

– Java Enterprise Edition poskytuje API a běhové prostředí pro vývoj a provoz podnikových (enterprise) aplikací. Pojem enterprise aplikace označuje skupinu spolehlivých, robustních, škálovatelných a bezpečných serverových aplikací s vícevrstvou architekturou. Jedná se o software používaný v komerčních a vládních organizacích. Typickými představiteli enterprise aplikací jsou například rozsáhlé podnikové systémy, bankovní aplikace, webové aplikace a jiný komplexní software. Vzhledem k charakteru aplikace bylo tedy zvoleno využití technologií platformy Java EE, která je navržena pro vývoj webových aplikací. Vývoj například pomocí skriptovacího programovacího jazyka PHP23 (ve srovnání s použitím Java EE technologií) je sice mnohem rychlejší a méně náročný (to platí i pro zvládnutí dané technologie programátorem), ale výslednému kódu je obtížnější porozumět a navíc údržba takové aplikace je náročnější.

5.1

Java EE

Java EE (dříve J2EE) je standardizovaná platforma určená pro vývoj enterprise aplikací v jazyce Java. Rozšiřuje platformu Java SE o podporu pro tvorbu webových aplikací, webových služeb a distribuovaných vícevrstvých aplikací. Aktuální verzí platformy je Java EE verze 6. Jedná se o kolekci standardizovaných komponent, kontejnerů a služeb pro vývoj a nasazení distribuovaných aplikací. Webové stránky společnosti Sun uvádí: „Java Platform, Enterprise Edition (Java EE) definuje standard pro vývoj komponentně orientovaných vícevrstvých enterprise aplikací.ÿ Jak naznačuje název, platforma Java EE je cílená na podnikové systémy velkého rozsahu. Software, který pracuje na této úrovni, neběží na jednom serveru, ale 22 23

V roce 2009 došlo k akvizici společnosti Sun Microsystems společností Oracle. http://www.php.net/

5.2

Apache Wicket

24

vyžaduje mnohem větší výpočetní výkon. Z tohoto důvodu je nutné software rozdělit na více funkčních součásti a nasadit na vhodné hardwarové platformy. Toto je podstata distribuovaného computingu24 . Java EE poskytuje soubor standardizovaných komponent, které usnadňují nasazení softwaru, standardních rozhraní, jež definují způsob propojení různých softwarových modulů, a standardních služeb určujících způsob komunikace těchto softwarových modulů. (Mukhar, Zelenak, Weaver a Crume, 2006, s. 2) Existuje velká řada rámců pro tvorbu webových aplikací v jazyce Java. V kapitole 4.1 jsou stručně charakterizovány jednotlivé vrstvy třívrstvé architektury enterprise aplikací. Pro implementaci každé z vrstvy je využit nějaký framework. Pro implementaci prezentační vrstvy je použit komponentně orientovaný nástroj Apache Wicket. Aplikační vrstva využívá služeb (řízení transakcí, dependency injection, apod.) frameworku Spring. Přístup k databázi je realizován pomocí perzistenčních služeb nástroje pro objektově-relační mapování Hibernate. Následující kapitoly jsou věnovány výše uvedeným frameworkům.

5.2

Apache Wicket

Apache Wicket25 je komponentně orientovaný rámec pro tvorbu webových aplikací v programovacím jazyce Java. Tento rámec se vyznačuje vysokou abstrakcí nad HTTP protokolem – programátor nepracuje s HTTP protokolem přímo, proto se vývoj webové aplikace pomocí tohoto nástroje blíží vývoji desktopové aplikace. V rámci řešené aplikace je framework Wicket použit pro správu její prezentační vrstvy. Wicket překonává celkový nesoulad mezi stavovým, objektově orientovaným programováním v jazyce Java na straně serveru a faktem, že web je postaven na bezstavovém protokolu HTTP. Při programování v Javě není nutné přemýšlet nad tím, jak JVM (Java Virtual Machine) spravuje instance tříd a členské proměnné. Oproti tomu při vytváření webových stránek přímo na protokolu HTTP je nutné spravovat všechna uživatelská rozhraní a stavy relací ručně. (Dashorst a Hillenius, 2009, s. 5) Protokol HTTP neposkytuje rozšířenou komunikaci mezi klientem a serverem. Každý požadavek je vždy nezávislý v tom smyslu, že neexistuje vztah s žádným předchozím požadavkem. Požadavky neznají stav aplikace na serveru. U webových aplikací je však nutná komunikace a znalost stavů, které se hromadí při uživatelské interakci s aplikací. (Dashorst a Hillenius, 2009, s. 7) Uložením stavu v URL26 v podobě parametrů se dosáhne toho, že stav je poskytován klientem (což je nutné, když není možné uchovávat stav na serveru). Při vývoji 24

Pojem distribuovaný computing označuje způsob řešení výpočetně extrémně náročných úloh, které je možné paralelizovat, tj. rozdělit na velké množství malých, na sobě nezávislých výpočtů. 25 http://wicket.apache.org/ 26 Uniform Resource Locator je řetězec znaků s definovanou strukturou představující referenci na umístění zdrojů na Internetu.

5.2

Apache Wicket

25

webových aplikací má však ukládání stavu do URL několik podstatných nevýhod: bezpečnostní riziko (uživatel se může snažit uhodnout URL a může tak dojít k neautorizovanému přístupu k jemu za běžných okolností nepřístupné funkcionalitě), omezení možností modularizace softwaru (každý odkaz a každý formulář na stránce musí znát stav všech ostatních komponent na stránce, aby bylo možné poskládat URL) a nutnost tvorby reprezentace objektů pomocí řetězce (řetězec znaků v URL je nutné dekódovat zpět na objekty). Výše popsaný přístup přenosu stavu prostřednictvím URL není všeobecně považován za vhodný. Všechny vyspělé technologie proto podporují koncept relací. (Dashorst a Hillenius, 2009, s. 9) Relace představuje konverzaci, která (obvykle) začíná při prvním přístupu uživatele na stránku a končí buď explicitně (odhlášení uživatele), nebo z důvodu vypršení časového limitu relace. V Javě je podpora relací pro webové aplikace implementována pomocí objektů třídy HttpSession (Servlet API). Servletové kontejnery jsou zodpovědné za zaznamenávání každé uživatelské relace a odpovídajících objektů relace. Hlavním problémem s umístěním veškerého stavu do relace je to, že nelze předpokládat způsob, jakým bude uživatel procházet webovými stránkami (možnost využití záložek a tlačítek Zpět a Vpřed v prohlížeči). Není tedy možné vědět, kdy je správná chvíle pro promazání proměnných evidovaných v relaci. Z tohoto důvodu je správa využití paměti na straně serveru obtížná. (Dashorst a Hillenius, 2009, s. 10) Při použití Wicketu není nutné rozhodovat o způsobu předávání stavu. Framework spravuje stav transparentně, pro implementaci logiky stránek a komponent je tedy možné aplikovat obvyklý způsob programování v jazyce Java. Objekty v Javě implicitně zaznamenávají stav (objekt = stav + chování). Rozvržení (layout) stránek se definuje pomocí běžných HTML šablon. (Dashorst a Hillenius, 2009, s. 5–10) 5.2.1

Programovací model

Wicket poskytuje programovací model, který řeší problém nesouladu bezstavového protokolu HTTP a objektově orientovaného programování v Javě. Tento model skrývá fakt, že se pracuje na bezstavovém protokolu. Vývoj webové aplikace pomocí nástroje Wicket je představován programováním v Javě, programováním v HTML a používáním smysluplných abstrakcí. Wicket umožňuje programovat komponenty a stránky prostřednictvím běžných konstrukcí programovacího jazyka Java. Komponenty se tvoří pomocí klíčového slova new, je možné vytvářet hierarchie přidáním potomků do rodičovských komponent a pomocí klíčového slova extend je možné dědit funkcionalitu jiných komponent. Wicket umožňuje plně využívat silných stránek jazyka Java a také řadu vývojových prostředí (IDE), která jsou pro něj dostupné. Ačkoliv je Java ideální pro implementaci chování webových aplikací, není vhodná pro definici rozvržení stránek. Pro vytvoření prezentačního kódu se ve Wicketu používá čistý značkovací jazyk HTML. (Dashorst a Hillenius, 2009, s. 11)

5.2

Apache Wicket

26

Při využití Wicketu je prezentační část aplikace definována v HTML šablonách. Rámec požaduje, aby HTML šablony obsahovaly výhradně statický prezentační kód a zástupné znaky pro napojení Wicket komponent. Tímto požadavkem se liší od většiny frameworků (např. Struts27 , Stripes28 , Play!29 , JavaServer Faces30 nebo Tapestry31 ). Kód HTML šablony vypadá následovně:

<span wicket:id=”name” />

Pomocí třídy v jazyce Java je do stránky třeba přidat komponentu ListView32 s identifikátorem list a pro každý řádek této komponenty je nutné poskytnout potomka s identifikátorem name. Wicket definuje abstrakce všech prvků, které je možné pozorovat na typické webové stránce, jako například odkazy, rozbalovací nabídky, textová pole a tlačítka. Framework také poskytuje abstrakce, jež nejsou přímo viditelné: aplikace, relace, stránky, validátory atd. Programování vlastních komponent představuje způsob, jak vytvořit abstrakce „na míruÿ pro vlastní doménové objekty. (Dashorst a Hillenius, 2009, s. 14) Zde se projevují výhody objektově orientovaného programování spočívající v tom, že jazyk umožňuje vytvořit abstrakce objektů z reálného světa a dodat jim vlastnosti a chování. V aplikaci vytvářené pomocí rámce Wicket se každá stránka skládá ze souboru Java třídy a přidružené HTML šablony. Oba tyto soubory musí mít stejný název (včetně velikosti písmen) a musí být uloženy ve stejném balíkovém adresáři: src/main/java/cz/mendelu/pef/xkotikov/bp/uploadserver/ pages/index/Index.java src/main/java/cz/mendelu/pef/xkotikov/bp/uploadserver/ pages/index/Index.html 27

http://struts.apache.org/ http://www.stripesframework.org 29 http://www.playframework.org/ 30 http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 31 http://tapestry.apache.org 32 Komponenta ListView je jedním z opakovačů. Tato komponenta jako parametr obdrží objekt třídy List obsahující seznam objektů a pro každý z těchto objektů zopakuje značkovací kód. 28

5.2

Apache Wicket

5.2.2

27

Wicket komponenty

Komponenty, stejně jako objekty, jsou znovupoužitelné softwarové moduly. Rozdíl mezi komponentami a objekty není velký – komponenty zapouzdřují nejen data, ale také procesy a je možné na ně pohlížet jako na funkcionalitu pro koncového uživatele, zatímco objekty se primárně orientují na data. Podle této definice příklady komponent jsou služba hlášení předpovědi počasí a modul pro validaci kreditní karty, a příklady objektů jsou uživatel a bankovní účet. (Dashorst a Hillenius, 2009, s. 31) Klíčovými vlastnostmi Wicket komponent jsou soběstačnost, znovupoužitelnost a požadavek využití jazyka Java (tvorba a použití komponent vyžaduje znalost pouze a jen jazyka Java). Wicket komponenta se vždy skládá z následujících tří částí, které spolu úzce spolupracují: ˆ statická HTML šablona

– Na základě hodnoty identifikátoru wicket:id Wicket připojí Java komponentu s daným identifikátorem v atributu k tagu, v němž je daný atribut definován. <span wicket:id=”message”> [sem Java komponenta vloz ˇı ´ obsah] ˆ Java komponenta

– Java komponenty představují abstrakce prvků, které obsahuje webová stránka. Tyto komponenty dodají dynamické součásti do HTML šablony. Je nutné, aby každá Java komponenta dědila ze základní třídy org.apache.wicket.Component, která zapouzdřuje minimální chování a charakteristiky. Existuje mnoho druhů komponent; jak generické, tak specifické. Label messageLabel = new Label(”message”); ˆ model

– Modely jsou využívány Java komponentami pro získání dat pro dané dynamické součásti. messageLabel.setDefaultModelObject(”Ahoj!”); HTML šablony nikdy neobsahují skutečnou logiku zpracování a zabývají se výhradně prezentací. Logika uživatelského rozhraní (například kdy zobrazit tlačítko a co provést po kliknutí na něj) je obsažena v Java komponentách, které také udržují stav (například na které stránce komponenty PageableList se uživatel aktuálně nachází). Použití Wicket modelů, které určují způsob získání dat pro Java komponenty, je volitelné. (Dashorst a Hillenius, 2009, s. 39)

5.2

Apache Wicket

28

Koncept modelů pochází ze softwarové architektury Model-View-Controller (MVC), kterou se zabývá následující kapitola. Samotným Wicket modelům je věnována kapitola 5.2.4. 5.2.3

MVC

Softwarová architektura Model-View-Controller rozlišuje tři elementy, z nichž každý má vlastní zodpovědnost. Tyto elementy představují odlišné části celku: ˆ model (model)

– Model představuje doménový model a interakce s ním. Doménový model obsahuje abstrakci objektů z reálného světa (uživatelé, soubory, vlákna, komentáře atd.), pro které je systém vyvíjen. ˆ view (pohled)

– Pohled vykresluje elementy uživatelského rozhraní, stará se o způsob zobrazení komponent a dotazuje se modelu na dynamické součásti. ˆ controller (řadič)

– Řadič reaguje na události pocházející od uživatele (kliknutí na odkaz, odeslání formuláře s vyplněným textovým polem apod) a pomocí nich aktualizuje model. Ve Wicketu je pohled a řadič představován Wicket komponentou, vlastní doménové objekty hrají roli modelu. (Dashorst a Hillenius, 2009, s. 40) Návrhový vzor MVC a třívrstvá architektura jsou velice podobné koncepty, které se liší topologicky. Základním pravidlem třívrstvé architektury je, že prezentační vrstva nikdy nekomunikuje přímo s datovou vrstvou – veškerá komunikace v třívrstvém modelu musí projít přes prostřední vrstvu aplikační logiky. Třívrstvá architektura je konceptuálně lineární. Oproti tomu architektura Model-ViewController je trojúhelníková: pohled posílá aktualizace řadiči, řadičem je aktualizován model a pohled dostává aktualizace přímo od modelu. V dnešní době je architektura MVC, řídící se principem oddělení zodpovědností (Separation of Concerns, SoC), aplikována výhradně na prezentační vrstvu většího systému. Architektura zde využívá vrstvu aplikační logiky pro naplnění modelů daty z vrstvy perzistence dat. 5.2.4

Wicket modely

Wicket modely zprostředkovávají přístup k datům, jimiž se naplní přidružené komponenty. Modely oddělují doménový model (uživatel, sekce, vlákno, soubor apod.) od Wicket komponent (textové pole, stránka, formulář), ale zároveň tyto doménové třídy a komponenty také navzájem provazují, a tvoří tak soudržnou a úhledně vrstvenou strukturu. Wicket modely komponentám umožňují získat svá data, když

5.3

Spring

29

je potřeba vykreslit obsah těchto komponent, a také umožňují konvertovat a uložit uživatelský vstup v případě, že dojde k nějaké události. Z úhlu pohledu komponenty plní Wicket modely roli modelu architektury MVC. (Dashorst a Hillenius, 2009, s. 82) Wicket poskytuje řadu užitečných implementací modelu. Nejpoužívanějšími z nich jsou: Model, což je jednoduchý model pro ukládání statického obsahu; PropertyModel, jenž přistupuje ke konkrétní vlastnosti doménového objektu; CompoundPropertyModel, model umožňující provázat komponentu s vlastnostmi doménového objektu na základě identifikátoru komponenty; dále pak LoadableDetachableModel, odpojitelný, abstraktní model, který zapouzdřuje získaný objekt v paměti po dobu požadavku, čímž minimalizuje využití paměti; a nakonec ResourceModel, který pracuje s lokalizovanými zprávami. (Dashorst a Hillenius, 2009, s. 84) Ukázku použití modelu CompoundPropertyModel představuje zdrojový kód 7 v kapitole 6.7, jež je věnována validaci formulářů, na straně 42.

5.3

Spring

Spring33 je populární open source framework pro vývoj vícevrstvých enterprise aplikací v programovacím jazyce Java. V řešené aplikaci je rámec Spring použit pro správu jedné z vrstev aplikace – aplikační (business) vrstvy. Spring usnadňuje vývoj aplikací v programovacím jazyce Java prostřednictvím několika klíčových strategií: ˆ odlehčený a neinvazivní vývoj pomocí POJO objektů34 ˆ odstranění těsných programových vazeb jednotlivých POJO objektů a vrstev pomocí návrhového vzoru Inversion of Control (viz kapitola 5.3.1) ˆ odstranění závislosti na roztroušených konfiguračních souborech a z toho vyplývajícího pracného dohledávání jejich významu ˆ podpora implementace komponent pro přístup k datům (buď formou JDBC35 , či ORM36 technologií a nástrojů)

Rámec Spring byl vytvořen pro zjednodušení komplexního vývoje enterprise aplikací. Využití tohoto rámce není omezeno pouze na vývoj na straně serveru – libovolná 33

http://www.springsource.org/ Plain Old Java Object představuje obyčejný Java objekt, který se neřídí žádným z modelů, frameworků, ani koncepcí. 35 Java Database Connectivity je API pro programovací jazyk Java, které definuje způsob přístup k relační databázi, http://www.oracle.com/technetwork/java/javase/jdbc/index.html 36 Objektově-relační mapování je v softwarovém inženýrství pojem označující programovací techniku, která zajišťuje konverzi dat mezi objektově orientovaným jazykem a relačním databázovým systémem. 34

5.4

Hibernate

30

Java aplikace může mít z frameworku Spring prospěch, co se týká jednoduchosti, testovatelnosti a volných vazeb. (Walls, 2011, s. 4–5) Následující kapitola se zabývá pojmy Inversion of Control a Dependency Injection, které jsou klíčové pro rámec Spring. 5.3.1

Inversion of Control a Dependency Injection

Inversion of Control (IoC, ve volném překladu obrácené řízení) je abstraktní princip objektově orientovaného programování spočívající v přesunutí zodpovědnosti za vytvoření a provázání objektů z aplikace na framework. Spring je označován jako IoC kontejner, neboť jeho jádro je postaveno na využití tohoto principu. Princip IoC by se dal vyjádřit myšlenkou „Nevolej mě, já zavolám tebeÿ. V praxi to znamená, že software je zavolán frameworkem (místo toho, aby byl software instruován zavolat daný framework). Kontejner je zodpovědný za správu životního cyklu objektů, který zahrnuje tvorbu objektů, volání inicializačních metod a konfiguraci objektů jejich propojením. (Johnson et al., 2004–2010) Objekty vytvořené kontejnerem se nazývají beany. Kontejner je typicky konfigurován pomocí XML souboru obsahujícího definice bean, jež poskytují informace potřebné k vytvoření těchto bean z objektů POJO. Při výchozím nastavení je konfigurační XML soubor applicationContext.xml vyhledáván v adresáři webapp. Toto nastavení je možné změnit v konfiguračním souboru web.xml. Ukázky konfiguračních souborů se nachází ve zdrojových kódech 2 a 3 v kapitole 6.2 zabývající se konfigurací aplikace. Objekty je možné získat s využitím prostředků návrhového vzoru Dependency Injection, což je konkrétní technika principu Inversion of Control. Dependency Injection, v překladu vkládání závislostí, umožňuje tvorbu komponent až za běhu aplikace, ne již při kompilaci.

5.4

Hibernate

Relační databázové systémy v současné době představují nejrozšířenější prostředek pro perzistenci37 a správu dat aplikací. Relační struktura těchto databází se však diametrálně liší od objektově orientované struktury aplikací. Z tohoto důvodu vznikla řada nástrojů umožňujících mezi těmito odlišnými strukturami data převádět. Díky těmto nástrojům vývojář získá mnohem více času na programování vlastní business logiky aplikace, neboť o konkrétní způsob uložení dat a jejich převod do objektové podoby se postará právě takový nástroj. (Krpata, 2011, s. 84) Jedním z nejpoužívanějších řešení je použití tzv. objektově-relačního mapování (Object Relational Mapping, ORM). Objektově-relační mapování představuje automatizované a transparentní řešení perzistence objektů Java aplikace v tabulkách 37

Perzistence dat je vlastnost umožňující uchovávat tato data i v případě, že program ukončí svůj běh.

5.5

HTML, CSS a JavaScript

31

v relačním databázovém systému pomocí metadat popisujících mapování mezi objekty a databází. ORM v podstatě představuje převod dat z jedné reprezentace do druhé. (Bauer a King, 2011, s. 25) Spring neposkytuje svůj vlastní ORM nástroj, ale podporuje většinu dostupných používaných implementací. Existují ORM nástroje jak pro programovací jazyk Java (Hibernate38 , TopLink39 ), tak i pro další objektově orientované jazyky (C++40 , Visual Basic .NET41 , PHP42 , Perl43 , Python44 , Ruby45 apod). ORM nástroje řeší vztahy (převod asociací mezi objekty na cizí klíče v tabulkách a naopak) a strukturu (převod mezi hodnotami atributů objektů a skalárními hodnotami tabulek). Pro každou entitu je třeba vytvořit POJO třídu s výchozím (bezparametrickým) konstruktorem a s gettery a settery46 . Objektově-relační mapování probíhá na základě metadat definovaných buď anotacemi (ukázku použití anotací u doménové třídy poskytuje zdrojový kód 4 v kapitole 6.4 na straně 38), nebo v XML souboru. (King et al., 2009) Momentálně nejvýznamnějším a nejrozšířenějším ORM nástrojem pro programovací jazyk Java je open source framework Hibernate, který kromě techniky mapování dat nabízí i celou řadu dalších funkcí v čele s možností získávání dat z databáze prostřednictvím vlastního objektově orientovaného jazyka Hibernate Query Language (HQL), který je odvozen od jazyka SQL a je mu tedy velice podobný. Framework v sobě dále zahrnuje podporu pro zpracování transakcí, kešování i vlastní datové typy. (Krpata, 2011, s. 84) Kapitola 6.5 na straně 39, která se zabývá servisními třídami, poskytuje ukázku použití jazyka HQL.

5.5

HTML, CSS a JavaScript

HTML (HyperText Markup Language), CSS (Cascading Style Sheets) a JavaScript (JS) jsou při vývoji webových stránek navzájem doplňkové jazyky. HTML se převážně používá pro organizaci komponent na webové stránce, kaskádové styly se využívají při definici prezentačního stylu obsahu a JavaScript definuje, jak se obsah chová a interaguje s uživatelem. 38

http://www.hibernate.org/ http://www.oracle.com/technetwork/middleware/toplink/overview/index.html 40 http://www.cplusplus.com/ 41 http://msdn.microsoft.com/en-us/vstudio/hh388568 42 http://www.php.net/ 43 http://www.perl.org/ 44 http://www.python.org/ 45 http://www.ruby-lang.org/ 46 Jedná se o get a set metody pro získání, resp. nastavení hodnoty atributu objektu. 39

5.6

5.6

Vývojové prostředí

32

Vývojové prostředí

Vývojové prostředí se označuje zkratkou IDE (Integrated Development Environment). Jedná se o software usnadňující práci programátorů, většinou zaměřený na jeden programovací jazyk. IDE typicky obsahuje editor zdrojového kódu, nástroj pro automatizaci buildů47 aplikace a většinou také debugger. Některá vývojová prostředí také obsahují prostředky pro refaktorování a automatické doplňování kódu. SpringSource Tool Suite48 (STS) je dostupný jako kompletní vývojové prostředí, nebo jako plugin do velmi oblíbeného vývojového prostředí Eclipse49 , na němž je STS založeno. Prostředí je určeno pro vývoj aplikací v jazycích Java, Groovy50 a AspectJ51 ve frameworcích Spring, Spring Roo52 a Grails53 . STS podporuje verzovací systém Apache Subversion54 (SVN), nástroj Apache Maven55 a další.

5.7

Další vývojové nástroje

Pro databázový systém PostgreSQL je dostupný open source administrační nástroj s grafickým uživatelským rozhraním pgAdmin56 , který je podporován na většině populárních platforem. Použití nástrojů Firebug57 a Web Developer58 , které se instalují do prohlížeče jako doplňky, usnadňuje vývoj prezentační vrstvy webové aplikace. Firebug, rozšíření pro prohlížeč Mozilla Firefox, usnadňuje ladění, úpravu a monitorování technologií CSS, HTML, DOM, XHR a JavaScript na webové stránce. Rozšíření Web Developer do prohlížeče přidá nejrůznější nástroje pro vývoj prezentační vrstvy aplikace.

47 Automatizace vykompilované verze vyvíjeného softwaru je proces automatizace široké řady úloh, mezi které patří například kompilace zdrojového kódu, spouštění testů, nasazení na produkční systémy, tvorba dokumentace atd. 48 http://www.springsource.com/developer/sts 49 http://www.eclipse.org/ 50 http://groovy.codehaus.org/ 51 http://www.eclipse.org/aspectj/ 52 http://www.springsource.org/spring-roo 53 http://grails.org/ 54 http://subversion.apache.org/ 55 http://maven.apache.org/ 56 http://www.pgadmin.org/ 57 http://getfirebug.com/ 58 http://chrispederick.com/work/web-developer/

6

IMPLEMENTACE

6

33

Implementace

V kapitole 5 bylo rozhodnuto, že vyvíjená aplikace bude postavena na platformě Java EE a její architektura bude třívrstvá. Na prezentační vrstvu realizované třívrstvé aplikace byla aplikována architektura MVC, jak je tomu dnes zvykem při vývoji většího systému. Pro usnadnění vývoje aplikace napříč všemi jejími vrstvami budou využity následující rámce: ˆ rámec Apache Wicket (verze 1.5.4 s datem vydání 17. ledna 2012), kterému se tato práce důkladněji věnuje v kapitole 5.2 na straně 24 ˆ framework Spring (verze 3.0.5 vydaná v říjnu 2010), o němž blíže pojednává kapitola 5.3 na straně 29 ˆ nástroj pro objektově-relační mapování Hibernate (ve verzi 3.6.10 s datem vydání 9. února 2012), jemuž je věnována kapitola 5.4 na straně 30

Při implementaci systému ve vývojovém prostředí STS byl využit také nástroj Apache Maven sloužící k automatizaci buildů aplikace. Při vývoji webové aplikace byl použit značkovací jazyk XHTML (specifikace XHTML 1.0 ve verzi Strict) a jazyk CSS (CSS level 3). Dále byl také využit skriptovací jazyk JavaScript, konkrétně knihovna jQuery, pro vytvoření hlavního horizontálního menu. Pro tvorbu a úpravu grafických prvků byl použit open source nástroj GIMP verze 2.6.10 v operačním systému Linux. Vývoj aplikace a její testování bylo prováděno v prohlížečích Firefox 11.0, Opera 11.60 a Google Chrome 5.0.375.125 na platformě Linux.

6.1

Struktura aplikace

Struktura upload serveru v podobě stromu ve vývojovém prostředí STS s hierarchií balíků je zobrazena na obrázku 4. Hlavní balík cz.mendelu.pef.xkotikov.bp.uploadserver obsahuje Java třídy a HTML šablony představující společnou funkcionalitu pro všechny ostatní součásti aplikace. Nachází se zde třída UploadServerApplication, která dědí ze třídy Application. Každá Wicket aplikace vyžaduje svou vlastní třídu Application s překrytou metodou init(), která inicializuje aplikaci a nakonfiguruje Wicket a v případě potřeby nastaví integraci s dalšími frameworky. V tomto balíku se také nachází třída InitDB sloužící k inicializaci dat v prázdné databázi (viz kapitola 6.13.1 na straně 48), dále třída ErrorPage poskytující vlastní chybovou stránku (viz kapitola 6.10 na straně 45), třída UploadServerBasePage (viz kapitola 6.3 na straně 37) a třída UploadServerSession, jejíž instance ukládá relaci pro jednoho uživatele po dobu jeho aktivity.

6.1

Struktura aplikace

34

Obrázek 4: Struktura balíků se zdrojovými kódy aplikace

Třídy potřebné pro zabezpečení aplikace (viz kapitola 6.6 na straně 40) patří do balíků cz.mendelu.pef.xkotikov.bp.uploadserver.authentication a cz.mendelu.pef.xkotikov.bp.uploadserver.authorization. Třídy v balíku cz.mendelu.pef.xkotikov.bp.uploadserver.domain slouží k definici doménových objektů (viz kapitola 6.4 na straně 38). Java třídy a HTML šablony obsažené v balících vyhovujících vzoru cz.mendelu.pef.xkotikov.bp.uploadserver.pages.* definují části aplikace, které jsou určené na základě příslušnosti jednotlivých webových stránek do hlavních kategorií informační architektury aplikace (viz obrázek 1 na straně 19). Balík cz.mendelu.pef.xkotikov.bp.uploadserver.service obsahuje servisní třídy sloužící k práci s databází (viz kapitola 6.5 na straně 39) a v balíku cz.mendelu.pef.xkotikov.bp.uploadserver.util se nachází třída

6.2

Konfigurace aplikace

35

Parameters, pomocí níž je možné získat hodnoty parametrů uložených v souboru uploadserver.properties, a dále také třída Constants, která obsahuje konstanty pro maximální velikost nahrávaného souboru a pro cestu k adresáři na serverovém disku, kde jsou uloženy uploadované soubory. Z obrázku 4 je také patrné umístění konfiguračních souborů pom.xml, web.xml, persistence.xml, applicationContext.xml a uploadserver.properties, jimiž se zabývá další kapitola, a souboru log4j.properties zmiňovaném v kapitole 6.11 na straně 46.

6.2

Konfigurace aplikace

Pro konfiguraci Maven projektu je nezbytný soubor pom.xml, který definuje jednotlivé části projektu a jeho závislosti na externích knihovnách a nástrojích. Tento XML dokument se nachází v kořenovém adresáři projektu. Zdrojový kód 1 ukazuje část tohoto souboru v realizované aplikaci. Zdrojový kód 1: Konfigurační soubor pom.xml <project> <modelVersion>4.0.0 cz.mendelu.pef.xkotikov.bp <artifactId>uploadserver 1.0 ... <properties> <wicket.version>1.5.4 <spring.version>3.0.5.RELEASE 3.6.10.Final ... <dependencies> <dependency> org.apache.wicket <artifactId>wicket-core ${wicket.version} <dependency> org.apache.wicket <artifactId>wicket-extensions ${wicket.version} ...

6.2

Konfigurace aplikace

36

Popisovač nasazení aplikace web.xml, který se nachází ve složce WEB-INF/ kořenového adresáře webové aplikace, umožní zaregistrovat Wicket servlet a namapovat ho přímo na URL kořenového kontextového adresáře serveru. Následuje zdrojový kód 2 s částí souboru web.xml, která říká Wicket filtru, aby k vytvoření instance objektu Application použil tovární třídu SpringWebApplicationFactory. Zdrojový kód 2: Konfigurační soubor web.xml ... UploadServer org.apache.wicket.protocol.http. WicketFilter <param-name>applicationFactoryClassName <param-value>org.apache.wicket.spring. SpringWebApplicationFactory ... UploadServer /* ... Samotná aplikace je tedy definována pomocí výše uvedené továrny, která očekává svůj kontext v souboru applicationContext.xml. V tomto klíčovém souboru se definují jednotlivé Spring beany využívané v aplikaci. Zdrojový kód 3 ukazuje malou část souboru applicationContext.xml. Zdrojový kód 3: Soubor applicationContext.xml ... <property name=”driverClassName” value=”${jdbc.driver}” /> <property name=”url” value=”${jdbc.url}” /> <property name=”username” value=”${jdbc.username}” />

6.3

Uživatelské rozhraní

37

<property name=”password” value=”${jdbc.password}” /> ... V kódu jsou definovány dvě Spring beany. První beana umožňuje rámci Spring spravovat třídu Application (k tomu je však nutné definovat Wicket filtr, viz zdrojový kód 2). Druhá beana slouží k navázání spojení s databází. Při určování jejích vlastností jsou využity placeholdery (zástupné znaky) definované v souboru uploadserver.properties, například definice JDBC driveru (ovladače) vypadá následovně: jdbc.driver=org.postgresql.Driver Pro konfiguraci instance EntityManager, která umožňuje v databázi vyhledat entity podle primárního klíče, vytvořit perzistentní instance entity, nebo je odebrat apod., slouží soubor persistence.xml. (Soldano et al., 2008) V tomto souboru se mimo jiné určuje typ databáze (dialect): <property name=”hibernate.dialect” value=”org.hibernate.dialect.PostgreSQLDialect”/> V případě realizované aplikace je definována databáze PostgreSQL. Další důležitou položkou je také nastavení automatické validace nebo exportu schématu do databáze po vytvoření továrny relace: <property name=”hibernate.hbm2ddl.auto” value=”update”/>

6.3

Uživatelské rozhraní

Implementované uživatelské rozhraní se řídí zásadami a pravidly stanovenými v kapitole 4.2 na straně 18 o návrhu uživatelského rozhraní. Rozvržení jednotlivých stránek je v rámci celé aplikace konzistentní bez toho, aniž by byl kód Java tříd nebo HTML šablon duplikován. Wicket umožňuje sdílení společného kódu pomocí dědičnosti jak Java třídám, tak HTML šablonám. Všechny stránky aplikace dědí ze základní webové stránky, která je tvořena třídou UploadServerBasePage.java a šablonou UploadServerBasePage.html. Java třídy dědí veškeré společné komponenty pomocí klíčového slova extend a HTML šablony dědí společný kód prostřednictvím tagů <wicket:extend> a <wicket:child>. Z obrázku 4 zobrazujícího strukturu balíků je také možné zjistit umístění souboru style.css, jenž obsahuje CSS kód. Všechny obrázky použité na webových stránkách jsou uloženy v adresáři images. Použité grafické formáty jsou JPEG, GIF

6.4

Doménové objekty

38

a PNG. Ikony vlajek České republiky a Spojeného království sloužící pro přepínání jazyka aplikace (viz kapitola 6.8 na straně 43) mají ve svém tagu img definován atribut alt, jehož text se zobrazí při technické chybě (nestažení obrázku), nebo v případě, že má návštěvník v prohlížeči vypnuté zobrazování obrázků. Do webové aplikace je také zabudována ikona favicon.ico. Favikona se v prohlížeči nejčastěji zobrazuje v adresním řádku, na panelu se stránkou a v nabídce záložek. Náhledy realizované aplikace jsou připojeny v příloze A.

6.4

Doménové objekty

Ve třídách balíku cz.mendelu.pef.xkotikov.bp.uploadserver.domain jsou definovány doménové objekty, které představují objekty reálného světa (v případě upload serveru se jedná o uživatele, sekci, vlákno, soubor, komentář a záznam o přihlášení). Doménové objekty využívá rámec Hibernate pro jejich mapování na tabulky v databázi. Na základě metadat, která poskytují anotace, rámec ve schématu databáze vytvoří tabulky odpovídající doménovým objektům (a datovému modelu zobrazenému pomocí ER diagramu na obrázku 3 na straně 21). Zdrojový kód 4 obsahuje část definice třídy UploadServerSigninLog. Doménový objekt této třídy představuje záznam o přihlášení uživatele. Zdrojový kód 4: Doménová třída UploadServerSigninLog @Entity @Table(name = ”uploadserver_signin_log”) public class UploadServerSigninLog implements DomainObject { @Id @GeneratedValue(strategy=GenerationType.IDENTITY) private Long id; @OneToOne(cascade = CascadeType.ALL) private UploadServerUser uploadserverUser; @Column(name = ”registration_date”, nullable=false) @Temporal(TemporalType.TIMESTAMP) private Date registrationDate; ... public UploadServerSigninLog() { } public Date getRegistrationDate() { return registrationDate; }

6.5

Servisní třídy

39

public void setRegistrationDate(Date registrationDate) { this.registrationDate = registrationDate; } ... Každá doménová třída musí obsahovat bezparametrický konstruktor. Anotací @Entity je perzistentní POJO třída označena jako entita. Anotace @Table umožňuje určit název tabulky v databázi. U jednotlivých atributů této třídy jsou uvedeny různé anotace. Anotace @Id označuje identifikátor dané entity a anotace @GeneratedValue umožňuje určit strategii generování identifikátoru. Anotace @Column definuje vlastnosti atributů entity. Anotace @OneToOne umožňuje asociovat entity pomocí vztahu 1:1 a prostřednictvím atributu cascade umožňuje nastavit, které operace se mají provádět kaskádově.

6.5

Servisní třídy

V balíku cz.mendelu.pef.xkotikov.bp.uploadserver.service se nachází servisní třídy, které slouží pro práci s databází (získání dat, jejich vytváření, úprava a odstranění). Pro každou entitu v databázi, resp. pro každou doménovou třídu existuje jedna servisní třída. Rozhraní AbstractService deklaruje základní metody společné pro všechny servisní třídy. Tyto metody jsou implementovány ve třídě AbstractServiceImpl, z níž dědí všechny ostatní servisní třídy. Jako ukázka servisní třídy poslouží zdrojový kód 5 obsahující třídu UploadServerFilesServiceImpl, která mimo jiné implementuje metodu pro nalezení souboru na základě identifikátoru sekce. Další metody (pro uložení záznamu do databáze, odstranění záznamu z databáze, nalezení jednoho/všech záznamů v databázi apod.) třída získá děděním ze třídy AbstractServiceImpl. Zdrojový kód 5: Servisní třída UploadServerFilesServiceImpl @Service(”uploadServerFilesServiceImpl”) @Transactional(propagation = Propagation.REQUIRED) public class UploadServerFilesServiceImpl extends AbstractServiceImpl implements UploadServerFilesService { public List findFilesBySectionId( Long id) { List files = createTypedQuery( ”SELECT o FROM UploadServerFile o” + ”INNER JOIN o.uploadserverThread p” + ”WHERE p.uploadserverSection.id = :id”, UploadServerFile.class).setParameter(”id”, id)

6.6

Zabezpečení aplikace

40

.getResultList(); return files; } ... Anotace @Service označuje, že třída UploadServerFilesServiceImpl je Spring beanou, a umožňuje, aby byla třída automaticky detekována pomocí skenování cesty classpath. Anotace @Transactional u třídy určuje transakční způsob zpracování59 všech metod třídy. (Johnson et al., 2004–2010) V ukázce se také vyskytuje dotaz v jazyce HQL obsahující syntaktickou konstrukci INNER JOIN. Rámec Hibernate využívá dotazovací jazyk HQL, který je na první pohled podobný jazyku SQL. V porovnání s jazykem SQL je však jazyk HQL plně objektově orientovaný a nepracuje nad tabulkami a sloupci, ale nad doménovými objekty a jejich vlastnostmi. (King et al., 2009)

6.6

Zabezpečení aplikace

V realizované aplikaci je její zabezpečení řešeno z hlediska neautorizovaného přístupu uživatelů. Anonymní uživatel (neregistrovaný, nebo nepřihlášený) má velice omezené možnosti zobrazování obsahu webové aplikace. Přihlášený uživatel je oprávněn využívat standardní funkcionalitu aplikace. Oproti tomu administrátor má přístup k veškeré funkcionalitě systému, včetně jeho správy. Dvěma hlavními koncepty zabezpečení jsou autentizace a autorizace. 6.6.1

Autentizace

Pojem autentizace označuje proces ověření proklamované identity subjektu. V aplikaci je autentizace prováděna ověřením zadaného uživatelského jména a hesla do přihlašovacího formuláře. Ověřuje se, zda v databázi existuje uživatel s daným uživatelským jménem. Pokud ano, zkontroluje se, zda je tento uživatel aktivní (zda nebyl „smazánÿ) a zda zadané heslo odpovídá heslu uloženému v databázi. Tato logika je implementována v servisní třídě LogInOutManager. 6.6.2

Autorizace

Kromě autentizace uživatelů je nutné provést také jejich autorizaci. Administrátor má na rozdíl od běžných uživatelů přístup do podkategorií Správa uživatelů a Uživatelské statistiky, je tedy nutné odkazy do těchto podkategorií skrýt ostatním uživatelům. 59 Transakce musí být vždy provedena jako jeden celek. Pokud se při zpracování v rámci transakce vyskytne jakákoliv chyba a transakce nemůže být dokončena, všechny dílčí operace musejí být vráceny do stavu před začátkem transakce.

6.6

Zabezpečení aplikace

41

Autorizace je ve webové aplikaci řešena prostřednictvím vytvoření a použití anotace @AdminOnly a třídy UploadServerAuthorizationStrategy. 6.6.3

Zabezpečení citlivých údajů v databázi

Pokud se v databázi zaznamenávají citlivá data, je vhodné zabezpečit tyto údaje proti přímému čtení. Typickým příkladem citlivých dat jsou hesla, jejichž původní podoba v textové formě je velmi zranitelná. V realizovaném systému je pro zabezpečení hesla aplikována bezpečnostní technika salted hash60 , která je implementována v servisní třídě LogInOutManager. Implementace je uvedena ve zdrojovém kódu 6. Zdrojový kód 6: Metoda getHash třídy LogInOutManager @Service public class LogInOutManager { @Autowired UploadServerUsersService usersService; @Value(”${password.salt}”) private String salt; private String getHash(String pass) throws NoSuchAlgorithmException, UnsupportedEncodingException { MessageDigest digest = MessageDigest .getInstance(”MD5”); digest.reset(); Charset charset = Charset.forName(”UTF-8”); digest.update(salt.getBytes(charset)); byte[] n = digest.digest(pass.getBytes(”UTF-8”)); StringBuffer sb = new StringBuffer(); for (int i = 0; i < n.length; i++) { String hex = Integer.toHexString(0xff & n[i]); if (hex.length() == 1) sb.append('0'); sb.append(hex); } return sb.toString(); } ... 60

Technika salted hash spočívá v přidání náhodné posloupnosti znaků (salt) k heslu a v aplikaci kryptografické hašovací funkce na takto vzniklý řetězec.

6.7

Validace formulářů

42

Při implementaci byla použita známa hašovací funkce MD561 . Hodnota řetězce salt se získá ze souboru uploadserver.properties, kde je definován jako hodnota pro klíč password.salt.

6.7

Validace formulářů

V realizované aplikaci se nachází řada formulářů se vstupními poli, jejichž správné vyplnění je třeba kontrolovat. K tomuto účelu slouží validace formulářů. Po odeslání formuláře se všechny hodnoty vstupních polí odešlou pomocí HTTP požadavku. Rámec Wicket tento požadavek zpracuje a přiřadí jeho parametry odpovídajícím komponentám formuláře. Poté následuje zpracování formuláře, které se provádí v pěti krocích: 1. kontrola vyplnění všech požadovaných polí 2. konverze vstupní hodnoty z typu String na požadovaný datový typ 3. validace vstupu pomocí použitých validátorů 4. předání konvertovaného a validovaného vstupu modelům 5. zavolání metod onSubmit nebo onError První tři kroky jsou součástí validačního cyklu. Čtvrtý krok se provede pouze v případě, že pro všechna pole byly předchozí kroky úspěšné. (Dashorst a Hillenius, 2009, s. 162) Část třídy, která představuje formulář pro vytvoření uživatele, je uvedena ve zdrojovém kódu 7. Zdrojový kód 7: Formulář pro registraci nového uživatele public final class UserRegistrationForm extends Panel { public UserRegistrationForm(String id) { super(id); CompoundPropertyModel userModel = new CompoundPropertyModel(new UploadServerUser()); ... final TextField<String> tEmail = new TextField<String>(”email”); final TextField<String> tUsername = new TextField<String>(”username”); final PasswordTextField tPassField = new PasswordTextField(”password”); 61

Message-Digest algorithm je hašovací algoritmus, který z libovolného vstupu dat vytvoří výstup fixní délky. Hlavní vlastností algoritmu je, že malá změna vstupního řetězce má za následek vznik zcela odlišného výstupu.

6.8

Lokalizace aplikace

43

final PasswordTextField tPassField2 = new PasswordTextField(”confirmPass”, Model.of(””)); final Form form = new Form(”userRegistrationForm”, userModel); add(form); form.add(new FeedbackPanel(”feedback”)); form.add(tEmail.setRequired(true).add( EmailAddressValidator.getInstance())); form.add(tUsername.setRequired(true).add( UniqueUsernameValidator.getInstance())); form.add(tPassField); form.add(tPassField2); form.add(new EqualPasswordInputValidator( tPassField, tPassField2)); ... Registrační formulář ve třídě UserRegistrationForm je vytvořen pomocí modelu CompoundPropertyModel, vstupních textových polí a polí pro zadání hesla. Pole pro zadání emailové adresy a pole pro zadání uživatelského jména jsou povinná (metoda setRequired(boolean)). Existují dva typy validátorů: validátory poskytované frameworkem Wicket a vlastní validátory. Ve zdrojovém kódu 7 je poli pro zadání emailové adresy přidán validátor EmailAddressValidator, jenž je poskytován rámcem Wicket. Dalším Wicket validátorem, který je v ukázce kódu uveden, je validátor pro porovnání hodnot dvou polí EqualPasswordInputValidator(FormComponent formComponent1, FormComponent formComponent2). V ukázce se také nachází vlastní validátor UniqueUsernameValidator, jehož úkolem je z databáze zjistit všechna uživatelská jména a porovnat je se zadaným uživatelským jménem. Tento validátor zajistí jedinečnost uživatelských jmen v systému. Důležitou funkcionalitu, která se aplikuje po neúspěšné validaci formuláře, představuje zpětná vazba pro uživatele. K zobrazování zpětné vazby slouží komponenta FeedbackPanel (viz zdrojový kód 7).

6.8

Lokalizace aplikace

Nad rámec požadavků na realizovanou aplikaci byla provedena její lokalizace. Byly implementovány dvě její jazykové verze: česká a anglická. Pro explicitní změnu jazyka jsou určeny ikony vlajek v pravém horním rohu stránek. Obě varianty lokalizace aplikace jsou zobrazeny na obrázcích 9 a 10 v příloze A.

6.9

Optimalizace adres URL

44

Pojem lokalizace označuje adaptaci aplikace na jeden nebo více konkrétních souborů parametrů locale62 . V závislosti na locale uživatelů se liší jazyky, ve kterých jsou stránky zobrazovány. (Dashorst a Hillenius, 2009, s. 282) Metoda getLocale() třídy UploadServerSession umožňuje zjistit locale uživatele, jemuž relace náleží. Ve Wicketu existují dvě možnosti pro poskytnutí lokalizovaného textu – buď v HTML šabloně, nebo v Java třídě. V kódu HTML šablony je nutné nahradit části, které jsou závislé na locale, tagem <wicket:message>, u něhož je nutné definovat atribut key. V Java třídě je možné získat lokalizovaný text pomocí metody getString(java.lang.String key), popřípadě prostřednictvím metody ResourceModel(java.lang.String resourceKey). V obou případech se Wicket snaží vyhledat hodnotu klíče v properties, nebo v XML souboru, které se nachází ve stejném balíku jako Java třída a HTML šablona. V případě lokalizace domovské stránky aplikace vypadá strom zdrojových souborů následovně: - Index.java - Index.html - Index_cs.properties - Index_en.properties Pokud není klíč v souboru nalezen, Wicket se jej pokusí najít v souborech package cs.properties a package en.properties.

6.9

Optimalizace adres URL

Při výchozím nastavení Wicket generuje příslušnou adresu URL, která v sobě obsahuje všechny potřebné parametry. Při tomto nastavení výsledná adresa URL odkazující na stránku Kontakty vypadá následovně: localhost:8080/uploadserver/wicket/bookmarkable/ cz.mendelu.pef.xkotikov.bp.uploadserver.Contacts Výchozí adresa URL obsahuje úplný název třídy definující stránku, což není ideální, neboť tyto adresy představují veřejné rozhraní aplikace. Při přesunu stránky do jiného balíku se nově generovaná adresa změní, ale jak staré adresy (například uložené v emailu nebo v záložkách uživatele), tak indexy internetových vyhledávačů zůstanou nezměněny. Pokud tedy dojde k pokusu o přístup na webovou stránku pomocí této uložené, již neplatné adresy URL, zobrazí se chybová stránka (HTTP stavové hlášení 404: Not Found). Framework Wicket umožňuje tento problém vyřešit napojením stránky na specifickou cestu v aplikaci způsobem uvedeným ve zdrojovém kódu 8. 62

Locale je soubor parametrů definujících jazyk a stát uživatele, které se následně projeví v uživatelském rozhraní. Locale se skládá přinejmenším z identifikátoru jazyka a státu.

6.10

Vlastní chybová stránka

45

Zdrojový kód 8: Napojení stránek v metodě init() aplikace public class UploadServerApplication extends WebApplication implements ApplicationContextAware { protected void init() { super.init(); mountPage(”/contacts”, Contacts.class); getRootRequestMapperAsCompound().add(new MountMapper (”/myAccount”, new PackageMapper(PackageName .forClass(MyAccount.class)))); mountPackage(”/myAccount”, MyAccount.class); ... Uvedený kód definuje napojení stránky Kontakty a dále napojení celého balíku, který obsahuje definici všech stránek náležících do hlavní kategorie Můj účet (viz obrázek 1 na straně 19). URL stránky kontakty bude tedy po napojení vypadat následovně: localhost:8080/uploadserver/contacts

6.10

Vlastní chybová stránka

Chybová stránka je zobrazena v případě, že dojde k nějaké nečekané události, například ke ztrátě spojení s databází. Bez ohledu na to, jak důkladně je provedeno testovaní aplikace, taková neočekávaná situace dříve či později nastane. A v takovém případě je přátelská chybová stránka pro uživatele velmi přívětivým prvkem. Vlastní implementaci chybové stránky je možné poskytnout pro následující typy stránek: ˆ Access Denied (přístup zamítnut)

– Stránka se zobrazí, když je požadavek odmítnut v důsledku bezpečnostního omezení. ˆ Internal Error (interní chyba)

– Stránka je zobrazena v případě, že nastane neočekávaná chyba. ˆ Page Expired (platnost stránky vypršela)

– Tato stránka se zobrazí pro požadavek v rámci relace, která vypršela. Chybová stránka je stránka jako každá jiná, je pouze nutné ji definovat místo defaultní chybové stránky. Tuto akci je třeba implementovat v metodě init() třídy UploadServerApplication. Jedná se o následující příkazy:

6.11

Logování

46

IApplicationSettings s = getApplicationSettings(); s.setAccessDeniedPage(ErrorPage.class); s.setPageExpiredErrorPage(ErrorPage.class); s.setInternalErrorPage(ErrorPage.class);

6.11

Logování

Vytváření logů v realizované aplikaci slouží k zaznamenávání informací o důležitých provedených úkonech (podle požadavků uvedených v kapitole 3.7.1 na straně 17). Tato funkcionalita byla implementována pomocí nástroje pro logování Apache log4j, který je založen na jazyce Java. V souboru log4j.properties se nachází jeho konfigurace. Zdrojový kód 9: Konfigurační soubor log4j.properties log4j.rootLogger=INFO, Stdout log4j.appender.Stdout=org.apache.log4j.ConsoleAppender ... log4j.logger.cz.mendelu.pef.xkotikov.bp.uploadserver= INFO, uploadserverappender log4j.appender.uploadserverappender= org.apache.log4j.DailyRollingFileAppender log4j.appender.uploadserverappender.File= /home/user/UploadServer/uploadServerLog/log.log ... V tomto konfiguračním souboru je nastaven kořenový logger, jenž je vypisován do konzole (Stdout), a dále logger, který do určeného souboru loguje pouze zprávy tříd z balíku cz.mendelu.pef.xkotikov.bp.uploadserver.

6.12

JUnit testy

Testování aplikace je realizováno pomocí frameworku JUnit pro jednotkové testování63 s využitím anotací. Ve frameworku Wicket je jednotkové testování založeno na mockování64 aplikace, kdy není nutné využití běžícího webového serveru. Tester, instance třídy WicketTester, pracuje přímo s implementovanými třídami na rozdíl od rámců jako JWebUnit, HtmlUnit a Selenium, které na úrovni protokolu zasílají požadavky na běžící webový server. 63

Unit testing je metoda pro ověření správné funkčnosti jednotek zdrojového kódu. Mock představuje objekt imitující skutečnou instanci třídy, jedná se o modelovou implementaci doménového kódu. 64

6.13

Nasazení aplikace

47

WicketTester je pomocná třída, která testuje stránky a komponenty způsobem, jímž by byly volány během běžného požadavku. Velkou výhodou oproti práci na úrovni protokolu je naprostá kontrola nad jednotlivými stránkami a komponentami. Takovým způsobem je možné testovat stránku nebo komponentu v izolaci a mimo servletový kontejner, což umožní rychlejší běh testu. (Dashorst a Hillenius, 2009, s. 332) Zdrojový kód 10 ukazuje jednotkový test pro přihlašovací stránku, který testuje validátory přihlašovacího formuláře na nevyplnění požadovaných polí (uživatelské jméno a heslo). Zdrojový kód 10: Metoda pro testování validátorů přihlašovacího formuláře @Test public void signInTest() { tester = new WicketTester(new TestUploadServerApplication()); tester.startPage(SignInPage.class); FormTester formTester = tester.newFormTester (”signInForm”); tester.assertNoErrorMessage(); tester.assertNoInfoMessage(); formTester.submit(); tester.assertRenderedPage(SignInPage.class); tester.assertErrorMessages (new String[] {”pole 'Uz ˇivatelske ´ jme ´no' je povinne ´.”, ”pole 'Heslo' je povinne ´.”}); } WicketTester obdrží instanci třídy TestUploadServerApplication. Ta dědí z třídy UploadServerApplication, která je zodpovědná za vytvoření relace UploadServerSession. V následujícím kroku se zavolá příkaz pro vyrenderování stránky SignInPage. V této chvíli je vyloučena existence jakýchkoli chybových zpráv, neboť zatím došlo pouze k vykreslení stránky. Po odeslání formuláře příkazem formTester.submit(); se stránka opět vykreslí a bude obsahovat chybovou zprávu pro každé nevyplněné vstupní pole, jehož vyplnění je požadováno.

6.13

Nasazení aplikace

Zadaná webová aplikace byla vyvíjena a otestována na servletovém kontejneru Apache Tomcat verze 7.0 s použitím databázového systému PostgreSQL. Elektro-

6.13

Nasazení aplikace

48

nická příloha obsahuje soubor WAR65 se samotnou realizovanou webovou aplikací nazvaný uploadserver.war. Po jeho rozbalení (v podstatě se jedná o formát ZIP) je nutné v souboru uploadserver.properties, který se nachází v adresáři WEB-INF/classes/, upravit informace o připojení k databázi a taktéž je nutné zde změnit hodnoty parametrů pro nastavení maximální velikosti nahrávaného souboru a cesty k adresáři na serverovém disku, kam se mají uploadované soubory ukládat. Pro správné fungování logování důležitých provedených akcí je nutné v souboru log4j.properties (v témže adresáři) nastavit hodnotu parametru log4j.appender.uploadserverappender.File, který definuje soubor pro zaznamenání těchto logů. 6.13.1

Inicializace dat v databázi

Po spuštění aplikace je nutné zjistit, zda databáze obsahuje potřebná data. Pokud tomu tak není, je nutné tato data do databáze uložit. Tuto funkcionalitu zajišťuje metoda initIt() třídy InitDB uvedená ve zdrojovém kódu 11. Zdrojový kód 11: Metoda zajišťující inicializaci dat v databázi @PostConstruct public void initIt() throws Exception { try { entityManager.createQuery(”SELECT o FROM” + ”UploadServerUser o WHERE o.admin=true”) .getSingleResult(); }catch (NoResultException e){ try { conn = dataSource.getConnection(); Statement s˜= conn.createStatement(); s.execute(”INSERT INTO uploadserver_user” + ”(is_admin, email, first_name, last_name,” + ”password, username, is_active) ” + ”VALUES (true, '[email protected]', 'A', 'A',” + ”'216ea934e34533a4e6e3ffd5a1929e85',” + ”'admin', true)”); s.execute(”INSERT INTO uploadserver_signin_log” + ”(last_signin, signin_count,” + ”uploadserver_user, registration_date) ” + ”VALUES (NULL, 0, 1, '” + new Date() + ”')”); 65

Web Application Archive je JAR soubor určený k distribuci kolekce Java tříd, HTML šablon, XML a dalších souborů, které dohromady tvoří webovou aplikaci. JAR soubory jsou postaveny na souborovém formátu ZIP a mají příponu .jar.

6.13

Nasazení aplikace

49

s.execute(”INSERT INTO uploadserver_section” + ”(description, name)” + ”VALUES ('sekce pro video soubory',” + ”'Video')”); ... Po každém spuštění aplikace (konkrétně po vložení závislostí, což zajišťuje anotace @PostConstruct) se prostřednictvím třídy InitDB zkontroluje, zda v databázi existuje administrátor. V případě, že v databázi není uložen, dojde k naplnění databáze počátečními daty: vytvoří se pět předdefinovaných hlavních sekcí upload serveru a administrátor (s uživatelským jménem i heslem „adminÿ a dalšími fiktivními údaji, které je doporučeno ihned po přihlášení změnit v kategorii Správa uživatelů).

7

7

ZÁVĚR

50

Závěr

Cíl této bakalářské práce, jímž bylo umožnit zákazníkům firmy WiFi Ždánice sdílení souborů mezi sebou prostřednictvím implementace webové aplikace, která by toto sdílení umožňovala, byl naplněn. Vytvořený systém je funkční a splňuje veškeré požadavky kladené na něj vedením firmy. Dokonce poskytuje funkcionalitu nad rámec těchto požadavků, kterou představuje lokalizace webové aplikace (existuje verze v češtině a v angličtině). Tato práce čtenáři přiblížila problematiku návrhu a vývoje webové aplikace pomocí frameworků platformy Java Enterprise Edition, konkrétně pomocí nástrojů Apache Wicket, Spring a Hibernate. V první kapitole jsem čtenáře uvedla do obecné problematiky sdílení souborů a poskytla jsem mu stručný popis poskytovaných služeb a cílů firmy WiFi Ždánice. V další kapitole byl definován cíl práce a uvedla jsem zde také metodiku této práce. Kapitola 3 uvádí výčet veškerých požadavků vedení firmy na realizovanou aplikaci. Po ukončení stádia specifikace požadavků jsem se věnovala návrhu výsledného systému, včetně návrhu uživatelského rozhraní a datového modelu. Kapitola 5 se zabývá volbou vhodných technologií a nástrojů pro implementaci. V kapitole 6 věnované implementaci systému jsem popsala vývoj některých funkcionalit z implementačního a funkčního hlediska. Během návrhu a implementace aplikace postupně vycházela najevo další rozšiřitelnost systému. Mezi funkcionalitu, kterou by bylo možné a vhodné při dalším vývoji do systému zahrnout, patří zasílání soukromých zpráv mezi přihlášenými uživateli, notifikace určitých uživatelů při vložení vlákna do určité sekce, formulář pro zaslání emailu s novým heslem v případě jeho zapomenutí, autentizace pomocí LDAP serveru, tlačítko pro nahlášení porušení autorských práv, formulář pro žádost o registraci, indikátor průběhu (progress bar) uploadování souboru, cyklické mazání souborů, které nebyly staženy během definovaného počtu dnů, a možnost určení hesla při vytvoření vlákna (tak by byl přístup do daného vlákna, a tedy i k jeho souborům, umožněn pouze uživatelům, kteří by znali toto heslo). Při vývoji aplikace jsem se setkala s několika problémy, které bylo nutné vyřešit. Největším z nich byla konfigurace frameworků a jejich integrace, zvláště při přechodu na novější verzi frameworku Spring z důvodu integrace zastaralé verze v počáteční etapě implementace systému. Výsledná webová aplikace byla poskytnuta firmě WiFi Ždánice. Aplikace byla nasazena na stroj Dell PowerEdge R21 a v současné době probíhá testování její finální verze. Prozatím se nevyskytly žádné zásadní nedostatky. Systém, jenž je výsledkem této bakalářské práce, v sobě nese stopu mnoha zajímavých technologií. Doufám, že jejich popis a praktické ukázky vzbudily čtenářovu zvědavost a zájem.

8

8

LITERATURA

51

Literatura

BAUER, Christian a KING, Gavin. Java persistence with Hibernate. Revised edition. Greenwich: Manning Publications, 2007, 841 s. ISBN 19-323-9488-5. DASHORST, Martijn a HILLENIUS, Eelco. Wicket in Action. Greenwich, CT: Manning, 2009, 364 s. ISBN 19-323-9498-2. HARTMAN, František. Testování portálových aplikací. Brno, 2011. Diplomová práce. Masarykova univerzita. Fakulta informatiky. JOHNSON, Rod et al. Spring Framework – Reference Documentation. [online]. 2004–2010 [cit. 2012-04-12]. Dostupné z: http://static.springsource.org/spring/docs/3.1.0.M2/spring-frameworkreference/html/. KING, Gavin et al. HIBERNATE – Relational Persistence for Idiomatic Java. [online]. 2009 [cit. 2012-04-13]. Dostupné z: http://docs.jboss.org/hibernate/orm/3.3/reference/en/html/index.html. KRPATA, Jan. Tvorba webových aplikací pomocí komponentně orientovaného rámce. Brno, 2008. Diplomová práce. Masarykova univerzita. Fakulta informatiky. MUKHAR, Kevin, ZELENAK, Chris, WEAVER, James L. a CRUME, Jim. Beginning Java EE 5: From Novice to Professional. Berkeley: Apress, 2006, 641 s. ISBN 15-905-9470-3. SOLDANO, Alessio et al. JBoss Application Server – Administration And Development Guide. [online]. 2008 [cit. 2012-04-14]. Dostupné z: docs.jboss.org/jbossas/docs/Server Configuration Guide/4/html/index.html. WALLS, Craig. Spring in Action. Third edition. Shelter Island: Manning, 2011, 400 s. ISBN 19-351-8235-8. Zákon č. 480/2004 Sb., o některých službách informační společnosti (zákon o některých službách informační společnosti). In: Sbírka zákonů. 7. 9. 2004. Dostupné z: http://aplikace.mvcr.cz/archiv2008/micr/files/1598/zakonois.pdf.

Přílohy

Náhledy aplikace

A

A

NÁHLEDY APLIKACE

Obrázek 5: Domovská stránka webové aplikace

53

A NÁHLEDY APLIKACE

Obrázek 6: Výpis stávajících uživatelů s možností jejich úpravy a odebrání

54

A

NÁHLEDY APLIKACE

Obrázek 7: Výpis souborů vlákna a diskuze k danému vláknu

55

A NÁHLEDY APLIKACE

56

Obrázek 8: Formulář pro úpravu parametrů vlákna, tabulka uvádějící soubory ve vláknu a odkaz pro přidání dalších souborů do vlákna

A NÁHLEDY APLIKACE

57

Obrázek 9: Česká lokalizace formuláře pro upload dalších souborů do vlákna

A NÁHLEDY APLIKACE

58

Obrázek 10: Anglická lokalizace formuláře pro upload dalších souborů do vlákna

B

ELEKTRONICKÉ PŘÍLOHY

B

Elektronické přílohy

Elektronické přílohy66 této bakalářské práce jsou následující: ˆ dokumentace (tato práce ve formátu PDF) v kořenovém adresáři ˆ zdrojové soubory upload serveru v adresáři uploadserver ˆ WAR archiv upload serveru v adresáři deploy ˆ textový soubor README.txt v adresáři deploy

66

V tištěné verzi této práce jsou všechny elektronické přílohy umístěny na přiloženém CD.

59