Optimalizace vývojového procesu webových aplikací Vratislav Čermák, Zdeněk Havlíček Katedra informačních technologií, Provozně ekonomická fakulta, Česká zemědělská univerzita v Praze, Praha 6 - Suchdol Abstrakt Příspěvek je zaměřen na návrh a vývoj aplikací určených pro provoz na internetu, tedy aplikací ovládaných prostřednictvím standardního webového prohlížeče. Je představena nová metodika ETWA (Efektivní Tvorba Webových Aplikací), která umožňuje snadnější a rychlejší vývoj webových aplikací. V rámci navrhované metodiky se využívá tzv. XML kolektor, který umožňuje jazykově oddělené shromažďování transportních dat a následný paralelní postup několika profesí, které se podílejí na vlastní tvorbě aplikace. Přínosy metodiky nejsou zaměřeny na žádnou konkrétní technologii, jazyk nebo platformu a jsou využitelné při řešení různých internetových projektů. Klíčová slova: Internetové projekty, Webové aplikace, metodika ETWA, XML kolektor Abstract The article is focused on design and development of applications intended for running at the Internet. It means applications controlled via the standard web browser. The new ETWA (abbreviation for Effective Web Application Development in Czech) philosophy of easier and faster development of web applications is presented in the article. The XML Collector idea enables transport data collection in different (programming and markup) languages. That facilitates to all project’s roles to work in parallel. ETWA philosophy benefits are not connected to any concrete technology, language or platform. It can be used for different types of internet projects. Key words: Internet projects, Web applications, ETWA method, XML Collector
1. Úvod V souvislosti s rozvojem Internetu a využíváním třívrstvé C/S architektury se při tvorbě aplikací a informačních systémů prosazují internetové technologie. Stále častěji se vytvářejí nové webové aplikace. Webovou aplikaci lze chápat jako souhrn dat, programových prostředků (zejména aplikačního software) a technických prostředků v rámci informačního systému, sloužících (většinou koncovému) uživateli k řešení jeho úlohy prostřednictvím www technologií. Hlavní výhodou těchto aplikací je nezávislost na použitém hardwarovém a programovém vybavení na straně klienta a možnost volného přístupu z libovolného počítače, který je připojen k Internetu.
SYSTÉMOVÁ INTEGRACE 1/2009
7
Vratislav Čermák, Zdeněk Havlíček
Požadavky na vývoj webových aplikací vycházejí z podnikatelské reality. Jsou vyvíjeny na míru podniku, a to proto, že software zajišťující požadovanou funkčnost není buď k disposici nebo je příliš drahý pro nasazení v daném podniku. Existuje celá řada přístupů, jak řídit a realizovat softwarový projekt. Např. Guckenheimer [1] porovná protikladné přístupy tzv. úkolocentrický (work-down) a hodnotocentrický (value-up). Postupy při tvorbě www aplikace vycházejí z obecných metod projektování informačních systémů, ale vzhledem ke specifickým vlastnostem www technologií hovoříme obecně o internetových projektech.
2. Cíl práce a metodika Cílem příspěvku je analyzovat současný stav řešení internetových projektů – tvorby webových aplikací a představit výsledek vlastního výzkumu, tj. novou metodiku ETWA. Analýza současného stavu byla zajištěna především z hlediska profesí, které se podílejí na realizaci internetového projektu. Metodika ETWA vychází z principů běžně využívaných metodik projektového řízení a řeší praktický problém při vlastní tvorbě webové aplikace, tj. využitím jazyka XML umožňuje efektivněji zajišťovat posloupnost činností při realizaci internetového projektu s cílem zkrácení celkové doby realizace a efektivního využití lidských zdrojů.
3. Zvláštnosti internetových projektů Voldán [2] uvádí, že u internetového projektu trvajícího čtyři měsíce je 95 % práce vykonáno během prvních dvou měsíců a další dva měsíce potom trvá dokončování projektu. Tento paradox vyplývá ze specifik internetových projektů, mezi ně patří především grafické uživatelské rozhraní a orientace na různé cílové skupiny. Význam grafického uživatelského rozhraní U internetových (nebo intranetových) projektů je uživatelské rozhraní většinou velice důležité, a to především z hlediska grafického designu, celkové logiky ovládání, rozmístění ovládacích prvků na stránce, apod. Vytvořené aplikace často slouží několika zcela rozdílným cílovým skupinám. Komunikace s designéry však pro řadu projektových manažerů z oblasti informačních technologií představuje značný problém, neboť dříve či později zjistí, že grafici komunikují úplně jiným jazykem a myslí jiným způsobem než programátoři nebo konzultanti. Orientace na cílové zákazníky Důležitým předpokladem internetových řešení je efektivní komunikace s cílovou skupinou. V současnosti bývá častěji zadavatelem internetových projektů marketingové oddělení než IT oddělení firmy. Je třeba si uvědomit, že lidé z oblasti marketingu přemýšlí o problému zcela jiným způsobem než lidé z IT, proto je vhodné cíle projektu a cílovou skupinu vyjádřit “v obrazech”. Vhodné jsou i příklady a přirovnání, aby byly cíle projektu skutečně vnímány stejně. Marketingové oddělení na vizuální část projektu obvykle klade velký důraz. Přechod projektu v průběžný rozvoj Softwarový projekt se obvykle definuje jako řešení nějakého přesně specifikovaného problému nebo řešení úkolu, v daném časovém rámci a s určeným 8
SYSTÉMOVÁ INTEGRACE 1/2009
Optimalizace vývojového procesu webových aplikací
rozpočtem. Internetové projekty nebývají přesně zadány a často přecházejí do fáze nespecifikovaného, průběžného rozvoje. Pro úspěšnou realizaci projektu je třeba vytvořit systém řízení požadavků. Systém by měl zajistit především podchycení všech požadavků (včetně jejich schválení či odmítnutí), sledování stavu realizace schválených požadavků. Rozpočet zadavatele Omezený rozpočet není pouze specifikem internetových projektů, ty jsou však z tohoto úhlu pohledu opět určitým způsobem odlišné. Jak již bylo zmíněno, jejich zadavatelem je velmi často marketingové oddělení firmy. Marketingové rozpočty stále ještě reflektují “tradiční” reklamní model obchodu - reklamní agentury získávají prostředky z provize za prodej médií, a z ní pokrývají i náklady na vytvoření toho, co se v nich má prezentovat. Většina marketingového rozpočtu firmy jde proto na média - jenomže v případě Internetu představuje hlavní část nákladů vytvoření vlastního řešení, nikoliv médium jako takové. Internetová řešení se sice dají často zrealizovat velice levně, avšak téměř vždy na úkor kvality, spolehlivosti a především bezpečnosti.
3.1 Role v projektu webové aplikace Webová aplikace představuje funkční softwarový výsledek internetového projektu. Tvorby aplikace se účastní různé profese, které mají na projektu a jeho úspěšné realizaci svůj podíl a svoji odpovědnost – viz obrázek č.1.
Obr. č. 1 Standardní vývojový proces webových aplikací Analytik Role analytika je v projektu nejvíce potřebná v začátku, v době přípravy zadání, komunikuje se zákazníkem, vytváří přípravné dokumenty pro vlastní přípravu a tvorbu aplikace. Role analytika v projektu může být dělena dle specializace na určité části aplikace (systémový návrh, provedení GUI, informační architektura, komunikační model, marketingový model) a toto rozdělení vždy závisí na schopnostech nominované osoby, na možnostech a pravidlech organizace. Výstupem práce analytika je dokument analýzy nebo specifikace, diagramy SYSTÉMOVÁ INTEGRACE 1/2009
9
Vratislav Čermák, Zdeněk Havlíček
představující návrh fungování celé, nebo části připravované aplikace. Diagramy mohou představovat např. databázové relace, procesní návrh, návrh datových toků, případy užití, stejně tak jako rozvržení grafických elementů a způsob ovládání aplikace. Hlavní část práce analytika je odvedena především na počátku projektu. V průběhu realizace analytik působí spíše jako konzultant a operativně ve spolupráci s týmem doplňuje nebo upravuje části specifikace tak, aby aplikace a dokumentace byly po dokončení konzistentní. Grafik Role grafika je velmi důležitá a specifická pro webové aplikace. Při tvorbě klasických desktopových aplikací obvykle není grafik v projektovém týmu zastoupen. Webová aplikace běží v jednom okně, je založena na sekvenčním přechodu mezi jednotlivými kroky, musí působit na uživatele atraktivně a být snadno ovladatelná. Použité grafické prvky nesmí výrazně zpomalovat načítání stránky. Grafik musí počítat s tím, že si uživatel může měnit velikost okna, velikost písma apod. Kodér Kodér je označení role, pro kterou se v praxi používá mnoho různých termínů: HTML programátor, CSS specialista, Front-End Web Developer, apod. Pro naše účely je kodérem míněn HTML/CSS specialista, který zná současné značkovací jazyky (HTML, XHTML, XML) a zároveň ovládá kaskádní styly CSS a dokáže převést grafický návrh do podoby statické stránky. Obecně lze tedy práci roli kodéra spatřovat v transformaci grafického materiálu do sady statických XHTML stránek s použitím formátování typu CSS. Předávaný výstup by měl být ověřen na různých platformách a být validní dle veřejných specifikací. Programátor Aplikace funguje, jestliže reaguje na vstupy od uživatele, vrací mu relevantní výstupy a nabízí mu další možnosti pokračování v práci. A právě tyto požadavky musí zaštítit programátor. Pro svoji práci využívá různé programovací jazyky (PHP, ASP/.NET, Java, Ruby, ...). Volba jazyka je závislá čistě na preferenci nebo znalosti programátora a většinou nemá zásadní vliv na naplnění cílů projektu. Od programátora se očekává práce s datovými zdroji, zpracování vstupů uživatele, ošetření chyb, ovládání serverových částí, komunikace s okolními systémy, příprava dat pro uživatelské rozhraní (UI), apod. Role programátora může být v závislosti na typu organizace dále dělena. Obecně lze do této role zařadit také databázové specialisty, JavaScript programátory nebo Flash programátory. Tester Jde o roli a činnost, která je implementována i v mnoha jiných odvětvích, ale nikde není tak podceňována jako právě v IT. Testování webových aplikací se provádí v mnohých případech pouze během vývoje. Integrační testování před předáním díla zákazníkovi nebo spuštěním do ostrého provozu se zajišťuje jen zřídka. Tento fakt je dán především způsobem řízení projektů, nižší mírou rizika a také nižším rozpočtem na aplikace tohoto typu.
10
SYSTÉMOVÁ INTEGRACE 1/2009
Optimalizace vývojového procesu webových aplikací
Projektový manažer Projektový manažer se účastní všech fází projektu – viz obr. č. 2. Je primárně zodpovědný za specifikaci, vymezení rozsahu, času a alokaci zdrojů, a tedy i dodávku celého projektu. Dohlíží na průběh realizace a porovnává dosažené výkony vůči plánu a milníkům, které byly stanoveny. V okamžiku, kdy se některá část začne zpožďovat, nebo je identifikováno navýšení odhadované pracnosti, musí projekt přeplánovat, což s sebou nese další rizika v nedostupnosti zdrojů v nově naplánovaném čase. I přesto že se pracovní alokace jednotlivých rolí na projektu prolínají, představuje nedostupnost jedné role značný problém, neboť není možné pokračovat na navazujících činnostech. Projektový manažer odsouhlasuje vstupy jednotlivých týmů, provádí průběžnou kontrolu kvality výstupů. Mimo řízení vlastního týmu je zodpovědný za komunikaci se zákazníkem, prezentaci výsledků a plnění projektového plánu. Domlouvá případné posuny projektu a další dopady. Nezbytnou administrativní částí práce projektového manažera je kontrola výkazů odpracované práce, reporting nadřízeným, otevírání a uzavírání projektu, včetně jeho vyhodnocení.
Obr. č. 2 Role v průběhu internetového projektu
4. Metodika pro zefektivnění procesu vývoje - ETWA Na základě základě teoretických poznatků a praktických zkušeností autorů je navržena nová metodika ETWA (Efektivní Tvorba Webových Aplikací), která má zefektivnit a urychlit vývoj webových aplikací. Cílem metodiky je implementačně nezávislý návrh, který je možné aplikovat na vývoj internetových projektů na úrovni malých a středních podniků. Metodika je navrhována pro webová studia a developerské společnosti, realizující projekty malého až středního rozsahu. Metodika se zatím neorientuje na velká (enterprise) řešení. Princip metodiky je založen na tom, že všechny tři hlavní projektové role - grafik, kodér a programátor - mohou paralelně pracovat s svých činnostech - tj. tvorbě designu, přípravě šablon a programování (viz obr. č.3).
SYSTÉMOVÁ INTEGRACE 1/2009
11
Vratislav Čermák, Zdeněk Havlíček
Obr. č. 3 Princip metodiky ETWA
4.1 Prvky metodiky
4.1.1 Transportní vrstva Hlavním prvkem metodiky ETWA je vložení nové mezivrstvy mezi vrstvu aplikační logiky a vrstvu prezentační. Nově vložená vrstva bude transportní a bude obsahovat veškerá data potřebná pro vytvoření obsahu (nikoliv vzhledu) uživatelského rozhraní a zobrazení požadovaných výstupů - viz obr. č. 4. Obdobné přístupy jsou již používány v konceptu MVC [4], kdy vrstva modelu zajišťuje vytvoření datové struktury a její následné použití v jednotlivých šablonách, tedy views. Obdobně je použit přístup v šablonovacích systémech, které pro sestavení transportní vrstvy využívají různé typy proměnných nebo objektů programovacího jazyka.
Obr. č.4 Zavedení transportní vrstvy
12
SYSTÉMOVÁ INTEGRACE 1/2009
Optimalizace vývojového procesu webových aplikací
4.1.2 XML kolektor Aby bylo možné shromáždit veškerá data, je nutné implementovat do aplikace “sběrač dat”, který je v rámci metodiky ETWA nazýván XML kolektor. Jeho primárním významem je strukturované ukládání dat z jednotlivých mezivýstupů aplikačních součástí. XML kolektor může být implementován např. jako sdílená funkce, třída (resp. objekt), kolekce nebo pole hodnot či objektů. Ačkoliv je tento prvek nazýván jako XML kolektor, nebude se vytvářet na úrovni aplikace jako XML kód, nýbrž jako hierarchická data sestavená na základě prostředků programovacího jazyka. Schéma fungovaní XML kolektoru je uvedeno na obr. č. 5. Rozhraní pro práci s kolektorem musí být poskytováno na úrovni programovacího jazyka, aby nemusel programátor definovat strukturu XML a zaobírat se XML reprezentací dat. Naopak v kódu aplikace by se tak neměly již vyskytovat deklarace typu print, echo, apod. zobrazující nějaké výstupy přímo do stránky. Všechny tyto výstupy aplikace by měly být předávány do XML kolektoru. Jestliže jsou programátoři zvyklí na používání některého z frameworků, není pro ně podobný způsob ničím zásadně novým, jen je striktně požadováno oddělení různých typů dat. XML kolektor by měl být naplněn daty tak, aby na straně prezentační vrstvy nebylo nutné jakékoliv údaje dopočítávat, či získávat pomocí konstrukcí programovacího jazyka.
Obr. č. 5 Princip fungování XML kolektoru
SYSTÉMOVÁ INTEGRACE 1/2009
13
Vratislav Čermák, Zdeněk Havlíček
4.1.3 Serializace Serializace je obecně používaný postup pro uložení datových struktur (proměnných, polí, kolekcí, objektů, apod.) do formátu, ve kterém je možné tato data uložit do databáze, trasportovat přes internet. Cílem serializace je objekt “zabalit” a uložit pro použití v budoucnu (např. při opětovném přihlášení uživatele), nebo jej odeslat do jiného systému, kde je možné serializovaný objekt obnovit a dále s ním pracovat. Kromě možností překonání omezení transportních vrstev nebo relačních databázových úložišť, umožňuje serializace elegantní formu klonování objektů programovacího jazyka. Výhod XML serializace je možné využít i v metodice ETWA, kde je doporučena pro vytváření XML vrstvy mezi aplikačním kódem a prezentační vrstvou. Data nashromážděna do jednotného úložiště pomocí XML kolektoru představují datový vstup pro serializaci. Aby byla tato data následně dobře použitelná pro účely prezentační vrstvy, je nutné zavést pravidla a ta prostřednictvím pravidel XML kolektoru vyžadovat. Do serializace tak vstupuje jeden velký datový objekt, obsahující veškerá data, která jsou požadována k předání do prezentační vrstvy. Jestliže je XML kolektor navržen dostatečně efektivně a obsahuje data v dohodnuté struktuře, je pak vlastní vytvoření XML pro účely prezentační vrstvy velice jednoduché.
4.1.4 Validace dat Metodika ETWA zavádí validaci generovaných XML dat ještě předtím, než je dokument předán do XML mezivrstvy. K vytvoření definice elementů bylo v minulosti využíváno převážně schéma dokumentu ve formátu DTD (Document Type Definition). V rámci metodiky ETWA se pro popis schématu dokumentu využívá validační schéma RELAX NG, které se zapisuje v syntaxi XML a celkové vyjádření schématu je velmi kompaktní.
4.1.5 Tvorba šablon uživatelského rozhraní Práce kodéra se v tomto případě omezuje pouze na používání HTML a formátovacích stylů (stylesheets), které umožňují formátovat výstup pro potřeby uživatelského rozhraní. Využívají CSS (Cascading Style Sheets) a jazyk XSLT. Každá vytvořená šablona transformuje data ze vzorového XML dokumentu do jednotlivých stránek odpovídajících jednotlivým navrženým designům. Data, která nejsou do šablony zaslána, se ve výsledné stránce vůbec nezobrazí, neboť není spuštěno renderování příslušné části šablony z důvodu chybějících dat. Naopak invalidní data, která by byla do šablony poslána při běžném zpracování, jsou odfiltrována již na úrovni validace dat vůči např. Relax NG schématu a v šabloně, resp. uživatelském rozhraní, se taktéž nezobrazí. V internetovém prohlížeči tak kodérovi vznikají skutečné stránky, přidáním nebo odebráním elementů ze zdrojového XML souboru mohou být simulovány různé stavy. Prostřednictvím odkazů obsažených uvnitř XML dokumentu je možné šablony navzájem propojit a vytvořit tím prototyp. Ten samozřejmě neobsahuje aplikační kód a proto slouží pouze pro představu jak budou prvky uživatelského rozhraní vypadat, jak budou na stránce formátovány, atd. Prototyp slouží pro interakci se zadavatelem, který tak má možnost vznést připomínky k ještě nekompletní aplikaci a tyto změny mnohem jednodušeji zapracovat do konceptu 14
SYSTÉMOVÁ INTEGRACE 1/2009
Optimalizace vývojového procesu webových aplikací
uživatelského rozhraní. Prototyp zároveň působí na zadavatele jako “hmatatelný” výstup projektu v raném období vývoje a je jím vždy dobře přijat.
4.1.6 Programování aplikace Programátorům byla odebrána přímá zodpovědnost za uživatelské rozhraní, což představuje hlavní přínos metodiky ETWA oproti standardním postupům. Aplikace pouze generuje data, která předává do XML kolektoru. Výraznou změnou je nezávislost postupu zpracování a uložení dat do XML kolektoru.
Obr. č. 6 Návrh procesu vývoje dle metodiky ETWA Hlavním významem navržené metodiky je striktní oddělení role programátora od role kodéra – viz obr. č. 6. Společně musí pracovat pouze na přípravě XML dokumentu, který je základem validace transportní vrstvy. Dále ve fázi vývoje může programátor pracovat zcela nezávisle na kodérovi. Navíc umožňuje programátorovi začít pracovat na svém úkolu mnohem dříve, než je tomu u klasických přístupů. Programátor nemusí čekat na dokončení fáze tvorby designu a šablon pro uživatelské rozhraní. Je možné navázat okamžitě na fázi přípravy datové základny, kdy je definováno, jaké výstupy má aplikace produkovat. Metodika ETWA eliminuje vazbu HTML rozhraní na aplikačním kódu. Veškeré výstupy jsou pouze v “čistém textu”, mají svoje jméno a patří do určité, pojmenované sady dat. V programovém kódu je třeba implementovat XML kolektor, který zajišťuje sběr veškerých výstupů aplikace do jednotného úložiště. To následně transformuje (např. serializací) do předem definovaného XML formátu, který by měl být validován vůči předem definovanému schématu. Výstupem fáze programování je generovaný, validní XML dokument s veškerými daty aplikace. SYSTÉMOVÁ INTEGRACE 1/2009
15
Vratislav Čermák, Zdeněk Havlíček
Každá role pracuje pouze se tou skupinou jazyků, ve které je specializována. Zejména je třeba zdůraznit, že programátor pracuje pouze v prostředí svého programovacího jazyka a prostřednictvím jeho prostředků data odesílá do jednotného datového úložiště (XML kolektoru) pro účely jejich prezentace v uživatelském rozhraní. Díky vlastnostem programového XML kolektoru je možné data vyexportovat do skutečného XML formátu a tato data předat jako statický soubor na vstup uživatelského rozhraní, které vytváří kodér. Tato role naopak výlučně pracuje s jazyky značkovacími - tedy XML (z XML kolektoru, statickými daty), XHTML/CSS (pro vlastní uživatelské rozhraní), XSLT (pro transformaci dat z XML do výstupních stránek) a Relax NG (pro validaci vstupních dat). Vstupní data mají vždy vlastnosti definované ve validačním schématu a proto není nutná přímá interakce s programovým kódem pro účely získání vstupního XML souboru a vygenerování uživatelského rozhraní, ale postačí ručně vytvořený soubor, ve kterém je možné simulovat různá vstupní data a na základě nich generovat uživatelské rozhraní v příslušné formě.
5. Přínosy metodiky ETWA Metodika ETWA byla vyzkoušena při řešení několika relativně menších internetových projektů a získané výsledky – přínosy lze shrnout do pěti bodů: 1. Efektivnější vývojový proces webových aplikací - metodika umožňuje provádět některé činnosti paralelně, což umožňuje zkrátit dobu vývoje aplikace. Lze dosáhnout flexibilní alokace grafiků, kodérů a programátorů. 2. Vyšší specializace týmových rolí - základem metodiky je striktní oddělení aplikační a prezentační vrstvy, přičemž jejich spojení je realizováno až v rámci integrační fáze. Každá role v projektu tak pracuje pouze s prostředky a znalostmi, které jsou primárním obsahem její specializace. 3. Rychlejší nasazení změn ve fázi údržby - každá role má v projektu svoji odpovědnost za samostatný funkční výstup, není proto nutné při každém požadavku na změnu nebo údržbu alokovat všechny role. Jasné oddělení zodpovědností umožňuje lépe určit, kdo bude danou změnu realizovat. 4. Podpora různých výstupních formátů – oddělení prezentační vrstvy, která generuje výstupy nad strukturovanými daty, umožňuje vytváření výstupů v libovolných formátech a to jen na základě výměny šablony na úrovni prezentační vrstvy – tj. bez nutnosti zásahu do aplikačního kódu. 5. Podpora vícejazyčných aplikací – skládání výstupů na základě vícejazyčných elementů, či konfiguračních prvků podporuje navrhovaný XML kolektor, který na základě těchto elementů připravuje data pro prezentační vrstvu, v níž je pak možné realizovat uživatelské rozhraní v různých jazycích na základě jedné konzistentní šablony.
6. Závěr Proces tvorby webových aplikací je specifický typ internetového projektu, na kterém se podílí několik rolí (analytik, grafik, kodér, programátor, tester a projektový manažer). Hlavní myšlenkou navržené metodiky ETWA (Efektivní Tvorba Webových Aplikací) je zavedení nové transportní mezivrstvy mezi aplikační a prezentační vrstvu 16
SYSTÉMOVÁ INTEGRACE 1/2009
Optimalizace vývojového procesu webových aplikací
webové aplikace, která umožňuje realizaci paralelních činností. Dále pak zavedení XML kolektoru, který zajišťuje realizaci transportní vrstvy, striktní validaci dat a zcela odlišný způsob tvorby šablon uživatelského rozhraní. XML kolektor usnadňuje zaznamenání požadavků na budoucí aplikaci a následně paralelní práci několika profesí, které se podílejí na vlastní tvorbě aplikace. Přínosem metodiky je především snadnější a rychlejší vývoj webových aplikací. Tento příspěvek byl zpracován v rámci řešení VZ MSM 6046070906 “Ekonomika zdrojů českého zemědělství a jejich efektivního využívání v rámci multifunkčních zemědělskopotravinářských systémů“.
Literatura, použité zdroje: 1. 2. 3. 4.
5. 6.
VOLDÁN, J. Zvláštnosti internetových projektů [online]. Publ. 2002-01-25 [cit. 2008-03-10]
. GUCKENHEIMER, S., PEREZ J.J. Efektivní softwarové projekty. Brno: Zoner Press, 2007. 255 s. ISBN 978-80-86815-62-6. Web application [online]. Wikipedia, posl. revize 2008-11-09 [cit. 2008-11-10]
. SINGH I., STEARNS B., JOHNSON M. Web-Tier Application Framework Design. Designing Enterprise Applications with the J2EE(TM) Platform (2nd Edition) (Java Series) [online]. ISBN 0-201-78790-3 [cit. 2008-11-10] . ZELDMAN, J. Tvorba webů podle standardů XHTML, CSS, DOM a dalších. Praha: Computer Press, 2004. ISBN 80-251-0347-1. NIEDERST, J. Web design in a nutshell. O'Reilly, 2005. 760 s. ISBN 0-596-00987-9.
SYSTÉMOVÁ INTEGRACE 1/2009
17