Poděkování. Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce.

Transkript

1 Karlova univerzita v Praze Matematicko-fyzikální fakulta DIPLOMOVÁ PRÁCE Danila Privalenkov Použitelnost dynamických webových technologií pro náročné aplikace pracující v reálném čase Katedra softwarového inženýrství Vedoucí diplomové práce: RNDr. Michal Kopecký, Ph.D. Studijní program: Informatika, softwarové systémy

2 Poděkování Chtěl bych vyjádřit velký dík a úctu především vedoucímu této diplomové práce Michalu Kopeckému za jeho úsilí, trpělivost a moudré vedení. Dále chci poděkovat Janě Štanclové za její cenné rady a připomínky a také za její vstřícnost a ochotu přečíst a velmi podrobně okomentovat celou diplomovou práci. Nakonec bych chtěl poděkovat všem, kteří mě v diplomové práci podporovali a vytvořili veškeré podmínky a zázemí pro její dokončení: svým blízkým a také svému zaměstnavateli firmě Logica za poskytnutí studijního volna, které mi umožnilo práci dokončit. Prohlašuji, že jsem svou diplomovou práci napsal samostatně a výhradně s použitím citovaných pramenů. Souhlasím se zapůjčováním práce. V Praze dne 1. prosince 2008 Danila Privalenkov 2

3 PODĚKOVÁNÍ... 2 ABSTRAKT... 6 ABSTRACT ÚVOD CÍLE PRÁCE FINANČNÍ TRHY ZÁKLADNÍ KOMPONENTY OBCHODNÍ PLATFORMY TYPICKÁ ČINNOST OBCHODNÍKŮ ARCHITEKTURA OP TICKER Architektura serveru Architektura databáze POŽADAVKY NA TICKERWEB A CÍLE DIPLOMOVÉ PRÁCE WEBOVÉ APLIKACE KLASICKÉ HTTP PARADIGMA POJEM WEBOVÁ APLIKACE, DRUHY WEBOVÝCH APLIKACÍ VÝHODY WEBOVÝCH APLIKACÍ OPROTI DESKTOPOVÝM PROBLÉMY SPOJENÉ S WEBOVÝMI APLIKACEMI MÁ TICKERWEB BUDOUCNOST? TECHNOLOGIE PRO VÝVOJ DYNAMICKÝCH WEBOVÝCH APLIKACÍ KLIENTSKÉ TECHNOLOGIE Adobe Flash Java Plug-in Aplet ActiveX DHTML DOM programování AJAX Poznámka k terminologii SUMÁRNÍ POROVNÁNÍ AJAX HISTORIE VZNIKU AJAXU ZÁKLADNÍ PRINCIP FUNGOVÁNÍ AJAXU KLÍČOVÉ KOMPONENTY AJAXU CSS DOM XMLHTTPREQUESTOBJECT (XHR) Metody XHR Atributy XHR Kompatibilita XHR s prohlížeči PROTOTYPOVÁ IMPLEMENTACE A STUDIUM ŘEŠENÍ JEDNOTLIVÝCH POŽADAVKŮ TICKERWEBU

4 6.1 PŘENOS DAT Definice požadavků na data Mechanizmus posílání požadavků na server Formát dat Přetížení serveru při použití AJAXu Mechanizmus komunikace mezi klientem a serverem Způsob odběru dat ze serveru Mechanizmus posílání zpráv od serveru klientovi BEZPEČNOST Bezpečnost datového přenosu mezi klientem a serverem Zamezení přístupu k neoprávněným zdrojům Ochrana osobních údajů zákazníků Ochrana proprietárního kódu IMPLEMENTACE TABULKY S KURZY IMPLEMENTACE REAL-TIMEOVÝCH GRAFŮ Knihovny pro generování statických obrázků grafů SVG Implementace grafů pomocí ChartDirector Implementace grafů pomocí SVG CHAT REAL-TIMEOVÁ KONTROLA VSTUPU A PREDIKTIVNÍ NÁPOVĚDA TŘÍDĚNÍ TABULEK A DRAG&DROP SPOUŠTĚNÍ TRIGERŮ PŘI DOSAŽENÍ LIMITŮ ZÁVĚR TESTOVÁNÍ POPIS TESTOVACÍHO PROSTŘEDÍ VOLBA TESTŮ TABULKA S KURZY Test A1: Krátkodobá spotřeba paměti Test B1: Dlouhodobá spotřeba CPU a RAM Test C1: Velmi vysoký počet instrumentů Test D1: Zatížení serveru GRAFY CHARTDIRECTOR Test A2: Krátkodobá spotřeba CPU a RAM Test B2: Dlouhodobá spotřeba CPU a RAM Test C2: Velmi vysoký počet grafů Test D2: Zátěž serveru GRAFY SVG Test A3: Krátkodobá spotřeba CPU a RAM Test B3: Dlouhodobá spotřeba CPU a RAM Test C3: Velmi vysoký počet grafů

5 7.5.4 Test D3: Zátěž serveru JSON VS XML SOUHRNNÝ ZÁVĚR MĚŘENÍ ZÁVĚR ODKAZY NA POUŽITÉ ZDROJE

6 Abstrakt Název práce: Použitelnost dynamických webových technologií pro náročné aplikace pracující v reálném čase. Autor: Danila Privalenkov Katedra: Katedra softwarového inženýrství Vedoucí diplomové práce: RNDr. Michal Kopecký, Ph.D. vedoucího: Michal.Kopecky@mff.cuni.cz Abstrakt: Vývoj současných webových technologií umožňuje vytvářet plnohodnotné aplikace, na které jsme zvyklí z prostředí dnes používaných operačních systémů. Tyto aplikace na rozdíl od svých klasických implementací pracují ve webovém prohlížeči, a jsou tudíž nezávislé na konkrétní platformě. Tato diplomová práce analýzuje technologie pro tvorbu dynamických webových aplikací a možnost jejich využití pro tvorbu aplikací s vyššími nároky na vzájemnou komunikaci mezi uživatelským rozhraním a aplikačním serverem. Zaměřili jsme se na obchodní platformy, sloužící pro pozorování cen cenných papírů či komodit v reálném čase.v práci jsme navrhli a implementovali prototypová řešení minimálních požadavků na klientskou část obchodní platformy. U implementovaných částí jsme rovněž provedli jejich zátěžové testy. Klíčová slova: Real-timeové webové aplikace, AJAX, SVG, obchodování na finančních trzích. Abstract Title: Usability of dynamic web technologies for demanding real-time applications. Author: Danila Privalenkov Department: Department of Software Engineering Supervisor: RNDr. Michal Kopecký, Ph.D. Supervisor's Michal.Kopecky@mff.cuni.cz Abstract: Emergence of modern web technologies enables creation of fully featured applications to which we are used in the environment of commonly available operation systems. Web applications however work in a browser and therefore are platform independent. The thesis studies technologies for creation of dynamic web content and their usability for applications that require frequent and massive communication between user interface and application layers. In the thesis we have focused on trading platforms. We analyzed and implemented minimal requirements imposed on trading platforms as well as performed load tests of implemented solutions. Keywords: Real-time web applications, AJAX, SVG, financial markets, trading. 6

