M A S A R Y K O V A U N I V E R Z I T A
F A K U L T A I N F O R M A T I K Y
Aplikace pro správu
kvalifikačních prací
průmyslového partnera
Red Hat
B A K A L Á Ř S K Á P R Á C E
Jakub Čecháček
Brno, p o d z i m 2013
Prohlášení
Prohlašuji, že tato bakalářská práce je mým původním autorským dílem,
které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu,
které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji
s uvedením úplného odkazu na příslušný zdroj.
Jakub Čecháček
Vedoucí práce: Mgr. Jiří Kolář
ii
Poděkování
Rád bych poděkoval vedoucímu práce Ing. Jiřímu Pechancovi a Mgr. Marku
Grácovi za poskytnuté konzultace a zpětnou vazbu. Dále bych rád poděkoval
zbylým členům vývojového týmu, Pavlu a Václavovi Dedíkovým.
iii
Shrnutí
Práce se v první části zabývá architekturou a vývojem aplikací s využitím
webového rámce Grails. Část druhá se zaměřuje na vývoj informačního systému
pro správu závěrečných prací, popis využitých technologií a vybrané
implementační detaily.
iv
Klíčová slova
informační systém, správa diplomových prací, správa souborů, Grails, MongoDB,
M V C
v
Obsah
1 Úvod 3
2 Informační systém pro správu diplomových prací 4
2.1 Diplomová práce 4
2.2 Informační systémy 4
2.3 Návrh systému pro správu diplomových prací 5
2.4 Použité technologie 5
2.4.1 Groovy 5
2.4.2 Aplikační rámec Grails 6
2.4.3 MongoDB 6
2.4.4 Technologie prezentační vrstvy 7
3 Groovy Grails 8
3.1 Technologie v pozadí 8
3.1.1 Aplikační rámec Spring 8
3.1.2 Groovy 8
3.1.3 Hibernate 9
3.1.4 Groovy Server Pages a SiteMesh 9
3.2 Convention over confíguration 10
3.3 Ekosystém zásuvných modulů 10
3.3.1 Instalace zásuvných modulů 11
3.4 Podobné platformy 11
3.4.1 RubyonRails 11
3.4.2 Django 12
4 Architektura aplikací na platformě Grails 13
4.1 Adresářová struktura 14
4.2 Aplikační model 15
4.2.1 Doménové třídy 15
4.2.2 Mapování doménových tříd do databáze 15
4.2.2.1 Persistenční logika 16
4.2.3 Servisní třídy 16
4.3 Prezentační vrstva 17
4.3.1 Knihovny značek 17
4.4 Komponenta Controller 18
5 Práce se soubory v systému pro správu diplomových prací . . . 20
5.1 Použité technologie 20
5.1.1 FineUploader 20
5.1.2 MongoGridFS 21
5.1.2.1 Kolekce f i l e s 21
1
5.1.2.2 Kolekce chunks 22
5.1.3 Dostupné moduly pro práci s Mongo GridFS 22
6 Implementace správy souborů 24
6.1 Archivace souborů 24
6.1.1 Servisní třída MongoFile 24
6.1.1.1 Uložení souboru do databáze 25
6.1.1.2 Získání souboru z databáze 26
6.1.2 Zasílání souborů klientovi 27
6.1.2.1 Knihovna značek pro práci s GridFile . . . 28
6.2 Nahrávání souborů 28
6.2.1 Přijetí a zpracování nahrávaných dat 28
6.2.1.1 Příjem souborů 29
6.2.1.2 Knihovna značek 30
7 Nasazení systému a budoucí vývoj 31
7.1 Budoucí vývoj 32
8 Závěr 34
A Doplňující informace 36
A. l Rozšíření pro práci s Mongo GridFS 36
B Diagramy 37
B.l Domain Model 37
C Odkazy 38
C l Zdrojový kód projektu 38
C.2 Adresa nasazeného systému 38
2
1 Úvod
Bakalářské a diplomové práce představují tradiční součást akademické sféry.
Nejspíše každý z nás s nimi má zkušenost jako student, někteří jako zadavatelé
či vedoucí. Ne každý si však uvědomuje složitost agendy související
s jejich správou a množství subjektů, které se celého procesu účastní, obzvláště
v případě, kdy je do procesu zahrnuto více univerzit.
Cílem této práce je vytvoření informačního systému pro správu diplomových
a bakalářských prací pro společnost Red Hat, průmyslové partnera
Fakulty informatiky Masarykovy univerzity. Systém nahradí stávající
agendu správy závěrečných prací prostřednictvím firemní wiki stránky,
která je s rostoucím počtem vypisovaných témat nedostačující. Hlavním
přínosem nového systému oproti stávající agendě by mělo být značné zjednodušení
a zpřehlednění distribuce vypisovaných témat jednotlivým uni
verzitám.
První část práce se věnuje vysvětlení základních pojmů a představení
použitých technologií. V následující části je čtenář blíže seznámen s rámcem
Grails, architekturou a vývojem aplikací na této platformě. Poslední
dvě části popisují vybrané implementační detaily práce se soubory ve vyvíjeném
systému a jeho nasazení.
3
2 Informační systém pro správu diplomových prací
2.1 Diplomová práce
Diplomová práce představuje finální studii, jejíž vypracování je požadováno
pro získání vysokoškolského diplomu. Většina studentů si oblast své
diplomové práce vybírá přibližně ve druhé polovině studia. Celý proces
obvykle vypadá nějak takto:
1. Student si vybere pro něj zajímavé téma diplomové práce.
2. Student kontaktuje vedoucího práce a po domluvě s ním se k danému
tématu přihlásí.
3. Student pracuje na své závěrečné práci a průběh konzultuje s ve
doucím.
4. Jsou vypracovány dva posudky hodnotící kvalitu práce. Autorem
prvního je vždy vedoucí. Druhý posudek je pak vypracován nezávislou
osobou
5. Studen musí práci obhájit před komisí, která s přihlédnutím k posudkům
udělí známku.
Obvykle existuje několik zdrojů, ze kterých mají studenti možnost vybírat
téma své budoucí diplomové práce. První možností je vybrat si ze
seznamu témat dostupných na dané univerzitě, v takovém případě se většinou
jedná o oblast blízkou vedoucímu daného tématu. Další možností je
vymyslet si téma vlastní a domluvit se s některým z vyučujících na jeho
oficiálním vypsání. V neposlední řadě si pak studenti mohou vybrat téma
nabízené nějakou třetí stranou - například společností Red Hat. V tomto
případě se často do výše zmíněného procesu zapojuje druhý vedoucí, například
člověk z firmy zadávající dané téma, který přebírá roli konzultanta.
2.2 Informační systémy
Informační systém představuje soubor lidí, prostředků a procesů pro sběr,
přenos, uchování a zpracování dat[l]. Ačkoliv příkladem takového systémů
může být i dobře vedená kartotéka, v kontextu této práce uvažuji
vždy informační systémy elektronické.
4
2. I N F O R M A Č N Í S Y S T É M P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
2.3 Návrh systému pro správu diplomových prací
Návrh informačního systému pro správu bakalářských prací probíhal ve
spolupráci se zástupci společnosti Red Hat. V průběhu prvních setkání byly
určeny funkční požadavky na systém a vypracován základní doménový
model celého systému, který byl následně během vývoje upravován. Mezi
hlavní funkční požadavky patří:
• uživatelské účty s různou úrovní oprávnění
• správa závěrečných prací dle definovaného procesu
• možnost nahrávat přílohy
• diskuse v podobě komentářů
• nástroje pro univerzitní vedoucí
Dále byly na základě požadavků společnosti Red Hat a zkušeností vývojářů
stanoveny nefunkční požadavky. Mezi nejdůležitější patří:
• Grails jako vývojová platforma.
• nasazení systému na OpenShift
• otevřený zdrojový kód
Pro bližší informace o návrhu systému a použitých procesech doporučuji
přečíst bakalářskou práci Václava Dedíka[2].
2.4 Použité technologie
2.4.1 Groovy
Groovy je dynamický objektově orientovaný programovací jazyk pro platformu
Java, který přináší spoustu vlastností a konstrukcí známých z jazyků
jako Python, Ruby a Smalltalk. Jednou z řady výhod jazyka Groovy
patří díky totožné syntaxi téměř nulová učící křivka pro stávající Java
programátory [3]. Mezi nejvýznamnější charakteristiky tohoto jazyka patří[4]:
• rozumné výchozí hodnoty a nastavení
• uzávěry
• syntaxe pro podporu návrhového vzoru Stavitel
5
2. I N F O R M A Č N Í S Y S T É M P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
• podpora doménových jazyků
Díky přímé kompilaci do java byte kódu mohou programy napsané
v Groovy využívat řadu existujících knihoven napsaných v jazyce Java a
běžet všude tam, kde je k dispozici Java Runtime Environment[3].
2.4.2 Aplikační rámec Grails
Grails je aplikační rámec a platforma pokrývající všechny aspekty vývoje
webových aplikací využívající programovací jazyk Groovy[5]. Díky systému
zásuvných modulů lze aplikace vyvíjené na této platformě relativně
snadno obohatit o nové funkce nebo upravit výchozí chování aplikačního
rámce. Detailněji se celou platformou zabývají následující kapitoly.
2.4.3 MongoDB
MongoDB je dokumentově orientovaná databáze, a jedna z předních NoSQL
databází na trhu, s otevřeným zdrojovým kódem[6]. V dokumentově orientovaných
databázích se jednotlivé záznamy ukládají do souborů, které
jsou následně seskupovány do takzvaných kolekcí. Pokud bychom se pokusili
o přirovnání k relační databázi, pak kolekce představuje tabulku a
dokumenty jednotlivé řádky. V případě MongoDB jsou data ukládána ve
formátu B S O N 1
a mohou být plně dynamická - nemusí dodržovat žádné
definované schéma. NoSQL databáze nabývají v posledních letech na popularitě
právě díky možnosti ukládat dynamická data a jejich vysoké škálovatelnosti.
Mezi nejvýznamnější vlastnosti této databáze patří:
• převod objektových struktur do jazyka JSON je přirozenější než jejich
mapování do tabulek relační databáze
• implementace návrhového vzoru Map/Reduce pro zpracování velkého
množství dat
• dotazovací jazyk
• GridFS
Systém pro správu závěrečných prací využívá MongoDB primárně ke
dvěma účelům. Prvním je ukládání dynamických dat (jako například konfigurace
systému). Druhým případem je využití GridFS pro ukládání souborů
nahrávaných studenty k jednotlivým diplomovým pracím a podobenek
uživatelů.
1. Binary JavaScript Object Notation
6
2. I N F O R M A Č N Í S Y S T É M P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
2.4.4 Technologie prezentační vrstvy
Prezentační vrstva je implementována za použití řady moderních značkovacích
a stylovacích jazyků. Dynamická části jsou skriptovány pomocí jazyka
JavaScript a technologie AJAX. Mezi nejvýznamnější použité technologie,
nástroje a jazyky dále patří:
• Groovy Server Pages (GSP)
• H T M L a H T M L 5
• CSS a LESS
• Twitter Bootstrap
Pro bližší informace o použitých technologiích a návrhu uživatelského
rozhraní doporučuji přečíst bakalářskou práci Pavla Dedíka[7].
7
3 Groovy Grails
3.1 Technologie v pozadí
Platforma programovacího jazyka Java je s námi již skoro 15 let. Pravděpodobně
nikoho proto nepřekvapí, že během této doby vznikla spousta
kvalitních knihoven řešících různé potřeby softwarového inženýrství. Této
skutečnosti si byli dobře vědomi v roce 2005 i vývojáři vůbec první verze
rámce Grails. Místo startu na zelené louce a vynalézání kola proto Grails
staví na existujících a v praxi prověřených technologiích[8].
r Grails
Zásuvné
( Spring ) Hibernate
v )
Ostatní j
moduly 0
0
v
Java V i r t u a l Machine Obrázek
3.1: Platforma Grails
3.1.1 Aplikační rámec Spring
Aplikační rámec Spring tvoří základ platformy Grails. Jedná se o rámec poskytující
prostředky pro vývoj moderních enterprise aplikací, jehož první
verzi vyvinul Rod Johnson jako součást své knihy „Expert One-on-One
J2EE Design" pojednávající o návrhu a principech vývoje Java EE aplikací.
Primárním cílem tohoto rámce je maximálně usnadnit vývoj enterprise
aplikací. Díky tomu se dnes jedná o jednu z nejrozšířenějších platforem
pro vývoj Java EE aplikací a alternativu k tradičním Enterprise Java
Beans[9]. Grails využívá podstatnou část funkcionality poskytované platformou
Spring - počínaje „Inversion of Control" kontejnerem, přes integrační
vlastnosti Springu, až po Aspektově orientované programování a
podporu transakcí. S Grails lze navíc velmi snadno použít i libovolný z modulů
rozšiřující jádro platformy Spring, jako je například Spring Security.
3.1.2 Groovy
V kontextu platformy Grails představuje Groovy nejen jazyk používaný
k vývoji aplikací. Jedná se také o pomyslné „lepidlo " spojující použité tech-
8
3. G R O O V Y G R A I L S
nologie a knihovny. Vlastnosti programovacího jazyka Groovy jako například
„buildery", jej dělají ideálním prostředkem pro vývoj doménově specifických
jazyků (dále jen DSL). Díky tomu vytváří Groovy uživatelsky přívětivá
rozhraní zastřešující jednotlivé části platformy. Velmi časté je například
využití DSL v konfiguračních souborech, jenž umožňuje uživatele odstínit
od komplexity celé konfigurace a minimalizuje množství opakujícího
se kódu.
1
2
4 < p r o p e r t y name="povider" ref="mongoProvider"/>
5
6
1 beans = {
2 c o n f i g u r a t i o n ( C o n f i g u r a t i o n ) {
3 p o v i d e r = r e f ( " m o n g o P r o v i d e r " )
4 }
5 }
Příklad 1: definice Spring bean - X M L (nahoře) a Grails DSL (dole)
3.1.3 Hibernate
Hibernate je populární knihovna pro objektově-relační mapování (dále jen
ORM), řešící problém rozdílné reprezentace dat v objektovém světě a relačních
úložištích. Hibernate se také snaží odstínit uživatele od rozdílných
dialektů jazyka SQL používaných v různých databázích. V kontextu platformy
Grails představuje Hibernate součást řešení vrstvy persistence dat
poskytované v základní distribuci.
3.1.4 Groovy Server Pages a SiteMesh
Groovy Server Pages (dále jen GSP) představují značkovací jazyk určený
pro vývoj aplikací prezentační vrstvy. Obdobně jako syntakticky podobné
Java Server Pages (dále jen JSP) umožňují GSP kombinovat statický a dynamický
obsah. GSP však přináší drobná vylepšení vyplývající z dynamické
podstaty jazyka Groovy. Lze tak například využít speciální textové řetězce
9
3. G R O O V Y G R A I L S
( G S t r i n g ) vyhodnocované přímo groovy interpretem, což minimalizuje
potřebu definovat knihovny značek.
SiteMesh pak představuje flexibilní šablonovací systém založený na návrhovém
vzoru „dekorátor". Mezi nevýhody samostatného použití šablon
SiteMesh patří zejména nutnost deklarovat každou šablonu, takzvaný
„dekorátor", v konfiguračním X M L souboru. Grails použití tohoto šablonovacího
systému usnadňuje pomocí přidaných značek pro práci se šablonami
a automatickým generováním konfiguračního souboru.
3.2 Convention over configuration
Princip „Convention over configuration" reprezentuje myšlenku poskytnutí
rozumných výchozích hodnot a konfigurace za účelem maximálně usnadnit
práci vývojáře. Cílem je jednak udělat vývoj aplikací zábavnějším
a hlavně umožnit vývojáři aby se soustředil na samotnou funkcionalitu vyvíjeného
systému místo přípravy prostředí. Jak jsem již zmínil, platforma
Grails staví na řadě jiných aplikačních rámců, z nichž většina vyžaduje určitou
formu konfigurace - ať už je to nastavení prostřednictví X M L souboru
nebo využití anotací. Dodržování stanovených zásad, jako například jména
proměnných, proto značným způsobem sníží množství potřebné konfigurace.
Ačkoliv princip využívání konvencí je nedílnou součásti Grails, samotný
rámec však vývojáře nijak k jejich dodržování nenutí a možnosti
konfigurace nejsou nijak omezeny [10].
3.3 Ekosystém zásuvných modulů
Existuje mnoho typů aplikací, určených pro různé oblasti naší společnosti,
které mají mnohdy velice rozdílné požadavky. Ačkoliv se Grails snaží poskytnout
komplexní řešení pro vývoj informačních systémů a webových
aplikací, nelze uspokojit požadavky na vývoj všech možných projektů. Místo
rozšiřování základní distribuce proto Grails nabízí možnost do vyvíjených
aplikací doinstalovat zásuvné moduly, které rozšíří možnosti rámce o požadovanou
funkci. Současné verze platformy Grails se snaží o modularizaci
základní distribuce a vlastnosti, které nejsou nezbytně nutné, přesouvat
právě do zásuvných modulů. Příkladem tohoto vývoje je plánované
přesunutí podpory Hibernate do zásuvného modulu, související s rozvojem
používání NoSQL databází. Základní distribuce platformy Grails aktuálně
obsahuje 23 zásuvných modulů - 16 modulů tvořících jádro rámce a 7
doplňkových modulů, které lze v případě potřeby odinstalovat. Průměrně
10
3. G R O O V Y G R A I L S
používá každá aplikace postavená na této platformě 30 rozšíření, včetně
modulů jádra. [10]
3.3.1 Instalace zásuvných modulů
V současné době lze do aplikace vyvíjené na platformě Grails nainstalovat
zásuvný modul dvěma způsoby. První způsobem je použití příkazu
g r a i l s i n s t a l l - p l u g i n < j m é m o m o d u l u x V aktuální verzi platformy
je však tento způsob označen jako zastaralý a do budoucna se počítá s jeho
odstraněním. Preferovaným způsobem je nyní přidat definici rozšíření do
sekce p l u g i n s v konfiguračního souboru B u i l d C o n f i g . g r o o v y [ l l ] . Ačkoliv
se toto může zdát krokem zpět, důvodem k této změně je sjednocení
instalace zásuvných modulů a definice ostatních závislostí projektu.
1 p l u g i n s {
2 b u i l d " : t o m c a t : $ g r a i l s V e r s i o n "
3 c o m p i l e " : p l a t f o r m - c o r e : 1 . 0 . R C 5 "
4 c o m p i l e ":markdown:1.1.1"
5 c o m p i l e " : m a i l : 1 . 0 . 1 "
6 }
Příklad 2: instalace zásuvného modulu
3.4 Podobné platformy
3.4.1 Ruby on Rails
Ruby on Rails je webovým rámcem, který začal jako první silně propagovat
princip „Convention over configuration". Jak název napovídá, jedná se
o rámec pro programovací jazyk Ruby a právě Rails je příčinou dnešní popularity
tohoto dynamického jazyka. Vlastnostmi se Ruby on Rails velmi
podobá rámci Grails, neboť bylo jeho předlohou - v obou případech se
jedná o vysoce produktivní webové rámce využívající konvence a rozumné
výchozí hodnoty.
Hlavním rozdílem mezi oběma rámci je přístup k doménovým třídám
a databázi. Grails využívá princip objektově-relačního mapování založeného
na návrhovém vzoru „Data Mapper", který kromě doménových tříd
využívá i takzvaný „mapovací objekt" zodpovědný za mapování dat z databáze
do konkrétní instance doménové třídy. Rails naproti tomu řeší persistencí
pomocí návrhového vzoru „Active Record", který Martin Fowler definuje
jako „Objekt, který obaluje řádek v databázové tabulce, zapouzdřuje
11
3. G R O O V Y G R A I L S
přístup k databázi, a přidává doménovou logiku". [12] Z pohledu vývojáře
představuje „Active Record" transparentnější spojení objektu a databáze,
cenou je však nižší flexibilita takového mapování.
3.4.2 Django
Django představuje alternativu ze světa jazyka Python. Stejně jako v případě
Grails a Rails se jedná o webový rámec s vysokou produktivitou.
Co se technických možností týče, je Django srovnatelné s oběma předchozími.
Hlavní odlišnosti této platformy jsou především filosofické a vycházejí
přímo z návrhu samotného Pythonu. Django se tak snaží mnohem méně
využívat takzvané „magie" v podobě implicitně definovaných atributů,
metod a výchozích hodnot. V důsledku tohoto chování jsou aplikace vyvíjené
s použitím tohoto rámce přehlednější. Právě přehlednost je Django
komunitou vyzdvihována jako velká výhoda této platformy, která je však
vykoupena nutností napsat více kódu.
12
4 Architektura aplikací na platformě Grails
Grails, stejně jako řada jiných rámců pro vývoj aplikací obsahujících nějakou
formu uživatelského rozhraní, využívá návrhového vzoru Model,
View, Controller1
(dále jen MVC). Ačkoliv jednotná definice tohoto vzoru
prakticky neexistuje a mírně se liší mezi jednotlivými implementaci, obecně
se vždy jedná o formu oddělení aplikační a prezentační logiky. Jak je patrné
z názvu, aplikace postavené na architektuře M V C lze rozdělit do tří komponent
(vrstev):
• Model
Zahrnuje aplikační logiku systému včetně doménových tříd.
• View
Tvoří základ prezentační vrstvy. Hlavním účelem této komponenty
je zobrazení informací uživateli.
• Controller
Zajišťuje komunikaci s uživatelem a prostřednictvím view zobrazuje
požadované informace.
^ MODEL
UPDATES MANIPULATES
I I
VIEW CONTROLLER
\ /\
USER
Obrázek 4.1: Architektura M V C
Poprvé tento návrhový vzor popsal v roce 1979 norský profesor Trygve
Reenskaug. O rok později vznikla jako součást programovacího jazyka
Smalltalk-80 první implementace této architektury. Specifické pro tuto implementaci
bylo spojení komponent view a controller. Tento typ M V C se i
1. V průběhu práce se uvádí anglická terminologie, běžně rozšířená v oboru.
13
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
dnes používá u rámců pro GUI, kde ovládací prvky nejen zobrazují informace,
ale také přijímají uživatelský vstup. Rozdělení všech tří komponent je
pak běžnou praxí u rámců pro vývoj webových aplikací, jakým je například
Grails.
4.1 Adresářová struktura
Stejně jako v aplikační rámec Spring umožňuje i Grails definovat jednotlivé
komponenty aplikace více způsoby. Dostupná je tedy možnost přímé registrace
komponenty v konfiguračním souboru nebo anotace jednotlivých tříd,
avšak tyto postupy nejsou příliš používané. V předchozí kapitole byl popsán
princip „Convention over Configuration" a jedním ze způsobu uplatnění
tohoto přístupu je dodržování stanovené adresářové struktury. Všechny
aplikace na této platformě proto využívají jednotnou adresářovou strukturu
s adresáři vyhrazenými pro příslušné komponenty. Následující výčet
uvádí vybrané adresáře.[11]
• grails-app/conf
Adresář conf je určen pro veškeré konfigurační soubory aplikace.
• grails-app/controllers
Adresář C o n t r o l l e r s je určen pro controllery.
• grails-app/domain
Adresář doma i n je určen pro doménové třídy
• grails-app/il8n
Adresář i 18 n je určen pro soubory s texty jednotlivých jazykových
mutací aplikace.
• grails-app/services
Adresář s e r v i ce s je určen pro servisní třídy
• grails-app/taglib
Adresář t a g l i b je určen pro knihovny značek.
• grails-app/views
Adresář v i e w s je určen pro pohledy prezentační vrstvy.
14
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
4.2 Aplikační model
Aplikační model představuje jednu ze tří komponent M V C . V kontextu
platformy Grails se jedná o souhrnné označení doménových a servisních
tříd.
4.2.1 Doménové třídy
Doménové třídy představují v rámci aplikace reprezentaci doménového
modelu. Doménový model popisuje jednotlivé entity vyvíjeného systému
a vztahy mezi nimi. Novou doménou třídu lze založit buďto manuálním
vytvoření * .groovy souboru v adresáři g r a i l s - a p p / d o m a i n nebo pomocí
grails příkazu c r e a t e - d o m a i n - c l a s s zpříkazové řádky. V případě
první možnosti je potřeba ručně vytvořit také případnou hierarchii balíčků.
Systém pro správu diplomových prací obsahuje celkem 14 doménových
tříd, za „základní" lze označit tyto entity:
• User: uživatel registrovaný v systému.
• University: univerzita evidovaná v systému.
• Topič: téma závěrečné práce.
• Thesis: konkrétní práce konkrétního studenta.
• Application: přihláška studenta k tématu závěrečné práce.
Detailní popis celého doménového modelu je obsažen v práci Václava Dedíka[2],
v příloze lze najít U M L diagram modelu [2].
4.2.2 Mapování doménových tříd do databáze
Platforma Grails využívá pro persistenci doménových tříd do databáze nástroj
G O R M (Grails Object Relational Mapping). Označení „objektově-relační
mapování" v názvu je lehce matoucí, neboť dnes existují i implementace
G O R M API pro řadu nerelačních databází. Systém pro správu diplomových
prací využívá rozhraní G O R M pro práci s databázemi MongoDB a
PostgreSQL.
Ačkoliv všechny implementace rozhraní G O R M poskytují stejné API,
liší se v rozsahu a poskytovaných funkcích (v případě NoSQL databází například
nemá smysl konfigurace tabulek). V rámci této kapitoly proto uvažuji
výchozí implementaci určenou pro relační databáze, kam je mapována
15
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
i převážná většina doménových tříd ve vyvinutém systému. V souladu s filosofií
platformy Grails o využívání existujících knihoven se ani v případě
G O R M nejedná o zcela nové řešení a základ výchozí implementace je tvořen
aplikačním rámcem Hibernate.
4.2.2.1 Persistenční logika
Jedním z principů popisovaným návrhovým vzorem „Data Mapper " je oddělení
persistenční logiky a doménové třídy - tento návrh přispívá ke snížení
závislosti na konkrétním řešení persistence. Ve srovnání s „Active Record",
kde je persistenční logika přímo součásti doménových tříd, je však
použití tohoto řešení méně přehledné a pohodlné. G O R M , jakožto řešení
využívající Hibernate je samozřejmě také založen na vzoru „Data Mapper ",
avšak díky dynamické podstatě programovacího jazyka Groovy umožňuje
využit přístup podobný „Active Record". Persistenční CRUD operace jsou
na jednotlivých entitách zpřístupněny pomocí „magických" metod, což
jsou metody přidané objektu mimo definici třídy pomocí metaprogramo'
'ivanr.
1 // získaní tématu s íd=l z databáze
2 d e f t o p i c = T o p i c . g e t ( 1 )
3 // vyhledaní tématu s názvem foo
4 t o p i c = T o p i c . f i n d B y T i t l e ( ' f o o ' )
5
6 / / editace tématu
7 t o p i c . t i t l e = " b a r "
8 t o p i c . s a v e ( )
9 / / smazáni tématu
10 t o p i c . remove ()
11
12 // vyhledáni vice záznamu
13 d e f t o p i c s = T o p i c . f i n d A H B y T i t l e L i k e (' buz z ' )
Příklad 3: Příklad C R U D operací
4.2.3 Servisní třídy
Účelem servisních tříd je zapouzdření komplexní aplikační logiky - tedy
takové logiky, která jde nad rámec základních C R U D operací nebo pracuje
s více zdroji zároveň. Při dodržení stanovených konvencí přináší servisní
třídy několik funkcí, které běžné třídy neposkytují.
2. Princip úpravy kódu programu za běhu
16
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
• Vkládání závislostí
V rámci servisních tříd funguje na základě jména třídy a jména atributu
automatické vkládání závislosti.
• Transakce
Jednotlivé metody probíhají vždy v rámci aktuální transakce. Pokud
žádná při volání metody neexistuje, zahájí se transakce nová.
Servisní třídy jsou v rámci kódu vyvinutého systému rozděleny do několika
balíčků:
• com.redhat.theses
Práce s doménovými třídami.
• com.redhat.theses.auth
Servisní třídy zajišťující autentizaci
• com.redhat.theses.config
Servisní třídy obsahující logiku pro práci s konfigurací.
• com.redhat.theses.listeners
Správa asynchronních událostí
• com.redhat.grails
Logika práce se soubory.
4.3 Prezentační vrstva
Základem prezentační vrstvy jsou takzvaná views. Jedná se v podstatě o šablony,
jejichž jediným účelem po naplnění daty je prezentace těchto data
uživateli. Ačkoliv lze tuto komponentu v rámci Grails implementovat pomocí
řady prezentačních rámců (Velocity, Freemarker, Thymeleaf), doporučuji
použít výchozí řešení založeném na GSP a šablonách SiteMesh - důvodem
je hluboká integrace s ostatními částmi platformy.
4.3.1 Knihovny značek
Jedním ze základních principů M V C je oddělení prezentační vrstvy a modelu.
V případě implementací s oddělenou komponentou controller to znamená
i omezení přímé komunikace mezi modelem a view - ideálně by
měla být všechna potřebná data předána view z controlleru. V praxi je však
17
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
striktní oddělení view a modelu velmi obtížné, neboť v moderních aplikacích
jsou jednotlivá view často dynamická. Důsledkem tak může být přenášení
nepotřebných dat nebo zanášení aplikační logiky do implementace
daného view. Volání metod obsahujících aplikační logiku přímo z view však
také není žádoucí, neboť na prezentační vrstvě často pracují programátoři
zaměření na prezentační vrstvu, bez znalosti aplikačního modelu.
Grails řeší tento problém možností definovat doplňující knihovny značek
(anglicky „tag libraries"), které umožní používat požadovanou logiku
prostřednictvím GSP značek. Novou knihovnu lze vytvořit manuálním založením
třídy v adresáři g r a i l s - a p p / t a g l i b nebo pomocí příkazu grails
c r e a t e - t a g - l i b
V rámci vyvíjeného systému vzniklo těchto knihoven několik, následující
seznam uvádí některé z nich (jednotlivé položky seznamu jsou ve tvaru
„tříd - jmenný prostor")
• Ajax4GSPTagLib - a4g
Knihovna značek pro práci s technologií A J A X .
• RichGSPTagLib - richg
Knihovna rozšiřující standardní sadu GSP značek.
• NotificationTagLib - notification
Značky pro práci se systémovými notifikacemi.
• GridFileTagLib - file
Knihovna pro přímý přístup k souborům uloženým v databázi Mon-
goDB.
• UploaderTagLib - u
Knihovna pro nahrávání souborů
4.4 Komponenta controller
Jak jsem již zmínil, controller slouží k propojení view a příslušného modelu.
Tato Komponenta však zajišťuje také komunikaci uživatele s modelem.
V případě webových rámců je tato funkce zajištěna pomocí mapování
metod controlleru, nazývaných akce, na jednotlivé URL aplikace. Obdobně
jako servisní třídy, controllery nabízí možnost automatického vkládání závislostí
při dodržení konvencí. Příklad níže uvádí akci dostupnou na U R L
/ t o p i c / l i s t pomocí metody GET protokolu HTTP.
18
4. A R C H I T E K T U R A A P L I K A C Í N A P L A T F O R M Ě G R A I L S
1 c l a s s T o p i c C o n t r o l l e r {
2 // prístup pouze pres GET
3 s t a t i c allowedMethods = [ l i s t : GET"]
4
def l i s t O {
6
8
7 // predaní dat príslušnému view
[ t o p i c I n s t a n c e L i s t : t o p i c s ]
9
10 })
Příklad 4: Definice controlleru
Systém pro správu diplomových prací obsahuje řadu controlleru rozdělených
do několika balíčků:
• com.redhat.theses
Obsluha požadavků pracujících se základními doménovými třídami.
• com.redhat.theses.auth
Obsluha požadavků souvisejících s uživateli a autentizací - například
přihlášení.
• com.redhat.theses.ajax
Obsluha požadavků zaslaných pomocí technologie A J A X .
• com.redhat.grails
Obsluha požadavků souvisejících se správou souborů.
19
5 Práce se soubory v systému pro správu diplomových
prací
Výstupem bakalářské práce bývá zpravidla zpráva v podobně textového
dokumentu (nejčastěji ve formátu PDF), často doplněna o množství příloh
jako implementace konkrétního řešení nebo vzorek použitých dat. Jedná se
o důležitou součást hodnocení práce a například konkrétní technické řešení
mnohdy bývá hlavním důvodem vypsání práce. Tyto soubory je proto
nutné archivovat. V této kapitole popisuji použité technologie a technické
řešení nahrávání a archivace souboru v systému pro správu závěrečných
5.1 Použité technologie
5.1.1 Fine Uploader
Fine Uploader je moderní nástroj pro nahrávání souborů prostřednictvím
webových aplikací. Jedná se o projekt s otevřeným zdrojovým kódem, implementovaný
v jazyce JavaScript bez jakýchkoliv závislostí[13]. K dispozici
je také verze využívající široce využívanou JavaScriptovou knihovnu
jQuery, jež poskytuje výrazně kompaktnější syntaxi. Právě tato varianta
byla použita i v systému pro správu diplomových prací.
1
2
3
prací.
4
10
6
9
8
7
< s c r i p t >
$ ( d o c u m e n t ) . r e a d y ( f u n c t i o n () {
$('#upload_wrapper' ) . f i n e U p l o a d e r ( {
r e q u e s t : {
e n d p o i n t : '/upload'
n
12 } ) ;
14
13 }) ;
< / s c r i p t >
is
Příklad 5: základní použití nástroje Fine Uploader
20
5. P R Á C E SE S O U B O R Y V S Y S T É M U P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
Soubory jsou na server zaslány zakódované v těle vícedílných požadavků
HTTP1
protokolu s využitím technologie AJAX. Fine Uploader poskytuje
široké možnosti konfigurace a několik rozšiřujících bodů v různých
fázích procesu nahrávání souboru.
5.1.2 Mongo GridFS
Pro ukládání souborů ve vyvinutém systému byla použita databáze MongoDB.
Využití databáze oproti přímému ukládání na disk přináší možnost
zaznamenat spolu se souborem i metadata poskytující doplňující informace.
GridFS je specifikace popisující způsob ukládání a získávání souboru z databáze
MongoDB, které přesahují maximální povolenou velikost BSON dokumentu,
stanovenou na 16 MB[14]. Data ukládána do hierarchie kolekcí
ve tvaru „ < b u c k e t > . < k o l e k c e > . ", kde:
• < b u c k e t > ( k y b l í č e k ) představuje kořenovou kolekci pro daný
GridFS
• < k o l e k c e > jedna z kolekcí f i l e s nebo c h u n k s (viz. následující
podkapitoly)
• samotný dokument
5.1.2.1 Kolekce f i l e s
Dokumenty v kolekci f i l e s reprezentují jednotlivé soubory v úložišti GridFS.
Obsah těchto dokumentů tvoří jednak základní informace o souboru
(jméno, typ, kontrolní součet, čas a datum uložení) a dále také souborová
metadata poskytující doplňující informace.
i {
2 " _ i d " : O b j e c t I d ( " 5 2 8 5 f c 9 4 9 3 f 4 7 d 2 c 7 7 e 4 c 2 d b " ) ,
3 " c h u n k S i z e " : NumberLong(262144),
4 " l e n g t h " : NumberLong(11448),
5 "md5" : "109dcd47fadda95f6b9adl12faO06adl",
6 " f i l e n a m e " : " a v a t a r . p n g " ,
7 "contentType" : "image/png",
s "uploadDate" : ISODate("2013-11-15T10:51:00.821Z"),
9 " a l i a s e s " : n u l l
io }
Příklad 6: dokument v kolekci f i l e s
1. Hypertext Transfer Protocol
21
5. P R Á C E SE S O U B O R Y V S Y S T É M U P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
5.1.2.2 Kolekce chunks
Samotná data tvořící soubor jsou rozdělena na bloky a následně po částech
ukládána v kolekci c h u n k s . Díky tomuto rozdělení lze číst pouze část uložených
dat, čehož lze využít při čtení velkých souborů - jako je například
streamování videa.
1 {
2 " _ i d " : O b j e c t I d ( " 5 2 8 5 f c 9 5 9 3 f 4 7 d 2 c 7 7 e 4 c 2 d c " ) ,
3 " f i l e s _ i d " : O b j e c t I d ( " 5 2 8 5 f c 9 4 9 3 f 4 7 d 2 c 7 7 e 4 c 2 d b " ) ,
4 "n" : 0,
5 " d a t a " :
6 }
Příklad 7: dokument v kolekci c h u n k s
Na příkladu výše lze vidět, že každý dokument uložený v této kolekci
obsahuje kromě standardního atributu _ i d a samotných dat také atributy
s pořadovým číslem bloku a id „rodičovského" souboru v kolekci f i l e s .
5.1.3 Dostupné moduly pro práci s Mongo GridFS
Repozitář zásuvných modulů platformy Grails nabízí hned několik implementací
technického řešení komunikace s databází MongoDB potažmo s
její nadstavbou GridFS. Pro výběr vyhovujícího řešení jsem proto stanovil
následující požadavky:
• Údržba modulu ze strany autora, alespoň v podobě opravy chyb.
• Alespoň stručná dokumentace k aktuální verzi modulu.
• Nejlépe žádné změny v entitách mapovaných na relační databázi.
• Zvolený zásuvný modul by měl řešit pouze ukládání souborů a to
dostatečně pružně pro budoucí rozvoj systému.
Hned první dva z požadavků však dokázaly vyřadit většinu dostupných
modulů. Ukázalo se, že velká část z nich postrádá dokumentaci, případně
to jsou jednorázově vyvinuté projekty bez jakékoliv údržby. Další
požadavky pak spolehlivě vyřadily i zbylé kandidáty. Seznam zvažovaných
možností lze najít v příloze, za zmínku stojí zejména dva z dostupných
modulů. MongoDB G O R M je, jak název napovídá, implementací rozhraní
G O R M pro databází MongoDB. Tento modul se však hodí spíše, ob-
22
5. P R Á C E SE S O U B O R Y V S Y S T É M U P R O S P R Á V U D I P L O M O V Ý C H P R A C Í
dobně jako výchozí O R M implementace, pro persistenci kompletních doménových
tříd. Mongo G O R M jsem se proto rozhodl použít k persistenci
objektů dynamického charakteru, jakým je například konfigurace systému,
ukládaných do databáze MongoDB. Druhým modulem, který se ukázal
být přínosným, je projekt Mongodb Gridfs. Ačkoliv tento modul obsahuje
spoustu drobných chyb a jeho vývoj byl s největší pravděpodobností ukončen,
zdrojový kód se ukázal jako výborný studijní materiál pro vývoj vlastní
aplikační logiky řešící ukládání souborů do GridFS.
23
6 Implementace správy souborů
6.1 Archivace souborů
Jelikož žádný z dostupných modulů pro práci s Mongo GridFS nevyhovoval
ani základním stanoveným požadavkům, vyvinul jsem jako součást
systému pro správu bakalářských prací s využitím získaných poznatků rozhraní
vlastní - pracovně nazvané MongoFile. Aktuálně se jedná o součást
vyvinutého informačního systému, avšak implementace umístěná v balíku
com. r e d h a t . g r a i l s . m o n g o d b počítá s budoucím osamostatnění projektu
v podobně zásuvného modulu platformy Grails.
6.1.1 Servisní třída MongoFile
Hlavní část implementace je tvořena servisní třídou G r i d F i l e S e r v i c e
poskytující rozhraní pro manipulaci se soubory. Při návrhu MongoFile jsem
zohlednil dva typy souborů:
• Soubory vázané na doménovou třídu
• Soubory bez doménových vazeb
Pro rozlišení mezi těmito soubory využívá navržené rozhraní možnost definovat
několik kořenových kyblíčku GridFS v rámci jedné databáze. Soubory
jsou ukládány do kyblíčku odvozeného z názvu vázané doménové
třídy, případně lze toto jméno změnit definováním statického atributu
b u c k e t M a p p i n g v dané doménové třídě. Soubory bez doménové vazby
jsou ukládány do kyblíčku výchozího, nazvaného f s. Vazba na konkrétní
instanci doménové třídy je tvořena pomocí následujících atributů v souborových
metadatech:
• i d slouží jako identifikátor vázané entity.
• g r o u p klasifikuje soubory v rámci jedné doménové třídy.
Jako identifikátor může sloužit hodnota libovolného atributu vázané entity.
Ve výchozím nastavení je použita hodnota atributu i d.
24
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
2 {
3 "metadata" : { "group" : " a v a t a r " , " i d " :
NumberLong(6) }
4 }
Příklad 8: metadata souboru v kolekci u s e r . f i l e s
6.1.1.1 Uložení souboru do databáze
Rozhraní MongoFile poskytuje několik metod pro uložení souboru do databáze.
Základem je metoda s ave obsahující hlavní logiku vkládání nového
souboru. Při volání této metody je potřeba uvést následující parametry:
1. c o n t e n t
Obsah ukládaného souboru. Zdrojem dat může být instance třídy
F i l e , M u l t i p a r t F i l e , I n p u t S t r e a m nebo pole bytů.
2. i d
Identifikátor vázané entity nebo nu 11 v případě souboru bez vazby.
3. b u c k e t
Kořenový kyblíček použitého GridFS. V případě hodnoty nu 11 se
použije výchozí kyblíček.
4. g r o u p
Zařazení souboru do skupiny.
5. m e t a d a t a
Doplňující informace o souboru.
6. f i l e n a m e
Jméno ukládaného souboru. Pokud je to možné, je jako výchozí hodnota
použito jméno původního souboru.
7. d e l e t e
Způsob jakým postupovat v případě již existujícího souboru se stejným
m o n g o l d nebo kombinací atributů i d a g r o u p .
V případě hodnoty t r u e budou existující soubory smazány.
8. m o n g o l d
Unikátní identifikátor dokumentu uloženého v kolekci f i l e s .
25
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
Z množství parametrů metody s ave je zřejmé, že její použití není příliš
pohodlné. Metoda navíc umožňuje libovolnou kombinaci hodnot a uživatele
nijak nenutí dodržovat stanovené konvence pro jména kyblíčků či nastavení
metadat. Z tohoto důvodu obsahuje třída G r i d F i l e S e r v i c e také
přetíženou variantu s ave umožňující použití jmenných parametrů v kombinaci
s výchozími hodnotami.
1 d e f t h e s i s = T h e s i s . g e t ( 1 )
2 d e f f i l e = new F i l e ( ' / h o m e / j c e c h a c e / f i l e . z i p ' )
3
4 / / uloženi souboru bez doménové vazby
5 g r i d F i l e S e r v i c e . s a v e ( f i l e , n u l l , n u l l , n u l l , n u l l , "
s t a n d a l o n e _ f i l e . z i p " , f a l s e , n u l l )
6
7 // s použitím jmenych atributu
8 g r i d F i l e S e r v i c e . s a v e ( c o n t e n t : f i l e , f i l e n a m e : "
s t a n d a l o n e _ f i l e . z i p " )
9
10
n / / uloženi souboru s doménovou vazbou
12 g r i d F i l e S e r v i c e . s a v e ( f i l e , 1, " t h e s i s " , " a r c h i v e s " ,
n u l l , " b o u n d _ f i l e . z i p " , f a l s e , n u l l )
13
14 // s použitím jmenych atributu
is g r i d F i l e S e r v i c e . s a v e ( c o n t e n t : f i l e , f i l e n a m e : "
b o u n d _ f i l e " , o b j e c t : t h e s i s )
Příklad 9: uložení souboru do databáze
6.1.1.2 Získání souboru z databáze
Rozhraní MongoFile umožňuje uložené soubory z GridFS získat buďto na
základě informací uložených v metadatech, nebo přímo pomocí _ i d dokumentu
v kolekci f i l e s .
26
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
1 d e f t h e s i s = T h e s i s . g e t ( 1 )
2
3 / / získaní souboru z kyblíčku "thesis" podle _íd
dokumentu
4 d e f f i l e = g r i d F i l e S e r v i c e . g e t F i l e B y U n i v e r s a l M o n g o I d (
mongold, " t h e s i s " )
5
6 // získaní souboru z kyblíčku podle metadat
7 d e f f i l e = gridFileService.getFile(['iď: 1, group: "
a r c h i v e s " ] , " t h e s i s " )
*
9 // místo konkreního kyblíčku lze uvést doménovou třídu
ío d e f f i l e = g r i d F i l e S e r v i c e . g e t F i l e (['iď : 1, group: "
a r c h i v e s " ] , T h e s i s . c l a s s )
Příklad 10: získání souboru z databáze
V případě vyhledávání souboru na základě metadat vrátí volání metody
g e t A U F i l e s pouze jednu instanci G r i d F S D B F i l e reprezentující soubor
s nejnižším _ i d . Pro získání všech vyhovujících souborů jsou k dispozici
přetížené varianty vracející seznam objektů typu G r i d F S D B F i l e .
6.1.2 Zasílání souborů klientovi
Poslední, avšak neméně důležitou, schopností MongoFile je zaslání získaného
souboru klientské aplikaci. Metoda s e r v e F i l e třídy G r i d F i l e S e r v i c e
nastaví potřebné hlavičky, jako například c o n t e n t - t y p e , a zapíše požadovaný
soubor do výstupního proudu HTTP odpovědi.
1 // získaní souboru z databáze
2 d e f f i l e = gridFileService.getFile(['iď: 1, group: "
a r c h i v e s " ] , T h e s i s . c l a s s )
3
4 / / zapsaní souboru do http odpovedí
5 g r i d F i l e S e r v i c e . s e r v e F i l e ( r e s p o n s e , f i l e , t r u e )
Příklad 11: zaslání souboru klientovi
Na příkladu lze vidět, že volání metody s e r v e F i l e vyžaduje tři para
metry:
1. R e s p o n s e : objekt reprezentující odpovědi HTTP protokolu.
2. F i l e : instanci třídy G r i d F S D B F i l e zasílanou klientovi.
27
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
3. S a v e : vynucení stažení souboru webovým prohlížečem.
Pravděpodobně nejčastější použití této metody bude jako součást akce v Controllern.
Proto jsem v rámci implementace MongoFile vytvořil jednoduchý
Controller G r i d F i l e C o n t r o l l e r , schopný při volání akce s e r v e F i l e
zaslat soubor s požadovaným identifikátorem.
6.1.2.1 Knihovna značek pro práci s GridFile
Pro usnadnění přístupu k souborům z prezentační vrstvy jsem implementoval
také knihovnu značek G r i d F i l e T a g L i b . Knihovna využívá jmenný
prostor g r i d a obsahuje modifikované verze značek l i n k a c r e a t e L i n k
ze standardní knihovny Grails. První značka slouží pro vytvoření hypertextového
odkazu na soubor, druhá pak pouze pro sestavení adresy využitelné
například v html značce ![]()
.
6.2 Nahrávání souborů
Implementace funkcionality pro nahrávání souborů se skládá ze dvou částí.
Klienta umožňujícího zaslat soubory na server, který následně interpretuje
výsledek provedené operace v uživateli přívětivé podobně. Právě tuto část
řeší použití nástroje Fine Uploader[13]. Implementací serverové části, zajišťující
zpracování přijatých dat, a její spolupráci s klientskou části aplikace
se zabývají následující podkapitoly.
6.2.1 Přijetí a zpracování nahrávaných dat
Celý proces nahrání souboru od uživatele na server lze rozdělit do 4 kroků
1. Uživatel vybere soubor.
2. Klientská aplikace zašle data na server.
3. Server příjme zaslaná data, zpracuje je a zašle zpět odpověď.
4. Uživateli je zobrazen výsledek.
Jak bylo zmíněno na začátku kapitoly, Fine Uploader se z vetší části postará
o všechny body s výjimkou čísla tři. Příjem a zpracování dat se při
použití architektury M V C běžně provádí vytvořením akce v příslušném
Controllern. V informačních systémech je však nezřídka potřeba zpracovávat
soubory určené pro různé části systému různým způsobem. Definování
28
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
akce pro každý druh souboru však často povede k množství opakujícího se
kódu.
1 d e f uploadToMongo() {
2 t r y {
3 M u l t i p a r t F i l e f i l e = ((
M u l t i p a r t H t t p S e r v l e t R e q u e s t ) r e q u e s t ) .
g e t F i l e ( ' q q f i l e ' )
4
5 // ulozeni souboru
6 d e f saved = g r i d F i l e S e r v i c e . s a v e ( f i l e , o b j e c t :
s p r i n g S e c u r i t y S e r v i c e . c u r r e n t U s e r , group: '
f i l e s ' )
7
8 / / vraceni vysledku
9 r e t u r n r e n d e r ( t e x t : [ s u c c e s s : t r u e ] as JSON,
c o n t e n t T y p e : ' t e x t / j s o n ' )
10 } c a t c h ( E x c e p t i o n e) {
n / / nastala chyba
12 l o g . e r r o r ( " E r r o r ^ d u r i n g ^ f ile,_,upload" , e)
13 d e f e r r o r M e s s a g e = message(code: 'uploader.
e r r o r . u p l o a d ' )
14
15 r e t u r n r e n d e r ( t e x t : [ s u c c e s s : f a l s e , message:
e r r o r M e s s a g e ] as JSON, c o n t e n t T y p e : ' t e x t /
json')
16 }
17 }
Příklad 12: akce pro zpracování přijatého souboru
Na příkladu výše lze vidět, že samotné uložení souboru do databáze
tvoří jen minimální část celé akce. Zbytek kódu se proto bude nejspíš opakovat
ve většině podobných metod. V systému pro správu diplomových
prací minimalizuji množství takového kódu pomocí návrhového vzoru Pozorovatel
a reaktivního přístupu1
.
6.2.1.1 Příjem souborů
V rámci vyvinutého systému jsem vytvořil controller c o m . r e d h a t . g r a i l s
. u p l o a d . U p l o a d C o n t r o l l e r , jehož akce u p l o a d slouží jako jediný kon-
1. Různé akce vyvolávají v systému tzv. události (anglicky events). Reakce na tyto události
je pak přesunuta do speciálních metod nazývaných pozorovatel (anglicky observer).
29
6. I M P L E M E N T A C E SPRÁVY S O U B O R Ů
cový bod pro příjem souborů v celém systému. Místo zpracování přijatého
souboru však tato akce za použití servisní třídy U p l o a d S e r v i c e v systému
vyvolá událost obsahující data potřebná ke zpracování. Konkrétní vyvolané
události lze specifikovat pomocí parametru t o p i č zaslaného jako
součást HTTP požadavku spolu se souborem. Logika pro zpracování přijatého
souboru je potom součástí metody reagující na vyvolanou událost.
Systém pro správu diplomových prací používá události a v a t a r a t h e s i s .
První slouží k archivaci profilových obrázků uživatelů, druhý k archivaci
souborů asociovaných s pracemi studentů. Obsluhu těchto událostí lze najít
ve třídě com. r e d h a t . t h e s e s . l i s t e n e r s . U p l o a d L i s t e n e r S e r v i c e
6.2.1.2 Knihovna značek
Pro snadnější použití nástroje Fine Uploader a eliminaci redundantního
kódu jsem vytvořil knihovnu značek U p l o a d e r T a g l i b , která slouží k zapouzdření
konfigurace a integraci s platformou Grails - včetně podpory
internacionalizace nástroje.
1
2 < u : t r i g g e r i d = " t r i g g e r U p l o a d " c l a s s = " t m s - b t n " >
3 < i c l a s s = " i c o n - u p l o a d " x / i >
4
5 < / u : t r i g g e r >
6
Příklad 13: použití nástroje Fine Uploader pomocí definovaných značek
30
7 Nasazení systému a budoucí vývoj
Po ukončení vývoje základních funkcí stanovených funkčními požadavky
byl systém pro správu diplomových prací nasazen do cloudového prostředí
OpenShift. OpenShift je „Platform as a Service" řešení vyvíjené společností
Red Hat, které umožňuje nasazení webových aplikací bez nutnosti
správy vlastních serverů. Základní stavební jednotkou v rámci prostřední
OpenShift je takzvaný „gear", reprezentující množství zdrojů (hardwarových
i softwarových) dostupných konkrétní aplikaci. V současné době jsou
k dispozici tři druhy gearů, v základu všechny poskytují 1GB diskového
prostoru [15]:
• Small gear (512 M B RAM): vhodný pro skriptovací jazyky
• Medium gear (1 GB RAM): vhodný pro JVM a provoz databází
• Large gear (2 GB RAM): vhodný pro vysoce náročné aplikace
V rámci jednotlivých gearů pak lze provozovat takzvané „cartridges",
což jsou nástroje připravené k nasazení v prostředí OpenShift - v podstatě
se jedná o ekvivalent linuxových balíčků. K dispozici je řada připravených
technologií - například aplikační servery či různé databáze.
Pro nasazení vyvinutého systému byl použit střední gear s diskovou
kapacitou navýšenou na hodnotu 10 GB, aplikace běží na JBoss EWS 2.01
a
využívá také cartridge s databázemi PostgreSQL a MongoDB. Celý proces
nasazení aplikace je velmi jednoduchý a zahrnuje tyto kroky:
1. Vytvoření cartridge pro Jboss EWS a databáze.
2. Přidání vzdáleného OpenShift repozitáře do nastavení lokálního git
repozitáře
3. Vytvoření souboru .my en v a export proměnných prostředí s nastavením
emailového serveru
e x p o r t O P E N S H I F T _ E M A I L _ H O S T = " s m t p . e x a m p l e . c o m "
e x p o r t O P E N S H I F T _ E M A I L _ P O R T = 4 65
e x p o r t O P E N S H I F T _ E M A I L _ U S E R N A M E = " e @ e x m p l . c o m "
e x p o r t O P E N S H I F T _ E M A I L _ P A S S W O R D = " p a s s w o r d "
4. Synchronizace vzdáleného a lokálního repozitáře příkazem g i t p u s h
1. Jboss Enterprise Web Server
31
7. N A S A Z E N Í S Y S T É M U A B U D O U C Í V Ý V O J
< < d e v i c e > >
OpenShift Gear
: < d a t a b a s e > ;
PostgreSQL
< d a t a b a s e >
MongoDB
JDBC JDBC
~7\
JBoss EWS 2.0
1
< < e x e c u t i o n E n v í r o n m e n t »
Java Virtual Machine
j
< < a r t i f a c t > >
thesismanagementsystem.war
Ď
<<
< d e v í c e > >
Client Computer
< c o m p o n e n t > > ^
Browser
Obrázek 7.1: Diagram nasazení[2]
7.1 Budoucí vývoj
Vývoj systému pro správu diplomových prací jeho nasazením neskončil.
Testovací provoz systému v semestru podzim 2013 již přinesl hodnotnou
zpětnou vazbu zástupců firmy Red Hat i vedoucích z Masarykovy univerzity
a Vysokého učení technického v Brně. Mezi nejčastější požadavky zástupců
obou stran patří
1. seznam vypsaných témat určený k tisku
2. export vypsaných témat
3. podpora školních projektů
První položku seznamu se podařilo implementovat již v průběhu testovacího
provozu. Export vypsaných témat předneslo jako návrh několik
zástupců M U a VUT. Tento požadavek je pochopitelný, jelikož možnost
importovat data (nebo automatizace jejich zadávání) zásadním způsobem
sníží množství práce vedoucích. V následujícím semestru proto plánujeme
vyvinutý systém rozšířit o export témat ve formátu X M L 2
a CSV3
.
2. Extensible Markup Language
3. Comma-separated values
32
7. N A S A Z E N Í S Y S T É M U A B U D O U C Í V Ý V O J
Kromě spolupráce v oblasti diplomových prací vyučuje společnost Red
Hat na partnerských univerzitách několik kurzů4
. Požadavek na rozšíření
systému o správu těchto kurzů byl očekávaný, avšak implementace požadované
funkcionality bude časově náročná. Správa kurzů se totiž od diplomových
prací výrazně liší.
V rámci budoucího vývoje je v plánu také vyčlenit funkcionalitu pro
práci s GridFS a nahrávání souborů do samostatných zásuvných modulu.
Zatímco v případě GridFS se jedná pouze o „formality" v podobě vyčlenění
kódu,v případě modulu pro nahrávání souborů je situace složitější. Během
uplynulého půl roku došlo k vydání nové verze nástroje Fine Uploader,
jenž rozšiřuje možnosti konfigurace a řeší problém oddělení prezentační
vrstvy, se kterým se tento nástroj dlouhodobě potýkal. V důsledku těchto
změn si tak vyčlenění modulu vyžádá rozsáhlý refaktoring.
Rád bych také zmínil chystanou změnu webové adresy, na které je systém
dostupný. Současná adresa5
je příliš komplikovaná a nepřehledná. Aktuálně
proto připravujeme přesunutí systému pod doménu společnosti Red
Hat, na adresu h t t p s : / / d i p l o m k y . r e d h a t . com.
4. Na FI se jedná například o kurz programovacího jazyka Python nebo enterprise Java
technologií
5. https:/ / thesis-managementsystem.rhcloud.com
33
8 Závěr
Hlavním cílem této práce bylo implementovat nový systém správy diplomových
prací pro průmyslové partnera Fakulty informatiky společnost Red
Hat. První část tohoto dokumentu poskytla základní informace o vyvinutém
systému a stručně představila použité technologie. Následovalo podrobnější
seznámení s aplikačním rámcem Grails, architekturou a vývojem
aplikací na této platformě. Třetí část byla věnována práci se soubory ve vyvinutém
systému se zaměřením na detaily vlastní implementace. V závěru
jsem popsal nasazení vyvinuté aplikace do cloudu OpenShift.
Systém se podařilo implementovat a úspěšně nasadit do produkčního
prostředí. Aktuálně tak probíhá první semestr testovacího provozu, v rámci
kterého se zaměřujeme na připomínky uživatelů, primárně studentů a vyučujících
z jednotlivých univerzit. Spolu s odstraňováním případně nalezených
chyb je systém průběžně upravován podle získaných ohlasů.
34
Literatura
[1] J. A. O'Brien, Introduction to Information Systems, eleventh ed.
McGraw-Hill, June 2003.
[2] V. Dedik, Thesis management system for industrial partner Red Hat,
Brno, 2013.
[3] D. Koenig, A . Glover, P. King, G. Laforge, J. Skeet, and J. Gossling,
Groovy in Action. Manning Publications, January 2007.
[4] Groovy homepage. [Online]. Available: http://groovy.codehaus.org
[5] Grails homepage. [Online]. Available: http://grails.org
[6] Mongodb homepage. [Online]. Available: http://www.mongodb.
org/
[7] P. Dedík, Grafické uživatelské rozhraní systému pro správu záverečných
prací, Brno, 2013.
[8] G. Smith and P. Ledbrook, Grails in Action. Manning Publications,
May 2009.
[9] Spring framwork homepage. [Online]. Available: http://spring.io/
[10] D. Koenig, A . Glover, P. King, G. Laforge, J. Skeet, and J. Gossling,
Programming Grails. Manning Publications, May 2013.
[11] Grails framework. [Online]. Available: http://grails.org/doc/latest/
[12] M . Fowler, Patterns of Enterprise Application Architecture. AddisonWesley
Professional, November 2002.
[13] Fineuploader homepage. [Online]. Available: http://fineuploader,
com/
[14] Mongodb. [Online]. Available: http://docs.mongodb.org/manual/
[15] Openshift online pricing. [Online]. Available: https://www.openshift.
com/products/ pricing
35
A Doplňující informace
A . l Rozšíření pro práci s Mongo GridFS
• MongoDB Tools
• Mongodb Gridfs Plugin
• MongoDB G O R M
• MongoDB G O R M - Morphia
• MongoFile Plugin
B Diagramy
B.l Domain Model
Supervision
feed 1
content
dateCreated
privateComment
V
messageCode
args
dateCreated
User
fullName
password
email
dateCreated
enabled
accountLocked
sendMail
roles
1 assignei
1 subscriber
Topic
secondaryTitle
lead
description
secondary Description
dateCreated
enabled
types
T~K—:—
topic
categories
^> University
university 1
*^>
1
university
Fag
question
answer
locale
37
C Odkazy
C . l Zdrojový kód projektu
Repozitář se zdrojovými kódy projektu (Thesis Management System) je
hostován službou GitHub:
h t t p s : / / g i t h u b . c o m / j c e c h a c e / T h e s i s - m a n a g e m e n t - s y s t e m
C.2 Adresa nasazeného systému
h t t p s : / / t h e s i s - m a n a g e m e n t s y s t e m . r h c l o u d . c o m /
38