2. Agenda
• Webové aplikace a jejich historie
• Výhody a nevýhody webových aplikací
• Jak webová aplikace funguje?
• Vývoj webových aplikací
• Webové technologie
• Internet, doporučená literatura
2
4. • Do poloviny 90. let
• Statické webové stránky
• Text, obrázky
• Akademická sféra, odborná veřejnost
• Uživatelé mohou obsah webových stránek ovlivnit jen minimálně
• Druhá polovina 90. let
• Dynamické webové stránky, webové služby (na přelomu století)
• Multimediální obsah
• Přístupné pro nejširší veřejnost
• Interaktivita s uživatelem
• http://evolutionofweb.appspot.com/ (interaktivní časová osa)
Historie webových aplikací 4
5. • Wikipedia – „Webová aplikace je poskytovaná uživatelům z webového serveru přes
počítačovou síť Internet, nebo její vnitropodnikovou obdobu (Intranet).“
• Jsou postaveny na modelu klient/server >> dotaz/odpověď
• Na straně uživatele (klienta) je webový prohlížeč, na opačné straně je webový server
(v nějaké podobě – HW, virtualizace, serverová farma… )
• Nejčastěji jde o webové stránky s aplikační logikou – ta je obvykle na straně serveru
(část, nebo i celá logika může být i na klientovi) – výstup je zobrazen v okně prohlížeče
na straně uživatele (klienta) bez ohledu na zařízení
• Pojem webová aplikace není striktně (normativně) vymezen!
• Mezi webové aplikace jsou někdy řazeny i služby typu Web API (nejčastěji WS/REST),
jejich výstup není určen přímo uživateli (BFU), ale je dále zpracováván aplikačně
Co to je webová aplikace? 5
6. • Nejčastěji typ webové aplikace (jsou i další možnosti… Flash, Ajax a spol./RIA, SPA)
• Používají (X)HTML kód (+ CSS a JavaScript) jako rozhraní pro komunikaci s uživatelem
• Na rozdíl od „běžných“ statických WWW stránek je na straně serveru navíc přítomna
aplikační logika, která reaguje na specifické požadavky klientů (což výrazně zvyšuje
úroveň interaktivity s uživatelem)
• Příklady
• Virtuální obchody (e-shopy)
• Mapy, katalogy a vyhledávací služby
• Redakční systémy (CMS)
• Sociální sítě (Facebook, Twitter a spol.)
• ASP (Application Service Provider), SaaS (Software as a Service) – hostování,
pronájem aplikací a služeb
Dynamické generované webové stránky 6
7. • Model klient/server
• Na straně klienta je většinou aplikace, která odpověď serveru dále zpracovává
• Webové služby používají formát XML, ve kterém spolu klient a server komunikují
(vlastní komunikace zpravidla probíhá přes protokol HTTP/HTTPS)
• Pomocí webových služeb je možné řešit komunikaci aplikací v heterogenním prostředí,
protože používaný formát (XML) a protokoly (SOAP = vzdálené volání procedur,
HTTP/HTTPS = přenos dat) jsou dostatečně univerzální
• Popis každé webové služby (dostupné metody a parametry) je k dispozici v XML formátu
(*.wsdl soubor)
• Webové služby je možné vytvářet na všech běžně používaných vývojových platformách
(Java, .NET, PHP).
• S čím dál výraznějším trendem vzájemného propojování existujících aplikací roste
význam technologií, které umožňují jejich integraci – tedy i webových služeb!
• Pozor, webové služby nemusí být vždy tím nejvhodnějším integračním řešením!
Webové služby (web services) 7
8. • REST navrhl Roy Fielding (spoluautor HTTP protokolu)
• Model klient/server
• Je bez-stavový, může pracovat z cache, jednoduchá implementace
• Je orientován datově (ROA), na rozdíl od webových služeb (orientovány
procedurálně)
• Používá běžné HTTP příkazy (GET, POST, PUT a DELETE) pro CRUD operace
• Stav aplikace a chování je vyjádřen takzvaným resourcem (klíčová abstrakce),
každý resource musí mít unikátní identifikátor (URL, URN)
• REST formáty pro výměnu dat… Atom/RSS, JSON, XML
REST (Representational State Transfer) 8
10. • Na straně klienta stačí webový prohlížeč, někdy s příslušným plug-inem
(Flash, Silverlight) – od nutnosti pluginů se ustupuje (nové možnosti HTML5)!
• Jednoduchá údržba – změny pouze na straně serveru
• Aktuálnost – každá úprava se okamžitě projeví (aplikační logika, data)
• Nižší nároky na HW klientů – stačí jakékoliv zařízení s webovým prohlížečem
• Nižší provozní náklady
• Nezávislost na platformě (OS) na straně klienta
• Přizpůsobení UI různým koncovým zařízením (exponenciálně roste počet
přístupů z mobilů)
• Výborná dostupnost, využití v lokální síti (Intranetu) i v Internetu (24/7)
Výhody webových aplikací 10
11. • Nehodí se pro některé typy aplikací
• Vysoká závislost na poskytovateli aplikace
• Roadmapa aktualizací nemusí vyhovovat všem klientům (viz. nasazení Office)
• Nemožnost práce v offline režimu (začíná se řešit – HTML5, Adobe Air)
• Omezené možnosti uživatelského rozhraní
• Omezené možnosti validace dat na straně klienta (webový prohlížeč)
• Nedokonalá podpora standardů (HTML, CSS, JavaScript) v prohlížečích
• Bez-stavová komunikace při použití protokolu HTTP/HTTPS (lze obejít)
• Množství přenášených dat (značkovací jazyk)
• Problémy s bezpečností (webový prohlížeč, dostupnost v Internetu)
Nevýhody webových aplikací 11
13. • Webová aplikace je postavena na modelu klient/server
• Na straně klienta je obvykle vizuální rozhraní aplikace (User Interface, frontend)
• HTML + CSS + JavaScript (nejčastější případ)
• Flash/Flex
• Silverlight…
• Na straně webového serveru (backend) je aplikační logika, datové úložiště atd.
• Část aplikační logiky může být i na klientovi (JavaScript)!
• Na straně serveru může být jen datové API (SOAP, REST apod.) – potom je
aplikační logika na klientovi celá (některé SPA)
• Obvykle se ke komunikaci využívá protokol HTTP/HTTPS (port 80, resp. 443), má
určité nedostatky… Google projekt SPDY, resp. nově schválený HTTP/2 >>
rychlejší načítání stránek, bezpečnější šifrování
• Klientským zařízením nemusí být jen stolní počítač!
Jak webová aplikace funguje? 13
14. • Synchronní komunikace
• Je (zatím) častější
• Dotaz klienta + odpověď serveru (znáte ze statických webů)
• Iniciátorem komunikace je vždy klient (webový prohlížeč)
• Aktuálnost informací má určité zpoždění (až když se klient zeptá)
• Asynchronní komunikace
• Má permanentně otevřený komunikační kanál
• Oboustranná komunikace mezi serverem a klienty
• Využívá se v tzv. realtime aplikacích (online chat, kurzy akcií apod.)
• Podpora v různých technologiích, nejznámější asi AJAX, web socket apod.
• Metody komunikace v HTML5 (XML HTTP Request, CORS, Web Sockets …)
• SignalR: Realtime web v ASP.NET (Michal „Altair“ Valášek)
Synchronní a asynchronní komunikace 14
16. • Webové aplikace mají, v porovnání s klasickými desktopovými a klient/server
aplikacemi, určité specifické požadavky
• Souběžný přístup velkého množství klientů >> rychlost odezvy
• Protokol HTTP je bez-stavový >> nutnost použití session a cookies
• Různá koncová zařízení, snaha o co nejmenší datový traffic (odezva, peníze)
• Při návrhu GUI aplikace je vhodné přesně specifikovat použité technologie
a standardy (ve firemních intranetech stále přežívá IE6!)
• I pro webové aplikace platí tradiční vývojový cyklus...
Analýza * –> Implementace –> Testování * –> Nasazení * –> Provoz *
Jednotlivé fáze vývojového cyklu (*) může ovlivnit zákazník (zadavatel)!
Vývoj webových aplikací 16
17. • Je třeba klást maximální důraz na testování (nejlépe automatizované) a brát
v úvahu rozdíly mezi testovacím a skutečným provozem (HW, SW, konfigurace)!
• Existují různé druhy (automatických) testů
• Funkční, integrační, zátěžové, unit testy apod.
• Při opakovaném použití (iterace) přináší automatické testování výraznou úsporu
času a lidských zdrojů (kapacit)… snižuje náklady na projekt!
• „Automatizace snižuje pravděpodobnost, že uděláme při zadávání chybu, ale
zvyšuje pravděpodobnost, že na něco zapomeneme“ – Michael Nygard
• Začněte měřit výkon systému (nebo jeho části) co nejdříve
• Agilní metodiky: Výkonnostní testy nejpozději od 3. iterace (1 iterace = cca 2-4 týdny)
• Pozdějším nasazením se připravíte o možnost identifikovat, jaká změna měla za následek
případné problémy s výkonem
Testování webových aplikací 17
18. • Podle podmínek a okolností vzniku
• Vývoj na zelené louce (celý vývojový cyklus běží od začátku)
• „Překlopení“ již existující aplikace (s použitím reverzní analýzy)
• Podle způsobu implementace
• Programováním
• Generováním (z databáze, z modelu (MDA) atd.)
• Oba způsoby implementace mají své výhody a nevýhody!
Možné přístupy k vývoji 18
19. • Při návrhu webové aplikace je vhodné rozdělení do tzv. aplikačních vrstev
• Nejjednodušší (obecné) rozdělení:
Přístup k datům (persistence) – Aplikační (business) logika – Prezentační vrstva (UI)
Aplikační vrstvy 19
Domain-Driven Design patterns:
1. User interface (Presentation Layer)
2. Application Layer
3. Domain Layer
4. Infrastructure and Technical Services Layer
http://davidhayden.com/blog/dave/archive/2004/12/12/685.aspx
Obecně: Návrhové vzory jsou užitečné, pomáhají
ke správnému návrhu designu aplikace!
20. • Rozdělení aplikace do vrstev umožňuje (kromě dalších výhod) při vývoji využít
nejrůznější podpůrné knihovny a frameworky, které mohou výrazně zjednodušit
a zefektivnit vývoj, např.
• Přístup k datům (DB, file systém, různé formáty…), ORM Object Relational Mapping)
• Automatizované testování (unit testy)
• Autentizaci uživatelů
• Příklad některých používaných knihoven a frameworků
• Java – JDO, Spring, JUnit, Hibernate (ORM)
• .NET – ADO.NET, NUnit, EF, LINQ, NHibernate (ORM), Spring.NET, ASP.NET MVC
• PHP – PEAR, Smarty, FastTemplates, Nette, Zend
• Používání frameworků a knihoven je trend!
Knihovny a frameworky 20
22. • Je závažnou (a bohužel obvyklou) chybou programovat webové aplikace jako
jednouživatelské
• Při návrhu aplikace se nepočítá s jejím budoucím rozvojem/rozšířením, integrací
s dalšími aplikacemi nebo rostoucím zatížením (více uživatelů)
• Živelný vývoj – často se začne programovat bez dostatečné analýzy nebo bez
komunikace se zákazníkem (chybí prototyp UI apod.)
• Uživatelům se nabízí zbytečně složité a nepřehledné ovládání
• Vývojové, testovací a provozní prostředí aplikace mají často rozdílnou konfiguraci
(liší se verze použitého SW, nastavení parametrů apod.)
• Podceňuje se fáze testování (funkční, integrační, zátěžové), nepoužívá se TDD (unit
testy)
• Neoddělují se jednotlivé aplikační vrstvy (data – business – user inteface)
• Objevují se zbytečné duplicity v programovém kódu
• Znovu se vynalézá kolo >> nepoužívají se vzory (design patterns), best practice
• Programují se funkce, která uživatel nepotřebuje nebo nevyužívá (řada z nich není v UI
vůbec vidět)
• Ignorují se základní bezpečnostní pravidla pro přístup k aplikacím a k datům
Chyby při vývoji web aplikací I. 22
23. • UI je složitý, nepřehledný, často s nestandardním ovládáním
• Netestují se vstupní data od uživatelů (uživatel = neřízená střela)
• Zůstávají neukončená připojení k databázi
• Je špatně navržená struktura databáze, chybí indexy apod.
• Používají se neoptimalizované SQL dotazy, často bez parametrů
• Není ošetřena souběžná modifikace dat
• Není ošetřen opakovaný zápis dat (F5, obnovení stránky)
• Nejsou správně nebo vůbec ošetřeny výjimky (chyby)!
• Nevyužívá se vyrovnávací buffer při generování odpovědi
• Nevyužívá se kešování (cache) stránek při opakovaných požadavcích
• Přenáší se zbytečně velké množství dat mezi serverem a klientem (pozor na mobily!)
• Při objektovém programování se chybně pracuje s kolekcemi
• Programátor po sobě „neuklízí“ v paměti, spoléhá na GC nebo na zázrak
• http://zdrojak.root.cz/clanky/programator-prestava-byt-amater-kdyz/
Chyby při vývoji web aplikací II. 23
25. • Volbu technologie ovlivňuje řada faktorů, např.
• Požadavky (různé role, potřeby)
• Použitá platforma (OS, aplikační server, databáze)
• Požadavky na bezpečnost
• Zvyk (zadavatel, dodavatel), obchodně-politické vlivy
• Dostupnost know–how na straně dodavatele
• Cena řešení
• Prostředí, podmínky provozu
• Co to přinese pro business (náklady, termíny, náročnost… udržitelnost!)
• Použitá technologie může výrazně ovlivnit rychlost (odezvu) webové aplikace
směrem ke klientovi (ASP/ASP.NET –> až 3x větší rychlost ASP.NET).
• Volba vhodné technologie ještě nezaručuje dobrý výsledek!
• Blbost je na platformě nezávislá
Volba technologie 25
26. • Na straně klienta
• HTML formuláře
• CSS, DHTML, XSLT
• Klientské skripty (JavaScript, dříve i VB.Script*)
• Java aplety*, ActiveX*
• Flash/Flex, Silverlight, AJAX a další technologie ze skupiny RIA
• Na straně serveru
• Interpretované (např. Perl, ASP*, PHP, Python, Ruby)
• Částečně kompilované (JEE, ASP.NET)
• Kompilované (CGI skripty*)
• Hvězdičkou (*) jsou označené zastaralé nebo jinak problematické technologie
Technologie používané u web aplikací 26
27. • Časová osa
• Pravěk – HTML formuláře a CGI skripty,
• Středověk – Perl, ASP, JSP, PHP, Java Aplety, ActiveX,
• Dnes – AJAX (HTML + JavaScript), JEE (J2EE), ASP.NET, Ruby (on Rails), Python
(Django), Silverlight, Flex atd.
• Na straně klienta (prohlížeče) je, a v nejbližší době bude, nejdůležitější kombinace
HTML5 + JavaScript + CSS3. Bez ohledu na technologie použité na straně serveru!
• Výhledově HTML5 může nahradit nativní aplikace, ale nebude to hned!
• Rozšířenost vybrané technologie ještě automaticky neznamená její kvalitu!
• Infografika: http://sixrevisions.com/infographs/what-websites-madeof/
Používané technologie z hlediska historie 27