7 1 Úvod Internet jako médium se v posledních letech významně posunul kupředu. Výrazně patrný je vývoj od původních statických stránek k dnešním webovým aplikacím je skutečně výrazný. Na Internetu se každým okamžikem objevují nové a nové ukázky toho, jak lze klasické desktopové programy i implementovat pomocí nových internetových technologií. K nejznámějším příkladům patří GMail ( Meebo ( AJAX Windows ( a celá řada jiných. Na druhé straně existují dosud klasické aplikace vyžadujících mnohem častější komunikaci mezi jednotlivými vrstvami. Příkladem takových aplikací mohou být aplikace pro sledování zatížení elektrické sítě nebo aplikace pro příjem a zobrazování dat z finančních trhů v reálném čase. Na aplikaci takového typu pracoval autor v rámci softwarového projektu TiCKER [1]. Výsledkem tohoto projektu je plnohodnotná obchodní platforma napsaná v J2EE obsahující plnohodnotného klienta v Javě a webového administrátorského klienta s omezenou funkčností. Již při dokončování práce nad zmíněným projektem vyvstala otázka, zda by bylo možné implementovat ve webovém prohlížeči plnohodnotného klienta s využitím nástrojů pro tvorbu dynamických webových aplikací. V dalším textu se na tohoto zamýšleného webového klienta budeme odkazovat pojmem TiCKERWeb. Ve druhé kapitole uvedeme základní pojmy o finančních trzích a obchodování nezbytné pro pochopení problematiky diplomové práce, popíšeme základní požadavky účastníků finančních trhů na software sloužící k zobrazování tržních dat a určíme cíle práce. Třetí kapitola přibližuje pojem webová aplikace a diskutuje jejich výhody a nevýhody ve srovnání s klasickými desktopovými řešeními. Čtvrtá kapitola je věnována přehledu současných technologií pro tvorbu dynamického obsahu webový stránek. V této kapitole vybereme technologii, která bude nejvíce vyhovovat podmínkám a cílům definovaným ve druhé a třetí kapitole. V páté kapitole se budeme věnovat podrobnému studiu vybrané technologie. Šestá kapitola je zaměřena na podrobnou analýzu požadavků na TiCKERWeb a návrh a ukázkové implementace těchto požadavků. Sedmá kapitola je věnována měření a testování navržených řešení. Součástí práce je rovněž přiložené CD, jehož obsah tvoří kromě textu této práce následující dokumenty: Programátorská dokumentace Zdrojové kódy implementovaných ukázek a testů Postup instalace a konfigurace implementačních ukázek a testů Výsledky měření ve formátu MS Excel Použité zdroje Instalační soubory webového serveru Apache, databáze MySQL, PHP a testovaných prohlížeců i Aplikace napsané pro konkrétní OS a spuštěné tímto OS (oproti webovým aplikacím, které spouští prohlížeč a které běží v prohlížeči). Příkladem může sloužit MS Word, Mozilla Firefox, Adobe Photoshop atd. 7

8 2 Cíle práce V této kapitole zavedeme a stručně vysvětíme pojem finanční trh, popíšeme komponenty obchodní platformy (OP) a typickou činnost obchodníků, uvedeme základní části OP TiCKER a definujeme cíle diplomové práce. 2.1 Finanční trhy Finanční trh lze definovat jako mechanizmus umožňující lidem kupovat a prodávat (obchodovat) zboží při nízkých transakčních nákladech za cenu, která odráží hypotézu eficientních trhů. Pod finančním trhem je často myšleno místo, kde se se zbožím obchoduje jako např. akciové nebo komoditní burzy [2]. Velmi zjednodušeně si lze představit, že se finanční trh skládá z následujících komponent: Zboží (cokoliv, s čím se obchoduje, např. cenné papíry, komodity atd.) Trh (místo, kde se se zbožím obchoduje, např. burzy, elektronické trhy atd.) Finanční zprostředkovatelé (prostředníci, kteří zajišťují obchody) Obchodníci Obr. 1 - Zjednodušená představa trhu Jak je vidět na obrázku 1, jednotlivé části trhu si vyměňují informace zprávy. Obsah zpráv mohou tvořit obchodní příkazy, zpravodajské informace, kotace atd. V této diplomové práci nás budou zajímat především kotace a zpravodajské informace. Kotace představují aktuální cenu daného finančního instrumentu a jsou posílány v pravidelných časových intervalech zpravidla po 1 sekundě. Aktuální hodnota instrumentu, která přichází z trhu, se nazývá tick. Tick se skládá ze tří hodnot: TIME (čas), BID (cena nabídky), ASK (cena poptávky). Pro vyměňování zpráv potřebují účastníci trhu odpovídající nástroje. Dnes na trhu existuje celá řada společností, které tyto služby zajišťují prostřednictvím vlastních obchodních platforem. K nejznámějším patří Bloomberg ( Thomson Reuters ( a Dow Jones.( 8

9 2.2 Základní komponenty obchodní platformy Typická OP se skládá ze dvou základních komponent: Serverová část Klientská část Serverová část poskytuje klientům data, jež získává z různých trhů a zpravodajských agentur. Klientská část tato data zobrazuje v podobě různých tabulek, grafů a textových polí. Logika propojení zmíněných části je zachycena na obrázku 2: Obr. 2 Finanční platforma 2.3 Typická činnost obchodníků Typická činnost obchodníků se zpravidla skládá z pozorování kurzů komodit, sledování zpravodajských informací, textové či hlasové komunikace s jinými obchodníky a se svými brokery, z analýzy obchodních dat a samotného obchodování. Obchodníci preferují různý způsob zobrazování dat. Zatímco někteří preferují čísla v tabulkách, jiní upřednostňují grafy a další vyžadují od obchodní platformy oboje. Při analytické práci často potřebují přetahovat data z jedné tabulky do druhé a třídit tabulky podle jednotlivých sloupečků. Obchodníci vyžadují přehledné zobrazení informací (pro pohodlné sledování trhů), bezpečnost přenosu informací (pro zabezpečení svých transakcí a zaručení jistoty ve správnost pozorovaných dat) a robustnost používané obchodní platformy (pro plynulé a nerušené sledování trhů). Při provádění obchodu se počítá s tím, že konečná cena obchodu nebude odpovídat ceně zobrazené v obchodní platformě v okamžiku stisku tlačítka což je většinou ošetřeno ve smlouvě mezi obchodníkem a brokerem či bankou. Podobné situace nastávají zvláště na volatilním trhu. 9

10 2.4 Architektura OP TiCKER Obchodní platforma je zpravidla implementována pomocí třívrstvé architektury, kde jednotlivými vrstvami jsou: klientská aplikace, aplikační (webový) server a databáze. Na obrázku 3 je uvedena konceptuální architektura OP TiCKER i : Obr. 3 Konceptuální architektura OP TiCKER [1] Server se připojuje k jednomu případně více poskytovatelům dat. V případě TiCKERu byla data generována přes specifikované rozhraní ii. Tato data pak server převádí do interního formátu průběžně je ukládá do databáze a přeposílá všem klientům, kteří si tato data na serveru zaregistrovali. Podrobný popis jednotlivých komponent obchodní platformy bude uveden níže Architektura serveru Na obrázku 4 je uvedena realizace architektury serveru OP TiCKER: Obr. 4 Architektura serveru TiCKER [1] i Níže je uveden stručný přehled architektury obchodní platformy TiCKER a jejích jednotlivých součástí. Podrobnější popis lze najít v technické dokumentaci obchodní platformy TiCKER, kterou lze najít na přiloženém CD. ii Každý poskytovatel dat má definované své vlastní proprietární rozhraní. 10

11 Jednotlivé komponenty plní následující úlohy: Vstupní fronty pro poskytovatele dat: do těchto front se ukládají kotace a zprávy od data vendorů. Tato data jsou následně vybírána z front a zpracovávána (ukládána do databáze, posílána klientům). Vstupní fronty pro požadavky klientů: do těchto front se ukládají požadavky klientů. Tyto požadavky jsou následně vybírány z front a zpracovány. Cache: tento modul slouží pro cachování dat, která byla dříve vyžádána nějakým klientem a byla již načtena z databáze. Datový modul: tento modul představuje perzistentní vrstvu a slouží pro řešení všech dotazů nad databází. Při řešení požadavků klientů bere v potaz i data z cache. Scheduler: scheduler slouží pro spouštění pravidelných procesů jako např. kontrola exspirace licencí, pravidelné pročišťování cache aj. Request beans: tento modul hraje úlohu prostředníka mezi klienty, poskytovatelem dat a databází Architektura databáze Data v databázi se dají rozdělit do následujících kategorií: Zákaznická data (např. jméno, příjmení, kontakt atd.) Historická agregovaná data kurzů měn Finanční zprávy (např. zprávy o změnách úrokových sazeb, fúze a akvizice atd.) Databáze obsahuje kromě dat tyto komponenty: Scheduler pro vytváření agregovaných historických dat (sloužících pro zobrazení historických grafů) Modul pro opravu chybných dat Architektura databáze OP TiCKER je znázorněna na obrázku 5: 11

12 Obr. 5 Architektura databáze TiCKER [1] 2.5 Požadavky na TiCKERWeb a cíle diplomové práce Cílem diplomové práce je navržení způsobu implementace následujících minimálních požadavků na klientskou část TiCKERWebu, resp. Jakékoliv obchodní platformy: Plynulé zobrazování většího množství real-timeových dat v podobě tabulek a grafů. Bezpečný přenos informací mezi klientem a serverem. Možnost komunikace mezi uživateli finanční platformy. Kromě uvedených vlastností by klientská část měla být schopná následujících úkonů: Třídění obsahu tabulek podle jednotlivých hodnot Drag&Drop (tj. možnost kopírovat data z jedné tabulky do druhé táhnutím myše) Vyjmenované požadavky jsou minimálními požadavky jakékoliv OP. Zajímavá je otázka, nakolik jsou současné technologie pro tvorbu dynamického webového obsahu dostatečně vyspělé, aby s jejich pomocí bylo možné realizovat podobný druh aplikací, případně za jakou cenu a s jakými omezeními. Pro dosažení cíle si tato diplomová práce vytkla následující body: Prostudovat pojem webová aplikace. Porovnat možné výhody a nevýhody TiCKERWebu ve srovnání s klasickým desktopovým řešením. 12

13 Provést přehledovou studii současných technologií pro tvorbu dynamického webového obsahu, porovnat jejich nabízené možnosti vzhledem k požadavkům na aplikaci a zvolit vhodné nástroje pro implementaci požadovaných rysů. Podrobně prostudovat zvolené nástroje. Ukázat možnost implementace základních požadavků TiCKERWebu pomocí zvolených technologií a navrhnout (ve sporných případech i částečně implementovat) prototypová řešení. Otestovat prototypová řešení jednotlivých požadavků, provést zátěžové testy vybraných prohlížečů a serveru při použití prototypových implementací navržených v práci. Na základě navržených řešení a provedených měření učinit závěr o použitelnosti zvolených(é) technologií(ie) pro implementaci základních požadavků TiCKERWebu. 13

14 3 Webové aplikace V této kapitole se blíže podíváme na různé druhy webových aplikací. Uvedeme očekávané výhody a nevýhody jejich použití pro implementaci TiCKERWebu v porovnání s klasickými desktopovým řešením příjmu a zobrazování real-timeových dat z finančních trhů. 3.1 Klasické HTTP paradigma Než se začneme zabývat webovými aplikacemi, připomeneme, jak vypadá klasické HTTP paradigma. Princip paradigmatu je zobrazen na obrázku 6. Obr. 6 Klasické HTTP paradigma Klient (míněno prohlížeč) pošle serveru dotaz na stránku (HTML, PHP, ASP ). Server dotaz obdrží, zpracuje jej a pošle zpět výslednou stránku, která bude obsahovat HTML kód s případným JavaScriptem či CSS. Výsledný HTML kód je pak zpracován prohlížečem. Nevýhoda tohoto přístupu zřejmě spočívá ve skutečnosti, že pokud je zapotřebí obnovit nějakou část obsahu stránky, je nutné poslat nový dotaz, a po obdržení odpovědi se celá stránka musí překreslit. 3.2 Pojem webová aplikace, druhy webových aplikací Pojem webová aplikace se dá definovat jako aplikace, která je přístupná přes internetový prohlížeč a je umístěná na síti (Internetu nebo intranetu) [3]. Je to aplikace typu klient-server, kdy prohlížeč hraje úlohu tenkého klienta. Na rozdíl od statických HTML stránek, mezi nimiž se přechází pomocí hypertextových odkazů a jež zobrazují neměnitelný obsah, má uživatel v případě webových aplikací možnost ovlivnit obsah zobrazovaného dokumentu. Příklady webových aplikací jsou např. wikipedia, internetové obchody, on-line ové schránky apod. Existují dvě kategorie webových aplikací: klasické a tlusté, známé též pod anglickým názvem Rich Internet Appliactions, nebo zkráceně RIA. Klasické webové aplikace jsou postaveny na architektuře klient server a zobrazují obsah kompletně vygenerovaný na straně serveru. Jedná-li se například o kalkulačku, uživatel zadá do formuláře hodnoty a požadovanou operaci. Data se pošlou na server, který spočítá výsledek a vygeneruje uživateli novou stránku s výsledkem. Jinými slovy: klasické webové aplikace jsou dynamické aplikace, v nichž je dynamičnost vytvářena sledem jednotlivých statických stránek. Nevýhoda těchto aplikací spočívá jednak v neustálém zatěžování serveru a síťového spojení, jednak v nutnosti překreslovat celý zobrazovaný dokument při každém dotazu na server. Další slabinou klasických WA, která vyplývá ze samotné podstaty principu jejich fungování, je skutečnost, že veškerá interakce uživatele se stránkou musí procházet serverem, čímž se práce uživatele 14

15 značně zpomaluje. Navíc jsou dotazy posílané na server při kliknutí uživatele na odkaz synchronní, a tak blokují veškerou činnost. Tlusté webové aplikace se svým chováním a funkcionalitou již přibližují tradičním desktopovým aplikacím. RIA obvykle posílají prohlížeči funkcionalitu, kdežto data včetně stavu aplikace se ukládají na serveru. RIA běží uvnitř prohlížeče, případně v tzv. sandboxu i, a nepotřebují proto instalaci žádného softwaru na straně klienta. Ve srovnání s klasickými webovými aplikacemi tlusté webové aplikace vykonávají kód i na straně prohlížeče (např. mohou měnit rozměry okna prohlížeče nebo vykonávat nějaké výpočty apod.). Je těžké přesně vymezit pojem tlusté webové aplikace. U většiny těchto aplikací lze však vysledovat jednu společnou vlastnost zavádí mezi klientem a serverem prostřední vrstvu, často nazývanou klientův engine. Tento engine se obvykle stahuje na začátku práce s aplikací. V průběhu práce se už pak jen dotahují potřebná data. Prostřední vrstva je jakýmsi rozšířením prohlížeče, které na sebe často přebírá zodpovědnost za komunikaci se serverem a úpravu vzhledu dokumentu. Výhody tlustých webových aplikací jsou následující: Poskytují uživatelům mnohem interaktivnější zkušenost, než jakou může nabídnout čisté HTML (uživatel totiž nemusí čekat na odpověď ze serveru, protože řada úkolů se vykonává přímo na klientovi). Lepší vyrovnanost využití prostředků mezi klientem a serverem. Operace se provede na klientské straně, pokud je to možné, čímž se předejde zbytečnému zatížení sítě a serveru. Větší přiblížení se klasickým desktopovým aplikacím (především díky zvýšení interaktivity aplikace). Hlavními nedostatky tlustých webových aplikací, jež jsou webovým aplikacím obecně společné, jsou tyto: Komplikovanost vývoje ve srovnání se standardními webovými aplikacemi. Tlusté webové aplikace je složitější navrhovat, vyvíjet, testovat a podporovat. Narušení tradičního HTML paradigmatu. To říká, že webová aplikace je tvořena souborem stránek, přičemž přechod mezi těmito stránkami je možný jen pomocí znovunačtení stránky. Tlusté webové aplikace díky asynchronnímu chování nic takového nepředpokládají. Na jednu stranu je to zřejmá výhoda z hlediska uživatele. Na druhou stranu však v situaci, kdy nějaký skript na pozadí dotahuje potřebná data (která uživatel nemusí vůbec potřebovat), vzniká problém, jak měřit dobu odezvy, což je v podstatě jedním z nejdůležitějších faktorů při testování webových aplikací a vyhledání úzkých míst ve výkonu. Vyhledávače mají problém s indexací tlustých webových aplikací. Jejich obsah je totiž často generován dynamicky a závisí na činnosti uživatele. Dále v práci bude pod pojmem webová aplikace myšlena tlustá webová aplikace (dále jen WA). WA se většinou skládají z těchto komponent: i Bezpečnostní mechanizmus zaručující ochranu běhu programu. V sandboxu se častou spouštějí nedůvěryhodné programy nebo programy třetích stran. Obvykle poskytuje hostitelskému programu, jež v něm běží, omezenou sadu prostředků, které dotyčný program může využívat. 15

16 tenký klient pro zobrazení obsahu získaného ze serveru webový server pro zpracování a vykonání požadavků klienta databáze pro perzistentní ukládání dat skriptovací jazyk na straně klienta pro modifikaci stránek bez posílání dotazů na server. Tenkým klientem je prohlížeč (Firefox, Internet Explorer, Safari aj.), který umí zobrazovat standardní dokumenty (HTML, XHTML, XML a podobně). Webový server odpovídá na dotazy posílané tenkým klientem. Programovacími jazyky pro webový server jsou například PHP, ASP, Java aj. Tyto programovací jazyky umožňují generovat HTML stránky, které se pak posílají klientům, a taktéž přistupovat k databázi. Jistou dynamičnost statickým dokumentům dodávají různé skriptovací jazyky spouštěné přímo na klientovi. Jedná se např. o JavaScript, Flash a řadu jiných. Tyto skriptovací jazyky jsou schopny měnit strukturu dokumentu a také interagovat se serverem. 3.3 Výhody webových aplikací oproti desktopovým Každý osobní počítač má operační systém. Není překvapením, že u převážné většiny PC je použitá ta či ona verze OS Windows. Když se ovšem zamyslíme nad tím, co uživatel od osobního počítače potřebuje, pak to není operační systém, ale například textový editor, internetový prohlížeč, mp3 přehrávač nebo v našem případě OP. S vývojem aplikací pro konkrétní cílovou platformu souvisí řada problémů: distribuce nových verzí, podpora starých verzí, přechod na nové verze operačních systémů, nákladná IT podpora atd. S pokrokem webových technologií vznikla myšlenka vytvořit dynamické webové aplikace i, nezávislé na žádném operačním systému, jež by plně nahradily dnešní desktopová řešení. Paul Graham uvádí následující výhody WA oproti jejich desktopovým protějškům [4]: Nízké náklady na předání produktu. Společnost nemusí udržovat velké oddělení IT podpory. Zaměstnanci potřebují pouze prohlížeč a připojení k Internetu (na rozdíl od produktů poskytovaných společnostmi Bloomberg nebo Reuters, kdy zákazníci musí platit technickou podporu). WA mají nízké náklady na upgrade. U WA odpadává problém distribuce nových balíků a podpora starých verzí. Nové verze se k uživatelům dostávají ihned. WA jsou plně přenositelné na různé operační systémy, neboť jediné, co potřebují, je prohlížeč a připojení na Internet (IT infrastruktura bank a brokerských firem tak není závislá na tom, jaký operační systém zvolí poskytovatel dat). WA mají centrální úložiště dat. Přístup k WA není omezen na jedno místo spojené s konkrétním počítačem. Jinými slovy své oblíbené aplikace můžete mít všude (což je zvláště významné v porovnání s Bloomberg a Reuters, které nic podobného vůbec nenabízejí a jejichž terminály se jen těžko dají označit za přenositelné). WA zajišťují větší bezpečnost, jelikož zanesení virů je velice málo pravděpodobné. Neexistují žádné přímé hardwarové požadavky na klientské počítače. i Dokonce vznikl pojem Web 2.0, což je jakási představa o současném pojetí webu. Web 2.0 je něco jako návod, jak vytvářet webové stránky/aplikace, kdy hlavní prioritou je interaktivita a vysoká použitelnost. 16

17 Chyby v programu se mohou řešit okamžitě. Tento aspekt je velmi významný u tak kritických aplikací jako jsou obchodní platformy. WA umožňují detailně monitorovat uživatele těchto aplikací. Firma vyvíjecí tyto aplikace pak má možnost sledovat, jak, kým, kde a kdy jsou jejich aplikace využívány. Vývoj WA je rychlejší a náklady na vývoj jsou menší. 3.4 Problémy spojené s webovými aplikacemi WA však mají i své nedostatky. Jedním z hlavních problémů síťových aplikací je jejich zpoždění (latence). Uživatel od aplikace očekává, že kdykoliv klikne na nějaké tlačítko, reakce programu bude okamžitá. Zadrhávání a pomalé odezvy, které jsou pro Internet typické, vyvolávají u průměrného uživatele negativní pocity. V případě obchodních platforem je tento jev velmi významný, a musí být proto podrobně prostudován a otestován. Obchodníkova práce nemůže být přerušována pomalými odezvami používaného programu. Ty mohou být spojeny jednak se samotným fyzickým přenosem dat, ale ve větší míře s procesy kódování a dekódování na obou koncích komunikačního kanálu: požadovaný objekt musí být zakódován do nul a jedniček, zabalen do protokolu, přenesen a zpětně dekódován. Vzhledem k nespolehlivé povaze sítě se navíc pakety často musí posílat opakovaně. Proces přenosu informace je znázorněn na obrázku 7: Obr. 7 - Sekvenční diagram vzdáleného volání funkce [5]. Existují dvě možná řešení problému latence: přenést část zpracování na klienta nebo umožnit asynchronní volání procedur. První řešení problému představuje např. JavaScript (jež poskytuje programátorovi možnost vykonávat kód na straně prohlížeče). Druhé řešení je poněkud složitější. Podstata HTTP protokolu spočívá v posílání dotazů na server, který může reagovat jedním z následujících způsobů: Buďto pošle požadovaný dokument, nebo odpoví, že dokument neexistuje, nebo požádá klienta, aby využil cache. Klient může kontaktovat server, zatímco server klienta kontaktovat nemůže. Navíc je HTTP protokol bezestavový a server neví, zda aktuální dotaz pochází od stejného klienta nebo jiného, než dotaz předchozí. Tento jev se dá vyřešit použitím tzv. sessions, které umožňují takové programovací jazyky jako Java, PHP nebo.net. Sessions vyplňují mezeru v uschování stavu serveru. Nicméně asynchronní volání procedur předpokládá, že klient bude informován dvakrát: po jeho zahájení a po jeho vykonání. Přímočarý klasický HTTP protokol nic takového neumožňuje. Řešení spočívá v aplikování kombinace existujících technologií, JavaScriptu a XML i. Další nevýhodu WA představuje nekompatibilita prohlížečů se standardy. Mezi problematické prohlížeče z hlediska dodržování standardů patří dokonce i dnes nejrozšířenější Internet Explorer. Zmíněný problém kompatibility se standardy má nepříjemné dopady, kdy i Podrobněji se tomu věnujeme v kapitole 4. Technologie pro vývoj dynamických webových aplikací a 5. AJAX 17

18 se stejné věci v různých prohlížečích zobrazují odlišně, což komplikuje práci webových designérů. Je nutné poznamenat, že míra vystavenosti tomuto problému je u různých technologií odlišná i. 3.5 Má TiCKERWeb budoucnost? Porovnáme-li diskutované klady a zápory technologií pro implementaci TiCKERWebu, je těžké předem jednoznačně říci, zda je tato myšlenka perspektivní. Výhody jsou bezesporné, nicméně zmíněná úskalí mohou způsobit potíže a v daném stadiu práce není zatím jasné, zda jsou současné technologie pro tvorbu dynamického webového obsahu schopny pokrýt požadavky na náročné real-timeové aplikace vyžadující masivní komunikaci mezi klientem a serverem. Abychom mohli učinit kvalifikované závěry, obsahuje práce řadu testů výkonnosti navržených řešení pro vybrané prohlížeče. Popis testů a odpovídající měření jsou uvedena v kapitole 7 Testování. i Pro výrobce prohlížečů byl vytvořen tzv. Acid3 test [8], jež by jim měl pomoci docílit náležité podpory dnes existujících standardů. Pro tvůrce webových stránek existuje celá řada testů validujících obsah vytvářených dokumentů vůči standardům. 18

19 4 Technologie pro vývoj dynamických webových aplikací V této kapitole uvedeme přehled nejpoužívanějších technologií pro vývoj dynamických WA s převážným zaměřením na technologie pro klientskou část; provedeme jejich porovnání a zvolíme nejvhodnější technologii pro TiCKERWeb. I na straně serveru se dají použít různé technologie. Jedním z nejpopulárnějších serverových jazyků je PHP. PHP získalo popularitu díky tomu, že je open source, je podobné Javě nebo C++, je relativně pokročilé, rychle se v něm vyvíjejí aplikace a v neposlední řadě může běžet na různých platformách. K dalším používaným technologiím patří ASP od firmy Microsoft a JSP od firmy Sun Microsystems. Soustřeďme se však na technologie klientské části, které tvoří jeden z hlavních cílů práce. 4.1 Klientské technologie K dnes nejrozšířenějším klientským technologiím pro vývoj dynamického webového obsahu na trhu patří: Adobe Flash Java Plug-in Applet ActiveX AJAX DHTML Existují i jiné technologie, jako např. WebStart, JavaFX, Microsoft Silverlight aj., jejich podíl na trhu však není významný [6], proto se jimi nebudeme zabývat. Podívejme se zvlášť na výše uvedené technologie Adobe Flash Adobe Flash Player je standard sloužící pro tvorbu bohatého webového obsahu. Design, animace a uživatelské rozhraní jsou umístěny okamžitě na libovolných platformách a prohlížečích a poskytují uživatelům interaktivní zkušenost [7]. Flash představuje soubor technologií vyvinutých firmou Adobe Systems pro vytváření dynamického a interaktivního webového obsahu. Flash byl uveden na trh v roce 1996 a od té doby se stal populární metodou pro vytváření dynamického a interaktivního obsahu. Flash byl zpočátku používán především pro vytváření reklamy, vizuálních efektů, videí, apod. V posledních letech se však Flash začal používat i pro vytváření RIA. Flash může operovat s vektorovou a rastrovou grafikou a podporuje obousměrné audio a video streamování. Flash se začleňuje do HTML stránky jako externí objekt a pro jeho fungování je třeba mít na počítači nainstalovaný Adobe Flash Player. Pro práci s Flash se používá programovací jazyk ActionScript. ActionScript byl na počátku velmi omezeným skriptovacím jazykem, který poskytoval takové prostředky, jako jsou proměnné, podmínky, cykly plus jednoduché nástroje pro manipulaci s tlačítky a rámci (např. přehrát/zastavit video/zvuk, získat URL atd.). ActionScript vznikl ze sady jednoduchých příkazů, kterým se v prvních verzích Flash říkalo actions. Verze ActionScript 1.0 vznikla v roce ActionScript byl ovlivněn JavaScriptem a standardem ECMA. První verze ActionScriptu byla slabě typovaná. Teprve verze 2.0 přinesla možnost silně typové kontroly, 19

20 běhové kontroly typu a také klíčová slova class a extends. Předchozí verze ActionScriptu poskytovala prostředky pro objektově orientované programování, nicméně tyto prostředky byly omezené a vycházely z tzv. prototypové dědičnosti. Verze 2.0 přinášela téměř plnohodnotnou variantu objektového programování. Nově vytvořená objektová vrstva se však i nadále kompilovala do byte kódu verze 1.0, což zaručovalo použitelnost nových programů ve starých verzích Flash Playeru. Poslední verzí ActionScriptu je verze 3.0 uvedená v roce Ta umožnila nejen významný posun ve výkonnosti Flash aplikací, ale i mnohem lepší programovací model umožňující vývoj RIA. ActionScript 3.0 není kompatibilní s předchozími verzemi a poskytuje programátorovi mimo jiné následující možnosti: Typová kontrola v čase kompilace a běhu programu Podpora balíků, prostorů jmen a regulárních výrazů XML podpora Práce s událostmi založenou na standardu DOM Přímý programátorský přístup k obsahu zobrazovanému Flash aplikací za běhu Kompletní implementace ECMAScriptu 4. vydání Aktuální verze 9.0 Adobe Flash má širokou podporu XML (XMLConnector), webových služeb (WebServicesConnector), kreslení grafů a jiných komponent významných pro vývoj obchodních aplikací. Výhody Flash aplikací: Grafická nasycenost. Flash umožňuje vytvářet graficky nasycené aplikace, které se silně přibližují klasickým desktopovým programům. Obchodníci se tak nemusí zvykat na zhoršení grafického rozhraní. Vynikající přenositelnost. Vzhledem ke skutečnosti, že je Flash aplikace zobrazována Flash Playerem, a nikoliv prohlížečem, se aplikace budou zobrazovat ve všech prohlížečích stejně. Navíc, jak uvádí Adobe na svých webových stránkách, pokrývá Flash v současné době okolo 99% trhu [9]. Tento aspekt je v souladu s jedním z hlavních cílů TiCKERWebu je dosažení přenositelnosti mezi různými operačními systémy. Jednoduché vytvoření samostatné desktopové aplikace. Aplikaci lze jednoduše exportovat do samostatného programu a distribuovat jej na CD, což se dá využít pro offline prezentaci vytvořené OP. K nevýhodám Flash patří následující body: Neexistence fallback možnosti. Pro fungování Flash aplikace je nutné mít nainstalovaný Flash plug-in. Pokud uživatel nemá Flash plug-in, není schopen Flash aplikaci vůbec používat. Tato nevýhoda může být významná v bankách nebo brokerských firmách, kde velmi často panuje striktní bezpečnostní politika. Pomalé načítání. Ve srovnání s klasickými webovými stránkami se Flash aplikace načítají velmi pomalu. Přitom rychlost v obchodních aplikacích hraje velmi důležitou roli. Nic společného s HTML. Flash ve své podstatě nemá nic společného s HTML, a proto nemůže využít všech možností, které HTML poskytuje. Závislost na proprietární technologii. Flash není otevřeným standardem, což zpochybňuje myšlenku přechodu od klasických desktopových programů k WA. Na 20

21 jedné straně přestaneme být závislí na konkrétním operačním systému, na druhou stranu však budeme závislí na rozhodnutí výrobce Flash platformy, zda zahrne, či nezahrne ten či jiný operační systém do seznamu podporovaných OS Java Plug-in Aplet Java Plug-in Aplet je program napsaný v Javě, který se zabudovává do HTML stránky jako externí objekt. Při otevření stránky obsahující aplet se kód apletu stahuje na klientský počítač a spouští se prohlížečem v Java Virtual Machine [10]. JVM poskytuje model tzv. bezpečnostního sandboxu, kdy kód programu nemůže mít přístup k datům uloženým na lokálním disku. Tento kód se stahuje ze serveru na lokální disk, kde je spuštěn. Java aplet, stejně jako Flash aplikace, je zabudován do HTML stránky v podobě externího objektu. Java aplety se programují v Javě (nebo nějakém jiném jazyce, který je možné zkompilovat do Java byte kódu). Ke spuštění Java apletu je třeba mít prohlížeč a JVM. Výhody Java Apletu jsou následující: Velmi dobrá přenositelnost. Java Virtual Machine v současné době pokrývá 84% trhu [9]. Podpora silné programovací platformy. Java aplety mají veškeré výhody Javy. Proto programátoři Java apletů mohou vytvořit skutečně plnohodnotnou obchodní aplikaci. Bezpečnost. Java aplety běží uvnitř sandboxu a nemají přístup k lokálním datům na disku. I když v poslední době se tato omezení zmenšují zavedením digitálních podpisů, kdy uživatel má možnost povolit apletu tu či jinou činnost. Tento faktor je pro obchodní aplikace velmi významný. Nevýhody Java apletů jsou stejné jako v případě Flash aplikací, plus tyto další: Pomalá rychlost běhu. Programy napsané v Javě běží velmi pomalu ve srovnání s programy napsanými v C++. Rychlost je přitom u obchodních aplikací velmi důležitým faktorem. Omezený přístup k lokálním prostředkům. Původní Java sandbox zakazuje přístup k lokálním datům na disku, k síťovým prostředkům, k datům prohlížeče aj. Na jednu stranu je to zřejmá výhoda, na druhou stranu ovšem uživatel nemá možnost importovat vlastní data, nemůže ukládat data na lokální disk atd ActiveX ActiveX, technologie vyvinutá společností Microsoft, podobně jako Flash a Java Aplet vytváří externí objekty, které se zabudovávají do HTML dokumentu. ActiveX elementy se dají programovat v C++, Delphi nebo Visual Basicu. ActiveX aplety však mají více nevýhod než výhod. K největším slabinám ActiveX patří: Velmi špatná přenositelnost. ActiveX aplety fungují jen v Internet Exploreru. Přitom jedním z hlavních přínosů TiCKERWebu by měla být přenositelnost. Nízká bezpečnost. Bezpečnost ActiveX je založena výhradně na soudnosti uživatele. Programy ActiveX přicházejí s digitálním podpisem autora programu či kohokoliv jiného, kdo bude program propagovat. Pokud uživatel přijme rozhodnutí spustit škodlivý či chybně napsaný program ActiveX, může způsobit neomezený rozsah škod,. ActiveX aplety totiž neposkytují uživateli selektivní volbu toho, co apletu povolit a co ne. OP pracuje s velmi citlivými daty a otázka bezpečnosti je pro ní klíčovým faktorem. 21

22 Protože je princip fungování ActiveX podobný jako u předchozích technologií a navíc podíl ActiveX na trhu není významný, přejdeme ke zkoumání posledních dvou dominantních technologií pro tvorbu dynamických webových stránek DHTML DHTML (Dynamic HTML) je směsicí technologií, které se používají pro vytváření interaktivních a animovaných webových stránek. DHTML používá statické HTML, skriptovací jazyk na straně klienta (JavaScript), DOM (Document Object Model) a CSS [11]. DHTML by se dalo definovat jako sekvence změn deklarací stylů jednotlivých elementů pomocí JavaScriptu (či jiného skriptovacího jazyka na straně webového prohlížeče). Právě změna stylů elementů vytváří dynamičnost webové stránky, protože není nutné překreslovat celou stránku. Za DHTML stránku se dá v podstatě označit jakoukoliv stránku, kde se vzhled dokumentu mění po jeho kompletním natažení i. DHTML se často používá pro vytváření rolovacích menu, různých tlačítek apod. Jak uvádí Ross Shannon, k nevýhodám a slabým místům DHTML patří tyto [12]: Nekompatibilita prohlížečů a neexistence jednotlivého standardu. Každý prohlížeč implementoval stejné věci různě. Programátoři pak museli psát kód zvláště pro Internet Explorer a zvláště pro Mozillu. Kód DHTML dokumentů byl pak prokládán častými kontrolami verzí prohlížečů. Smíchávání procesní logiky a vizuální stránky. Vizuální stránka je napevno určena v JavaScript kódu, což ztěžuje údržbu webové aplikace. Budeme-li chtít upravit vzhled stránek, budeme muset upravovat JavaScript kód. Složitá údržba kódu. DHTML kód je obecně těžké udržovat. Spolupráce s jinými skripty. Používáme-li více DHTML skriptů nad jednou stránku, je třeba mít na paměti, že jednotlivé skripty mohou navzájem kolidovat kvůli konfliktům při používání společných názvů proměnných. Složité ladění a úprava. Ladění a úprava DHTML skriptů jsou velmi náročné. DHTML v poslední době vypadává z obliby programátorů [13] a je nahrazeno DOM programováním DOM programování Ve své podstatě DOM programování operuje se stejnými technologiemi jako DHTML, ale vychází z jiných předpokladů [12]: Progresivní zvětšení (progressive enhancement). Skript se má aplikovat pouze tehdy, pokud uživatelovo prostředí podporuje jeho technologie. Progresivní zvětšení nařizuje používat jen ty technologie, na které v dnešní době existují standardy. Před použitím těchto technologií se ještě provádí test, zda daný prohlížeč tyto technologie podporuje. Z toho vyplývá, že tato metoda zaručuje fungování skriptu jak v současných i Je třeba zdůraznit, že existuje rozdíl mezi pojmy DHTML stránky a dynamické webové stránky. Dynamické webové stránky jsou širším pojmem zahrnujícím veškeré případy webových stránek, jejichž obsah může být jiný pro různé uživatele. DHTML stránky jsou obecně podmnožinou dynamických webových stránek. 22

23 prohlížečích podporujících danou technologii, tak i v prohlížečích budoucích (za předpokladu, že technologie bude implementována dle standardu) i. Oddělení vizuální a skriptovací stránky. Vizuální stránka je zcela oddělena od skriptovací, což umožňuje mnohem snazší úpravu vizuální stránky, kdy není potřeba znalostí použitého skriptovacího jazyku. Vymezení tří vrstev stránky: struktura (HTML), prezentace (CSS), chování (JavaScript). Tyto tři vrstvy by měly být striktně odděleny, kdy se do HTML kódu nebude začleňovat JavaScript kód a vizuální komponenty nebudou definovány v JavaScriptu, ale v CSS souborech. Oddělení HTML a JavaScriptu se provádí použitím JavaScript listenerů AJAX AJAX (Asynchronous JavaScript and XML) je skupina technologií sloužící pro vytváření webových aplikací, jež komunikují se serverem na pozadí a nenarušují aktuální stav stránky [14]. AJAX je ve své podstatě je ve své podstatě konceptem zahrnujícím postupy, návody a doporučení, jak vytvářet dynamické WA s použitím JavaScriptu a několika dalších technologií (HTML, XML, DOM aj.). Hlavním přínosem AJAXu je výrazné zvýšení interaktivity webových stránek prostřednictvím asynchronní komunikace se serverem a změn vzhledu stránky za běhu bez nutnosti překreslovat celý obsah. Výhody AJAXu jsou následující: Absolutní přenositelnost. AJAX technologie jsou implementovány v každém prohlížeči. Podle statistik W3Schools JavaScript je povolen v 95% prohlížečů [15]. Navíc AJAX se skládá z technologií, které bezprostředně vycházejí z HTML. Otevřenost. AJAX je založen na open-source technologiích a standardech. Rozmanité nástroje pro vývoj. AJAX má celou řadu otevřených i komerčních frameworků podporovaných velkými firmami jako např. Google, IBM, AOL aj. Celá řada frameworků je velmi rychlá a svou rychlostí vítězí nad Flash [16]. AJAX má i několik nevýhod: Kompatibilita s prohlížeči. Ne všechny prohlížeče striktně dodržují standardy. Zvláště dnes nejrozšířenější prohlížeč Internet Explorer má nejhorší podporu standardů ze všech ostatních prohlížečů. Aby obchodní platforma byla skutečně přenositelná, tato otázka musí být velmi důkladně ošetřena. Bezpečnost. AJAX sám o sobě nevnáší žádné nové bezpečnostní slabiny. Ovšem vzhledem k tomu, že zatím neexistují žádné ustálené praktiky, špatné programování může způsobit bezpečnostní problémy. Testování bezpečnostní stránky aplikace je složitější vzhledem ke asynchronní povaze AJAXu [17]. Bezpečnost u obchodní platformy je jedním z nejkritičtějších faktorů Poznámka k terminologii AJAX a DHTML/DOM jsou dvě technologie/koncepty, které se navzájem nevylučují, ale naopak doplňují. DHTML/DOM se dá použít pro modifikaci stránky, aniž by se musel posílat dotaz na server. AJAX se dá použít v případech, kdy je nutné získávat informace ze serveru. i Opačnou metodou je elegantní degradace (graceful degradation), která říká, že je nutné psát skripty tak, aby je starší prohlížeče byly schopny správně zpracovat. 23

24 Vzhledem k tomu, že v terminologii k dané problematice neexistuje přesné vymezení pojmů AJAX a DHTML/DOM, tyto dva pojmy se často zaměňují. V poslední době existuje tendence rozumět pod pojmem AJAX jak jeho core funkcionalitu, tak i funkcionalitu DHTML/DOM. V této diplomové práci se budeme držet současné tendence, kdy DHTML/DOM budeme považovat za podmnožinu AJAXu. Pokud budeme chtít zkonkretizovat tu či jinou techniku, explicitně řekneme, zda se jedná o AJAX, či DHTML/DOM. 4.2 Sumární porovnání Nyní provedeme sumární porovnání technologií uvedených v předchozích kapitolách. Za porovnávací kritéria vezmeme tyto faktory: Napojení na HTML. Jak daná technologie navazuje na HTML. Grafická nasycenost. Jaké prostředky poskytuje daná technologie pro vytvoření graficky nasycených aplikací, které by se svým chováním a vzhledem přibližovaly ke klasickým desktopovým programům. Kód. Přehlednost kódu, jednoduchost ladění, existence frameworků. Napojení na data. Schopnost pracovat s XML a jinými prostředky pro přenos informací. Rozšiřitelnost. Rozšiřitelnost stávajících aplikací. Přenositelnost. Přenositelnost v rámci prohlížečů a jiných operačních systémů. Výkon Bezpečnost HTML Grafik Kód Data Rozšíř. Přen. Výkon Bezpeč. Flash Java Aplet ActiveX AJAX Tab. 1 - Sumární porovnání diskutovaných technologií Jak je vidět z tabulky 1, nejlépe ze všech technologií je na tom AJAX. K jeho přednostem ve srovnání s konkurencí patří jeho propojenost s HTML a skutečnost, že je postaven na zcela otevřených technologiích a standardech. Ve srovnávací tabulce můžeme vysledovat, že AJAX zaostává hlavně v oblasti grafické stránky, výkonu a bezpečnosti. Celá řada existujících AJAX aplikací jako např. Meebo, AjaxDesktop, GoogleMaps aj. však dokazují, že se tyto slabiny dají překonat. Naopak nejhůře dopadl ActiveX a to prakticky ve všech oblastech. Pro TiCKERWeb jsou klíčovými faktory bezpečnost a přenositelnost a jak jsme ukázali, ActiveX je zcela nepřenositelný a je založen na slabém bezpečnostním modelu. Prakticky nastejno jsou na tom Flash a Java Aplet, ale jejich největší nevýhodou je skutečnost, že jsou založeny na proprietárních technologiích, čímž by v případě jejich využití pro implementaci TiCKERWebu zpochybnily jeden z jeho hlavních přínosů. 24

25 Jako základní metodu pro vývoj TiCKERWebu použijeme AJAX. V dalším textu prozkoumáme jeho nejcitlivější oblasti: grafické prostředky, výkon a bezpečnost. 25

26 5 AJAX V této kapitole uvedeme stručný přehled historie vzniku AJAXu, probereme jeho základní principy fungování, stručně popíšeme jednotlivé komponenty a standardy, které jej tvoří. 5.1 Historie vzniku AJAXu Asynchronní volání serveru z prohlížeče bylo dostupné už v roce 1996, kdy společnost Microsoft vyvinula tzv. IFrame. IFrame je HTML element, který umožňuje vnořovat jeden HTML dokument do druhého. Velikost IFramu může být určena v obklopující HTML stránce, a tak obklopující stránka už může být zobrazena, mezitím co se obsah IFramu může dotahovat. V roce 2002 došlo po opadnutí boomu internetových portálů k prudkému zastavení vývoje internetových technologií. Předtím ale společnost Microsoft dokázala implementovat do svého prohlížeče Internet Exploreru 5 (dále IE 5) metodu XMLHttpRequest, kterou krátce nato implementovala i Mozilla. Nicméně širokého použití se tato funkce nedočkala. XMLHttpRequest (XHR) objekt poskytl něco, co předtím nebylo možné: schopnost dotahovat data poté, co stránka už byla načtena. Dříve jediná možnost, jak dostat nová data, spočívala v poslání nového dotazu na server a obnovení obsahu celé stránky. Jedněmi z prvních, kteří pochopili, jaké možnosti tato vlastnost poskytuje, byla společnost Google. Google na tomto základě vyvinul aplikace GMail a Google Maps, které ve byly ve své době vskutku revolučními. Jejich revolučnost spočívala v poskytování rozhraní uživatelům. které se velice přibližovalo rozhraním obyčejných desktopových programů, na něž byli uživatelé zvyklí (např. dotahování nových ů, přetahování map atd.). Člověkem, který poskytl tomuto konceptu jméno, byl J. J. Garrett ve své eseji z 18. února 2005 Ajax: A New Approach to Web Applications. Již před AJAXem existovaly techniky postupného dotahování dat, kdy se stránka obnovovala a nebylo třeba překreslovat její celý obsah. Příkladem může sloužit technika z roku 1999 spočívající v neuzavírání spojení se serverem, kdy prohlížeč neustále informoval uživatele, že stahování stránky není dokončeno. Jednalo se o tzv. progressively rendered animated GIF přístup, který se využil např. v Tato technika se používala také např. v různých deskových online hrách (šachy, dáma atd.). 1 Není zcela jednoduché zdůvodnit, proč se popularita AJAXu tak dramaticky zvýšila až v posledních letech, přestože byly jednotlivé technologie dostupné už celou řadu let. Je možné, že impulz k širokému použití AJAXu dal právě Google svojí implementací reálně použitelných aplikací GoogleMaps a GMail. Na druhou stranu můžeme předpokládat, že velká pozornost komunity vývojářů internetových aplikací, která je dnes AJAXu věnována, byla vyvolána spíše díky samotným vývojářům než uživatelům aplikací. AJAX poskytl vývojářům WA nový pohled na existující postupy a technologie, přičemž tento pohled otevřel nové, donedávna zcela nepochopitelné, možnosti. AJAX je více spojen nikoli s kódem, ale s funkcionalitou, ergonomií a rozhraním. Vývojáři AJAX aplikací se nemusí tolik soustřeďovat na zprovoznění kódu, ale na využití vytvářené aplikace. Velkou překážkou na cestě k širokému použití AJAXu byla válka prohlížečů, kdy společnosti Microsoft a Netscape bojovaly mezi sebou o nadvládu nad trhem. Jejich snahy o zlepšování vlastních produktů však měly překvapivě kontraproduktivní dopad na vývoj internetu, jelikož tyto společnosti nebraly ohled na standardy. Nekonzistence, které vznikaly, způsobovaly velkou nestabilitu technologického trhu, která nedávala vývojářům webových 26

27 aplikací jistotu. Výrazný posun ve vývoji dynamických webových aplikací nastal až po skončení války prohlížečů. Velkou podporu AJAXu zaručil Google, kdy samotné jméno tak velké a revoluční společnosti vzbuzovalo důvěru a jistotu. V únoru 2006 společnost IBM spolu se skupinou vedoucích firem v oblasti AJAXu založily open source iniciativu, jejímž cílem bylo podporovat propagaci AJAXu. Tato iniciativa nese jméno OpenAjax a v současnosti je podporována takovými firmami jako např. BEA Systems, Borland, the Eclipse Foundation, Google, IBM, Laszlo Systems, Mozilla, Oracle, Red Hat a Yahoo. 5.2 Základní princip fungování AJAXu Základní mechanismus fungování AJAXu spočívá v následujícím: klient posílá dotaz na server, server posílá dokument spolu s JavaScriptem, JavaScript pak posílá na server asynchronní dotazy. Jakmile server zpracuje asynchronní dotaz, pošle klientovi požadovaná data. Volající procedura je pak informována o přijetí odpovědi ze strany serveru. Server může poslat data v podobě XML nebo obyčejného textového řetězce. Toto asynchronní volání neblokuje klientskou aplikaci a nenarušuje tak tok práce uživatele. Důležitou vlastností komunikace mezi klientem a serverem v případě AJAXu je skutečnost, že server neposílá obsah, ale data. Obsah se zpravidla načte na začátku,a dále se nemění. Mění se pouze některé části stránky. To umožňuje snížit množství přenášených dat mezi klientem a serverem. Jak je vidět na obrázku 8, v případě klasického HTTP modelu je přenos dat mezi serverem a klientem v podstatě stejný po celou dobu session. Je to hlavně způsobeno neustálým přenosem stejného obsahu. V případě AJAXu (viz obrázek 9 a 10) je situace jiná. JavaScript totiž umožňuje měnit pouze část stránky (prostřednictvím DOM), proto stále překreslování stránky není nutné. Zpravidla se celé jádro klientské WA načte na začátku, dále se jen dotahují potřebná data. Tento aspekt je nesmírně důležitý. Právě díky tomuto fungování AJAX přibližuje WA aplikacím desktopovým. AJAX aplikace funguje spolu s uživatelem a nepřerušuje uživatelův tok práce. AJAX, myšleno XMLHttpRequestObject (dále jen XHR), je prostřední vrstvou mezi prohlížečem a serverem, která hraje roli komunikačního modulu. Obr. 8 Zátěž sítě v případě klasické WA [19] 27