Moˇznosti na´vrhu webovy´ch aplikac´ı (Vy´nˇatek z diplomov´e pra´ce) Luk´aˇs Gemela, A11N0101P
[email protected] 25. ˇcervna 2013
Obsah ´ 1 Uvod
2
2 V´ıcevrstv´ a architektura 2.1 Z´ asady pro n´ avrh v´ıcevrstv´eho modelu . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Tˇr´ıvrstv´ a architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 3
3 Aplikaˇ cn´ı vrstva 3.1 Dom´enov´ y model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Servisn´ı vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 6 6
4 Vrstva persistence dat 4.1 Syst´em ˇr´ızen´ı b´ aze dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Objektovˇe-relaˇcn´ı mapov´ an´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Data Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 8 9 10
5 Prezentaˇ cn´ı vrstva 5.1 Architektura MVC (Model-View-Controller ) 5.2 MVC v prostˇred´ı webu . . . . . . . . . . . . 5.3 Architektura MVP (Model-View-Presenter ) 5.4 JavaServer Faces . . . . . . . . . . . . . . . 5.5 Shrnut´ı . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
12 12 14 16 17 18
6 Architektura orientovan´ a na sluˇ zby 6.1 Sluˇzba v SOA . . . . . . . . . . . . 6.2 SOA a tˇr´ıvrstv´ a architektura . . . 6.3 V´ yhody SOA . . . . . . . . . . . . 6.4 Protokoly komunikace v SOA . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
20 20 20 20 21
7 Technologick´ e n´ astroje pro v´ yvoj 7.1 Aspektovˇe orientovan´e programov´an´ı . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23 23
8 Z´ avˇ er
25
. . . .
. . . .
. . . .
1
. . . .
. . . .
´ 1 Uvod N´ asleduj´ıc´ı text je v´ yn ˇatek z diplomov´e pr´ace Mobiln´ı aplikace pro rezervace objekt˚ u. Tato diplomov´ a pr´ ace si klade za c´ıl vytvoˇrit syst´em pro obecnou spr´avu v´ yp˚ ujˇcek a rezervac´ı movit´ ym a nemovit´ ych objekt˚ u, a to pomoc´ı unik´atn´ıch moˇznost´ı mobiln´ıch zaˇr´ızen´ı. Protoˇze v´ ysledn´ y syst´em implementuje centr´ aln´ı server s webov´ ym rozhran´ım a dalˇs´ımi sluˇzbami, je souˇc´ast´ı diplomov´e pr´ ace je i anal´ yza moˇznost´ı implementace takov´e serverov´e aplikace. Tato anal´ yza je pot´e i samotn´ ym obsahem tohoto dokumentu. Budou zde rozebr´ any moˇznosti n´ avrhu a implementace syst´emu pro spr´avu rezervac´ı a uvedeny nˇekter´e vyuˇziteln´e technologie zaloˇzen´e na platformˇe Java (c´ılem tohoto textu vˇsak nen´ı poskytˇ aˇr se sezn´am´ı s obecn´ nut´ı kompletn´ı program´ atorsk´e dokumentace). Cten´ ymi architektonick´ ymi principy uplatniteln´ ymi pˇri vytv´ aˇren´ı informaˇcn´ıch syst´em˚ u a distribuovan´ ych webov´ ych aplikac´ı.
2
2 V´ıcevrstv´ a architektura V´ıcevrstv´ a architektura je architektonick´ y vzor, ve kter´em se model aplikace skl´ad´a z v´ıce vz´ajemnˇe spolupracuj´ıc´ıch vrstev. Soused´ıc´ı vrstvy komunikuj´ı pˇres pˇredem definovan´a rozhran´ı a d´ıky tomu mohou b´ yt zamˇen ˇov´ any, aniˇz by to mˇelo dopad na funkˇcnost cel´e aplikace nebo bylo nutn´e mˇenit ostatn´ı vrstvy. Pˇrenos dat a definov´ an´ı vz´ajemn´eho rozhran´ı mezi vrstvami je souˇc´ast´ı n´avrhu v´ıcevrstv´e architektury. Pravdˇepodobnˇe nejzn´ amˇejˇs´ım z´ astupcem uplatnˇen´ı v´ıcevrstv´e architektury je referenˇcn´ı OSI (Open Systems Interconnection) model. Jeho p˚ uvodn´ım u ´ˇcelem byla snaha o standardizaci komunikace uvnitˇr poˇc´ıtaˇcov´ ych s´ıt´ı [1], dnes se vˇsak pouˇz´ıvaj´ı jeho jednoduˇsˇs´ı odvozeniny (napˇr. protokol TCP/IP) a p˚ uvodn´ı model m´ a sp´ıˇse metodick´ y v´ yznam. Je vˇsak pˇr´ıkladem, ˇze v´ıcevrstv´a architektura se nemus´ı omezovat pouze na ˇcistˇe softwarovou implementaci. Model se skl´ ad´ a ze sedmi vrstev. Nejvyˇsˇs´ı vrstva v modelu zajiˇst’uje pˇr´ıstup aplikac´ı k s´ıt’ov´emu komunikaˇcn´ımu syst´emu. Pokud klientsk´a aplikace vytvoˇr´ı poˇzadavek na pˇr´ıstup do s´ıtˇe, je tento pˇred´ av´ an sestupnˇe v z´ asobn´ıku vstev aˇz do vrstvy nejniˇzˇs´ı, kter´a zajiˇst’uje pˇr´ım´ y pˇr´ıstup k fyzick´emu m´ediu. Kaˇzd´ a vrstva m´ a pˇresnˇe vymezenou sadu u ´kol˚ u jako je ˇsifrov´an´ı, navazov´an´ı spojen´ı, synchronizace, smˇerov´ an´ı atp. a m´a jednoznaˇcnˇe definov´ano rozhran´ı mezi sousedn´ımi vrstvami v z´ asobn´ıku. Na tom lze n´ azornˇe demonstrovat v´ yhody v´ıcerstv´ ych architektur. D´ıky tomu, ˇze se kaˇzd´a vrstva omezuje na pˇredem definovanou sadu u ´kol˚ u a kaˇzd´a pracuje s jinou u ´rovn´ı abstrakce, zb´ yv´a jen mal´ y krok k vytvoˇren´ı standardizovan´ ych protokol˚ u pro kaˇzdou vrstvu. Jednotliv´e implementace tˇechto protokol˚ u bude pot´e moˇzn´e libovolnˇe vymˇen ˇovat bez ovlivnˇen´ı funkcionality ostatn´ıch vrstev. Pokud se uk´ aˇze, ˇze souˇcasn´ a implementace je jiˇz pˇr´ıliˇs sloˇzit´a, je moˇzn´e vrstvy d´ale dˇelit. Tyto lze dokonce i sluˇcovat, jak se tak´e stalo ve v´ yˇse zm´ınˇen´e od OSI modelu odvozen´e architektuˇre TCP/IP, kter´ a vyuˇz´ıv´ a pouze ˇctyˇr vrstev.
2.1
Z´ asady pro n´ avrh v´ıcevrstv´ eho modelu
Architekt aplikace by mˇel navrhnout novou vrstvu vˇsude tam, kde je zapotˇreb´ı jin´ y stupeˇ n abstrakce. Kaˇzd´ a vrstva by mˇela zajiˇst’ovat pˇresnˇe vymezen´e funkce zvolen´e tak, aby pro jejich realizaci mohly b´ yt vytvoˇreny standardizovan´a rozhran´ı nebo protokoly. Poˇcet vrstev by mˇel b´ yt tak velk´ y, aby vz´ ajemnˇe odliˇsn´e funkce nemusely b´ yt zaˇrazov´any do stejn´e vrstvy, a souˇcasnˇe s t´ım tak mal´ y, aby cel´ a architektura z˚ ustala dostateˇcnˇe pˇrehledn´a. Moˇzn´e budouc´ı komplexn´ı pˇrepracov´an´ı vrstvy nesm´ı z´ asadnˇe ovlivnit sousedn´ı vrstvy. Rozhran´ı mezi vrstvami by mˇela b´ yt zvolena tak, aby byl minimalizov´ an tok dat.
2.2
Tˇ r´ıvrstv´ a architektura
Tˇr´ıvrstv´ a architektura je obecn´ y typ v´ıcevrstv´e architektury. Je s oblibou vyuˇz´ıv´ana v kombinaci s modelem distribuovan´e aplikace klient-server. Rozdˇeluje aplikaci do tˇr´ı separ´atn´ıch logick´ ych vrstev, kter´e nemus´ı nutnˇe bˇeˇzet na stejn´ ych zaˇr´ızen´ıch nebo operaˇcn´ıch syst´emech. Rozdˇelen´ı architektury je zjednoduˇsenˇe zn´ azornˇeno na Obr. 2.1. Prezentaˇcn´ı vrstva zajiˇstuje vizualizaci dat pro uˇzivatele a interakci s uˇzivatelem [3]. Aplikaˇcn´ı (dom´enov´ a) vrstva obsahuje samotn´e j´adro aplikace, funkce pro v´ ypoˇcty nebo zpracov´an´ı dat.
3
Obr´ azek 2.1: Z´akladn´ı sch´ema tˇr´ıvrstv´e aplikace. Datov´ a vrstva se pot´e star´ a o persistenci dat. Je nutn´e zm´ınit, ˇze v ˇcistˇe tˇr´ıvrstv´e architektuˇre se tok dat dˇeje vˇzdy jen mezi soused´ıc´ımi vrstvami, tzn. pˇri pˇr´ıstupu z prezentaˇcn´ı vrstvy nem˚ uˇze ´ b´ yt prostˇredn´ı vrstva pˇrekroˇcena a opaˇcnˇe. Ukolem tˇr´ıvrstv´e architektury nen´ı definov´an´ı rozhran´ı mezi vrstvami nebo technologick´eho z´ akladu pro tˇr´ıvrstv´e aplikace, klade si za c´ıl pouze rozvrˇzen´ı logick´eho modelu aplikace. Na Obr´ azku 2.2 je zn´ azornˇeno typick´e rozvrˇzen´ı tˇr´ıvrstv´e aplikace. Datov´a vrstva je zde reprezentov´ ana relaˇcn´ı datab´ az´ı na vzd´ alen´em serveru. K t´eto datab´azi se pˇripojuje aplikaˇcn´ı server, zajiˇst’uj´ıc´ı v´ ypoˇcetn´ı j´ adro syst´emu. K aplikaˇcn´ımu serveru se pˇripojuj´ı jednotliv´ı klienti – na tˇechto zaˇr´ızen´ıch jsou data vizualizov´ ana a je umoˇznˇeno uˇzivatel˚ um tˇechto klient˚ u s daty pracovat. D´ıky existenci aplikaˇcn´ıho serveru tito klienti neobsahuj´ı ˇz´adnou dalˇs´ı aplikaˇcn´ı logiku a hraj´ı roli tzv. tenk´ych klient˚ u.
Obr´ azek 2.2: Pˇr´ıklad tˇr´ıvrstv´e architektury (tenk´y klient).
4
Nicm´enˇe d´ıky obecnosti tˇr´ıvrstv´e architektury je moˇzn´e si pˇredstavit celou ˇradu jin´ ych sc´en´aˇr˚ u. Kupˇr´ıkladu relaˇcn´ı datab´ aze m˚ uˇze fungovat pˇr´ımo na aplikaˇcn´ım serveru nebo m˚ uˇze u ´plnˇe chybˇet a roli datov´e vrstvy sehraje napˇr. implementace transformuj´ıc´ı data do XML soubor˚ u. Na Obr. 2.3 je pak zn´ azornˇena situace, kde aplikaˇcn´ı server zcela chyb´ı. Aplikaˇcn´ı vrstva m˚ uˇze b´ yt pot´e pˇr´ıtomna jako souˇc´ ast relaˇcn´ı datab´ aze v podobˇe uloˇzen´ ych procedur a tzv. trigger˚ u (viz d´ale), nebo mohou jednotliv´ı klienti s sebou n´est i aplikaˇcn´ı logiku – stanou se tzv. tlust´ymi klienty. Je moˇzn´e tyto postupy i kombinovat. Je moˇzn´e (a dnes jiˇz celkem obvykl´e), aby ˇc´ast aplikaˇcn´ı logiky leˇzela na aplikaˇcn´ım serveru a ˇc´ ast k´ odu se spouˇstˇela na jednotliv´ ych klientech.
Obr´ azek 2.3: Pˇr´ıklad tˇr´ıvrstv´e architektury (tlust´y klient). Vyuˇzit´ı tˇr´ıvrstv´e architektury je tedy velice flexibiln´ı. Pˇri n´avrhu syst´emu si softwarov´ y architekt mus´ı velmi dobˇre rozmyslet celkov´e rozvrˇzen´ı jednotliv´ ych logick´ ych vrstev s ohledem na v´ ykon, bezpeˇcnost, udrˇzitelnost, technick´e vlastnosti a moˇznosti klientsk´ ych zaˇr´ızen´ı a dalˇs´ı rozˇsiˇritelnost navrhovan´eho syst´emu. Je tak´e nutn´e vˇzdy jednoznaˇcnˇe definovat komunikaˇcn´ı rozhran´ı mezi vrstvami podle z´ asad n´ avrhu v´ıcevrstv´ ych aplikac´ı tak, aby bylo moˇzn´e jednotliv´e vrstvy zamˇenit nebo je standardizovat. Nyn´ı si detailnˇeji rozebereme jednotliv´e ˇc´asti a dalˇs´ı architektonick´e vzory tˇr´ıvrstv´e architektury s ohledem na moˇzn´e vyuˇzit´ı pˇri implementaci distibuovan´ ych webov´ ych aplikac´ı.
5
3 Aplikaˇ cn´ı vrstva Aplikaˇcn´ı (nebo tak´e dom´enov´ a) vrstva je takov´a vrstva, do kter´e by mˇelo b´ yt soustˇredˇeno maximum v´ ykonn´eho k´ odu a vlastn´ı logiky aplikace. Existuje cel´a ˇrada obecn´ ych architektonick´ ych vzor˚ u uplatniteln´ ych pˇri n´ avrhu t´eto vrstvy, nicm´enˇe zejm´ena u webov´ ych aplikac´ı se vrstva obvykle rozdˇel´ı na dom´enov´y model, ve kter´em jsou definov´any z´akladn´ı entity aplikace a jejich vz´ ajemn´e vazby, a servisn´ı vrstvu, kter´a s t´ımto modelem manipuluje nebo vytv´aˇr´ı jeho rozhran´ı [3].
3.1
Dom´ enov´ y model
Dom´enov´ y model vytv´ aˇr´ı jakousi s´ıt’ objekt˚ u navz´ajem spojen´ ych vazbami, kde kaˇzd´ y objekt obvykle reprezentuje nˇejakou entitu v re´aln´em svˇetˇe. N´avrhem dom´enov´eho modelu by mˇel zaˇc´ınat jak´ ykoliv n´ avrh implementace aplikace a jeho programov´e realizaci obvykle pˇredch´az´ı vytvoˇren´ı analytick´eho dom´enov´eho modelu za vyuˇzit´ı jazyka UML (Unified Modeling Language). Objekty dom´enov´eho modelu maj´ı sadu atribut˚ u definovanou tak, aby se co nejv´ıce pˇribl´ıˇzily sv´emu re´ aln´emu vzoru. Kaˇzd´ y objekt dom´enov´eho modelu by vˇsak mˇel b´ yt jen tak velk´ y, jak je to bezpodm´ıneˇcnˇe nutn´e. V pˇr´ıpadˇe pˇr´ıliˇs komplexn´ıho objektu je vhodn´e ho rozdˇelit na menˇs´ı objekty a tyto propojit vazbami. Kv˚ uli snadn´e rozˇsiˇritelnosti a udrˇzitelnosti je d˚ uleˇzit´e m´ıt neust´ ale moˇznost bˇehem ˇzivotn´ıho cyklu aplikace snadno dom´enov´ y model mˇenit a testovat. D´ale je nutn´e udrˇzovat co nejm´enˇe vazeb modelu na ostatn´ı ˇc´asti syst´emu (coˇz je mimo jin´e c´ılem mnoha n´ avrhov´ ych vzor˚ u). Ve svˇetˇe Javy jsou obvykle jednotliv´e dom´enov´e objekty realizov´any pomoc´ı POJO (Plain Old Java Object) objekt˚ u. Definice POJO vznikla jako reakce na nepˇr´ıliˇs flexibiln´ı EJB2 (Enterprise Java Bean), kter´e se v´ aˇz´ı na pouˇzit´ y framework a nesplˇ nuj´ı tak poˇzadavek na co nejniˇzˇs´ı poˇcet vazeb modelu na okoln´ı programov´e prostˇred´ı. Pro POJO neexistuje ˇz´adn´ y uchopiteln´ y standard, nicm´enˇe lze je definovat jako instance kaˇzd´e Java Beany, kter´a se snaˇz´ı minimalizovat sv´e vazby v˚ uˇci okol´ı at’ uˇz po str´ ance anotac´ı, dˇediˇcnosti nebo implementace rozhran´ı. To samozˇrejmˇe nen´ı (napˇr´ıklad v pˇr´ıpadˇe spolupr´ ace aplikace s jin´ ymi frameworky) t´emˇeˇr nikdy moˇzn´e, nicm´enˇe zejm´ena podm´ınka neexistuj´ıc´ı dˇediˇcnosti od nˇejak´e komponenty uˇzit´eho frameworku by mˇela b´ yt splnˇena. Pod pojmem Java Bean se pot´e ch´ape takov´a tˇr´ıda, k jej´ımˇz ˇclensk´ ym promˇenn´ ym se pˇristupuje pouze pomoc´ı veˇrejn´ ych getter˚ u a setter˚ u a tyto dodrˇzuj´ı jist´e jmenn´e konvence. Pro pˇr´ıstup k jednotliv´ ym ˇclensk´ ym promˇenn´ ym se d´ıky jednoduchosti POJO m˚ uˇze vyuˇz´ıt pokroˇcil´ ych programovac´ıch technik, jako je aspektov´e programov´an´ı a reflexe. Obdobn´a situace je i v jin´ ych programov´ ych prostˇred´ıch (napˇr. v .NET Frameworku), i kdyˇz syntax k´odu a uˇzit´a terminologie se samozˇrejmˇe liˇs´ı.
3.2
Servisn´ı vrstva
Jak ukazuje Obr. 3.1, servisn´ı vrstva je v hierarchii vrstev um´ıstˇena na vyˇsˇs´ı u ´rovni abstrakce neˇz je dom´enov´ y model a souˇcasnˇe vytv´ aˇr´ı programov´e rozhran´ı (Application Programming Interface, zkratkou API) pro prezentaˇcn´ı vrstvu. Jinak neˇz skrze servisn´ı vrstvu nelze s dom´enov´ ym modelem pracovat.
6
Obr´ azek 3.1: Z´akladn´ı rozdˇelen´ı aplikaˇcn´ı vrstvy. Servisn´ı vrstva je d´ıky tomu, ˇze tvoˇr´ı u ´zk´e hrdlo“ v toku dat, dobr´ ym m´ıstem nejen pro um´ıstˇen´ı ” aplikaˇcn´ı logiky, ale i zabezpeˇcen´ı nebo kontroly dat. Podle [3] existuj´ı dva pˇr´ıstupy, jak vytvoˇrit servisn´ı vrstvu. Prvn´ı z nich je tzv. Dom´ enov´ a Fas´ ada. Ta principi´alnˇe deleguje aplikaˇcn´ı logiku do dom´enov´eho modelu a tvoˇr´ı pouze zmiˇ novan´e rozhran´ı mezi prezentaˇcn´ı a aplikaˇcn´ı vrstvou a celou servisn´ı vrstvu tvoˇr´ı pouze mnoˇzina fas´ ad nad dom´enov´ ym modelem. Fas´ady obsahuj´ı pouze ty operace, kter´e jsou poskytnuty klientovi nad dom´enov´ ym modelem a samotn´a servisn´ı vrstva je tak velice tenk´ a. Druh´ y princip, tzv. Operation Script, funguje pˇresnˇe opaˇcnˇe. Dom´enov´ y model neimplementuje ˇz´ adnou aplikaˇcn´ı logiku a tato je cel´a implementov´ana pˇr´ımo v servisn´ı vrstvˇe. Rozhran´ı dostupn´e klientovi tedy nedeleguje pr´ aci do dom´enov´eho modelu, ale s dom´enov´ ym modelem pˇr´ımo pracuj´ı. V tomto pˇr´ıpadˇe se d´ a jiˇz hovoˇrit o robustn´ı servisn´ı vrstvˇe a tˇr´ıdy hraj´ıc´ı roli servis b´ yvaj´ı programovˇe velmi rozs´ ahl´e. Oba pˇr´ıstupy maj´ı sv´e klady a z´ apory. V pˇr´ıpadˇe dom´enov´e fas´ady se d´a jistˇe hovoˇrit o lepˇs´ı dekompozici aplikaˇcn´ı logiky a t´ım p´ adem rozˇsiˇretelnˇejˇs´ı implementaci. S t´ım se ovˇsem tak´e poj´ı netrivi´ aln´ı n´ avrh aplikace. Nav´ıc d´ıky tomu, ˇze je aplikaˇcn´ı logika rozeseta do mnoha m´ıst v dom´enov´em modelu, m˚ uˇze se s rostouc´ım poˇctem dom´enov´ ych objekt˚ u tvoˇrit duplicitn´ı k´od. U druh´eho pˇr´ıstupu je aplikaˇcn´ı k´ od pouze na nˇekolika m´alo m´ıstech a to umoˇzn ˇuje snaˇzˇs´ı refaktorizaci k´odu, na druhou stranu to znesnadˇ nuje budouc´ı rozˇsiˇritelnost dom´enov´eho modelu.
7
4 Vrstva persistence dat V pˇredchoz´ım textu jsme zavedli z´ akladn´ı terminologii vrstev a tˇr´ıvrstv´eho architektonick´eho vzoru. Nyn´ı je nutn´e detailnˇeji rozebrat ot´azku zachov´an´ı persistence dat a programov´eho pˇr´ıstupu k tˇemto dat˚ um (tedy nejniˇzˇs´ı vrstvy tˇr´ıvrstv´eho modelu).
4.1
Syst´ em ˇ r´ızen´ı b´ aze dat
ˇ sen´ı probl´emu uchov´ Reˇ av´ an´ı dat spoˇc´ıv´a obvykle v nasazen´ı nˇekter´e z implementac´ı syst´emu ˇr´ızen´ı ˇ b´ aze dat (SRBD nebo anglicky DBMS – Database management system). Jejich hlavn´ım u ´ˇcelem je poskytnut´ı ˇr´ızen´ı (vkl´ ad´ an´ı, editace, maz´an´ı) nad b´az´ı dat (neboli datab´ az´ı), definovat strukturu uloˇzen´ı tˇechto dat a vytvoˇrit rozhran´ı mezi aplikaˇcn´ımi programy a uloˇzen´ ymi daty [2]. Pojmem ˇ datab´ azov´ y syst´em“ pot´e obvykle oznaˇcuje spojen´ı SRBD se samotnou b´az´ı dat. ” Pouˇzit´ı nˇekter´eho z datab´ azov´ ych syst´em˚ u pˇrin´aˇs´ı celou ˇradu v´ yhod, jako je udrˇzov´an´ı strukturovanosti dat, podpora transakc´ı, moˇznost agregace dat, ˇr´ızen´ı pˇr´ıstupov´ ych pr´av atd. Datab´azov´e syst´emy se obvykle snaˇz´ı maxim´ alnˇe vyuˇz´ıt operaˇcn´ıho a souborov´eho syst´emu tak, aby bylo z´ısˇ k´ av´ an´ı a ukl´ ad´ an´ı dat co nejv´ıce efektivn´ı. Pˇrev´aˇzn´a vˇetˇsina dnes pouˇz´ıvan´ ych SRBD pak pro strukturov´ an´ı dat v datab´ azi vyuˇz´ıv´ a tzv. relaˇcn´ı model.
Relaˇ cn´ı model Relaˇcn´ı model sdruˇzuje data do tabulek, kter´e obsahuj´ı n-tice jednotliv´ ych entit (ˇr´adk˚ u). Tabulka je struktura entit s pevnˇe stanoven´ ymi atributy (sloupci). Kaˇzd´ y sloupec m´a jasnˇe definov´an jednoznaˇcn´ y n´ azev, typ a moˇzn´ y rozsah vkl´adan´ ych dat. Pokud jsou v r˚ uzn´ ych tabulk´ach sloupce stejn´eho typu, pak tyto sloupce mohou vytv´aˇret vazby mezi jednotliv´ ymi tabulkami. Tabulky se pot´e naplˇ nuj´ı konkr´etn´ımi daty. Kolekce v´ıce tabulek, jejich funkˇcn´ıch vztah˚ u, index˚ u a dalˇs´ıch souˇc´ ast´ı tvoˇr´ı samotnou relaˇcn´ı datab´ azi. Relaˇcn´ı model umoˇzn ˇuje pˇrirozenou reprezentaci zpracov´avan´ ych dat a je v nˇem moˇzn´e pˇri n´ avrhu datab´ aze snadno a pomˇernˇe intuitivnˇe definovat jednotliv´e vazby mezi tabulkami. Model tak´e klade velk´ y d˚ uraz na zachov´ an´ı integrity dat. Model d´ale pracuje s term´ıny jako je referenˇcn´ı integrita, ciz´ı kl´ıˇc, prim´ arn´ı kl´ıˇc, norm´ aln´ı forma apod. Relaˇcn´ı datab´azov´ y syst´emy obvykle pro kontrolu datab´ aze a nastavov´ an´ı dalˇs´ıch direktiv vyuˇz´ıvaj´ı strukturovan´ y dotazovac´ı jazyk SQL (Structured Query Language). Problematika datab´ az´ı je velmi obs´ ahl´a a pro u ´ˇcely t´eto pr´ace postaˇc´ı, pokud se nad´ale budeme zab´ yvat jen nˇekter´ ymi vlastnostmi relaˇcn´ıch datab´azov´ ych syst´em˚ u uplatniteln´ ych v prostˇred´ı webov´ ych distribuovan´ ych aplikac´ı.
4.1.1
Uloˇ zen´ e procedury a triggery
Jak jiˇz bylo zm´ınˇeno v pˇredchoz´ım textu, datab´azov´e syst´emy umoˇzn ˇuj´ı ˇc´asteˇcnˇe pˇrevz´ıt roli aplikaˇcn´ı vrstvy d´ıky uloˇzen´ ym procedur´am a tzv. trigger˚ um. To jsou v podstatˇe bloky k´odu napsan´eho v nˇekter´em programovac´ım jazyce (napˇr. PL/SQL) vytvoˇren´eho speci´alnˇe pro u ´ˇcel bˇehu v prostˇred´ı relaˇcn´ı datab´ aze. Lze je kupˇr´ıkladu vyuˇz´ıt pro zachov´an´ı referenˇcn´ı integrity dat. V´ yhodou je zpravidla mnohem vˇetˇs´ı rychlost zpracov´an´ı neˇz pokud by tyto bloky k´odu mˇely b´ yt ˇr´ızeny vzd´ alenˇe klientskou aplikac´ı.
8
Kromˇe velmi specifick´ ych pˇr´ıpad˚ u vˇsak nelze pouˇzit´ı procedur a trigger˚ u pˇr´ıliˇs doporuˇcit. Jsou jen velmi obt´ıˇznˇe udrˇzovateln´e, na velmi n´ızk´e u ´rovni abstrakce, nen´ı moˇzn´e je rozumnˇe debuggovat a jejich podpora se liˇs´ı v z´ avislosti na pouˇzit´e implementaci datab´azov´eho syst´emu.
4.1.2
Nev´ yhody relaˇ cn´ıch datab´ az´ı
Aˇckoliv existuj´ı standardy pro jazyk SQL, mezi jednotliv´ ymi implementacemi relaˇcn´ıch datab´az´ı jsou znaˇcn´e rozd´ıly v jejich podpoˇre. Obvykle nejsou implementov´any vˇsechny poˇzadavky standardu a naopak, kaˇzd´ a implementace obsahuje nejr˚ uznˇejˇs´ı prvky, kter´e nejsou ve standardech obsaˇzeny. Pˇrenositelnost SQL sekvenc´ı mezi jednotliv´ ymi datab´azemi je proto omezen´a. Souˇcasnˇe nen´ı moˇzn´e jednoduˇse pˇren´ aˇset data mezi r˚ uzn´ ymi datab´azemi. Relaˇcn´ı datab´ azov´e syst´emy jsou dobr´e pro ˇr´ızen´ı velk´eho mnoˇzstv´ı dat, ale poskytuj´ı n´ızkou podporu pro manipulaci s nimi. Jsou zaloˇzeny na dvourozmˇern´ ych tabulk´ach a vztahy mezi daty jsou vyjadˇrov´ any porovn´ av´ an´ım hodnot v nich uloˇzen´ ych. SQL sice umoˇzn ˇuje tabulky za bˇehu propojit, nicm´enˇe tento pˇr´ıstup je velmi neintuitivn´ı a nepˇrehledn´ y. Relaˇcn´ı model datab´az´ı je sice jednoduch´ y a pˇritom velmi robustn´ı a flexibiln´ı, je ale tak´e naprosto rozd´ıln´ y od objektov´eho modelu. Relaˇcn´ı datab´ aze nejsou navrhov´ any pro ukl´ad´an´ı objekt˚ u a vytvoˇren´ı rozhran´ı pro ukl´ad´an´ı tˇechto objekt˚ u v relaˇcn´ı datab´ azi je netrivi´aln´ı u ´kol. Alespoˇ n ˇc´ asteˇcn´e ˇreˇsen´ı obou v´ yˇse nast´ınˇen´ ych probl´em˚ u tkv´ı v pouˇzit´ı bud’ objektovˇe orientovan´ ych datab´ az´ı (kter´e ovˇsem nejsou pˇr´ıliˇs vyuˇz´ıvan´e), nebo v nasazen´ı tzv. objektovˇe-relaˇcn´ıho mapov´ an´ı.
4.2
Objektovˇ e-relaˇ cn´ı mapov´ an´ı
Jako objektovˇe-relaˇcn´ı mapov´ an´ı (Object-Relational Mapping, zkratkou ORM) se oznaˇcuje sada programovac´ıch technik, kter´e se snaˇz´ı zajistit automatickou konverzi dat mezi relaˇcn´ı datab´az´ı a dom´enov´ ym modelem a n´ aslednou synchronizaci dom´enov´ ych objekt˚ u v aplikaci a jejich reprezentaci v datab´ azov´em syst´emu tak, aby byla zajiˇstˇena persistence dat (Obr. 4.1). D´ıky ORM je moˇzn´e pˇrirozenˇe pracovat s dom´enov´ ymi objekty, aniˇz by se program´ator staral jak zajistit jejich perzistenci. Ve [3] jsou rozebr´ any nˇekter´e z´ akladn´ı n´avrhov´e vzory, kter´e umoˇzn´ı sv´epomoc´ı implementovat ORM. Nicm´enˇe protoˇze zajiˇstˇen´ı synchronizace mezi datab´az´ı a dom´enov´ ym modelem je netrivi´aln´ı probl´em zejm´ena v kontextu paraleln´ıho pˇr´ıstupu a v´ ykonnosti cel´e aplikace, vyuˇz´ıv´a se dnes obvykle jiˇz ust´ alen´ ych a standardizovan´ ych framework˚ u, kter´e ORM mapov´an´ı zajist´ı.
Obr´ azek 4.1: Vyuˇzit´ı objektovˇe-relaˇcn´ıho mapov´an´ı. Nˇekter´e implementace ORM framework˚ u nav´ıc program´atora odst´ın´ı od ponˇekud nepohodln´eho SQL jazyka a poskytnou mu jin´e moˇznosti pˇr´ıstupu do datab´aze, kter´e obvykl´e implementace datab´ azov´ ych syst´em˚ u nenab´ız´ı. D´ ale tak´e umoˇzn ˇuj´ı ˇc´asteˇcnˇe smazat rozd´ıly mezi jednotliv´ ymi implementacemi datab´ azov´ ych syst´em˚ u – je moˇzn´e konfigurovat SQL dialekt, se kter´ ym framework
9
komunikuje s datab´ az´ı a t´ım je lze pˇri zmˇenˇe datab´azov´eho syst´emu m´ısto pˇrepisov´an´ı cel´e datov´e vrstvy pouze pˇrekonfigurovat ORM framework. I pˇres nesporn´e v´ yhody je vˇsak nasazen´ı tˇechto framework˚ u sp´ıˇse poˇc´atek cesty za bezprobl´emov´ ym mapov´ an´ım mezi dom´enov´ ym modelem a relaˇcn´ı datab´az´ı a v nˇekter´ ych pˇr´ıpadech se dokonce vyplat´ı jejich nasazen´ı u ´plnˇe vyhnout.
4.2.1
Java Persistence API
Specifikac´ı pro ORM frameworky na platformˇe Java je tzv. Java Persistence API (zkratkou JPA). P˚ uvodnˇe existovalo nˇekolik r˚ uzn´ ych ORM framework˚ u, kter´e vznikly jako reakce na pˇr´ıliˇs komplikovan´ y tehdejˇs´ı model EJB, kter´ y se nav´ıc dal pouˇz´ıt pouze ve svˇetˇe rozs´ahl´ ych Java EE aplikac´ı [4]. V r´ amci standardizace tˇechto ORM framework˚ u pot´e dodateˇcn´e vznikla specifikace JPA, jej´ıˇz podporu n´ aslednˇe st´ avaj´ıc´ı frameworky pˇrevzaly. Nejzn´amˇejˇs´ımi implementacemi JPA je Hibernate a EclipseLink. Pˇri dodrˇzen´ı konvenc´ı pˇredepsan´ ych JPA je moˇzn´e tyto dva frameworky na ORM vrstvˇe navz´ ajem zamˇenit bez zmˇeny implementace. JPA mimo jin´e definuje i dotazovac´ı jazyk JPQL (Java Persistence Query Language). Ten je syntax´ı podobn´ y SQL, nicm´enˇe nam´ısto tabulek se pohybuje na u ´rovni dom´enov´ ych objekt˚ u. Nˇekter´e frameworky jazyk d´ ale rozˇsiˇruj´ı, napˇr´ıklad Hibernate m´a vlastn´ı jazyk HQL (Hibernate Query Language), jemuˇz je JPQL podmnoˇzinou.
4.3
Data Gateway
I v okamˇziku vyuˇzit´ı ORM framework˚ u se nelze vyhnout k´odu, kter´ y pˇr´ımo z´avis´ı na logice relaˇcn´ıch datab´ az´ı. Zejm´ena pro CRUD (Create-Read-Update-Delete) operace je st´ale nutn´e vyuˇz´ıt at’ uˇz generick´e SQL nebo napˇr´ıklad v´ yˇse zm´ınˇen´ y jazyk JPQL. Je naprosto neˇz´adouc´ı m´ıchat“ ” tento specifick´ y k´ od do aplikaˇcn´ı vrstvy uˇz jen s ohledem na to, ˇze nˇekter´a z budouc´ıch odvozenin aplikace m˚ uˇze vyuˇz´ıvat m´ısto relaˇcn´ıch datab´az´ı napˇr´ıklad XML soubory, s nimiˇz se ovˇsem pracuje diametr´ alnˇe odliˇsnˇe. Obvykl´ ym postupem je tedy vytvoˇren´ı programov´eho rozhran´ı pro pˇr´ıstup k persistentn´ı vrstvˇe. Implementace tohoto rozhran´ı bude pot´e obsahovat vˇsechen k´od specifick´ y pro technologii pouˇzitou pro persistenci dat. Takov´e implementace pot´e tvoˇr´ı jakousi br´anu (gateway) mezi architektonick´ ymi vˇety aplikaˇcn´ı a persistentn´ı vrstvy (Obr. 4.2).
Obr´ azek 4.2: Rozhran´ı mezi aplikaˇcn´ı a persistentn´ı vrstvou. Nen´ı ˇz´ adouc´ı do tˇechto objekt˚ u vkl´ adat aplikaˇcn´ı logiku – rozhran´ı by mˇelo b´ yt co nejjednoduˇsˇs´ı a zajiˇst’ovat pouze z´ akladn´ı CRUD operace. Jak´akoliv komplexn´ı logika by mˇela b´ yt souˇc´ast´ı klienta tohoho rozhran´ı. Implementace se pot´e ˇcasto neprogramuj´ı ruˇcnˇe, ale vyuˇz´ıv´a se sp´ıˇse r˚ uzn´ ych moˇznost´ı dˇediˇcnosti nebo gener´ ator˚ u k´odu. Je dokonce moˇzn´e vytv´aˇret implementace rozhran´ı pˇr´ımo za bˇehu aplikace pomoc´ı aspektovˇe orientovan´eho programov´ an´ı (viz d´ale).
10
4.3.1
Data Access Object
Jako Data Access Object (objekt zpˇr´ıstupˇ nuj´ıc´ı data, zkratkou DAO) se tradiˇcnˇe oznaˇcuje uplatnˇen´ı n´ avrhov´eho vzoru Data Gateway v prostˇred´ı Java aplikac´ı. Rozhran´ı DAO navenek poskytuje metody pro pr´ aci s dom´enov´ ymi objekty – instancemi POJO nebo EJB, a umoˇzn ˇuje jejich persistenci. Vnitˇrnˇe pot´e zajiˇst’uj´ı pˇreklad“ tˇechto objekt˚ u do tvaru, kter´emu rozum´ı relaˇcn´ı datab´aze. ” To m˚ uˇze b´ yt zajiˇstˇeno mnoha cestami – parametrizac´ı generick´ ych SQL dotaz˚ u nebo napˇr´ıklad vyuˇzit´ım jiˇz zmiˇ novan´ ych ORM framework˚ u. Sezn´ amili jsme se s obvykl´ ymi architektonick´ ymi n´avrhov´ ymi vzory pro spojen´ı datov´e a aplikaˇcn´ı vrstvy. Nyn´ı je nutn´e vyˇreˇsit posledn´ı pr´azdn´e m´ısto v rozboru tˇr´ıvrstv´e architektury – prezentaˇcn´ı vrstvu.
11
5 Prezentaˇ cn´ı vrstva ´ Ukolem t´eto kapitoly je uk´ azat obvykl´ a architektonick´a ˇreˇsen´ı rozhran´ı mezi aplikaˇcn´ı a prezentaˇcn´ı vrstvou specifick´ a pro webov´e aplikace a pˇredstavit nˇekter´e technologie, kter´e tyto obecn´e vzory implementuj´ı.
5.1
Architektura MVC (Model-View-Controller )
MVC je architektonick´ y vzor, kter´ y oddˇeluje dom´enov´ y model aplikace od uˇzivatelsk´eho rozhran´ı. Vznikl spolu s prvn´ımi n´ avrhy grafick´eho uˇzivatelsk´eho rozhran´ı a dnes se uplatuje zejm´ena v r´amci distribuovan´ ych webov´ ych aplikac´ı. Popis jednotliv´ ych komponent je n´asleduj´ıc´ı: - Model – v klasick´em tˇr´ıvrstv´em modelu obvykle odpov´ıd´a dom´enov´emu modelu v aplikaˇcn´ı vrstvˇe. Nicm´enˇe frameworky implementuj´ıc´ı MVC obvykle tyto komponenty neum´ı navz´ajem synchronizovat a je tedy na program´atorovi, aby synchronizaci zajistil (napˇr´ıklad pˇres servisn´ı vrstvu). - Pohled (View) –pˇrev´ ad´ı data reprezentovan´a modelem do podoby vhodn´e k zobrazen´ı uˇzival˚ um. ˇ c (Controler) – reaguje na ud´alosti od uˇzivatele a zajiˇst’uje zmˇeny v modelu nebo v po- Radiˇ hledu. Aˇckoliv by se mohlo zd´ at, ˇze MVC je vlastnˇe tˇr´ıvrstv´a architektura (a oba architektonick´e vzory opravdu b´ yvaj´ı ˇcasto zamˇen ˇov´ any a jsou si na prvn´ı pohled podobn´e), nen´ı to v˚ ubec pravda. Topologie MVC totiˇz nen´ı line´ arn´ı, ale tvoˇr´ı jak´ ysi troj´ uheln´ık. Na rozd´ıl od obecn´e tˇr´ıvrstv´e architektury tak´e definuje z´ akladn´ı tok dat a pohybuje se na rozhran´ı aplikaˇcn´ı a prezentaˇcn´ı vrstvy, zp˚ usoby zajiˇstˇen´ı persistence dom´enov´eho modelu nejsou architekturou nijak pokryty a obecnˇe nelze zamˇen ˇovat datovou vrstvu s MVC Modelem. Na Obr´azku 5.1 je zobrazeno z´akladn´ı sch´ema MVC architektury.
Obr´ azek 5.1: Z´akladn´ı sch´ema MVC architektury. ˇ c a Pohled z´avisej´ı na Modelu, ale Model nez´avis´ı ani na jedn´e D˚ uleˇzit´ y je zejm´ena fakt, ˇze Radiˇ z tˇechto dvou komponent. To (mimo jin´e) umoˇzn ˇuje testovat dom´enov´ y model aplikace nez´avisle 12
na vizu´ aln´ı prezentaci dat. D´ ale m˚ uˇzeme podle [3] rozdˇelit MVC architekturu na dva z´akladn´ı typy.
5.1.1
Pasivn´ı MVC
ˇ c, kter´ ˇ c modifikuje V pasivn´ım modelu je to pouze Radiˇ y je opr´avnˇen manipulovat s Modelem. Radiˇ Model a pot´e informuje Pohled, ˇze se Model zmˇenil. Tento se pot´e pˇrekresl´ı, aby zobrazoval aktu´aln´ı data. Model je v pasivn´ım MVC naprosto nez´avisl´ y a proto nemus´ı nijak notifikovat zmˇenu s´am ˇ c. sebe – tuto ˇcinnost obstar´ a Radiˇ Pˇr´ıkladem pasivn´ıho MVC m˚ uˇze b´ yt klasick´a webov´a prezentace pˇres HTTP protokol. Bez vyuˇzit´ı dalˇs´ıch technologi´ı neexistuje cesta, jak jednoduˇse pˇrij´ımat asynchronn´ı aktualizace dat ze serveru. Webov´ y prohl´ıˇzeˇc zobraz´ı Pohled a um´ı zachyt´avat vstupy od uˇzivatele, neum´ı vˇsak detekovat ˇz´ adn´e zmˇeny modelu na serveru.
5.1.2
Aktivn´ı MVC
ˇ ce. To se m˚ V aktivn´ım MVC m˚ uˇze Model mˇenit sv˚ uj stav bez jak´ehokoliv zapojen´ı Radiˇ uˇze st´at v pˇr´ıpadˇe, kdy jsou data mˇenˇena z nˇejak´ ych dalˇs´ıch zdroj˚ u (napˇr´ıklad jin´ ym uˇzivatelem, pˇr´ımo v datab´ azi, opakuj´ıc´ı se paraleln´ı u ´lohou atp.) a zmˇeny se mus´ı okamˇzitˇe projevit do Pohledu. Model tedy notifikuje zmˇenu sama sebe, Pohled tuto zmˇenu zachyt´ı a dojde k pˇrekreslen´ı okna ˇ ce se nicm´enˇe nijak nevyluˇcuje. M˚ grafick´eho uˇzivatelsk´eho rozhran´ı. Zapojen´ı Radiˇ uˇze to b´ yt ˇ pr´ avˇe Radiˇc, kter´ y Model zmˇen´ı, nicm´enˇe aktualizaci Pohledu nebude s´am zajiˇst’ovat a nech´a ji plnˇe v kompetenci Modelu.
5.1.3
Tok ud´ alost´ı v MVC
Pro u ´pln´e pochopen´ı MVC architektury jsou na Obr´azku 5.2 zn´azornˇeny typick´e interakce mezi uˇzivatelem a aplikac´ı vyuˇz´ıvaj´ıc´ı MVC. Tok ud´alost´ı v aplikaci vypad´a n´asledovnˇe: - uˇzivatel vykon´ a nˇejakou akci v uˇzivatelsk´em rozhran´ı. ˇ cem. - ud´ alost je zachycena Radiˇ ˇ c provede rozhodnut´ı o tom, jak na ud´alost zareagovat a zmˇen´ı hodnoty v modelu nebo - Radiˇ pˇr´ımo ovlivn´ı Pohled. - Pohled se aktualizuje a uˇzivateli zobraz´ı zmˇeny v Modelu (nebo se zobraz´ı zcela jin´ y Pohled ).
Obr´ azek 5.2: Sc´en´aˇr interakce v MVC architektuˇre. ˇ c, kter´ V cel´em modelu je to tedy Radiˇ y hraje dominantn´ı u ´lohu a urˇcuje, jak se bude reagovat na ud´ alosti vznikl´e na stranˇe uˇzivatele – odtud anglick´ y n´azev Controller. 13
5.1.4
Spojen´ı MVC a servisn´ı vrstvy
Nab´ız´ı se ot´ azka, jak vyˇreˇsit jiˇz dˇr´ıve zm´ınˇen´ y probl´em synchronizace Modelu s dom´enov´ ym modelem aplikace. V Kap. 3 jsme definovali servisn´ı vrstvu, kter´a bude vytv´aˇret programov´e rozhran´ı mezi prezentaˇcn´ı vrstvou a dom´enov´ ym modelem aplikace. Na obr´azku 5.3 je zn´azornˇeno jedno z moˇzn´ ych spojen´ı MVC se servisn´ı vrstvou (nˇekdy naz´ yvan´e jako MVCS - Model View Controller Service). Jak jiˇz bylo dˇr´ıve zm´ınˇeno, servisn´ı vrstva m˚ uˇze s dom´enov´ ym modelem manipulovat pˇr´ımo podle vzoru Operation Script, nebo m˚ uˇze tvoˇrit pouze dom´enovou fas´adu a delegovat logiku do dom´enov´eho modelu.
Obr´ azek 5.3: MVC architektura ve spojen´ı se servisn´ı vrstvou. ˇ c tedy m˚ Radiˇ uˇze pˇr´ımo mˇenit Model a na ˇz´adost uˇzivatele m˚ uˇze prov´est napˇr´ıklad uloˇzen´ı dat z Modelu do datab´ aze prostˇrednictv´ım servisn´ı vrstvy. Servisn´ı vrstva m˚ uˇze m´ıt pˇr´ımou referenci ˇ c. na Model nebo m˚ uˇze b´ yt aktualizace provedena pˇres Radiˇ
5.2
MVC v prostˇ red´ı webu
ˇ cem nen´ı u desktopov´ Rozliˇsovat rozd´ıl mezi Pohledem a Radiˇ ych aplikac´ı aˇz tak d˚ uleˇzit´e a nˇekter´e frameworky explicitnˇe logick´e rozdˇelen´ı pˇr´ısluˇsn´e ˇc´asti prezentaˇcn´ı vrstvy do tˇechto MVC komponent nevyˇzaduj´ı (napˇr´ıklad st´ ale ˇsiroce pouˇz´ıvan´ y Swing toolkit). Nicm´enˇe zejm´ena u webov´ ych aplikac´ı je situace zcela jin´a a MVC architektura je zde naprosto pˇrirozenˇe vyuˇzita pro dekompozici komponent staraj´ıc´ıch se o generov´an´ı HTML k´odu od ˇc´ast´ı syst´emu obsluhuj´ıc´ıch HTTP poˇzadavky: - Model je identick´ y s Modelem v desktopov´ ych technologi´ıch (obsahuje data a dom´enovou logiku). - Pohled je ta ˇc´ ast serverov´eho k´ odu, kter´a se star´a o generov´an´ı HTML k´odu. M˚ uˇze vˇsak prezentovat data i jinak, napˇr´ıklad ve form´atu XML, JSON (JavaScript Object Notation), PDF (Portable Document Format) atp. ˇ c se v prostˇred´ı webu nejˇcastˇeji skl´ad´a ze dvou hlavn´ıch ˇc´ast´ı. Prvn´ı je tzv. Front Con- Radiˇ troller, kter´ y zachyt´ av´ a vˇsechny HTTP poˇzadavky. Ty n´aslednˇe zpracuje a pˇrepoˇsle dalˇs´ım ˇ c˚ ˇ c potom typicky pˇriRadiˇ um, kter´e jsou obvykle identifikov´any podle URI. Konkr´etn´ı Radiˇ jme data p˚ uvodnˇe poch´ azej´ıc´ı z HTTP poˇzadavku, uloˇz´ı je do Modelu a ten prov´aˇze s konkr´etn´ım Pohledem. Situace se komplikuje v pˇr´ıpadˇe, kdy je vyuˇzito technologi´ı jako je AJAX (Asynchronous JavaScript and XML). V tˇechto situac´ıch je znaˇcn´a ˇc´ast prezentaˇcn´ı logiky (tedy Pohledu) pˇresunuta na 14
klienta (jak velk´ a ˇc´ ast z´ aleˇz´ı na konkr´etn´ı implementaci). Nicm´enˇe lze ˇr´ıci, ˇze i v tˇechto pˇr´ıpadech je architektura MVC vyuˇziteln´ a.
JavaServer Pages Jako nejtypiˇctˇejˇs´ıho pˇredstavitele uplatnˇen´ı MVC ve svˇetˇe webov´ ych Java aplikac´ı m˚ uˇzeme jmenovat technologii tzv. servlet˚ u a s t´ım souvisej´ıc´ı JavaServer Pages (JSP). Servlet je velmi obecnˇe ˇreˇceno tˇr´ıda odpovˇedn´ a za zpracov´ an´ı HTTP poˇzadavku a vytvoˇren´ı odpov´ıdaj´ıc´ı odpovˇedi [5]. Servletu b´ yv´ a v pr˚ umˇern´e webov´e aplikaci cel´a ˇrada a jejich organizaci a mapov´an´ı na jednotliv´a URL m´ a na starosti tzv. servletov´e nebo tak´e webov´e kontejnery, coˇz jsou vlastnˇe obecnˇe zn´am´e Java servery“ jako je napˇr´ıklad Apache Tomcat nebo GlassFish. Tyto kontejnery obvykle vy” tvoˇr´ı jednu nebo v´ıce instanc´ı od kaˇzd´eho servletu a pokud na server pˇrijde HTTP poˇzadavek, je vyvol´ ana odpov´ıdaj´ıc´ı metoda instance servletu namapovan´eho na URL tohoto poˇzadavku. JSP servlet je pot´e velmi specifick´ y typ servletu. Jeho programov´ y z´apis totiˇz nen´ı realizov´an v Javˇe, ale ve struktuˇre velmi bl´ızk´e HTML. Je moˇzn´e do znaˇcek HTML m´ıchat“ dalˇs´ı tagy ze ” standardn´ıch JSP knihoven, vytvoˇrit si knihovnu vlastn´ı nebo d´ale pouˇz´ıvat dalˇs´ıch ˇsablonovac´ıch n´ astroj˚ u. Lze tak´e omezenˇe vyuˇz´ıt Java k´od. Takto zapsan´ y servlet je pot´e internˇe v servletov´em kontejneru automaticky konvertov´ an na Java zdrojov´ y k´od a n´aslednˇe se chov´a jako kaˇzd´a jin´a tˇr´ıda. Nicm´enˇe jak ukazuje Obr. 5.4, c´ılem JSP servlet˚ u je jedin´a vˇec – form´atovat data obdrˇzen´a ˇ ce do podoby HTML k´ ve od Radiˇ odu (sch´ema nen´ı zcela pˇresn´e, obvykle nejsou data do JSP ˇ c, ale pˇres nadˇrazen´ servletu pˇred´ ana pˇr´ımo pˇres Radiˇ y Front Controller ).
Obr´ azek 5.4: Z´akladn´ı architektura JSP. ˇ c pot´e obvykle b´ Radiˇ yv´ a realizovan´ y jako klasick´ y programovˇe implementovan´ y servlet. V servletu ˇ ce m˚ Radiˇ uˇze b´ yt soustˇredˇena veˇsker´ a logika souvisej´ıc´ı s pˇr´ıpravou dat k zobrazen´ı nebo vol´an´ı ˇ c tak´e m˚ niˇzˇs´ıch vrstev pro naˇcten´ı dat do Modelu. Radiˇ uˇze prov´adˇet pˇresmˇerov´an´ı a dalˇs´ı vˇeci, kter´e nutnˇe nesouvis´ı s aplikaˇcn´ı logikou – ta by mˇela leˇzet vˇzdy v aplikaˇcn´ı vrstvˇe. P˚ uvodn´ı ˇcist´e JSP se dnes jiˇz u d˚ uvodu velk´e pracnosti v´ yvoje moc nepouˇz´ıv´a a v praxi tuto technologii nahradily frameworky, kter´e moˇznosti JSP d´ale rozˇsiˇruj´ı. Je vˇsak nutn´e pochopit 15
principy fungov´ an´ı JSP a MVC architektury obecnˇe, protoˇze z nich vˇetˇsina modern´ıch framework˚ u pˇr´ımo vych´ az´ı.
5.3
Architektura MVP (Model-View-Presenter )
Architektonick´ y vzor MVP je principi´ alnˇe podobn´ y MVC a oba vzory b´ yvaj´ı dost ˇcasto navz´ajem zamˇen ˇov´ any. Nicm´enˇe jednotliv´e komponenty hraj´ı v MVP trochu jinou roli (Obr. 5.5).
Obr´ azek 5.5: Sc´en´aˇr interakce v MVP achitektuˇre. Uˇzivatelsk´ y vstup a v´ ystup tentokr´ at plnˇe kontroluje Pohled skrze ovl´adac´ı prvky uˇzivatelsk´eho rozhran´ı. Prim´ arn´ı motivac´ı pro oddˇelen´ı Pohledu a Presenteru (budeme nad´ale pouˇz´ıvat anglick´e slovo presenter“, protoˇze pro nˇe nen´ı ˇz´adn´ y vhodn´ y ˇcesk´ y ekvivalent) uˇz nen´ı nutnost oˇsetˇren´ı ” ud´ alost´ı od uˇzivatele a kontroly vstupu, d˚ uvody jsou ˇcistˇe architektonick´e (lepˇs´ı udrˇzovatelnost k´ odu). Pohled m´ a typicky pˇr´ımou vazbu na Presenter a ten obvykle pˇr´ımo pracuje s Pohledem, takˇze i tato vazba je silnˇejˇs´ı neˇz v pˇr´ıpadˇe MVC. Pohled oproti MVC nav´ıc zpracov´av´a uˇzivatelsk´ y vstup a je zde tedy dominantn´ı komponentou (typicky v reakci na ud´alost od uˇzivatele zavol´a nˇejakou metodu v Presenteru). Presenter m˚ uˇze obsahovat prezentaˇcn´ı a aplikaˇcn´ı logiku (nebo deleguje aplikaˇcn´ı logiku do dˇr´ıve popsan´e servisn´ı vrstvy). Manipuluje s Modelem, coˇz (napˇr´ıklad pomoc´ı syst´emu posluchaˇc˚ u a notifikac´ı) zajist´ı aktualizaci Pohledu, nebo ovlivˇ nuje Pohled pˇr´ımo (z´aleˇz´ı na implementaci a moˇznostech jazyka). Popsan´ y architektonick´ y vzor se tak´e oznaˇcuje jako Supervising Presenter. Existuj´ı dalˇs´ı modifikace MVP, napˇr´ıklad Passive View, kdy je naopak zv´ yˇsena odpovˇednost Presenteru a Pohled u ´plnˇe ztr´ ac´ı vazbu na Model. Jejich popis vˇsak pˇresahuje u ´ˇcel tohoto textu. D˚ uvod, proˇc zde uv´ ad´ıme tento architektonick´ y vzor je zejm´ena fakt, ˇze se MVP velice ˇcasto a zcela nespr´avnˇe zamˇen ˇuje s MVC. Pˇr´ıkladem vyuˇzit´ı MVP m˚ uˇze b´ yt toolkit WinForms, kter´ y je souˇc´ast´ı .NET Frameworku od spoleˇcnosti Microsoft.
5.3.1
MVP v prostˇ red´ı webu
MVC se dobˇre hod´ı pro klasick´e webov´e aplikace, kde jsou statick´e HTML str´anky generov´any pˇr´ımo na serveru. Nicm´enˇe v pˇr´ıpadˇe modern´ıch AJAX aplikac´ı, kdy se ˇc´ast prezentaˇcn´ı vrstvy pˇresouv´ a do klientsk´eho prohl´ıˇzeˇce, zaˇc´ın´a b´ yt MVC nevyhovuj´ıc´ı. Oproti tomu MVP architektura je pro tento u ´ˇcel jako stvoˇren´ a. Jak je vidˇet na Obr´ azku 5.6, komponenta Pohledu (obvykle implementovan´a pomoc´ı JavaScriptu) se pˇresouv´ a do klientsk´eho prohl´ıˇzeˇce a m´ısto programov´eho rozhran´ı a vol´an´ı metod budou tyto komunikovat napˇr´ıklad pomoc´ı HTTP protokolu. Pˇri vyplˇ nov´an´ı formul´aˇr˚ u je moˇzn´e validovat data pˇr´ımo na stranˇe klienta. Pokud tedy uˇzivatel klikne na tlaˇc´ıtko, kter´e m´a zobrazit nˇejak´e 16
poloˇzky z datab´ aze, je tento poˇzadavek zpracov´an na stranˇe webov´eho prohl´ıˇzeˇce a na pozad´ı se odeˇsle ˇza´dost do Presenteru. Ten m˚ uˇze ze servisn´ı vrstvy naˇc´ıst patˇriˇcn´a data za datab´aze a uloˇzit do Modelu. Pot´e dojde opˇet pomoc´ı HTTP protokolu k aktualizov´an´ı Pohledu tak, aby zobrazil aktu´ aln´ı data. Z toho vypl´ yv´ a tak´e potenci´ al sn´ıˇzit z´atˇeˇz na servery a s´ıt’ obecnˇe. Jelikoˇz nen´ı potˇreba pˇri kaˇzd´em poˇzadavku sestavit cel´ y HTML dokument, ale pouze zobrazit aktualizovan´ y Model, je mnoˇzstv´ı vymˇen ˇovan´ ych dat v´ yraznˇe niˇzˇs´ı. Nicm´enˇe tento pˇr´ıstup naopak m˚ uˇze zv´ yˇsit poˇcet vymˇen ˇovan´ ych HTTP poˇzadavk˚ u, a tˇrebaˇze pˇren´aˇsej´ı niˇzˇs´ı mnoˇzstv´ı dat, pˇri nevhodn´e implementaci z´ atˇeˇz neklesne.
Obr´ azek 5.6: Sc´en´aˇr interakce ve webov´e MVP aplikaci.
5.4
JavaServer Faces
Jiˇz dˇr´ıve jsme si uk´ azali JSP jako jedno z uk´azkov´ ych nasazen´ı architektury MVC ve webov´e aplikaci. Nyn´ı si detailnˇeji rozebereme technologii JavaServer Faces (zkratkou JSF), kter´a i pˇres to, ˇze z JSP pˇr´ımo vych´ az´ı, se naopak bl´ıˇz´ı sp´ıˇse MVP architektuˇre. Myˇslenkou je opˇet oddˇelen´ı definice uˇzivatelsk´eho rozhran´ı (tzv. Faces) od vlastn´ı aplikaˇcn´ı a prezentaˇcn´ı logiky. I zde se tak dˇeje pomoc´ı soubor˚ u podobn´ ych HTML, ve kter´ ych je definov´ano vlastn´ı uˇzivatelsk´e rozhran´ı. Pˇri psan´ı tˇechto XML soubor˚ u se pouˇz´ıvaj´ı speci´aln´ı XML tagy, kter´e se importuj´ı z tzv. Tag Library Description (TLD) knihoven. I zde je vyuˇzito Front Controlleru a vykreslov´ an´ı HTML str´ anky se odehr´ av´a na serveru [6]. Prvn´ı rozd´ıl pˇrich´ az´ı v okamˇziku, kdy si uvˇedom´ıme, ˇze konfigurace grafick´eho rozhran´ı je komponentovˇe orientovan´ a. Kaˇzd´ y tag m´a internˇe v r´amci sv´e knihovny pˇriˇrazeno nˇekolik Java tˇr´ıd. Soubor tˇechto tˇr´ıd se naz´ yv´ a Komponenta. Tato programov´a reprezentace vytv´aˇr´ı aplikaˇcn´ı logiku tagu (jako konverzi hodnot na text, validaci a pˇr´ıpravu pro vykreslen´ı“ informace). Ke ” kaˇzd´e komponentˇe je vytvoˇren jej´ı programov´ y Renderer, kter´ y zap´ıˇse do v´ ystupu vlastn´ı HTML k´ od a data z reprezentace tagu. Je tedy moˇzn´e vytvoˇrit cel´e uˇzivatelsk´e rozhran´ı aniˇz bychom pouˇzili jedin´ y HMTL tag. V JSF tak´e odpad´a nutnost vyuˇzit´ı ˇsablonovac´ıch framework˚ u (souˇc´ast´ı je framework Facelets, kter´ y umoˇzn ˇuje ˇsablonov´an´ı). Jak je vidˇet na Obr´ azku 5.7, JSF zav´ad´ı tak´e pojem backing nebo tak´e managed beans. Pˇrestoˇze jsou tyto beany“ ˇcasto realizov´ any jako POJO objekty, nemaj´ı v˚ ubec nic spoleˇcn´eho s dom´eno” v´ ym modelem aplikace. Reprezentuj´ı ty tˇr´ıdy, jejichˇz instance by mˇely b´ yt dynamicky vytv´aˇreny za bˇehu aplikace spolu s generov´ an´ım HTML str´anek, pˇriˇcemˇz je moˇzn´e urˇcit jejich rozsah“ (scope) ” neboli kontext ve kter´em budou konkr´etn´ı instance referencovateln´e (je moˇzn´e urˇcit rozsah v r´amci jednoho HTTP poˇzadavku, uˇzivatelsk´e relace, v r´amci cel´eho bˇehu aplikace atp.). Jednotliv´e ˇclen-
17
sk´e promˇenn´e a metody tˇechto objekt˚ u jsou pot´e za pomoci tzv. bindov´ an´ı moˇzn´e referencovat pˇr´ımo z XML soubor˚ u jednotliv´ ych Pohled˚ u a na ud´alosti vyvolan´e uˇzivatelem (napˇr´ıklad odesl´an´ı vyplnˇen´eho formul´ aˇre) volat pˇr´ımo metody backing beany.
Obr´ azek 5.7: Z´akladn´ı architektura JSF. Jak je tedy patrn´e, architektura JSF je v pˇr´ım´e shodˇe s architektonick´ ym vzorem MVP – domiˇ c ani Presenter, ale je to pr´avˇe Pohled, kter´ nantn´ı komponentou zde nen´ı Radiˇ y je pˇri konstrukci HTML str´ anky vytvoˇren jako prvn´ı a jednotliv´e backing beany hraj´ı roli zpˇr´ıstupnˇen´ı Modelu a dodateˇcn´e prezentaˇcn´ı logiky. Backing beany tak´e mohou pˇr´ımo ovlivˇ novat Pohled, protoˇze jednotliv´e komponenty jsou referencovateln´e jako klasick´e Java objekty pˇr´ımo z aplikaˇcn´ıho k´odu, coˇz je dalˇs´ı obrovsk´ a v´ yhoda oproti JSP (i kdyˇz trochu nav´ad´ı k vytv´aˇren´ı r˚ uzn´ ych form´atovac´ıch zkratek“ v Presenteru, coˇz je principi´alnˇe ˇspatnˇe). ” JSF nicm´enˇe zach´ az´ı jeˇstˇe d´ al. Nˇekter´e TLD knihovny (napˇr. MyFaces nebo Primefaces) obsahuj´ı komponenty, kter´e mohou s backing beanou pˇr´ımo komunikovat pomoc´ı AJAXu. Renderery tˇechto komponent pˇri vytv´ aˇren´ı (z principu statick´eho) HTML k´odu jednoduˇse pˇridaj´ı do str´anky JavaScript, kter´ y umoˇzn´ı obousmˇernou komunikaci mezi serverem a webov´ ych prohl´ıˇzeˇcem klienta. Pohled se pak ˇc´ asteˇcnˇe pˇresouv´ a do webov´eho prohl´ıˇzeˇce a program´ator˚ um je umoˇznˇeno vytv´aˇret velice rychle robustn´ı interaktivn´ı webov´e grafick´e rozhran´ı, aniˇz by napsali jedinou ˇr´adku HTML nebo JavaScriptov´eho k´ odu.
5.5
Shrnut´ı
V pˇredchoz´ıch kapitol´ ach jsme se sezn´amili s architektonick´ ymi postupy uplatniteln´ ymi pˇri n´avrhu rozs´ ahl´ ych webov´ ych aplikac´ı a distribuovan´ ych informaˇcn´ıch syst´em˚ u a nejpouˇz´ıvanˇejˇs´ımi frameworky, kter´e tyto postupy implementuj´ı pro platformu postavenou na programovac´ım jazyce Java. Definovali jsme z´ akladn´ı architektonick´e pojmy jako je tˇr´ıvrstv´ a architektura, dom´enov´y model a bude ˇz´ adouc´ı se tˇechto term´ın˚ u a postup˚ u drˇzet i nad´ale. Nicm´enˇe dosud jsme se zab´ yvali architekturou, kter´a sledovala jedin´ y c´ıl – poskytnut´ı webov´eho rozhran´ı ˇciteln´eho a pouˇziteln´eho pro lidsk´eho uˇzivatele. Nyn´ı je tˇreba si poloˇzit ot´azku, jak mohou 18
s webov´ ymi aplikacemi komunikovat jin´e syst´emy nebo klienti, kteˇr´ı neumoˇzn ˇuj´ı zobrazovat webov´e str´ anky nebo je z nˇejak´eho d˚ uvodu neˇz´adouc´ı ˇci nepraktick´e tˇemto klient˚ um webov´e rozhran´ı poskytovat.
19
6 Architektura orientovan´ a na sluˇ zby Architektura orientovan´ a na sluˇzby (Service-oriented architecture, zkratkou SOA) je obecn´ y architektonick´ y vzor zaloˇzen´ y na spolupr´ aci navz´ajem nez´avisl´ ych sluˇzeb [7]. Motivac´ı pro vytvoˇren´ı SOA byla rostouc´ı n´ aroˇcnost na udrˇzov´an´ı spolupr´ace r˚ uzn´ ych vnitropodnikov´ ych syst´em˚ u. D´ıky jejich platformn´ı z´ avislosti a navz´ ajem nekompatibiln´ıch programov´ ych rozhran´ı bylo jen velmi obt´ıˇznˇe zajistit vz´ ajemnou komunikaci tˇechto syst´em˚ u.
6.1
Sluˇ zba v SOA
Sluˇzba je urˇcit´ a ˇc´ ast funkˇcnosti aplikace, kter´a je zpˇr´ıstupnˇen´a pomoc´ı definovan´eho rozhran´ı. Kaˇzd´ y jednotliv´ y informaˇcn´ı syst´em m˚ uˇze poskytovat sadu sluˇzeb sv´emu okol´ı. Za sluˇzbou v SOA stoj´ı vˇetˇsinou pomˇernˇe velk´e mnoˇzstv´ı programov´eho k´odu a jakkoliv je princip vol´an´ı sluˇzeb podobn´ y vol´ an´ı metod, prob´ıh´ a zde na vyˇsˇs´ı u ´rovni granularity. Rozhran´ı sluˇzeb tak´e nen´ı z´ avisl´e na implementaci hostitelsk´eho syst´emu. Hranice syst´emu se od programov´ ych rozhran´ı posunuj´ı d´ ale od klasick´eho programov´eho API k jasnˇe definovan´emu rozhran´ı, ve kter´em dan´ a sluˇzba data produkuje ˇci pˇrij´ım´a bez ohledu na to, v jak´e technologii je tato sluˇzba implementov´ ana. Ve vˇetˇsinˇe pˇr´ıpad˚ u se pak pro komunikaci mezi sluˇzbami d´ıky vysok´e prostupnosti s´ıt´ı, platformn´ı nez´ avislosti a pˇrenositelnosti vyuˇz´ıv´a HTTP protokol. Pˇren´aˇsen´ y form´at dat m˚ uˇze b´ yt v podstatˇe libovoln´ y, pokud vˇsichni akt´eˇri komunikace tento form´at podporuj´ı. Nicm´enˇe zdaleka nejvyuˇz´ıvanˇejˇs´ı jsou form´ aty postaven´e (zejm´ena z d˚ uvodu transparentnosti a multiplatformnosti) na b´ azi XML. Takov´e sluˇzby se pot´e zpravidla oznaˇcuj´ı jako sluˇzby webov´e (Web Services). Takov´e sluˇzby se pak obvykle jednoznaˇcnˇe identifikuj´ı na z´akladˇe URL adresy.
6.2
SOA a tˇ r´ıvrstv´ a architektura
V´ıcevrstv´ a architektura se SOA spolu navz´ajem velice u ´zce souvis´ı. Jednotliv´e syst´emy jsou obvykle distribuovan´e, v´ıcevrstv´e aplikace s prezentaˇcn´ı, aplikaˇcn´ı a perzistentn´ı vrstvou. Nicm´enˇe veˇsker´a funkcionalita takov´e aplikace je vystavena prostˇrednictv´ım sluˇzeb, nebo je vytvoˇreno rozhran´ı, kter´e tyto sluˇzby navenek poskytuje. V SOA aplikac´ıch se typicky neudrˇzuje stav konverzace s klientem, komunikace obvykle prob´ıh´a zp˚ usobem dotaz-odpovˇed’. T´ım se n´ apadnˇe bl´ıˇz´ı jednoduch´emu HTTP poˇzadavku s t´ım rozd´ılem, ˇze URL poˇzadavku tentokr´ at neidentifikuje HTML str´anku, ale pˇr´ımo konkr´etn´ı webovou sluˇzbu. Je tedy zcela jistˇe moˇzn´e (v pˇr´ıpadˇe pˇredchoz´ı dobr´e dekompozice probl´emu) rozhran´ı webov´ ych sluˇzeb implementovat za vyuˇzit´ı architektonick´eho vzoru MVC na prezentaˇcn´ı vrstvˇe, kdy jedin´ y rozd´ıl nastane v Pohledu, kter´ y m´ısto zobraziteln´eho HTML bude generovat XML dokument o pˇredem dan´em sch´ematu.
6.3
V´ yhody SOA
D´ıky bezstavosti a slab´emu prov´ az´ an´ı komponent je moˇzn´e sluˇzby skl´adat do vˇetˇs´ıch celk˚ u, coˇz ide´ alnˇe splˇ nuje potˇrebu podnik˚ u pokr´ yt a integrovat sv´e vnitropodnikov´e procesy pomoc´ı informaˇcn´ıho syst´emu. Jednotliv´e komponenty je moˇzn´e pˇri v´ ypadku velice rychle nahradit nebo zav´est 20
centr´ aln´ı registr sluˇzeb, kter´ y umoˇzn´ı vyhled´av´an´ı aktivn´ıch sluˇzeb a z´ısk´an´ı jejich popisu (mechanismus Universal Description, Discovery and Integration, zkratkou UDDI).
6.4
Protokoly komunikace v SOA
Jiˇz dˇr´ıve jsme si ˇrekli, ˇze data jsou v SOA architektuˇre obvykle pˇren´aˇseny pomoc´ı XML dokument˚ u. Tyto lze ale d´ ale strukturovat podle pˇredem definovan´ ych sch´emat a pravidel a vytv´aˇret komunikaˇcn´ı protokoly, kter´ y jsou na XML form´atu zaloˇzen´e.
6.4.1
Simple Object Access Protocol (SOAP)
SOAP je standardizovan´ y protokol pro v´ ymˇenu dat mezi webov´ ymi sluˇzbami [8], kter´ y je obvykle pouˇzit spolu s HTTP protokolem. Zpr´ avu zde reprezentuje jednoduch´ y XML dokument, kter´ y m´a koˇrenov´ y element Envelope. V t´eto ob´alce jsou pak uzavˇreny dva elementy Header (hlaviˇcka) a Body (tˇelo). Hlaviˇcka se zpravidla pouˇz´ıv´ a pro pˇrenos pomocn´ ych informac´ı pro zpracov´an´ı zpr´avy – napˇr´ıklad autorizaci klienta. V tˇele zpr´ avy se pˇren´aˇs´ı identifik´ator volan´e sluˇzby a parametry zpr´avy, resp. n´ avratov´e hodnoty sluˇzby. SOAP pouˇz´ıv´a jmenn´e prostory pro identifikov´an´ı jednotliv´ ych ˇc´ ast´ı XML zpr´ avy. Je tˇreba zd˚ uraznit, ˇze SOAP protokol je orientov´an procedur´alnˇe a funguje na principu RPC (Remote Procedure Call ). Komunikace m˚ uˇze b´ yt v SOAP stavov´a. Typick´ y SOAP poˇzadavek se zas´ıl´ a v tˇele HTTP poˇzadavku. Pouˇz´ıv´a se pˇritom metoda POST, kter´ a podle [9] dovoluje pos´ılat data v tˇele HTTP poˇzadavku. Nicm´enˇe ten m˚ uˇze m´ıt i dalˇs´ı metody, kter´e je moˇzn´e vyuˇz´ıt. Z toho by mˇelo b´ yt patrn´e, ˇze klasick´a SOAP komunikace vytv´aˇr´ı vlastn´ı protokol nad klasick´ ym HTTP a nesnaˇz´ı se jej nijak d´ale vyuˇz´ıt. HTTP protokol je pˇritom dostateˇcnˇe robustn´ı na to, aby bylo moˇzn´e jej rozˇs´ıˇrit aˇz do u ´rovnˇe protokolu urˇcen´eho pro webov´e sluˇzby.
6.4.2
Representational State Transfer (REST)
REST je architektura rozhran´ı navrˇzen´a pro distribuovan´e prostˇred´ı. REST je narozd´ıl od SOAP orientov´ an datovˇe, nikoli procedur´ alnˇe: rozhran´ı webov´ ych REST sluˇzeb je pouˇziteln´e pro jednotn´ y a snadn´ y pˇr´ıstup k tzv. zdroj˚ um (dat˚ um nebo stav˚ um aplikace, pokud je lze popsat konkr´etn´ımi daty). Vˇsechny zdroje jsou jednoznaˇcnˇe identifikovateln´e pomoc´ı URI a jsou reprezentov´any (a pˇren´ aˇseny) pomoc´ı r˚ uzn´ ych datov´ ych form´at˚ u (XML, JSON nebo jin´eho form´atu, kter´ y je moˇzn´e odeslat pomoc´ı HTTP). REST definuje z´ akladn´ı CRUD(Create-Read-Update-Delete) metody pro manipulaci s tˇemito zdroji (metody mˇen´ı stav zdroje). Tyto metody jsou pot´e realizov´any pomoc´ı odpov´ıdaj´ıc´ıch HTTP metod (GET, POST, PUT, DELETE ). Je tedy patrn´e, ˇze zat´ımco SOAP pouˇz´ıval HTTP pouze jako jeden z moˇzn´ ych komunikaˇcn´ıch kan´al˚ u, REST na architektuˇre HTTP pˇr´ımo stav´ı a d´ ale ji rozˇsiˇruje. Narozd´ıl od SOAP neexistuj´ı ˇz´ adn´e specifikace kladen´e na strukturu dat. REST je tak´e koncipov´ an jako bezestavov´ y. Jednotliv´e implementace REST rozhran´ı (tedy webov´e sluˇzby) se pot´e pˇri splnˇen´ı tˇechto podm´ınek obvykle oznaˇcuj´ı jako RESTful. SOAP definuje vlastn´ı zp˚ usoby autorizace, REST vyuˇz´ıv´a HTTP autorizace. Autorizaˇcn´ı tokeny ale mus´ı b´ yt odesl´ any s kaˇzd´ ym poˇzadavkem, jinak nen´ı splnˇena podm´ınka bezestavosti (webov´ a sluˇzba si o klientovi nesm´ı nic pamatovat“). ”
6.4.3
Srovn´ an´ı REST a SOAP
Uˇcinit objektivn´ı srovn´ an´ı tˇechto dvou protokol˚ u nen´ı zcela moˇzn´e uˇz jen kv˚ uli tomu, ˇze se oba od sebe odliˇsuj´ı samotnou svou koncepc´ı. Aˇc je to dnes popul´arn´ı n´azor, REST nen´ı vˇzdy tou spr´avnou volbou. Sice je implementaˇcnˇe mnohem m´enˇe n´aroˇcn´ y a pouze rozˇsiˇruje standardn´ı HTTP protokol, d´ıky jeho datacentrismu“ a omezen´e mnoˇzinˇe CRUD operac´ı m˚ uˇze b´ yt implementaˇcnˇe ”
21
pˇr´ıliˇs svazuj´ıc´ı. Tak´e bezestavost komunikace se m˚ uˇze uk´azat jako velk´ y probl´em. Jednoduchost REST rozhran´ı m˚ uˇze b´ yt v´ yhoda a slabina z´aroveˇ n, vˇzdy z´aleˇz´ı na pˇr´ıpadu implementace. Obecnˇe lze ˇr´ıci ˇze REST je velmi siln´ y ve spojen´ı s technologiemi jako je AJAX nebo ke vzd´alen´e spr´avˇe datab´ aze (k ˇcemuˇz vyb´ız´ı uˇz jen z´ akladn´ı CRUD matice operac´ı). SOAP je robustnˇejˇs´ı a d´ıky stavov´e komunikaci a procedur´aln´ı orientaci je mnohem vhodnˇejˇs´ı k realizaci komunikace mezi dvˇema netrivi´aln´ımi informaˇcn´ımi syst´emy, coˇz je ovˇsem vykoupeno potˇrebou mnohem rozs´ ahlejˇs´ı implementace. Nav´ıc funguje stejnˇe dobˇre i na jin´ ych s´ıt’ov´ ych vrstv´ ach a nen´ı tˇreba se omezovat na pouh´ y HTTP protokol.
22
7 Technologick´ e n´ astroje pro v´ yvoj Vˇsechny dˇr´ıve zm´ınˇen´e architektonick´e vzory je moˇzn´e implementovat manu´alnˇe“ a sv´epomoc´ı ” spravovat a udrˇzovat jednotliv´e vazby mezi dom´enov´ ymi objekty, mezi vrstvami, komponentami ˇci uˇzit´ ymi frameworky. Nicm´enˇe takto postaven´a aplikace je jen obt´ıˇznˇe znovupouˇziteln´a a nen´ı nutn´e vlastn´ım k´ odem ˇreˇsit probl´emy, kter´e jiˇz nˇekdo vyˇreˇsil pˇred n´ami. V t´eto kapitole si uk´aˇzeme postupy, kter´e vedou ke zjednoduˇsen´ı vlastn´ıho aplikaˇcn´ıho k´odu a pˇredstav´ıme si framework, kter´ y tyto postupy implementuje.
7.1
Aspektovˇ e orientovan´ e programov´ an´ı
Principem aspektovˇe orientovan´eho programov´ an´ı (zkratkou AOP) je oddˇelen´ı nˇekter´ ych ˇc´ast´ı k´ odu, tzv. pr˚ uˇrezov´ych koncern˚ u (cross-cutting concerns), od vlastn´ı aplikaˇcn´ı logiky. Jako pr˚ uˇrezov´ y koncern m˚ uˇzeme definovat takov´ y k´od, kter´ y se dot´ yk´a mnoha r˚ uzn´ ych ˇc´ast´ı aplikace (pˇr´ıkladem mohou b´ yt napˇr´ıklad transakˇcn´ı a bezpeˇcnostn´ı algoritmy nebo logov´an´ı) a nen´ı jednoduch´e ho dekomponovat. AOP se snaˇz´ı tyto koncerny organizovat do tzv. aspekt˚ u. AOP nen´ı n´ ahrada jin´ ych programovac´ıch technik jako je napˇr. objektovˇe orientovan´e programov´ an´ı, slouˇz´ı sp´ıˇse jako architektonick´ y doplnˇek k jiˇz zaveden´ ym technik´am a uplatn´ı se zejm´ena tam, kde tyto techniky ve snaze dobˇre dekomponovat k´od jiˇz nestaˇc´ı nebo je jejich uplatnˇen´ı neˇsikovn´e. Aspekty upravuj´ı chov´ an´ı programu pˇri spouˇstˇen´ı metod, pˇr´ıstupu k atribut˚ um tˇr´ıdy nebo pˇri vyhozen´ı v´ yjimky. Tato m´ısta se oznaˇcuj´ı jako pˇr´ıpojn´e body (joinpoints). Samotn´a u ´prava chov´an´ı aplikaˇcn´ıho k´ odu (realizovan´ a opˇet jako prost´ y blok k´odu) se pot´e oznaˇcuje jako advice. V Javˇe se pak oznaˇcen´ı pˇr´ıpojn´ ych bod˚ u v aplikaˇcn´ım k´odu obvykle ˇreˇs´ı pomoc´ı anotac´ı.
7.1.1
Java Anotace
Anotace jsou vlastnˇe jenom textov´e znaˇcky v k´odu o urˇcit´em pˇredepsan´em form´atu (anotac´ı je i notoricky zn´ am´e @Override), jejichˇz c´ılem je nˇejak´emu programov´emu primitivu pˇriˇradit pˇr´ıznak nebo metadata. Anotace je moˇzn´e vyhodnocovat pˇri pˇrekladu nebo pˇri samotn´em bˇehu programu (to ovˇsem vyˇzaduje speci´ aln´ı classloader ). Ve spojen´ı s AOP mohou identifikovat ta programov´a primitiva, kter´ ym se m´ a pˇriˇradit aspekt (ten je identifikovan´ y samotnou anotac´ı). I bez vyuˇzit´ı AOP je moˇzn´e vytv´ aˇret anotace vlastn´ı pro u ´ˇcely napˇr. dokumentace, statick´eho generov´an´ı k´odu atp. Anotac´ım je moˇzn´e vytv´ aˇret parametry a tˇem pˇri pouˇzit´ı anotace pˇred´avat hodnoty, coˇz jejich moˇznosti d´ ale rozˇsiˇruje (je moˇzn´e tyto hodnoty pˇred´avat aspekt˚ um, kter´e jsou anotacemi identifikov´ any).
7.2
Spring Framework
C´ılem t´eto kapitoly je pˇredstavit framework, kter´ y umoˇzn ˇuje spojit vˇetˇsinu uveden´ ych technologi´ı a postup˚ u do jednoho kompaktn´ıho celku – Spring Framework. Tento velice popul´arn´ı modul´arn´ı aplikaˇcn´ı framework umoˇzn ˇuje velice rychle vytv´aˇret rozs´ahl´e aplikace za vyuˇzit´ı principu Inversion of Control, kdy je framework za bˇehu aplikace zodpovˇedn´ y za vytvoˇren´ı a prov´az´an´ı objekt˚ u
23
implementovan´e aplikace a na program´atorovi z´avis´ı pouze samotn´a implementace aplikaˇcn´ı logiky [10]. To je moˇzn´e d´ıky pokroˇcil´ ym programovac´ım technik´am, jako je napˇr´ıklad reflexe. Nicm´enˇe hlavn´ı ˇca´st Spring Frameworku stoj´ı pr´avˇe na anotac´ıch a AOP. Jednotliv´e komponenty aplikaˇcn´ı logiky, jako jsou napˇr. POJO objekty, se doslova zaregistruj´ı“ ” do aplikaˇcn´ıho frameworku a tento s tˇemito komponentami d´ale manipuluje. Je moˇzn´e si pˇredstavit napˇr´ıklad implementaci n´ avrhov´eho vzoru MVC, kdy program´ator implementuje vˇsechny tˇri ˇ ce, aniˇz by tyto na sebe mˇely navz´ajem jakoukoliv prograkomponenty Pohledu, Modelu a Radiˇ movou vazbu nebo dˇedily nˇejakou generickou implementaci. Aplikaˇcn´ı framework se pak za bˇehu aplikace postar´ a o jejich vz´ ajemn´e prov´az´an´ı. Za vyuˇzit´ı reflexe a AOP Spring Framework d´ale injektuje vlastn´ı aplikaˇcn´ı k´ od (neboli aspekty) do zdrojov´eho k´odu vytv´aˇren´e aplikace, a to bud’ na z´ akladˇe XML konfigurace, nebo pomoc´ı jiˇz zm´ınˇen´ ych anotac´ı. Mezi ˇc´ asti Spring Frameworku patˇr´ı komponenty pro ORM mapov´an´ı, testovac´ı n´astroje, integraci uˇzivatelsk´ ych komponent, modul´arnˇe orientovan´ y v´ yvoj, webov´e aplikace a webov´e sluˇzby, bezpeˇcnost na z´ akladˇe rol´ı a ˇrada dalˇs´ıch. Podrobn´ y popis tˇechto komponent jde dalece nad r´amec t´eto pr´ ace a v pˇr´ıpadˇe nutnosti budou jednotliv´e komponenty v dalˇs´ım textu struˇcnˇe pops´any.
24
8 Z´ avˇ er Nyn´ı m´ ame obecn´ y pˇrehled o tom, jak´e architektonick´e vzory m˚ uˇzeme vyuˇz´ıt pro programov´an´ı rozs´ ahl´ ych distribuovan´ ych syst´em˚ u a zn´ame ˇsiroce vyuˇz´ıvan´e technologie stavˇej´ıc´ı na Java platformˇe, kter´e tyto postupy implementuj´ı. Vyuˇzit´ı zde uveden´ ych technologi´ı vˇsak z´aleˇz´ı ˇcistˇe na program´ atorovi syst´emu. Pro dalˇs´ı studium architektonick´ ych vzor˚ u uplatniteln´ ych v rozs´ahl´ ych syst´emech lze zejm´ena doporuˇcit [3], kde jsou uvedeny i pˇr´ıpady tzv. n´avrhov´ ych antivzor˚ u. Pro lehk´e sezn´amen´ı s v´ yvojem modern´ıch Java EE aplikac´ı zaloˇzen´ ych na frameworku Spring pak postaˇc´ı [10]. Obsahem t´eto knihy je pak i lehk´e sezn´ amen´ı a pˇr´ıklady vyuˇzit´ı technologi´ı jako je REST, JSP atp. Spring Framework s´ am nut´ı program´ atora do pouˇz´ıv´an´ı spr´avn´ ych“ n´avrhov´ ych vzor˚ u, a proto lze tuto ” knihu doporuˇcit zejm´ena program´ ator˚ um s ˇz´adn´ ymi pˇredchoz´ımi zkuˇsenostmi se Spring Frameworkem a zde uveden´ ymi n´ avrhov´ ymi vzory obecnˇe.
25
Literatura [1] DAY, J.D. a H. ZIMMERMANN. The OSI reference model. Proceedings of the IEEE [online]. roˇc. 71, ˇc. 12, s. 1334-1340 [cit. 2013-04-30]. ISSN 0018-9219. DOI: 10.1109/PROC.1983.12775. Dostupn´e z: http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1457043 ¨ [2] LIU, Ling a M OZSU. Encyclopedia of database systems. New York: Springer, c2009, 5 v. (lxix, 3749 p.). ISBN 978-038-7496-160. [3] FOWLER, Martin. Patterns of enterprise application architecture. Boston: Addison-Wesley, c2003, xxiv, 533 p. ISBN 03-211-2742-0. [4] ELLIOTT, James, Ryan FOWLER a Tim O’BRIEN. Harnessing Hibernate. Sebastopol: O’Reilly, 2008, xiv, 363 s. ISBN 978-0-596-51772-4. [5] JOEL MURACH, Andrea Steelman, Ryan FOWLER a Tim O’BRIEN. Murach’s Java servlets and JSP: training. 2nd ed. Fresno, CA: Mike Murach, 2008, xiv, 363 s. ISBN 18-907-7444-8. [6] BERGSTEN, Hans, Ryan FOWLER a Tim O’BRIEN. JavaServer faces: training. 2nd ed. Sebastopol, CA: O’Reilly, c2004, xiv, 589 p. ISBN 05-960-0539-3. [7] HEWITT, Eben, Ryan FOWLER a Tim O’BRIEN. Java SOA cookbook: training. 1st ed. Sebastopol, Calif.: O’Reilly, c2009, xxiv, 714 p. ISBN 05-965-2072-7. [8] SOAP Specifications. World Wide Web Consortium (W3C) [online]. 2013 [cit. 2013-05-07]. Dostupn´e z: http://www.w3.org/TR/soap [9] HTTP/1.1: Method Definitions. World Wide Web Consortium (W3C) [online]. 2013 [cit. 201305-05]. Dostupn´e z: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html [10] WALLS, Craig. Spring in action. 3rd ed. Shelter Island: Manning, c2011, xxiii, 400 p. ISBN 19-351-8235-8.
26
