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
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.
CÍLE PRÁCE............................................................................................................................................... 8 2.1
FINANČNÍ TRHY ..................................................................................................................................... 8
2.2
ZÁKLADNÍ KOMPONENTY OBCHODNÍ PLATFORMY ................................................................................ 9
2.3
TYPICKÁ ČINNOST OBCHODNÍKŮ ........................................................................................................... 9
2.4
ARCHITEKTURA OP TICKER.............................................................................................................. 10
DOM .................................................................................................................................................. 30
Kompatibilita XHR s prohlížeči..................................................................................................... 32
6 PROTOTYPOVÁ IMPLEMENTACE A STUDIUM ŘEŠENÍ JEDNOTLIVÝCH POŽADAVKŮ TICKERWEBU ................................................................................................................................................... 34
3
6.1 6.1.1
Definice požadavků na data........................................................................................................... 34
6.1.2
Mechanizmus posílání požadavků na server.................................................................................. 35
6.1.3
Formát dat ..................................................................................................................................... 36
6.1.4
Přetížení serveru při použití AJAXu .............................................................................................. 36
6.1.5
Mechanizmus komunikace mezi klientem a serverem .................................................................... 38
6.1.6
Způsob odběru dat ze serveru........................................................................................................ 41
6.1.7
Mechanizmus posílání zpráv od serveru klientovi ......................................................................... 44
6.2
7
PŘENOS DAT ........................................................................................................................................ 34
ODKAZY NA POUŽITÉ ZDROJE................................................................................................................... 82
5
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. E-mail vedoucího: [email protected] 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 e-mail: [email protected] 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
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é programyi implementovat pomocí nových internetových technologií. K nejznámějším příkladům patří GMail (www.gmail.com), Meebo (www.meebo.com), AJAX Windows (www.ajaxwindows.com) 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ů
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
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 (www.bloomberg.com) , Thomson Reuters (www.thomsonreuters.com) a Dow Jones.(www.dowjones.com). 8
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
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 TiCKERi:
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.
2.4.1 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
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í.
2.4.2 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
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
•
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
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 emailové 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
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. sandboxui, 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
•
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é aplikacei, 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
•
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 XMLi. 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
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
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.
4.1.1 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 2000. 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
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 2003. 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
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.
4.1.2 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.
4.1.3 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
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.
4.1.4 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.
4.1.5 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
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ů.
4.1.6 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ů.
4.1.7 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
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í.
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
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
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 emailů, 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 http://zesty.ca/chat/. 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
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
Obr. 9 – Zátěž sítě v případě aplikace vytvořené na bázi AJAXu [19]
Obr. 10 – Celkové zvýšení síťové zátěže v obou případech [19]
5.3 Klíčové komponenty AJAXu AJAX, jak již bylo řečeno, je nikoliv jednou technologií, ale celým souborem technologií a standardů: JavaScript, Cascading Style Sheets (CSS), Document Object Model (DOM) a XHR. Vzájemné propojení technologií je uvedeno na obrázku 11:
28
Obr. 11 – Komponenty AJAXu a jejich propojení
JavaScript je programovací jazyk, jehož kód se zabudovává do HTML stránky buď přímo nebo v podobě odkazu na externí soubor. JavaScript kód se interpretuje prohlížečem a poskytuje programátorovi možnosti s nim interagovat. JavaScript spojuje dohromady všechny ostatní komponenty AJAXu. Pomocí CSS se dají vytvářet znovu použitelné vizuální styly pro elementy webové stránky. Výhoda CSS spočívá ve vytváření konzistentního stylu v celém webu. AJAX umožňuje pomocí JavaScriptu interaktivně měnit CSS dokument. DOM je model popisující, jak se elementy HTML stránky jako např. formuláře, tlačítka, apod. vztahují k nejvyšší struktuře dokumentu. Prostřednictvím id elementu se k elementu dá přistupovat a manipulovat s ním. AJAX využívá změn DOM pro manipulaci s webovou stránkou. XHR umožňuje posílat dotazy na server na pozadí. Server zpravidla posílá data ve formátu XML, ale je možné použít i jiné formáty. Všechny čtyři používané technologie jsou implementovány ve většině dnes používaných prohlížečů. Podrobnějšímu popisu jednotlivých komponent AJAXu se budeme věnovat v následujících kapitolách.
5.4 CSS CSS je komponenta AJAXu zodpovědná za design. Poskytuje centralizovaný přístupový bod pro řízení vzhledu WA. CSS umožňuje definovat konzistentní vzhled prvků na všech webových stránkách. Kód CSS se zpravidla ukládá do jednoho souboru, což zvyšuje přehlednost kódu. Kromě definování vzhledu elementů, jako např. barvy, velikosti atd., CSS umožňuje definovat umístění elementů jak vůči ostatním elementům (relativní umístění), tak i vůči stránce jako celku (absolutní umístění).
29
CSS dokument je souhrn pravidel uložených v jednom, případně ve více souborech. Na tyto soubory webové stránky odkazují. Je sice možné definovat styly přímo uvnitř webové stránky, ale toto řešení se používá pouze v případech, kdy požadujeme ojedinělou změnu vzhledu konkrétního elementu. Obvyklejším řešením je definování stylů v jednom souboru. CSS pravidlo se skládá ze dvou částí: Selektor, který říká, na který element se bude dané pravidlo uplatňovat, a deklarace stylu, která popisuje, které vlastnosti element definovaný v selektoru dostane. V selektoru se dá použít jednak typ elementu, na nějž chceme aplikovat pravidlo (tzv. elementové selektory), jednak třída elementů. V následujícím případě se pravidlo aplikuje na elementy spadající do daného typu. Příklad CSS dokumentu: body { font-family: Verdana, Arial; font-size: 10pt } table { width: 500px; } Při konstrukci vzhledové struktury webové stránky se vychází ze dvou CSS modelů: Modelu vzhledového formátování (Visual Formatting Modeli) a Modelu boxů (Box Modelii). Model boxů říká, že každý HTML prvek lze považovat za box, a představuje specifikaci, která určuje, jak se krabice a její atributy navzájem pozičně ovlivňují. Jak se tyto krabice pak budou prohlížečem zobrazovat definuje Model vzhledového formatování.
5.5 DOM DOM je technologie umožňující manipulovat webovou stránkou programovým způsobem. V klasickém modelu HTML se vzhled stránky mění díky skutečnosti, že se prohlížeči posílá nový HTML dokument, i když bylo třeba pozměnit jen vzhled či obsah jediného elementu. DOM představuje programátorovi HTML stránku jako stromovou strukturu uloženou v globální proměnné document. Tato struktura odrážející strukturu HTML dokumentu začíná značkou a končí značkou . Ostatní značky jsou do nich vnořeny a mohou mít vlastní potomky. JavaScript umožňuje programátorovi s DOMem pracovat a manipulovat s jednotlivými elementy stránky. DOM je rozhraní nezávislé na platformě a na programovacím jazyku, poskytující skriptům možnost přistupovat a obnovovat obsah, strukturu a styl dokumentu. Klíčovou výhodou DOMu je možnost přistupovat k veškerému obsahu stránky a provádět četné obsahové změny v jednotlivých fragmentech. Celá řada úkonů manipulace s webovou stránkou je díky DOMu velice jednoduchá: např. přemístění části dokumentu z jednoho umístění pod jiného rodiče bez nutnosti rušit a znovu vytvářet celý obsah dokumentu, vyrábět a rušit jednotlivé elementy, organizovat a manipulovat s novými nebo již existujícími větvemi před vložením objektů zpět do stromu.
i
http://www.w3.org/TR/REC-CSS2/visuren.html
ii
http://www.w3.org/TR/REC-CSS2/box.html
30
Identifikace uzlů je jednouchá, známe-li jeho id. DOM poskytuje také nástroje pro vyhledání potomků daného elementu. Nyní popišme, jak práce s DOMem vypadá. Chceme-li měnit dokument, první krok, který je třeba provést, je identifikace elementu, jež má být modifikován. Každý element v DOMu je potomkem document. První způsob, jak element identifikovat, je postupně procházet stromem. Jedná se však o zdlouhavý proces, který navíc nemůže být snadno proveden programově, aniž bychom přesnou strukturu dokumentu předem znali. Druhý způsob spočívá v identifikaci elementu pomocí jeho id. Třetí možnost je vyhledat element na základě jeho typu. Ttuto variantu volíme v případě, kdy nemáme nad dokumentem velkou kontrolu. Při práci s dokumentem často potřebujeme vytvářet nové elementy, což DOM umožňuje. Navíc DOM dokáže přidávat a ubírat elementům styly. Toho lze využít, chceme-li nějaký element zviditelnit, nebo naopak skrýt. Velice užitečnou vlastností poskytovanou DOMem a podporovanou většinou dnes používaných prohlížečů je schopnost vložit do HTML dokumentu libovolný obsah. Jedná se o tzv. innerHTML. Do innerHTML se vkládá jakýkoliv text, který se pak jednoduše zapojí pod nějaký uzel. Jednotlivé funkce DOM API použijeme v implementaci jednotlivých aspektů funkčních celků a budou vysvětleny na místě. Proto je zde probírat nebudeme.
5.6 XmlHttpRequestObject (XHR) XHR je API, které využívá JavaScript pro přenos dat ze serveru a na server s použitím HTTP protokolu. XHR umožňuje, jak již bylo zmíněno výše, asynchronní komunikaci. XHR byl původně vyvinout společností Microsoft pro Outlook Web Access 2000. Tento objekt začal být dostupný v IE 5. Původní implementace se jmenovala XMLHTTP a byla dostupná přes VBScript a JScript. V roce 2002 byla do Mozilly verze 1.0 začleněna nativní verze XHR. Pak následovaly další prohlížeče: Safari, Konqueror, Opera aj. V roce 2006 byl vytvořen první pracovní draft W3, jehož cílem bylo sepsat základní vlastnosti, které by byly přístupné programátorům nezávisle na prohlížeči [20]. Současné problémy XHR spočívají v dosud trvající nekompatibilitě s jednotlivými prohlížeči. Jedním z nich je řešení otázky cachování. Firefox nedovoluje cachovat data, která prohlížeč dostal přes XHR. Tato možnost sice umožňuje uživateli prohlížet aktuální obsah stránky, nicméně na druhou stranu se zvětšuje objem přenášených dat. Internet Explorer vykazuje zcela opačný extrém. Jakmile dostane data prostřednictvím XHR, cachuje je a už je neobnovuje. Před existencí XHR se problém asynchronního volání procedur serveru řešil prostřednictvím ActiveX, Flash, LiveConnect aj. XHR funguje v různých prohlížečích odlišně. Microsoft Internet Explorer vytváří tento objekt jako objekt ActiveX, kdežto Firefox ho vytváří jako základní objekt JavaScriptu, což má samozřejmě dopad na kompatibilitu.
5.6.1 Metody XHR V tabulce 2 je uveden přehled metod, které XHR poskytuje: Název metody
Popis
abort()
Stornuje aktuální dotaz. 31
Název metody
Popis
getAllResponseHeaders()
Vrací všechny HTTP hlavičky jako řetězec.
getResponseHeader()
Vrací hodnotu HTTP hlavičky, která je specifikovaná v parametru této metody.
open()
Specifikuje různé atributy, které jsou zapotřebí pro vytvoření spojení se serverem jako např. typ spojení (synchronní/asynchronní), adresa serveru, GET/POST.
Používá se pro spouštění událostí při změně tohoto atributu.
readyState
Obsahuje hodnotu aktuálního stavu objektu (0: neinicializován, 1: nabíhá, 2: stažen, 3:interaktivní, 4: dovršen).
responseText
Odpověď serveru jako řetězec.
responseXML
Odpověď serveru jako XML.
Status
Obsahuje hodnotu statusu dotazu (např. 401 atd.).
statusText
Vrací hodnotu statusu dotazu, ale jako řetězec (např. Not Found). Tab. 3 – Atributy XHR objektu
5.6.3 Kompatibilita XHR s prohlížeči Jak již bylo řečeno, různé prohlížeče pracují s XHR odlišně. Internet Explorer má vlastní implementaci lišící se od implementace použité v prohlížeči Mozilla Firefox. Jedním z hlavních faktorů určujících význam a perspektivu TiCKERWebu byla schopnost fungování TiCKERWebu nezávisle na prostředí. Proto je při vývoji finální aplikace třeba věnovat náležitou pozornost otázkám kompatibility. Jednoduchým způsobem, jak kompatibilitu zajistit, je aplikace následujícího kódu při vytváření XHR:
32
var xmlhttp; //Když je dostupný objekt ActiveX, určitě používáme IE if (window.ActiveXObject){ xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); } else { //V opačném případě můžeme používat nativní JavaScript handler. xmlhttp = new XMLHttpRequest(); } Existuje ale i jiný způsob, jak tohoto docílit. Např.: // Vytvoříme boolean proměnnou pro kontrolu validní instance IE var xmlhttp = false; //Zkontrolujeme, jestli používá IE try { // Pokud je verze JavaScript > 5 xmlhttp = new ActiveXObject("Msxml2.XMLHTTP"); alert ("Pouzivame IE."); } catch (e) { // Pokud ne, používáme starší verzi ActiveX objektu try { //Pokud používáme IE xmlhttp = new ActiveXObject("Microsoft.XMLHTTP"); alert ("Pouzivate IE"); } catch (E) { //Zřejmě používáme jiný prohlížeč než IE xmlhttp = false; } } // Když používáme jiný prohlížeč než IE, vytvoříme JavaScript instanci objektu if (!xmlhttp && typeof XMLHttpRequest != 'undefined') { xmlhttp = new XMLHttpRequest(); alert ("Nepouzivate IE"); } První způsob je přehlednější, druhý je vhodnější pro objektové programování. Druhý způsob nejprve zkontroluje, zda uživatel používá novější verzi Internet Exploreru, což se zjistí pokusem vytvořit ActiveX objekt. Pokud se to nezdaří, skript se pokusí vytvořit starší verzi ActiveX objektu. Pokud se nepodaří ani to, víme, že uživatel má jiný prohlížeč než Internet Explorer, a vytvoříme standardní XHR objekt.
33
6 Prototypová implementace a studium řešení jednotlivých požadavků TiCKERWebu Tato kapitola představuje proof of concept realizace TiCKERWebu s využitím zvolené technologie – AJAXu. V této kapitole se budeme zabývat klíčovými požadavky TiCKERWebu a jejich podrobné analýze, budeme diskutovat potenciální problémy a následně možné způsoby řešení. . Ta z řešení, která to dle našeho názoru vyžadují, podrobíme v kapitole následující zátěžovým testům. Jednotlivé požadavky jsou probrány v samostatných oddílech. Implementované části kódu ilustrují řešení jednotlivých požadavků TiCKERWebu nebo vyzdvihují problematická místa.
6.1 Přenos dat Otázka přenosu dat a výběru vhodného formátu je jednou z klíčových otázek obchodních aplikací. V této části se budeme věnovat následujícím problémům: •
Formátu dat, který musí být zvolen tak, aby umožnil přenést veškerou informaci, ale zároveň minimalizoval síťové zatíženíi.
•
Mechanizmu získání dat ze serveru.
•
Zabezpečení datového přenosu.
6.1.1 Definice požadavků na data Data proudících v obchodních aplikacích můžeme rozdělit na dvě základní skupiny: •
Kotace
•
Zprávy
Formát kotace je tentoii: Instrument:Čas:Nabídka:Poptávka Například: EURUSD:01.05.2008.17.01.34:1,1244:1,1234 Formát zprávy je tento: Zdroj:Tělo Například: ADMIN: Systém je v provozu. Obchodování je zprovozněno. Nebo zpráva může vypadat následovně:
i
I když v současné době otázka síťového zatížení může mít větší význam v podstatě jen u mobilních zařízení. Je asi málo pravděpodobné, že by byl burzovní obchodník limitován datovým přenosem.
ii
Ve finální implementaci může být formát upraven podle definitivních byznys požadavků.
34
Reuters, 01.05.2008.17.34: FED rozhodl zvýšit úrokové sazby beze změn. FED rozhodl dle očekávání o zvýšení úrokových sazeb o 0,25 procentního bodu. Americké úrokové sazby tak dosáhly 3,5 %, přičemž úrokové sazby Evropské centrální banky jsou o 1,5 procentního bodu nižší. Kotace se dělí na real-timové tickyi a historické kotace. Real-timové ticky přicházejí každou sekundu a musí být zobrazeny uživateli ihned. Historické kotace slouží pro konstrukci historických grafů. Historické kotace jsou v naprosté většině případů agregovaná data a dělí se na minutové, 5minutové, 15minutové, 30minutové, hodinové, denní, měsíční a roční. Při vykreslování historických dat se může počítat se zpožděním. Při zobrazovaní realtimových ticků by ke zpoždění docházet nemělo.
6.1.2 Mechanizmus posílání požadavků na server Pro posílání požadavků na server se dají použít dvě metody: GET a POST. Jedná se o dvě standardní metody, které používáme, posíláme-li na server požadavek na zobrazení nové stránky. Nicméně v případě použití těchto dvou metod v AJAXu existují dva rozdíly: •
Místo celé stránky požadujeme často jen malou část stránky.
•
Při poslání požadavku na server uživatel neuvidí v adresovém řádku žádné změny (tj. použití metod GET nebo POST neodkryje proměnné, které se posílají na server, ani jejich hodnoty).
Nyní se zamyslíme nad otázkou, na základě čeho a pro jakou metodu (GET nebo POST) se máme rozhodnout při implementaci jednotlivých prvků TiCKERWebu (tabulky kurzů, grafy, chat). Metoda GET má omezení, co se týče velikosti dotazu (omezení je dáno velikostí HTTP adresyii). Metoda POST žádná omezení na velikost přenášených dat nemá. Pokud množství dat není omezujícím faktorem, musíme se podívat na to, k čemu v první řadě byly tyto metody vyvinuty - jelikož obě byly původně určeny pro zcela odlišné cíle. GET se používá pro načítání informací na předpokládané statické stránce. Prohlížeče proto informace získané metodou GET cachují. Pokud bude stejný dotaz použit znovu, prohlížeč vezme obsah z cache. Tímto způsobem se odezva metody GET optimalizuje. Důvod tohoto návrhu spočívá v tom, že GET data ze serveru pouze získává a nijak je na serveru nemodifikuje. Výsledek při opětovném volání metody GET by proto měl být stejný jako v případě prvního volání. Metoda POST by se měla používat v případech, kdy chceme informaci na serveru měnit, např. při ukládání dat o uživateli při jeho registraci nebo při ukládání nastavení. Z toho vyplývá, že volání dvou identických POST požadavků by mohlo vrátit různé výsledky. Proto při volání metody POST se dotaz vždy přeposílá na server a data se neberou z cache. Při implementaci chatu a ukládání uživatelských dat je tedy třeba použít metodu POST. V ostatních případech je třeba použít metodu GET. Pokud budeme očekávat, že se získávaná data budou na serveru měnit jako výsledek jiných operací (což se děje např. u historických dat v důsledku přírůstku aktuálních dat), je třeba dodat jako parametr dotazu časovou složku. Tím zajistíme změnu URL, a nově odesílané dotazy nepoužijí starší cachovaná data, která v případě real-timeových kotací už nejsou aktuální.
i
Aktuální hodnota obchodovaného instrumentu.
ii
Specifikace HTTP 1.1 protokolu neudává maximální velikost adresy, nicméně všechny prohlížeče a servery zavádějí omezení. Např. pro IE je to 2,048 znaků, Firefox přes 100,000 (a nejspíše i více), Opera 190,000 (a nejspíše i více), Apache cca 4,000, Microsoft Internet Information Server 16,384 [21].
35
6.1.3 Formát dat JavaScript může operovat s různými formáty odpovědí ze serveru: •
XML
•
JSON
•
HTML
•
Prostým textem
Podíváme se na jednotlivé formáty a vybereme z nich nejvhodnější pro přenos ticků v aplikaci TiCKERWeb. Výběr formátu dat je ovlivněn dvěma hlavními kritérii: způsobem zpracování dat pomocí JavaScriptu na straně klienta a velikostí datového toku, i když, jak již bylo řečeno, velikost datového toku není pro obchodníky omezujícím faktorem. XHR objekt byl navržen pro práci s XML. Hlavní výhodou XML formátu je jeho čitelnost pro uživatele i software. XML navíc existuje již celou řadu let a je obecně přijatelným formátem výměny dat mezi různými aplikacemi. Budeme-li například chtít importovat historická či realtimová data od nějakého poskytovatele nebo budeme-li chtít integrovat TiCKERWeb s jinými bankovními systémy, XML bude jistě přijatelnou formou pro programátory na obou stranách. Další výhodou XML je možnost využití existujících web služeb. K nevýhodám XML patří „neobratnost“, se kterou se musí potýkat JavaScript při parsování a vkládání dat do HTML stránky. Parsovací kód JavaScriptu bude v takovém případě zbytečně zdlouhavý. K nevýhodám XML formátu lze zařadit i velikost přenášených dat, která je oproti JSONu větší. Druhou možností je poslání požadavků v podobě fragmentu HTML kódu, který se vloží do stránky jednoduše zavoláním JavaScript funkce innerHTML. Výhodou tohoto způsobu předání dat je tedy jednoduchost. K nevýhodám přístupu patří komplikovanost (z programátorského hlediska) vytváření složitějších HTML dokumentů na straně serveru. Třetí možností přenosu dat je JSON (JavaScript Object Notation). Myšlenka JSONu spočívá v tom, že server posílá řetězec, na který se v klientské části volá metoda eval(), jež ho převádí na reálný JavaScript objekt. Hlavní výhodou JSONu je možnost přenášet data z jiných domén, než je doména serveru. Nevýhodou JSON je špatná čitelnost pro uživatele a snížení bezpečnosti kvůli použití metody eval(). Pokud máme server, z něhož očekáváme odpověď, pod vlastní kontrolou, není čeho se obávat. Posíláme-li však dotaz na server třetí strany, musíme vzít na vědomí, že mu v tento okamžik předáváme veškerou kontrolu nad naší aplikací. Obchodní aplikace manipulují s velmi citlivými daty, proto formát přenášených dat v podobě JSONu zamítneme. Největší výhodou prostého textu je jeho malá velikost. Nevýhodou je obtížnost práce s takovým formátem. Velmi důležitým aspektem při výběru formátu přenášených dat je pro nás otázka výkonu. V kaptiole 7.6 JSON vs XML jsme provedli testy dokazující, že výkonnost (parsování) JSONu a XML jsou prakticky stejné. Ze zmíněných bezpečnostních důvodů použijeme pro přenos údajů formát XML za cenu vyšších nároků na množství přenesených dat.
6.1.4 Přetížení serveru při použití AJAXu XHR může generovat v krátkém časovém úseku mnoho dotazů na server. V případě jedné tabulky se za 10 sekund vygeneruje 10 dotazů. Několik současně spuštěných obchodních platforem nebo více zobrazených tabulek tak velmi snadno může vyvolat desítky až stovky 36
dotazů na server za sekundu, což povede jak ke zvýšení zátěže sítě a serveru, tak i k možnému prodloužení časových intervalů mezi jednotlivými odpověďmi ze serveru. Nyní budeme diskutovat, jaké metody existují k řešení tohoto problému. Metoda první využívá zpoždění při vytváření požadavků na server. Lze ji použít např. při implementaci funkcionality dynamické nápovědy při vyhledávání nějakého instrumentu. Při zadávání textu do políčka nebude požadavek o nápovědu poslán na server ihned po posledním stisknutím klávesy, ale s mírnou časovou prodlevou. JavaScript poskytuje pro implementaci zmíněného řešení následující funkce: setTimeout() a clearTimeout(). První funkce spouští definované příkazy po uplynutí zadaného časového intervalu, druhá ukončuje vykonání těchto příkazů. setTimeout() po vykonání kódu, který dostává ve svém prvním parametru, končí. Uvádíme jednoduchý příklad implementace navrženého řešení: Zadejte text:: <script type="text/javascript"> var timer = null; //inicializace timeru var delay = 300; //v ms var input = document.getElementById('query'); var output = document.getElementById('where'); function runRequest() { output.innerHTML = input.value; input.focus(); // nastavení blikajícího kurzoru } function startTimer() { window.clearTimeout(timer); timer = window.setTimeout(runRequest, delay); // vynulování timeru } Kód po stisknutí klávesy spustí metodu startTimer(). Ta vynuluje jakékoliv předchozí timery a nastartuje timer nový, jenž po nastaveném čase – zde 300 ms – spustí metodu runRequest(). Druhá metoda pro omezení datového toku mezi klientem a serverem by mohla spočívat v neposílání dat v podobě XML dokumentu, ale např. pole, čímž by odpadla režie s XML značkami. Máme-li například následující pole:
37
new Array("EURUSD", "GBPUSD", "USDCHF"), new Array(1,1000, 1,1000, 1,1000); new Array(1,1010, 1,1010, 1,1010), new Array(13:19:01, 13:19:01, 13:19:03) Toto pole zabere 146 B (při kódování jeden znak na jeden byte) datového přenosu. Pokud stejná data pošleme v podobě XML dokumentu, dostaneme 246 B, což je 168%-ní procentní zvýšení oproti předchozímu formátu. Navíc v případě XML je třeba počítat s časem pro validaci vstupních dat a parsování XML: Ovšem vzhledem k již zmíněnému pozorování, které ukázalo, že zatížení sítě nehraje v obchodní platformě až tak významnou roli a že při použití polí budeme muset užít funkci eval(), která je velmi nevhodná z hlediska bezpečnosti, musíme tento způsob omezení datového toku odmítnout.
6.1.5 Mechanizmus komunikace mezi klientem a serverem V projektu TiCKER byla komunikace mezi klientem a serverem řešena pomocí technologie RMI. V případě TiCKERWebu bude tedy nutné vyřešit komunikaci mezi klientem a serverem a upravit rozhraní na straně serveru, protože původní implementace nepočítala s případným napojením webového prohlížeče. Při analýze různých možných řešení zabývajících se propojením současného serveru TiCKERu a nového webového klienta, byly uvažovány následující alternativy: •
JavaScript jako klient webových služeb. Vytvoření webových služeb na straně serveru, které bude využívat přímo JavaScript kód na straně klienta (JavaScript bude v tomto případě vystupovat jako klient webových služeb).
•
Mezivrstva v PHP. Vytvoření webových služeb na straně serveru, využívané prostředníkem v podobě PHP skriptu (PHP skript bude vystupovat jako klient webových služeb), který bude spojkou mezi JavaScript kódem a serverem. V tomto případě JavaScript bude volat PHP skript, který se postará o dodání dat ze serveru.
•
ESB. Vytvoření webových služeb na straně serveru, jenž bude JavaScript využívat prostřednictvím sběrnice ESB (Enterprise Service Bus, stručně ESB). V tomto případě bude uživatelem webových služeb ESB. Ten zpřístupní služby JavaScriptu ve formě HTTP.
Ve všech třech případech bude nutné změnit session beany na webové služby (změna anotace), což dle dokumentace Java EE [22] se nejeví jako technicky složitý problém. JavaScript na straně prohlížeče bude počítat s jedinou metodou či skriptem v závislosti na tom, jak bude vyřešeno propojení stávajícího serveru TiCKER s webovým rozhraním: 38
metodou getData(instrumentList). Předávaný parametr instrumentList reprezentuje seznam instrumentů, pro nějž data požadujeme. Ke každému instrumentu se jako atribut uvede: granularita a v případě granularity větší než tick rovněž časové rozpětí, pro které historická data požadujeme. Časové rozpětí bude nabývat dvou hodnot: all, nebo last. Hodnota all znamená, že požadujeme veškerá data pro daný graf či tabulku , hodnota last, že požadujeme jen poslední hodnotu. Metoda vrací XML obsahující kotace pro seznam instrumentů dodávaný jako parametr a také veškeré systémové a zpravodajské zprávy. Důvod tohoto přístupu bude podrobně vysvětlen v kapitole 6.1.6. Způsob odběru dat ze serveru. Nyní se podíváme na jednotlivá řešení zvlášť a navzájem je porovnáme.
JavaScript jako klient webových služeb Při implementaci tohoto způsobu řešení je zapotřebí vytvořit JavaScript knihovnu, která v sobě zapouzdří implementační rozdíly při parsování XML různými prohlížeči a poskytne rozhraní pro práci s webovými službami (např. pomocí SOAP protokolu). V tomto řešení je nutné obejít omezení JavaScriptu, které mu nedovoluje kontaktovat server nenáležící doméně daného skriptu. Např. pokud se objekt XHR nachází na adrese http://www.domena.cz/objekt, pak tento objekt může v prohlížečích Firefox, Netscape a Safari posílat data pouze v rámci domény domena.cz. Prohlížeče IE 5 a IE 6 umožňují posílat data i mimo doménu v případě, že to uživatel sám povolí. Existuje způsob, jak zprovoznit komunikaci XHR mimo jeho doménu i v rodině prohlížečů Mozilla. Je na to pouze potřeba použít digitálně podepsané skripty. Digitální podpisy ale nejsou kompatibilní s IE. Tento problém se v současnosti řeší dvěma způsoby: •
Aplikační proxy. Na serveru se umístí aplikace v libovolném programovacím jazyce, která bude odpovídat na dotazy XHR. Tato aplikace může volat libovolné webové služby a posílat data zpět klientovi.
•
Apache proxy. Server Apache má možnost nastavení transparentního přesměrování dotazu XHR z našeho serveru na cílový server.
Obě možnosti ve své podstatě spočívají v tom, že z pohledu webového prohlížeče data přicházejí z našeho serveru. Nejčistší způsob řešení problému je nastavení konfigurace našeho Apache serveru. Za tímto účelem musíme mít přístup ke konfiguračnímu souboru httpd.conf. Také je nutné mít aktivovaný Apache extension mod_proxy. Příklad nastavení Apache: # Přeposlat dotaz z našeho serveru na cizí server. ProxyPass /call/ http://api.cizi.server.cz/ # Vyřešit všechna přesměrování, která mohou být přeposlána z cizího serveru ProxyPassReverse /call/ http://api.cizi.server.cz/ Bezpečnost přenosu se zajistí protokolem HTTPS. Výhodou tohoto řešení propojení serveru TiCKER a webového klienta ve srovnání s ostatními dvěma je bezprostřední komunikace mezi klientem a serverem. K velkým nevýhodám řešení pomocí JavaScript Web Service klienta patří zejména tyto: •
Nutnost implementovat celou vrstvu webové služby.
39
•
První argument vede ke zvětšení velikosti JavaScript kódu, což zpomalí nabíhání aplikace.
•
Při změně rozhraní na straně serveru bude nutné měnit kód na straně klienta.
Mezivrstva v PHP (či jiném skriptovacím jazyce) Tato varianta, stejně jako varianta uvažující service bus jako prostředníka, vychází z myšlenky, že veškerá komunikační logika se bude nacházet v této vrstvě a na straně JavaScriptu se vyřeší jen zobrazování dat. Bude-li JavaScript chtít dostat aktuální data kurzů nebo historická data pro graf nějaké měny, zavolá se PHP skript, který jako parametry (přes GET metodu) dostane hodnoty zmíněné v kapitole 6.1.5 Mechanizmus komunikace mezi klientem a serverem. PHP skript zpracuje tyto hodnoty a na jejich základě zavolá patřičnou metodu, která přes rozhraní webových služeb obstará potřebná data z existujícího jádra serveru TiCKER. PHP pak tato data upraví do požadovaného formátu a přepošle je klientovi. Bezpečnost přenosu dat mezi JavaScriptem a PHP vyřešíme pomocí HTTPS protokolu (jenž se nastaví na web serveru). Hlavní výhodou tohoto řešení je, že má PHP plnou podporu protokolu SOAP (ať už nativní od verze PHP5 či v podobě NuSOAP knihovny). Nevýhodou tohoto řešení je prodloužení délky putování zpráv mezi klientem a serverem.
Enterprise service bus (ESB) Řešení pomocí enterprise service bus je shodné s řešením popsaným v předchozí kapitole. Úlohu prostředníka nyní hraje ESB. ESB je pojem popisující softwarovou vrstvu hrající úlohu prostředníka mezi aplikacemi, které mezi sebou komunikují prostřednictvím zpráv (tzv. servisně orientovaná architektura). Hlavní výhodou tohoto přístupu oproti dvěma předchozím řešením je relativní jednoduchost implementace. Toto řešení rovněž zmenšuje počet styčných bodů, což vede k jednoduššímu přizpůsobení změnám na jednotlivých koncích komunikačního kanálu. V ideálním případě by měl ESB zcela vyloučit přímou komunikaci mezi klientem a serverem. Toho lze dosáhnout přesným určením seznamu zpráv, které bude ESB přijímat a posílat. Jakmile ESB obdrží zprávu, přepošle ji cílové aplikaci. Z pohledu JavaScriptu se nic nemění. Bude i nadále prostřednictvím HTTP protokolu volat internetovou adresu, které pomocí GET předá potřebné parametry. Bezpečnost přenosu dat zajistí ESB. Je to otázka její konfigurace. K dalším výhodám tohoto přístupu patří následující: •
Řešení je založeno na standardech
•
Moderní softwarové produkty service bus představují robustní enterprise řešení
•
Řešení je spojeno více s konfigurací service busu než s programováním
•
Možnost soustředit se na vývoj byznys logiky a méně na integrační detaily (např. pokud konzument ztratí připojení, není nutné řešit problém dočasného odkládání dat, protože to zajistí ESB). ESB odstiňuje účastníky komunikace od chyb spojených s problémy v komunikaci mezi klientem a serverem.
•
ESB umožňuje inkrementální vývoj.
40
Nevýhoda tohoto řešení spočívá v nutnosti získat odpovídající know-how. K dalším problémům patří zvýšení nároků na hardware a nutnost udržovat o jednu komponentu více. Stejně jako v předchozím případě se prodlouží cesta putování zpráv mezi serverem TiCKER a webovým rozhraním. Příklady současných nejrozšířenějších ESB jsou Bea AquaLogic, Mule, ServiceMix a JBoss ESB.
Shrnutí a vzájemné porovnání variant Základní shrnutí a porovnání uvedených variant je uvedeno v tabulce 4. Jak je z ní vidět, nejlepší alternativou se jeví implementace mezivrstvy v PHP. Hlavními faktory pro tuto volbu je relativní jednoduchost implementace tohoto řešení a také relativně malé know-how. ESB je velmi dobrá varianta, ale její největší nevýhodou je již zmíněná nutnost získat další poměrně velké know-how. Tato varianta by připadala v úvahu, kdyby se z TiCKERu vyvinula velká komerční platforma. Varianta JSWS se jeví jako nejhorší a to především z důvodu dalšího nárůstu kódu a komplikace webového rozhraní. Řešení
Jednoduchost implementace
Jednoduchost údržby
Bezpečnost
Jednoduchost know-how
JSWS
-
-
+
++
PHP
++
+
+
++
ESB
+
+
+
--
Tab. 4 – Vzájemné porovnání tří variant
6.1.6 Způsob odběru dat ze serveru Než začneme definovat logiku odběru dat ze serveru, pozastavíme se nad problémem paralelního spouštění několika XHR. Dle specifikace protokolu HTTP verze 1.1 [23] by měl mít prohlížeč otevřena maximálně dvě perzistentní spojení se serverem. V reálu toto omezení vypadá tak, že jsme sice schopni vytvořit více než dva XHR, nicméně jen první dva z nich pošlou svůj požadavek na server. Ostatní se zařadí do fronty a budou čekat, dokud jeden z prvních dvou neuvolní spojení. Čím více paralelních připojení je, tím více dotazů můžeme poslat na server současně. IE 6 a Firefox 2 a starší toto doporučení dodržovaly. IE 8 a Firefox 3 už umožňují 6 paralelních perzistentních spojení se serverem. Nicméně i tak bychom měli při návrhu způsobu odběru dat ze serveru uvážit tento omezující faktor. U aplikací, jež nevyžadují masivní datovou komunikaci a které vytvářejí dotazy jen v závislosti na občasném vstupu od uživatele, bychom se pravděpodobně s takovým problémem nesetkali. Obchodní platforma je ovšem příkladem aplikace, která vyžaduje relativně masivní komunikaci. Existuje několik způsobů řešení: •
Seskupování více dotazů na server do jednoho
•
Nastavení timeoutů pro jednotlivé dotazy
•
„Chytřejší kódování“. Při posílání dotazů v závislosti na vstupu od uživatele neposíláme dotaz hned, ale až po uplynutí předem definovaného časového intervalu. 41
Tím bychom nevytvářeli zbytečně velké množství požadavků na server a ušetřili volná spojení. V obchodní platformě připadají v úvahu všechny tři varianty. První se použije při řešení datového přenosu kurzů. Druhá při každém volání serveru prostřednictvím XHR. Třetí možnost pak při implementaci funkcionality predikce zadávaného vstupu při vyhledávání kurzů měn, protože tato třetí varianta slouží právě pro úlohy tohoto druhu. Nyní popíšeme způsob, jimž se budou data pro jednotlivé prvky TiCKERWebu odebírat. Data, která se zobrazují v klientovi, se dají rozdělit do tří skupin: •
Tabulky s aktuálními kurzy instrumentů
•
Grafy s historickými kurzy instrumentů
•
Zprávy (zpravodajské, systémové i chatování)
Postup odběru dat ze serveru bude následující: •
Při prvním naběhnutí aplikace se otevře tabulka s kurzy a základní nabídka a vytvoří se seznam instrumentů, pro něž budeme chtít data odebírat. Každý prvek seznamu bude obsahovat: id elementu, požadovanou granularitu a atribut volume nabývající dvou hodnot: last a all (viz 6.1.5 mechanizmus komunikace mezi klientem a serverem). Při první inicializaci grafu se hodnota atributu nastaví na all (data pro graf TiCKERWeb ještě nemá), pro ticky na last (chceme aktuální hodnotu instrumentu), pro již inicializovaný graf opět na last (TiCKERWeb již má všechna potřebná data kromě aktuální hodnoty dotyčného instrumentu).
•
Vytvoří se globální XHR, který pošle na server požadavek na data pro instrumenty uvedené v seznamu.
•
Po obdržení odpovědi ze serveru se zmíněná tabulka s kurzy naplní daty.
•
Při kliknutí na libovolný kurz se zobrazí menu, z něhož bude možné otevřít graf daného instrumentu. Při kliknutí na položku graf se do seznamu instrumentů pro odběr dat přidá nový prvek s těmito atributy: id daného elementu, granularita a all. Dále se již před další aktualizací grafu ze seznamu vybere tento prvek a vloží se stejný jako vyjmutý s tím rozdílem, že poslední atribut bude nastaven na hodnotu last.
•
Při uzavření grafu či tabulky se ze seznamu odebíraných instrumentů odstraní dotyčné elementy.
Níže uvádíme prototyp kódu implementující popsaný algoritmus: // zde bude uložen náš XmlHttpRequestObject var xmlHttp = null; // zde budeme udržovat seznam instrumentů, pro které budeme chtít // odebírat data v dalším požadavku var instrumentList = new array(); // vytváří XHR function createXmlHttpRequestObject() { // nějaký kód }
42
// na základě instrumentList vybuduje požadavek na server function buildRequestList() { // nějaký kód } /* zpracovává odpověď ze serveru: updatuje tabulky, grafy, zobrazuje případné zprávy od administrátora atd. */ function handleServerResponse() { // nějaký kód } // metoda pro posílání požadavků na server o data function getData() { // pokud objekt jeste není, vytvoříme ho if (!xmlHttp) xmlHttp = createXmlHttpRequestObject(); // pokud je dotaz neincializován, nebo je dokončen, vytvoříme nový if (xmlHttp && (xmlHttp.readyState == 4 || xmlHttp.readyState == 0)) { xmlHttp.onreadystatechange = handleServerResponse; var url = buildRequestList(); xmlHttp.open("GET", url, true); xmlHttp.send(null); } // uspíme se na 1 sekundu (což je v obchodní platformě rozumný předpoklad) setTimeout("getData()", 1000); } Samotný seznam se implementuje jako struktura fronta (LIFO) uchovávající seznam objektů s výše zmíněnými atributyi. Struktura pole v JavaScriptu poskytuje metody push() a shift(), takže samotnou LIFO strukturu implementovat nemusíme. Pro vložení nového instrumentu do struktury bude metoda addInstrument(id,timeFrame,volume), pro odstranění metoda removeInstrument(id,timeFrame). Ze serveru se bude očekávat XML obsahující následující údaje: •
Aktuální čas
•
Seznam aktuálních kurzů instrumentů definovaných ve vstupních parametrech metody GET a hodnoty HIGH (nejvyšší cena pro daný časový interval), LOW (nejnižší cena pro daný časový interval), OPEN (cena otevření pro daný časový interval), CLOSE (cena uzavření pro daný časový interval)
•
Aktuální zpravodajské zprávy
i
JavaScript poskytuje možnost implementovat pole objektů. Existuje velmi zajímavá knihovna pro vytváření podobných struktur: DP_ObCollectionOrdered (http://www.depressedpress.com/Content/Development/JavaScript/Extensions/DP_ObCollectionOrdered/Index.c fm)
43
•
Případné systémové informace
Při zpracování odpovědi ze serveru se pro graf zjistí, anoda je obdržený timestamp pro daný graf novější, než dříve obdržená hodnota, a pokud ano, graf se obnoví Pro tabulku s kurzy nemusíme timestamp vyhodnocovat. Tabulka se obnoví v každém případě. Pro datový přenos tedy budeme v celé aplikaci používat pouze jeden XHR, čímž se zcela vyhneme zmíněnému omezení u prohlížečů co do počtu současně otevřených spojení se serverem. Druhé volné spojení budeme využívat pro druhý XHR, jenž bude sloužit pro realizaci grafických událostí jako např. predikce textu atd. Tímto využijeme oba kanály a zároveň se vyvarujeme nebezpečí, že by se naše aplikace začala chovat iracionálně z důvodu, že nějaký požadavek čeká na uvolnění komunikačního kanálu. By bylo jistě nežádoucí, kdyby po kliknutí uživatele na sloupeček tabulky pro její setřídění najednou přestala téco data ze serveru, protože požadavek na obnovení dat byl zařazen prohlížečem do jeho interní fronty.
6.1.7 Mechanizmus posílání zpráv od serveru klientovi Ve směru od serveru k JavaScript aplikaci neexistuje možnost přímého posílání zpráv. Stejně tak zde není přímá kontrola, jaké konkrétní účty jsou v daném okamžiku připojeny na server. Této funkcionality se však můžeme docílit tímto způsobem: Na straně serveru se pro každého zákazníka vytvoří fronta. Pokud server obdrží od zákazníka žádost o nová data, zkontroluje jeho frontu a pokud není prázdná, přidá nalezené zprávy do výsledné odpovědi . Klient po rozparsování přijatého XML musí nejprve zpracovávat systémové zprávy, protože mezi nimi může být např. zpráva o odhlášení se ze systému či jiná zpráva mající pro běh systému důležitý význam). Server rovněž potřebuje udržovat seznam aktuálně přihlášených zákazníků. Důvody jsou blíže rozvedeny v následujících kapitolách. Tento seznam můžeme zrealizovat takto: Jakmile se uživatel přihlásí do aplikace, jeho identifikační číslo se zapíše do tabulky, udržující informaci o aktuálně přihlášených zákaznících. Tato tabulka bude obsahovat kromě id zákazníka také čas posledního dotazu od daného klienta. Na serveru poběží úloha, která bude v pravidelných časových intervalech kontrolovat, zda čas posledního dotazu od klienta není starší než přednastavená hodnota. Pokud ano, session bude ukončena na time-out a uživatel bude odpojen. Přijde-li následně od daného uživatele žádost o data, bude zamítnuta s chybovým hlášením „session expired“, které se doplní do odesílané odpovědi.
6.2 Bezpečnost Bezpečnost obchodních platforem je jedním z klíčových faktorů, v jehož rámci je třeba se věnovat následujícím otázkám: •
Bezpečnost datového přenosu mezi serverem a klientem
•
Znemožnění provedení zákazníkem neoprávněných operací
•
Ochrana osobních údajů zákazníků
•
Ochrana proprietárního kódu TiCKERWebu
Nyní se budeme věnovat jednotlivým bodům podrobněji.
44
6.2.1 Bezpečnost datového přenosu mezi klientem a serverem Je nutné, aby data nemohla být cestou podvržena.Vlastní bezpečnostní model JavaScriptu řeší bezpečnost výhradně na straně klienta a už se nezabývá bezpečností komunikace mezi klientem a serverem. Proto je třeba komunikační bezpečnost mezi klientem a serverem zajistit jinak: Bezpečnost datového přenosu mezi klientem a serverem nám zajistí HTTPS protokol. Jedná se o nastavení konfigurace serveru. Dle pracovního draftu W3C [24] XHR nerozlišuje, zda posílá dotazy přes HTTP či HTTPS. K provedení kriticky důležitých operací jako např. vykonání obchodů, objednání si nových služeb atd. je nutné vyzvat uživatele k zadání hesla, případně mu poslat na mobilní telefon či email kód pro potvrzení transakce. To z hlediska obchodování nepředstavuje větší problém Pokud by obchodník do banky či svému brokerovi volal se žádostí o provedení obchodu, kurz se bude rovněž měnit. Z těchto důvodů žádná banka ani broker negarantuje vykonání příkazu za dohodnutou cenu. Nepředpokládá se, že poslání potvrzujícího kódu ze serveru na mobilní číslo či email výrazně zvýší prodlevu mezi žádostí zákazníka o obchod a jeho potvrzením.
6.2.2 Zamezení přístupu k neoprávněným zdrojům Každá obchodní aplikace musí vyřešit otázku zamezení neoprávněného využití zdrojů, které poskytuje - nikdo nesmí odebírat data, za která nezaplatil. V této formulaci jsou skryty dva možné scénáře neoprávněného odběru dat: •
Na jedno platné uživatelské jméno a heslo se nesmí současně připojit více než jeden uživatel.
•
I kdyby útočník zjistil adresy, na kterých jsou webové služby poskytovány (a tyto adresy jsou zjistitelné velmi snadno ze zdrojového kódu JavaScriptu), nesmí se na tyto adresy připojit a odebírat data.
Tyto dva problémy se dají vyřešit následujícím způsobem: Budeme mít dvě tabulky: LOGGED_IN_CUSTOMERS (customer_id, session_id, ip_address, is_banned,login_time,number_of_login_attempts,is_banned) a BANNED_CUSTOMERS (customer_id, session_id, ip_address). Při pokusu o přihlášení do systému se server podívá do tabulky LOGGED_IN_CUSTOMERS a zjistí, zda pro daný customer_id existuje v této tabulce záznam. Pokud tomu tak není, vloží do tabulky id uživatele, jeho IP adresu a id session a také nastaví flag is_banned na hodnotu null. Pokud záznam pro uživatele existuje, porovná, zda session_id a ip_address z tabulky LOGGED_IN_CUSTOMERS souhlasí s hodnotami dotazu. Pokud ano, server zpracuje požadavek od uživatele. Pokud ne, staré spojení musí být zakázáno. To se provede takto: Do tabulky BANNED_CUSTOMERS se vloží hodnoty tohoto zákazníka z tabulky LOGGED_IN_CUSTOMERS, staré hodnoty se přepíšou novými hodnotami a nastaví se flag is_banned na ‘X’. Pokud přijde požadavek ze staré session, server zjistí, že dané session id je v tabulce BANNED_CUSTOMERS a žádost o data zamítne. Pokud přijde požadavek z nové session, celý proces se opakuje. Toto řešení nemusí fungovat v případě, kdy útočník získá validní session id již přihlášeného zákazníka a bude sedět za stejným NATem jako vlastník ukradeného session id. Celý tento algoritmus je nutný z důvodu, že server neví, zda je stará session aktivní, či nikoliv. Z důvodu zamezení brute force útoků na účty uživatelů v tabulce LOGGED_IN_CUSTOMERS existuje sloupec number_of_login_attempts. Do tohoto sloupce se ukládá, kolik pokusů o
45
přihlášení uživatel provedl v rozpětí 1 minuty od času uloženého v políčku login_time. Tato hodnota se vyplňuje následujícím způsobem: Při pokusu o přihlášení se server podívá na hodnotu atributu login_time. Pokud je zde hodnota null, do políčka se zapíše čas přihlášení a do pole number_of_login_attempts se uloží hodnota 1. Pokud je v poli login_time nenulová hodnota, server ji porovná s hodnotou času daného přihlášení. Pokud současné přihlášení je v intervalu +-1 minuty od hodnoty uložené v login_time, čítač se zvětší o jedničku. Pokud je čítač větší než pevně definovaná konstanta, účet se dočasně zablokuje (nastaví se atribut is_banned, který má defaultně null hodnotu). Pokud čas nového připojení neleží v intervalu +-1 minuty od hodnoty uložené v login_time, čítač se vynuluje. Zmíněně řešení ovšem neošetřuje situaci, v níž by se útočníkovi podařilo získat validní session cookie. Útočník pak nemusí vstupovat do aplikace pomocí přihlašování. Toto je na serveru velmi složité ošetřit. Při zkoumání problému jsme dospěli k jedinému řešení: ukládat lokální IP adresu počítače a v případě, že pro existující id session přijde dotaz z jiné lokální IP adresy, odpojit tohoto zákazníka. Toto řešení samozřejmě nemusí samozřejmě řešit NAT. JavaScript neumí získat lokální adresu počítače. Toto omezení lze sice obejít zavoláním jiného programovacího jazyka uvnitř našeho JavaScript kódu (např. Javy), ne všechny prohlížeče to však umožňují. Proto je jediným způsobem, jak toho docílit, je zjistit údaj na straně serveru. Např. v PHP lze toto řešení realizovat takto: Musíme však konstatovat, že v naších testech tato metoda nevracela vždy skutečnou lokální adresu klientského počítače. Problémy většinou vznikají v situaci, kdy se uživatel nachází za proxy či NATem. Při implementaci session je nutné se držet obecných zásad [25]: •
Vytvořit dostatečně „náhodný a nepředvídatelný“ algoritmus pro generování id session
•
Odpojovat neaktivní sessiony
•
Poskytnout uživatelům možnost se odpojit od aplikace (nejen zavřít prohlížeč)
•
Kontrolovat IP adresu dotazu
•
Validovat vstupní data od uživatele
6.2.3 Ochrana osobních údajů zákazníků Tato kapitola se prolíná s předchozí s tím rozdílem, že celý problém nahlédneme nikoliv z pohledu provozovatele obchodní platformy, ale z pohledu uživatele. Výše popsané bezpečnostní prvky se aplikují i v tomto případě. Jediným zaručeně bezpečným způsobem, jak uživatele ochránit před zneužitím jeho konta, je posílání verifikačního emailu či SMS zprávy při provádění kriticky důležitých operací jako např. uskutečnění obchodu, převodu peněz, objednání služeb atd.
46
6.2.4 Ochrana proprietárního kódu JavaScript kód uložený ve stránce nelze schovat. Jediné, čeho lze docílit, je ztížit jeho čtení prostřednictvím obfuskátorů. Tento fakt zjednodušuje útočníkovi jeho práci, ale metody ochrany popsané v předchozích kapitolách by měly být postačující k bezpečnému fungování TiCKERWebu.
6.3 Implementace tabulky s kurzyi Jedním ze základních prvků pro zobrazování dat je tabulka. V tabulce s kurzy měn se většinou uvádějí následující hodnoty: •
BID/ASK
•
HIGH/LOW
•
OPEN/CLOSE
•
TIME
•
případně jiné hodnoty v závislosti na požadavcích zákazníků
V této práci jsme implementovali prototypovou ukázku tabulky s kurzy (viz obrázek 12).
Obr. 12 – Tabulka s kurzy implmentovaná v diplomové práci
Implementace je rozdělena do dvou souborů: •
index.html: stránka, na níž se zobrazuje samotná tabulka s kurzy
•
server.php: server, generující ticky.
Zdrojové kódy lze najít na přiloženém CD v adresáři implementace/tc. Názvy následujících podkapitol souhlasí s názvy odpovídajících zdrojových souborů.
index.html Princip implementace tabulky s kurzy je následující: Na HTML stránce pomocí div elementu označíme místo, kam chceme tabulku vložit. Při načítání stránky se zavolá metoda loadTicks(), která pošle na server požadavek o nová data a po přijetí odpovědi (zpracovává call back metoda handleResponse()) tato data zpracuje, vytvoří tabulku (metoda createTable()) a vloží ji do označeného div elementu (handleResponse()). Parsování vstupních dat a vytváření tabulky se provádí pomocí metod
i
Podrobnější informaci lze najít ve zdrojových souborech a programátorské dokumentaci.
47
poskytovaných API DOM. Na konci metody loadTicks() se zavolá JavaScript funkce setTimeout(), která zajistí spuštění celé sekvence znovu po uplynutí doby předané jako její parametr. Pro vytvoření XHR slouží metoda createXmlHttpRequestObject(), která jej vytváří nezávisle na použité prohlížeči. Nyní vysvětleme způsob, jakým se v této ukázce komunikuje se serverem prostřednictvím XHR. Pro každý nový dotaz se vytváří nový XHR. Však vzhledem k tomu, že se další objekt nevytvoří, dokud neskončí metoda, jež tento objekt používá, nemůže nastat situace, že by novější tick předběhl starší. XHR nemá vestavěný timeout, proto je třeba jej implementovat (není implementováno v této ukázce). Ten zruší dotaz v případě, že ze serveru nepřijde odpověď po zadaném intervalu. Implementace vypadá následovně: // vytvoříme ajaxRequest object var reqAbort = 0; ajaxRequest.send(); // zrušíme požadavek, pokud nepřijde odpověď po 5 sekundách var t imeoutId=setTimeout("requestTimeout();",5000); function requestTimeout(){ reqAbort = 1; ajaxRequest.abort(); } Pokud dotaz stihne přijít ve stanové době, v metodě, která zpracovává odpověď ze serveru, je nutné tento časovač zrušit: function handleResponse(xhr) { if (!reqAbort && ajaxRequest&&readyState == 4 && ajaxRequest.status == 200) { clearTimeout(timeoutId); responseOutput.innerHTML = xhr.responseText; } } Problém „předbíhání“ novějších odpovědí ze serveru před staršími se dá řešit i jinými způsoby: •
Mít pouze jeden globální XHR (viz kapitola 6.4.4 Implementace grafů pomocí SVG)
•
Uschování timestampu odpovědi na již zpracovaný dotaz a porovnání ho s timestampem nové odpovědi. Pokud je novější, „novou“ odpověď zahodit.
Zmíněné problémy jsou způsobeny síťovou latencí, jež byla diskutována v kapitole 3.4 Problémy spojené s webovými aplikacemi. Níže uvádíme univerzální metodu pro vytvoření XHR objektu, kterou budeme využívat ve této a ostatních prototypových implementačních ukázkách:
48
function createXmlHttpRequestObject() { var xmlHttp; // tohle by mělo fungovat pro všechny prohlížeče kromě IE6 try { xmlHttp = new XMLHttpRequest(); } catch(e) { // předpokládejme IE6 nebo starší var XmlHttpVersions = new Array("MSXML2.XMLHTTP.6.0", "MSXML2.XMLHTTP.5.0", "MSXML2.XMLHTTP.4.0", "MSXML2.XMLHTTP.3.0", "MSXML2.XMLHTTP", "Microsoft.XMLHTTP"); // zkoušíme všechno, dokud něco nebude fungovat for (var i=0; i<XmlHttpVersions.length && !xmlHttp; i++) { try { xmlHttp = new ActiveXObject(XmlHttpVersions[i]); } catch (e) {} } } // buď vrátíme objekt nebo vyhodíme chybu if (!xmlHttp) alert("Chyba při vytvářeni XHR objektu."); else return xmlHttp; }
server.php Server je implementován pomocí jediného skriptu – server.php. Jeho činnost spočívá v generování náhodných dat a posílání těchto dat klientovi v podobě XML. Na severu se dá nastavit počet vygenerovaných instrumentů.
6.4 Implementace real-timeových grafů Nyní se budeme zabývat možností implementace real-timeových grafů v prostředí JavaScriptu. V současné době existují dva způsoby implementace real-timeových grafů: •
Graf se vygeneruje na serveru a pošle se v podobě obrázku. Na klientovi se pak tento obrázek dá vložit tam, kde je zapotřebí, a pomocí AJAXu se dá obnovovat s libovolnou frekvencí bez nutností obnovovat celý obsah stránky.
•
Ze serveru se pošlou pouze data, graf se bude generovat na klientovi.
První možnost spočívá v implementaci vlastní či použití již existující knihovny pro generování grafů. K dnes nejpoužívanějším knihovnám (včetně komerčních) patří: 49
•
JpGraph [26]
•
ChartDirector [27]
•
DISLIN [28]
•
MayaVi [29]
•
ReportLab [30]
Druhá možnost spočívá v použití knihovny na straně prohlížeče, která by byla schopna přijímat a zobrazovat data. Jednou z možností je použití Flash nebo JavaApplet. Tyto alternativy jsme již probrali. Další možností je vektorová knihovna SVG. V dalších podkapitolách se budeme věnovat jednotlivým řešením podrobněji a rozebereme naše prototypové implementace těchto řešení.
6.4.1 Knihovny pro generování statických obrázků grafů Knihovny, které jsme uvedli v předchozí kapitole, se dělí na open source a komerční. Níže uvádíme přehled zmíněných knihoven a jejich stručný popis. JpGraph [26] je open source produkt napsaný v PHP. Jedná se o objektově orientovanou knihovnu podporující PHP verze 4.3.1 a vyšší. Pomocí níž se dají snadno vytvářet jak jednoduché, tak i velmi sofistikované grafy. Křivka učení je údajně plochá [26]. Bižší studium knihovny ukázalo, že knihovna nemá žádnou podporu finančních indikátorů a také neposkytuje širší škálu finančních grafů. ChartDirector [27] je komerční knihovna, podporující celou řadu programovacích jazyků (PHP, .NET, ASP, C++ aj.). ChartDirector má širokou podporu pro AJAX: •
Události generované myší
•
Na grafu se dají definovat vlastní místa pro vytváření událostí
•
Posouvání grafů
•
Zoomování grafů
Tato knihovna má širokou podporu pro finanční grafy a to: •
Celá řada vestavěných indikátorů technické analýzy (MA, Bollinger, MACD, Stochastic aj.)
•
Na každý graf se dá aplikovat neomezené množství technických indikátorů
•
Různé druhy finančních grafů (svíčky, bary, křivka)
Velkou nevýhodou této knihovny je nedostupnost zdrojového kódu a závislost na třetí straně, což narušuje jednu z hlavních myšlenek TiCKERWebu o použití open-source standardů a technologií. DISLIN [28] a MayaVi [29] slouží spíše pro vytváření statistických grafů a nemají přímou podporu finančních grafů. Pro účely OP se tedy nehodí. Tyto dvě knihovny uvádíme jen pro úplnost. ReportLab [30] obsahuje balíček pro generování grafů, ale kvalita grafů je ve srovnání s prvními dvěma knihovnami mnohem horší. Vzhledem k tomu, že potřebujeme vytvářet sofistikované grafy, tato knihovna nám nepřipadá vhodná. Níže uvádíme příklady finančních grafů (obrázky 12-15), které mohou být vytvořeny pomocí těchto knihoven (nepodařilo se najít ukázku pro MayaVi):
50
Obr. 13 – Ukázka grafu ChartDirector
Obr. 14 – Ukázka grafu JpGraph
51
Obr. 15 – Ukázka grafu DISLIN
Obr. 16 – Ukázka grafu ReportLab
V tabulce 5 uvádíme sumární porovnání uvedených knihoven: Knihovna
Open source
Podpora AJAXu
Finanční grafy
Vzhled
JpGraph
+
+
+
+
ChartDirector
--
++
++
++
DISLIN
+
+
--
-
MayaVi
+
-
--
++
+
--
--
--
ReportLab
Tab. 5 – Sumární porovnání knihoven pro generování statických grafů
Jak je z tabulky vidět, nejlepší volbou pro generování finančních grafů na straně serveru a posílání je klientům v podobě statického obrázku je ChartDirector (i za cenu použití proprietárního produktu). ChartDirector zcela zastiňuje své konkurenty ve všech oblastech. Její jedinou velkou nevýhodou je její uzavřenost. Kvalita finančních grafů generovaných ostatními knihovnami je však nepostačující, proto je naší volbou v této kategorii ChartDirector. 52
6.4.2 SVG SVG (Scalable Vector Graphics) je jazyk pro popis dvojdimenzionálních obrázků a grafických aplikací v XML. V současné době SVG verze 1.1 představuje doporučení W3C a tvoří jádro vývoje SVG [31]. SVG se vytváří na straně serveru a posílá se prohlížeči v podobě XML souboru. Prohlížeč tento soubor interpretuje a vytváří obrázek, který pak zobrazuje jako externí objekt (stejně jako v případě Flash či JavaApplet). Současné prohlížeče vyjímaje Internet Explorer mají zabudovanou nativní podporu formátu. Microsoft již dlouhou dobu prosazuje svůj vlastní formát – VML. V IE se SVG objekty dají zobrazovat po nainstalování plug-inu. Dnes nejrozšířenějším je Adobe SVG Viewer. Adobe ovšem oznámil ukončení podpory tohoto plug-inu v lednu 2009 [32]. SVG je svým rozsahem podobný Flash, ale to, co ho od Flash výrazně odlišuje, je podpora standardů. Stejně jako JavaScript, i SVG je ve své podstatě otevřenou webovou technologií a tím ho oproti jeho rivalovi zvýhodňuje. SVG zahrnuje podporu takových technologií, jakými jsou CSS, XHTML, XSL, DOM a XLink, což vytváří velmi silnou alianci pro tvorbu finančních grafů. Detailnější porovnání SVG a Flash lze najít na přiloženém CD. SVG je univerzální knihovna, která se nespecializuje na žádnou konkrétní oblast. To znamená, že je pomocí ní možné implementovat finanční grafy, ale za cenu podstatně většího úsilí než v případě hotových PHP knihoven (jako např. ChartDirector). Budeme muset vytvořit vlastní knihovnu pro generování finančních grafů. Na druhou stranu výhodou je vytvoření knihovny šitou přesně na míru obchodním požadavkům TiCKERWebu a nezávislost na třetí straně.
6.4.3 Implementace grafů pomocí ChartDirectori V kapitole 6.4.1 Knihovny pro generování statických obrázků grafů se ChartDirector ukázal jako nejlepší alternativa pro implementaci generování grafů na straně serveru. V této kapitole probereme ukázku, kterou jsme implementovali. Prototypová ukázka je uvedena na obrázku 17. Uživatel má možnost zadat frekvenci obnovování grafů. V políčku zbývající čas je uveden čas, který zbývá do obnovení grafů. Počet zobrazovaných grafů lze nastavit parametrem numCharts v souboru cdindex.php.
i
Podrobnější informaci lze najít ve zdrojových souborech a programátorské dokumentaci.
53
Obr. 17 – Prototypová implementace real-timeových grafů pomoci CD
Implementace je rozdělena do několika souborů: •
ChartDirector knihovna: Obsahuje dva dll soubory a dva PHP soubory.
•
cdindex.php: výchozí soubor, který se zobrazí uživateli.
•
chartgen.php: PHP skript generující obrázek grafu pomocí ChartDirector knihovny.
•
cdjcv.js: JavaScript, jenž je součástí balíku ChartDirector a který představuje obálku nad XHR.
Zdrojové kódy lze najít na přiloženém CD v adresáři implementace/cd. Názvy následujících podkapitol souhlasí s názvy odpovídajících zdrojových souborů. ChartDirector knihovna je implementována jako rozšíření PHP (jako např. PHP_MYSQL, PHP_SOAP aj.). Balík obsahuje dva dll soubory (chartdir.dll a phpchartdir520.dll)i a dva PHP soubory (FinanceChart.php a phpchartdir.php), které se musí pomocí direktivy include vložit do PHP skriptů, které budou graf vytvářet. cdindex.php je výchozí soubor, který se pošle prohlížeči. Tento se skládá ze dvou části: HTML kódu a JavaScriptu. V dokumentu se identifikuje místo pro vkládání obrázku (pomocí img elementu s patřičným id) a na toto místo se bude v pravidelných intervalech, které uživatel může zadat ručně, vkládat nový obrázek, vygenerovaný na serveru. JavaScript nám zaručí vkládání tohoto obrázku na specifikované místo. chartgen.php je náš PHP skript, který generuje obrázky grafů s využitím knihovny ChartDirector. V tomto skriptu se nadefinuje, jak graf má vypadat, jaká data se v něm mají zobrazit atd.
i
V současné době ChartDirector pro PHP podporuje tyto OS: Windows, Linux, FreeBSD, Solaris [33].
54
cdjcv.js je JavaScript, jenž je součástí ChartDirector a představuje obálku nad XHR. Obnovování obrázku v souboru cdindex.php se dá implementovat i bez využití tohoto JavaScriptu, ale použití cdjcv.js (konkrétně metody JsChartViewer.streamUpdate()) je výhodnější, jelikož nám poskytuje hotové vlastnosti, které bychom jinak museli implementovat sami. Tyto vlastnosti jsou: •
Dvojité buffrování. Místo přímého updatování img elementu zmíněná metoda vytváří skrytý obrázek, který se poté, co se obrázek zcela dotáhne, dá namísto předchozího.
•
Překrývající aktualizace. Metoda streamUpdate() řeší následující situaci. Pokud se nový dotaz vytvoří dříve, ne se stihne zpracovat předchozí dotaz, původní dotaz bude zrušen a na server se pošle nový dotaz (toto je standardní chování JavaScriptu). Pokud ale zpracování starého dotazu trvá delší dobu, než je doba mezi vytvořením dvou po sobě jdoucích dotazů, pak nebude zpracován žádný z nich a výsledkem bude neaktualizovaný graf. StreamUpdate() tento případ řeší tím, že nový dotaz bude zamítnout, pokud předchozí dotaz nebyl ještě zpracován.
•
Chybné načtení obrázku. Klasické chování JavaScriptu v případě chybného načtení obrázku je takové, že se místo obrázku zobrazí značka o nenačtení obrázku. Při použití označené metody takováto situace nenastane a místo nového obrázku zůstane starý, dokud nebude další obrázek správně načten.
•
Obejití cache prohlížeče a případných proxy. Prohlížeče a proxy cachují data, což může vést k situaci, kdy se graf přestane obnovovat. Aby se takovému stavu předešlo, každý nový dotaz dostává unikátní identifikátor.
cdindex.php Nejdříve vytvoříme tabulku. V jednom políčku tabulky poskytneme uživateli rozvrhovací seznam, ze kterého může vybrat frekvenci obnovování grafu. Výchozí hodnotou je 1 vteřina. V dalším políčku poskytneme uživateli přehled o čase zbývajícím do obnovení grafu. Ve třetím políčku budeme zobrazovat samotný graf. cdindex.php dále obsahuje JavaScript kód, který se skládá z jediné metody: updateChart(), jež v pravidelných intervalech obnovuje graf dané měny. Obnovování grafu je řešeno pomocí JavaScript metody setInterval() (a ne setTimeout()) z důvodu, že výše popsaný cdjcv.js podporuje jen tuto metodu. Rozdíl mezi setInterval() a setTimeout() spočívá ve skutečnosti, že setInterval() po svém zavolání neskončí a po uplynutí zadaného intervalu se spustí znovu, kdežto druhá metoda skončí.
chartgen.php Na začátku skriptu naloadujeme knihovnu ChartDirector, s níž pak dále pracujeme. Poté vytvoříme dvě pole. Do jednoho vložíme časy, do druhého vygenerujeme data. Obsah dat z těchto dvou polí se bude používat pro generování grafu. Na konci skriptu vytvoříme PNG soubor a pošleme ho prohlížeči PHP funkcí print().
6.4.4 Implementace grafů pomocí SVGi Prototypová ukázka je zachycena na obrázku 18. Počet grafů se dá nastavit pomocí proměnné numCharts v souboru index.php.
i Uvádíme jen zajímavé části kódu. Podrobnější informaci lze najít ve zdrojových souborech a programátorské dokumentaci. Naše implementace se inspirovala myšlenkami z [3].
55
Obr. 18 – Ukázka prototypové implementace real-timeových grafů pomocí SVG
Implementace pomocí SVG je rozdělena do následujících souborů: •
index.html: základní soubor, který zobrazuje vygenerovaný graf.
•
svgChartDoc.svg: SVG soubor, ve kterém je náš graf definován.
•
chartProcess.js: je skript, který dynamicky pomocí DOM mění SVG svgChartDoc.svg na základě dat, které obdrží ze serveru.
•
ajaxRequest.js: vytváří dotaz na server.
•
svgChart.php: generuje data pro SVG soubor.
Zdrojové kódy lze najít na přiloženém CD v adresáři implementace/svg. Názvy následujících podkapitol souhlasí s názvy odpovídajících zdrojových souborů.
index.html Toto je centrální bod této prototypové implementace. Na této stránce se zobrazuje graf, jenž je zabudován do HTML kódu pomocí značky embed. V této značce se pomocí atributu nastavuje velikost grafu.
svgChartDoc.svg svgChartDoc.svg je grafickým jádrem celé ukázky. Tento soubor je interpretován prohlížečem (případně plug-inem). Na začátku souboru definujeme velikost grafu v procentech a také JavaScript metodu, jež se spouští při první inicializaci grafu. Dále se
56
nalinkují dva JavaScripty (ajaxRequest.js a chartProcess.js), které budou naplňovat svg soubor daty. <svg width="100%" height="100%" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" onload="initialize(evt)"> <script type="text/ecmascript" xlink:href="ajaxRequest.js"/> <script type="text/ecmascript" xlink:href="chartProcess.js"/> Realtime Graf pomoci AJAXu a SVG
chartProcess.js Na počátku skriptu inicializujeme proměnné, které budeme používat ve zbývající části skriptu. Při načtení SVG souboru svgChartDoc.svg se spustí inicializační metoda initialize() z tohoto skriptu, která graf inicializuje. Inicializace grafu spočívá ve vytvoření os, popisků k souřadnicím na osách a nastavení časovače, který bude v pravidelných intervalech (1 sekunda) posílat dotaz na server a zobrazovat tick na grafu. SVG má pojem skupiny (group), jež představuje kontejner seskupující související grafické elementy. Charakteristikou skupiny je skutečnost, že potomci dědí vlastnosti skupiny. Tento rys se dá využít např. v situaci, kdy chceme, aby se celý obrázek (tj. včetně všech elementů ho tvořících) posunul nebo aby všechny elementy obrázku měly stejnou barvu atd. Inicializační metoda dále řeší velmi zajímavý problém: když inicializujeme souřadnice na osách, nevíme, jaké souřadnice budeme muset nakreslit (to zaleží na cenách, které dostaneme od poskytovatele dat). Z toho vyplývá, že nemůžeme přepočítat správně šířku a výšku jednotlivých popisků na osách. Problém se navíc komplikuje tím, že implementace SVG ve Firefoxu neumožňuje spočítat šířku a výšku textu, dokud se nezobrazí v prohlížeči. Řešením je zobrazit data nejprve bílým fontem (obecně barvou pozadí), následně spustit časovač, který přepočítá hodnoty šířky a výšky textových popisků a zobrazí je na osách již viditelnou barvou. Časovač se v našem případě spouští každých 500 milisekund. Pro vytváření osy a samotné křivky grafu používáme SVG element path (cesta). Atribut d, path data (data cesty), je pro naše účely velmi důležitý. Pomocí „pohybových“ příkazů se v něm definují souřadnice cesty mezi jejími jednotlivými body. Z pohybových příkazů jsme využili M (moveto) a L (lineto). Více informací o elementu path lze najít ve specifikaci SVG[34]. Všechny vytvořené metody pro manipulaci s SVG dokumentem definujícím zobrazovaný graf používají DOM.
AjaxRequest.js Tento skript slouží pro vytváření a posílání požadavku na server. Spouští se v případě, že používáme prohlížeč Firefox. Princip fungování skriptu je stejný jako v předchozích skriptech s tím rozdílem, že se vytváří jen jeden XHR. Skript jako vstupní parametr dostává URL serveru, na který se má posílat dotaz, a callback metodu.
57
Server.php Toto je poslední skript z dané ukázky. Jeho jediným účelem je generování dat pro SVG soubor. Skript jako vstupní parametr dostává dvě předchozí hodnoty. Na jejich základě vygeneruje hodnoty nové. Na konci skriptu se posílají HTTP hlavičky, které zabrání cachování dat na straně serveru (v předchozí ukázce to měla na starosti přímo knihovna ChartDirector).
6.5 Chati V této kapitole se podíváme na implementaci chatování, jež je jedním z požadavků na obchodní aplikaci. Kromě samotné implementace chatování se dotkneme ještě dvou aspektů: Implementace zmiňovaného modelu boxů a vytvoření posouvacího pole pomocí techniky DHTML. Ukázka implementace je zachycena na obrázku 19.
Obr. 19 - Chat
Implementace je rozdělena do několika souborů: •
index.php: základní stránka, na které se uživatel může přihlásit do chatu
•
indChat.php: základní stránka, na které se nachází samotné chatovací okno
•
chat.css: soubor stylů pro prvky chatovací aplikace
•
style.css: soubor stylů pro indChat.php a index.php
•
chat.js: hlavní JavaScript soubor obsahující komunikační a zobrazovací logiku
•
server.php: hlavní rozhraní pro klientskou část
•
classChat.php: chatovací logika na straně serveru
•
check.php: kontroluje správnost zadaného hesla
•
signout.php: odhlašuje uživatele z chatu
•
config.php: obsahuje konfigurační údaje pro ostatní serverové skripty.
V dalších podkapitolách rozebereme implementaci jednotlivých souborů a jejich význam. Zdrojové kódy lze najít na přiloženém CD v adresáři implementace/chat. Názvy následujících podkapitol souhlasí s názvy odpovídajících zdrojových souborů.
i Uvádíme jen zajímavé části kódu. Podrobnější informaci lze najít ve zdrojových souborech a programátorské dokumentaci. Naše implementace se částečně inspirovala myšlenkami z [3].
58
index.php Index.php je základní stránka, na které se uživatel může přihlásit do chatu. Vzhled stránky je založen na modelu boxů. Dokument index.php (a indChat.php) je složen z několika boxů určených příslušnými div elementy. Každý div element má přiřazenou třídu, jež je definována v CSS souboru style.css. Při pokusu o přihlášení se zavolá skript check.php.
check.php Tento skript se připojí do DB a zkontroluje, zda se v ní uživatel, jehož přihlašovací jméno a heslo dostal přes parametry metody GET, nachází. Pokud ano, přesměruje uživatele na stránku s chatem (indChat.php) a nastaví session proměnnou username. V opačném případě vrátí uživatele zpět na hlavní stránku.
indChat.php Toto je centrální bod celé ukázky. Na této stránce je implementováno několik věcí, které stojí za povšimnutí. Tou první je implementace posouvacího políčka, do kterého se vkládají zprávy. To je implementováno pomocí dvou vrstev, které spolu sousedí: Vnější msgsArea a vnitřní item, která se vkládá pomocí DOM metod v chat.js. Vnější vrstva má pevnou délku a má nastavenou vlastnost overflow. Ta zaručuje, že pokud vnitřní box, v daném případě item, přesáhne velikost vnější vrstvy, vznikne skrolovací lišta. Nad políčkem pro vkládání textu zprávy je vytvořen listener, který odchytává události spojené s tímto HTML elementem (onkeydown), a pokud je vyvolána stiskem klávesy enter, odešle napsaný text na server. Listener je definován v chat.js. JavaScriptovi se předává přihlašovací jméno zákazníka.
chat.js Požadavky na server se ukládají do fronty (FIFO). Při inicializaci se na sever pošle požadavek na zobrazení všech zpráv. Pokud je fronta prázdná, posílá se požadavek na nové zprávy. Pokud je fronta neprázdná, vybere se z ní jeden požadavek a ten se pošle na server. Před zobrazením zprávy se musí zkontrolovat příchozí XML, zda DB nebyla promazána a pokud ano, smažeme staré zprávy zobrazené v chatovacím okénku. Pro práci se vstupním XML se používají metody z API DOM.
server.php Tento skript je hlavním rozhraním pro klientskou část. Server poskytuje následující operace: •
opSendGet: uloží zprávu do DB a pošle nové zprávy
•
opDeleteGet: smaže z DB všechny zprávy
•
opGet: pošle nové zprávy z DB
Druh operace spolu s jejími parametry server dostává jako parametry metody POST. Při operaci sendGet server kromě samotné zprávy dostává id předchozí zprávy, kterou tento klient obdržel, a uživatelské jméno. Na konci zpracování skriptu se pošlou hlavičky, které zabrání cachování na straně prohlížeče a XML obsahující seznam zpráv novějších než vstupní id.
59
classChat.php V tomto skriptu je implementována veškerá logika chatu. Skript je řešen s použitím objektově orientovaného přístupu. Základem je třída Chat, která se skládá z několika metod: konstruktoru a destruktoru (jež vytváří, resp. ruší DB spojení) metody pro vložení nové zprávy do DB, metody pro dolování nových zpráv a metody pro promazání celé tabulky se zprávami.
errorHandler.php Tento skript obsahuje jedinou funkci errorHandler(), která se spouští v případě výskytu chyby. PHP má vlastní prostředky práce s chybami, proto pokud chceme, aby chyby ošetřovala naše, a nikoliv vestavěná funkce, je třeba ji namapovat pomocí metody set_error_handler().
signout.php Posledním skriptem je signout.php, který se volá, když se uživatel rozhodne odhlásit ze systému. Skript zruší session proměnnou a session a přesměruje uživatele na úvodní stránku.
6.6 Real-timeová kontrola vstupu a prediktivní nápověda Zaměřme se nyní na problém real-timeové kontroly vstupu od uživatele (RTKV) a prediktivní nápovědy (PN). Jedná se o podobné problémy, proto má smysl je probrat společně. RTKV spočívá v tom, že když uživatel zadá nějaký nesprávný údaj a zmáčkne tlačítko odeslat, nebude se překreslovat celá stránka, pouze se upraví její část. V případě PN se uživateli zobrazuje automatické doplňování textu na základě hodnot v DB. Např. při zadávání instrumentu se uživateli bude zobrazovat seznam instrumentů, jejíchž název odpovídá zadávanému textu. Realizace této funkcionality není těžká a všechny techniky nutné pro implementaci tohoto požadavku byly popsány v předchozích kapitoláchi. Jediný aspekt, kterého jsme se nedotkli, je problém spojený s rychlým přepínáním mezi jednotlivými políčky (RTKV) a rychlé psaní a mazání textu (PN). V obou případech může nastat situace, kdy XHR nestihne zpracovávat jednotlivé žádosti ať už z důvodu síťové latence nebo přetížení serveru. Existuje několik způsobu, jak tento problém řešit: •
Vkládat nové požadavky do fronty (jako v případě chatu). Nevýhoda tohoto řešení je ta, že aplikace nemusí být zcela interaktivní. Zdá se, že tuto vadu odstranit nejde. Výhodou je zachování pořadí událostí.
•
Zamítnutí zprávy. U PN je to možná i vhodné, u RTKV to však vhodné není.
•
Kombinace obou, kdy fronta sice neexistuje, ale zpráva se bude v pravidelných intervalech ptát, zda se objekt uvolnil.
•
Cachování. Možné jen v případě PN.
i
U RTKV se validační dotaz posílá při přepnutí na jiné políčko (událost onblur). U PN se dotaz posílá při ukončení mačkání klávesy (viz také kapitolu 6.1.6 Způsob odběru dat ze serveru). Samozřejmě bude ještě nutné dořešit technické detaily (např. jak zobrazovat validační chyby, ale to pro nás už není zajímavé).
60
6.7 Třídění tabulek a drag&drop Jedním z minimálních požadavků na front-end obchodní platformy je možnost třídění tabulek podle jednotlivých sloupců. Existuje celá řada hotových open-source JavaScript knihoven, které implementují tuto funkcionalitu. Jejich implementační ukázky uvádíme na přiloženém CD. Příklady knihoven pro třídění tabulek: •
Sortable [35]
•
SortedTables [36]
•
Matt Kruse [37]
Příklady knihoven pro drag&drop (ukázky nejsou na CD): •
Scripaculous [38]
•
Isocra [39]
•
DHX [40]
Je třeba si uvědomit, že zmiňované knihovny jsou primárně určeny pro statické tabulky, nikoliv tabulky s dynamicky se měnícím obsahem. Řešením bude přetřídit tabulku před jejím vykreslením na obrazovku. Tabulku přetřídíme podle sloupečku, podle něhož uživatel rozhodl třídit. Pořadové číslo sloupečku si uložíme do proměnné. Defaultně bude tabulka přetříděna podle prvního sloupečku (ve kterém se zpravidla zobrazuje kotovaný instrument).
6.8 Spouštění trigerů při dosažení limitů Uschovávání hodnot limitů pro instrumenty, které se mají sledovat, se provede jednoduše uložením těchto hodnot do proměnné. Budeme tedy udržovat nejlépe pole struktur, kdy struktura bude obsahovat hodnoty instrumentId, limitLow, limitHigh. Zadané hodnoty se musí uložit i na server, protože v případě odhlášení uživatele a jeho nového přihlášení se tato informace ztratí. Nebylo by přitom příliš praktické, aby uživatel musel pokaždé tyto hodnoty vyplňovat.
6.9 Závěr V této kapitole jsme prostudovali problematiku formátu pro přenos real-timeových dat, mechanizmus komunikace se serverem a zabezpečení datového přenosu. Naše úvahy ukázaly, že nejvhodnějším formátem pro nás bude XML (i za cenu jeho větších nároků na velikost přenášených dat). Navrhli jsme tři způsoby propojení stávajícího serveru TiCKER a nového webového klienta. Nejvhodnějším bude vytvoření mezivrstvy v podobě PHP či ESB. Konkrétní volba bude záviset na podrobnější analýze při dalším vývoji projektu TiCKER. Navrhli jsme způsob posílání zpráv směrem od serveru, kdy se na serveru pro každého přihlášeného klienta vytvoří fronta pro zprávy. Při doručení žádosti klienta o data server zkontroluje, zda je klientova fronta neprázdná a pokud je neprázdná, vybere z ni zprávy a přibalí je do odpovědi spolu s požadovanými daty. Poukázali jsme na omezení počtu současně otevřených perzistentních spojení se serverem, které zavádějí dnešní prohlížeče (dle specifikace protokolu HTTP 1.1). Jako řešení tohoto problému jsme navrhli vytváření pouze jednoho datového dotazu pro všechny prvky GUI, v nichž se data zobrazují. 61
Zabývali jsme se problematikou bezpečnosti TiCKERWebu. Bezpečnost datového přenosu nám zajistí protokol HTTPS. Bezpečnost aplikace z hlediska zamezení neoprávněného odběru dat se vyřeší algoritmy navrženými v příslušných kapitolách. Bezpečnost transakcí zajistit čistě programátorsky není možné. Jediná relativně bezpečná cesta je potvrzení kritických transakcí prostřednictvím emailu či SMS. Ochrana proprietárního kódu klienta však není možná prakticky vůbec (nepočítáme-li použití obfuskátorů). Navrhli jsme a implementovali pomocí AJAXu tabulku s kurzy měn, real-timeové grafy (s použitím ChartDirector a SVG) a chat. Rozebrali jsme možnosti implementace funkcionality drag&drop, třídění tabulek podle jednotlivých sloupečků a spouštění trigerů při dosažení kurzem instrumentu předem stanoveného limitu. Ukázali jsme, že pomocí zvolené technologie AJAX lze implementovat požadavky na klientskou část OP definované v kapitole 2.5 Požadavky na TiCKERWeb a cíle diplomové práce. Nezodpovězenou otázkou zůstává otázka výkonu (klientské i serverové části). Tomu se bude věnovat následující kapitola.
62
7 Testování Klíčovým cílem diplomové práce je určení, zda vybraná webová technologie je použitelná pro aplikace vyžadující masivní datovou komunikaci mezi klientem a serverem, tj. splňuje minimální požadavky definované v kapitole 2.5 Požadavky na TiCKERWeb a cíle diplomové práce. Dosud nezodpovězenou otázkou je otázka plynulého zobrazování většího množství real-timových dat v podobě tabulek a grafů. Ostatní minimální požadavky jsme otestovali implementačně. V některých jasných případech jsme se omezili pouze na návrh. Podrobné výsledky měření lze najít na přiloženém CD v adresáři mereni. Názvy jednotlivých souborů obsahujících výsledky měření budou uvedeny v následujících kapitolách. Na CD v adresáři implementace lze najít návod na instalaci a konfiguraci popisovaných testů. V adresáři Instalace prohlizecu, PHP, MySQL, Apache lze najít veškeré potřebné instalační soubory pro vytvoření testovacího prostředí.
7.1 Popis testovacího prostředí Konfigurace serveru: •
Intel Core2Duo 2.40 GHz
•
2GB RAM
•
Windows XP Pro
•
Apache 2.2.9 (Win32)
•
PHP 5.2.5
Konfigurace klienta: viz konfigurace serveru. Testované prohlížeče: •
Internet Explorer 6.0, 7.0
•
Mozilla Firefox 2.0, 3.0
•
Opera 9.6
•
Google Chrome 0.3
Testovací nástroje: •
Firebug 1.2.1
•
Apache JMeter 2.3.2
•
MS Performance Monitor
7.2 Volba testů Abychom mohli na otázku položenou na začátku kapitoly fundovaně odpovědět, potřebujeme zvolit a provést vypovídající zátěžové testy. Testy by se měly převážně zaměřit na paměťové a procesorové nároky vykonávaného kódu v závislosti na množství přenášených dat a frekvenci dotazů. Dále by měla otestovat zátěž serveru při nárůstu počtu připojení. Ke komponentám TiCKERWebu, které mohou způsobit vytížení aplikace a serveru, patří tabulka s kurzy a grafy. Můžeme bezpečně předpokládat, že třídění tabulek, jež většinou obsahují jen několik řádek, drag&drop ani limitní trigery nevyžadují velké nároky na paměť 63
a procesor. Posílání zpráv nemusíme testovat zvlášť, protože jak bylo popsáno v kapitole 6.1.6 Způsob odběru dat ze serveru, zprávy se budou přenášet spolu s kotacemi.
7.3 Tabulka s kurzy 7.3.1 Test A1: Krátkodobá spotřeba paměti Popis testu a postupu měření Cílem testu bylo změřit závislost mezi počtem odebíraných instrumentů a paměťovými nároky prohlížeče. Uvážili jsme sedm případů: 0 instrumentů (prohlížeč zobrazuje prázdnou stránku) a dále 10, 20, 30, 40, 50 a 100 instrumentů. Množství testovaných instrumentů by mělo odpovídat reálnému počtu instrumentů, které obchodníci obvykle pozorují současně. Sto instrumentů je v naprosté většině případů maximálním horním odhadem. XHR posílal na server dotaz každou sekundu. Server jako vstupní parametr dostával pořadové číslo dotazu. Vracel XML ve tvaru: USDCZK6 Počet elementů tick byl roven počtu odebíraných instrumentů. Velikost XML je pro 10 instrumentů rovna cca 1KB. Paměť prohlížeče jsme monitorovali po dobu jedné minuty. V případě prohlížeče Google Chrome jsme při měření uvažovali součet paměťové spotřeby obou vláken: jak hlavního vlákna, tak i vlákna pro danou záložku, v níž se zobrazuje tabulkai.
Souhrnné výsledky měření V tabulce 6 jsou uvedeny průměrné hodnoty paměťové spotřeby uvedených prohlížečů. Podrobnější výsledky lze najít v přiloženém excelu (CT_1min.xls). Hodnoty v tabulce jsou uváděné v MB. Počet instrumentů Prohlížeč
0
10
20
30
40
50
100
Chrome 0.3
27,4
32,5
38,0
38,0
35,3
37,3
44,0
IE 6.0
17,3
21,7
21,8
21,9
20,6
22,6
22,8
IE 7.0
26,0
27,0
27,8
28,0
28,0
28,4
29,1
Firefox 2.0
25,4
26,0
26,3
26,6
26,7
27,0
27,7
Firefox 3.0
36,0
39,6
40,2
40,6
40,7
41,3
44,0
Opera 9.6
28,5
31,4
31,5
31,7
31,7
31,7
32,6
Tab. 6 – Test A1 průměrná spotřeba RAM (v MB)
i
Platí i pro všechna ostatní měření.
64
Vyhodnocení výsledků měření Testy ukázaly, že se zvětšením počtu odebíraných instrumentů roste spotřeba paměti prohlížečem. Narůst spotřebované RAM v absolutních hodnotách však (kromě Chrome) nebyl výrazný a v nejhorším případě dosahoval 44 MB. U všech prohlížečů (s výjimkou Chrome) jsme nezaznamenali žádný růst spotřeby ani v závislosti na čase. Hodnota paměti kolísala kolem uvedených průměrů. U Google Chrome jsme zaznamenali výrazný nárůst paměťových nároků jednak v závislosti na čase, jednak na počtu instrumentů. Pro stanovení konečného závěru o použitelnosti tohoto prohlížeče bude zapotřebí vykonat Test B1. Změny zátěže CPU v závislosti na počtu instrumentů pozorovány nebyly. U žádného z prohlížečů jsme nepozorovali jakékoliv narušení plynulého zobrazování kotací.
7.3.2 Test B1: Dlouhodobá spotřeba CPU a RAM Popis testu a postupu měření Cílem testu B1 bylo změření paměťové spotřeby prohlížečem v delším časovém intervalu. Vzhledem k časové náročnosti testu jsme omezili počet měření na jedno pro každý prohlížeč. Počet odebíraných instrumentů jsme zafixovali na 100, což u většiny uživatelů OP představuje horní mez co do počtu současně pozorovaných instrumentů. Délka měření činila 8 hodin - pracovní doba burzy. XHR každou sekundu generoval jeden požadavek na server. Server vracel XML ve tvaru popsaným v Testu A1. Za uváženou dobu bylo XHR vygenerováno na server 28,800 požadavků a ze serveru bylo přeneseno cca 288 MB dat.
Souhrnné výsledky měření Níže (na obrázkách 16 a 17) uvádíme výsledky měření v podobě grafů. Podrobnější výsledky lze najít v přiloženém souboru (CT_8hod.xls) na CD. 70000
Vyhodnocení výsledků měření V průběhu testu jsme nepozorovali žádný růst ani paměťových ani procesorových prostředků. Zajímavým bylo chování Google Chrome, u něhož v cyklických intervalech docházelo k nárůstu a následnému poklesu spotřeby paměti. Domněnka vyslovená v Testu A1 o nárůstu paměťových prostředků v čase se u něj nepotvrdila.
7.3.3 Test C1: Velmi vysoký počet instrumentů Popis testu a postupu měření Test C1 se zaměřil na pozorování chování prohlížečů při zobrazování abnormálně vysokého počtu instrumentů. Pozorovali jsme paměť, vytíženost procesoru, dobu zpracování odpovědi včetně schopnosti prohlížeče data vůbec zobrazit. Měření jsme provedli pro následující počet instrumentů: 1000, 2000, 3000, 4000, 5000. Délka jednoho měření činila 1 minutu, za níž bylo na server vygenerováno 60 dotazů. Velikost jedné odpovědi činila cca 100 KB.
Souhrnné výsledky měření Níže (v tabulkách 7 až 10) uvádíme souhrnné výsledky měření. Podrobné výsledky lze najít v souboru (CT_Velka.xls) na přiloženém CD.
Prohlížeč
Počet instrumentů 1000
2000
3000
4000
5000
Chrome 0.3
25,88
56,92
75,81
85,96
86,55
IE 6.0
47,94
71,51
82,22
89,30
92,99
IE 7.0
92,92
93,78
95,13
96,02
96,35
66
Prohlížeč
Počet instrumentů 1000
2000
3000
4000
5000
Firefox 2.0
70.63
86,85
87,63
88,10
88,49
Firefox 3.0
50,78
80,05
84,97
90,47
90,31
43,61
85,16
85,68
90,03
88,49
Opera 9.6
Tab. 7 – Test C1 průměrná spotřeba CPU (v %)
Prohlížeč
Počet instrumentů 1000
2000
3000
4000
5000
Chrome 0.3
54,1
60,6
72,7
78,7
85,9
IE 6.0
28,5
36,6
40,9
47,5
53,2
IE 7.0
36,3
43,0
50,4
52,2
64,9
Firefox 2.0
36,6
39,3
43,0
43,1
50,3
Firefox 3.0
69,0
70,1
80,9
80,5
87,4
37,5
45,7
51,7
60,4
65,7
Opera 9.6
Tab. 8 – Test C1 průměrná spotřeba RAM (v MB)
Prohlížeč
Počet instrumentů 1000
2000
3000
4000
5000
Chrome 0.3
0
0
0
0-2
0-3
IE 6.0
1
2-3
4-5
9
13-14
IE 7.0
0
1-2
2-4
6-7
9
Firefox 2.0
0
0-1
1-2
2
2-3
Firefox 3.0
0
0-1
0-2
1-3
1-3
Opera 9.6
0
0-3
2-5
5-7
5-10
Tab. 9 – Test C1 zpoždění při vykreslování tabulky (v sek)
Prohlížeč
Počet instrumentů 1000
2000
3000
4000
5000
Chrome 0.3
0
0
0
0
0
IE 6.0
0
0
0
0
0
IE 7.0
0
0
0
0
0
Firefox 2.0
0
0
0
0
0
Firefox 3.0
0
0
0-1
0-1
0-1
Opera 9.6
0
1
1
2-3
3-5
Tab. 10 - Test C1 počet zahozených ticků mezi dvěma po sobě zobrazenými ticky
67
Vyhodnocení výsledků měření Testy ukázaly, že žádný prohlížeč kromě Google Chrome nebyl schopen bez problémů zpracovávat větší počet instrumentů než 1,000. Na hranici 2,000 instrumentů docházelo k výraznému nárůstu spotřeby prohlížečem procesoru, zpoždění doby zpracování příchozích dat a zahazování ticků. U paměťových nároků nebyl zaznamenán větší růst. Nejhůře ze všech testovaných prohlížečů dopadl IE 6.0, u něhož nejvíce se zvětšením počtu odebíraných instrumentů rostla doba zpracování odpovědí ze serveru. Nejlépe dopadl Google Chrome a to v prakticky ve všech porovnáních (kromě paměti). U prohlížečů Firefox 3.0 a Opera 9.6 jsme pozorovali zajímavé chování: když prohlížeče nestíhaly zobrazovat ticky, jednoduše je všechny zahazovaly. Opera při 5,000 instrumentech zahazovala 3-5 ticků mezi dvěma po sobě zobrazenými ticky.
7.3.4 Test D1: Zatížení serveru Popis testu a postupu měření Cílem testu D1 bylo změření zátěže serveru a doby odezvy v závislosti na počtu současně připojených klientů. Pozorovali jsme CPU a RAM spotřebu serveru a také odezvu a množství chyb. Časový interval měření byl omezen na 1 minutu. Počet odebíraných instrumentů jsme stanovili na 50, což vycházelo z reálného použití OP. Měřili jsme 100, 500, 1000, 1500 a 2000 současně připojených klientů. XHR každou sekundu generoval jeden požadavek na server. Server vracel XML ve tvaru popsaném v Testu A1.
Souhrnné výsledky měření Níže (na obrázkách 18 a 19 a v tabulce 11) uvádíme výsledky měření. Podrobnější výsledky lze najít v přiloženém souboru (Apache_CT_CD_1min.xls) na CD.
Vyhodnocení výsledků měření Měření ukázala, že server nebyl schopen zpracovávat více než 500 současných dotazů za sekundu. Neprojevilo se to ani na tolik nárocích na CPU a RAM, ale spíše na velkém růstu doby odezvy a chybovosti odpovědí. Při 2,000 současných dotazů chybovost dosahovala 78,1%. Průměrná doba odezvy činila 1,784 ms a více než 90 procent dotazů mělo dobu odezvy větší než 3,6 s.
7.4 Grafy ChartDirector 7.4.1 Test A2: Krátkodobá spotřeba CPU a RAM Popis testu a postupu měření Cílem testu bylo změřit závislost mezi počtem odebíraných grafů a CPU a RAM nároky prohlížeče. Uvážili jsme 6 případů: 0 grafů (prohlížeč zobrazuje prázdnou stránku), 1, 5, 10, 20, 50. Množství testovaných grafů by mělo odpovídat reálnému počtu grafů, které obchodníci obvykle pozorují současně. Poslední dva testované případy jsou spíše teoretického charakteru a mají sloužit pro měření mezních případů, které by při reálném použití programu neměl nastávat. Interval obnovování grafů byl stanoven na 1 sekundu, což odpovídá tickovým grafům. Zátěž při jiných granularitách je menší, proto jsme jiné frekvence neuvažovali. Server vracel obrázek grafu o velikosti cca 14,2 KB. Měření jsme prováděli po dobu jedné minuty.
Souhrnné výsledky měření V tabulkách 12 a 13 jsou uvedeny souhrnné výsledky testu A2. Podrobnější výsledky lze najít v přiloženém souboru (CD_1min.xls) na CD.
Prohlížeč
Počet grafů 0
1
5
10
20
50
Chrome 0.3
31,7
62,4
67,0
76,6
99,1
111,7
IE 6.0
17,5
20,4
21,4
24,6
27,5
33,8
IE 7.0
26,0
29,0
30,2
31,4
33,0
39,6
Firefox 2.0
25,6
26,7
56,4
92,9
140,4
239,1
70
Firefox 3.0
40,3
Opera 9.6
19,7
40,0
44,6
65,5
122,7
276,2
28,0
54,6
87,1
142,7
274,0
Tab. 12 – Test A2 průměrná spotřeba RAM (v MB)
Prohlížeč
Počet grafů 0
1
5
10
20
50
Chrome 0.3
0,57
1,77
4,04
7,65
12,44
11,59
IE 6.0
0,10
1,54
8,10
14,58
24,34
36,15
IE 7.0
0,00
1,53
4,32
7,97
10,49
18,76
Firefox 2.0
0,05
0,39
1,74
2,55
2,16
4,43
Firefox 3.0
0,18
2,26
5,76
6,09
8,93
17,50
Opera 9.6
0,03
2,24
4,87
9,19
12,18
20,23
Tab. 13 – Test A2 průměrná spotřeba CPU (v %)
Vyhodnocení výsledků měření Měření ukázala, že s nárůstem počtu zobrazovaných grafů roste jak spotřeba paměti, tak i procesoru. Výrazná tendence růstu paměťových nároků se pozorovala především u prohlížečů Firefox a Opera. Firefox dosahoval hodnoty 500 MB, po čemž následovalo uvolnění paměti. U prohlížečů Opera a Chrome jsme pozorovali lineární růst spotřeby RAM. Růst spotřeby CPU nebyl velký. Nejvyšších hodnot dosahoval u IE 6. U žádného prohlížeče jsme v žádném z měření nepozorovali narušení plynulého zobrazování a obnovování grafů. Problematickým místem je tedy spotřeba paměti, proto pro přijetí definitivního rozhodnutí o použitelnosti této metody zobrazování real-timeových grafů budou nutné další testy.
7.4.2 Test B2: Dlouhodobá spotřeba CPU a RAM Popis testu a postupu měření Cílem testu B2 bylo změření spotřeby CPU a RAM prohlížečem v delším časovém intervalu při použití pro generování real-timeových grafů knihovny ChartDirector. Vzhledem k časové náročnosti testu jsme omezili počet měření na jedno pro každý prohlížeč. Počet odebíraných grafů jsme zafixovali na 5, což u většiny obchodníků představuje obvyklý počet současně pozorovaných grafů. Délka měření činila 8 hodin – pracovní doba burzy. Frekvence obnovování grafů byla stanovena na 1 sekundu – simulovali jsme tickové grafy (ostatní typy grafů by určitě měly menší spotřebu prostředků počítače). Server jako odpověď vracel obrázek o velikosti cca 14,2 KB. Za uvedenou dobu bylo na server vygenerováno 28,800 požadavků a ze serveru bylo přeneseno cca 2GB dat pro každý prohlížeč.
Souhrnné výsledky měření Níže (na obrázkách 20 a 21) uvádíme výsledky měření v podobě grafů. Podrobnější výsledky lze najít v přiloženém souboru (CD_8hod.xls) na CD.
Vyhodnocení výsledků měření V průběhu testu jsme u prohlížečů Google Chrome a Opera zaznamenali velký nárůst spotřeby RAM. Relativně velkou spotřebu vykazoval i Firefox 2.0. U ostatních prohlížečů spotřeba nepřesahovala obvyklou hranici. Zvýšení zátěže CPU nebylo pozorováno u žádného z prohlížečů.
72
7.4.3 Test C2: Velmi vysoký počet grafů Test C2 byl zahrnut do A2.
7.4.4 Test D2: Zátěž serveru Popis testu a postupu měření Cílem Testu D2 bylo prozkoumat chování serveru při odebírání grafů větším množstvím klientů současně. Testovali jsme následující počet klientů: 100, 500, 1000, 1500 a 2000. Každý klient generoval jeden požadavek na server za sekundu. Doba měření činila 1 minutu. Server vracel obrázek o velikosti cca 14,2 KB.
Souhrnné výsledky měření Níže (na obrázkách 22 a 23 a v tabulce 14) uvádíme výsledky měření. Podrobnější výsledky lze najít v přiloženém souboru (Apache_CT_CD_1min.xls) na CD. 250
Vyhodnocení výsledků měření Měření ukázala, že server nebyl schopen zpracovávat více než 500 současných dotazů za sekundu. Docházelo k velmi silnému nárůstu jak spotřeby CPU a RAM a také doby odezvy a chybovosti, která při 2,000 klientů dosahovala 91 procent. Je tedy očividné, že tato metoda pro vytváření real-timeových grafů není vůbec vhodná.
74
7.5 Grafy SVG 7.5.1 Test A3: Krátkodobá spotřeba CPU a RAM Popis testu a postupu měření Cílem testu bylo změřit závislost mezi počtem odebíraných grafů implementovaných pomocí SVG a paměťovými a CPU nároky prohlížeče. Uvážili jsme 6 případů: 0 grafů, kdy prohlížeč zobrazuje prázdnou stránku, a následně 1, 5, 10, 20 a 50 grafů. Množství testovaných grafů by mělo odpovídat reálnému počtu grafů, který obchodníci obvykle pozorují současně. Poslední dva testované případy jsou spíše teoretického charakteru a mají opět sloužit pro měření mezních případů. Interval obnovování grafů byl jako v testech A1 a A2 stanoven na 1 sekundu. Zátěž při jiných granularitách je menší, proto jsme ji netestovali. Server vracel hodnotu ticku o velikosti několika bytů. Měření trvala po dobu jedné minuty. SVG není podporován rodinou prohlížečů IE, proto jsme tyto prohlížeče z testování vynechali.
Souhrnné výsledky měření V tabulkách 15 a 16 jsou zachyceny souhrnné výsledky testu. Podrobnější výsledky lze najít v přiloženém souboru (SVG_1min.xls) na CD.
Prohlížeč
Počet grafů 0
1
5
10
20
50
Chrome 0.3
31,7
31,6
36,2
33,5
45,8
52,0
Firefox 2.0
25,6
27,0
28,2
29,8
32,6
40,9
Firefox 3.0
40,3
40,6
51,1
42,6
45,3
54,1
Opera 9.6
19,7
25,5
33,4
41,2
61,2
95,2
Tab. 15 – Test A3 průměrná spotřeba RAM (v MB)
Prohlížeč
Počet grafů 0
1
5
10
20
50
Chrome 0.3
0,57
4,90
5,80
12,76
25,16
45,57
Firefox 2.0
0,05
6,93
18,49
22,47
26,40
32,65
Firefox 3.0
0,18
2,79
6,46
8,82
11,45
29,35
Opera 9.6
0,03
1,64
7,60
11,35
10,86
22,89
Tab. 16 – Test A3 průměrná spotřeba CPU (v %)
Vyhodnocení výsledků měření Měření ukázala, že s nárůstem počtu zobrazovaných grafů roste jak spotřeba paměti, tak i procesoru. Růst u většiny prohlížečů nebyl v absolutních hodnotách výrazný. Největší tendence se pozorovala u Opery (v případě RAM) a Chrome (v případě CPU). Nepozorovali jsme závislost mezi časem a nárůstem spotřeby RAM či CPU. 75
Taktéž jsme nepozorovali žádné zadrhávání, zpomalení či jiné problémy se zobrazováním grafů.
7.5.2 Test B3: Dlouhodobá spotřeba CPU a RAM Popis testu a postupu měření Cílem testu B3 bylo změření spotřeby CPU a RAM prohlížečem v delším časovém intervalu při použití SVG implementace real-timeových grafů. Vzhledem k časové náročnosti testu jsme omezili počet měření na jedno pro každý prohlížeč. Parametry testu B3 byly shodné s parametry testu B2 s tím rozdílem, že server jako odpověď vracel kotaci nového ticku v podobě jednoduchého textu o velikosti několika bytů. Za dobu měření bylo na server vygenerováno 28,800 požadavků a ze serveru bylo přeneseno cca 112 KB dat.
Souhrnné výsledky měření Níže (na obrázkách 24 a 25) uvádíme výsledky měření v podobě grafů. Podrobnější výsledky lze najít v přiloženém souboru (SVG_8hod.xls) na CD. 70000
Vyhodnocení výsledků měření V průběhu testu jsme u žádného prohlížeče nezaznamenali růst CPU a RAM spotřeby. Největší spotřeby RAM vykazoval Firefox 3.0.
7.5.3 Test C3: Velmi vysoký počet grafů Test C3 byl zahrnut do A3.
7.5.4 Test D3: Zátěž serveru Test D3 jsme neprováděli, protože je totožný s testem D1.
7.6 JSON vs XML Popis testu a postupu měření Cílem testu bylo porovnání rychlostí parsování JSONu a XML testovanými prohlížeči. Na začátku testu jsme zadali počet záznamů, které se měly vygenerovat. Po stisknutí tlačítka otestuj JSON (otestuj XML) se vygeneroval zadaný počet záznamů a na tyto záznamy se zavolal metoda eval() (parseXML()). Na začátku a konci parsování dat jsme zaznamenali časy. Rozdíl času pak představoval dobu zpracování vygenerovaných dat.
Souhrnné výsledky měření Výsledky testy jsou uvedeny v tabulkách 17 a 18.
Prohlížeč Chrome 0.3
Počet záznamů 100
500
1,000
5,000
10,000
2
8
14
75
136
77
Prohlížeč
Počet záznamů 100
500
1,000
5,000
10,000
Firefox 2.0
0
16
16
63
109
Firefox 3.0
1
5
10
45
86
IE 6.0
0
0
0
16
31
IE 7.0
0
16
16
16
31
Opera 9.6
0
16
16
46
78
Tab. 17 – doba parsování JSON
Prohlížeč
Počet záznamů 100
500
1,000
5,000
10,000
Chrome 0.3
3
11
22
106
175
Firefox 2.0
0
0
15
63
31
Firefox 3.0
3
6
10
39
75
IE 6.0
0
0
16
16
31
IE 7.0
16
16
16
16
31
Opera 9.6
0
16
16
63
110
Tab. 18 – doba parsování XML
Vyhodnocení výsledků měření Jak je vidět z naměřených hodnot, nepozorovali jsme žádné větší rozdíly v rychlostech parsování JSONu a XML.
7.7 Souhrnný závěr měření Naše testy ukázaly, že při normálním provozu aplikace zkoumané prohlížeče nemají problém s plynulým zobrazováním real-timeových dat v podobě tabulek či grafů měn při použití námi navržených způsobů implementace. Jen v několika případech bylo pozorováno velké zvýšení spotřeby RAM v čase. Spotřeba však nebyla neúnosně velká a nepřesáhla 1 GB. Samotné zobrazování bylo plynulé a bezeztrátové. Zátěžové testy na abnormálně velkém počtu současně odebíraných instrumentů dopadly nepříznivě ve všech případech kromě prohlížeče Google Chrome. Zátěžové testy pro zkoumaný počet grafů dopadly příznivě u všech prohlížečů. V případě SVG jsme však pozorovali relativně velký nárůst spotřeby RAM. Z hlediska zátěže serveru a dob odezvy jsme narazili na očividné limity zvláště v případě využití knihovny pro generování statických obrázků grafů. Na našem testovacím stroji jsme byli schopni zpracovávat bez problémů pouze kolem 500 požadavků současně. Otázkou je, nakolik to závisí na HW konfiguraci serveru. V každém případě způsob implementace tickových grafů pomocí knihovny na straně serveru není zřejmě vhodný a to nejen z hlediska zátěže serveru (která je v tomto případě neúnosná a při velkém počtu klientů odebírajících tickové grafy zcela nepoužitelná), ale i síťového spojení. V případě SVG přenášíme jen textová data o velikosti několika bytů, kdežto v případě knihovny na generování statických obrázků grafů přenášíme obrázek o velikosti několika KB, což představuje několika set procentní zvýšení síťové zátěže. Je to o to horší, že nově vygenerovaný obrázek se liší od předchozího obrázku jen v prvním a posledním ticku. 78
Vzhledem k tomu, že jsme jako formát přenášených dat zvolili XML, který má velké nároky na velikost, bude nutné data komprimovat Testování rychlostí parsování záznamů ve formátu JSON a XML neukázalo žádné větší rozdíly.
79
8 Závěr Tato diplomová práce si vytkla za cíl prostudovat případné výhody TiCKERWebu a stanovit, zda současné webové technologie implementaci TiCKERWebu vůbec umožňují. Ukázali jsme, že webové aplikace (WA) poskytují širokou škálu výhod. Pro obchodní aplikace (jako je TiCKER) představuje webové řešení front-endu velmi atraktivní volbu. Takové výhody jako cross-platformní přenositelnost, centralizovaná technická podpora nevyžadující zásah u zákazníka a přístupnost aplikace mimo kancelář jsou pro tento druh aplikací výraznou předností oproti klasickým front-endům. Dále jsme prokázali, že rychlost odezvy, jež je slabým místem WA a plyne z existence síťové latence, lze elegantně ošetřit pomocí nastavování timeoutů pro jednotlivé asynchronní požadavky na server a kontroly časových razítek příchozích dat (řeší problém předbíhání starších dat novějšími). Prostudovali jsme v současnosti dostupné a rozšířené technologie pro tvorbu WA. Do úvahy jsme vzali Flash, ActiveX, Java Plug-in Aplet, DHTML, DOM programování a AJAX. Ukázalo se, že nejlepšími kandidáty pro vývoj TiCKERWebu jsou Flash a AJAX. Naši volbu jsme stanovili na AJAXu, a to především z důvodu nezávislosti na proprietárním kódu a jeho architektuře založené na otevřených standardech, jež jsou navíc navzájem velmi těsně propojeny. AJAX se skládá z pravých webových technologií, má velký výběr frameworků a jeho vývoj je podporován takovými společnostmi jako Google, IBM, AOL a dalšími. AJAX je konceptem popisujícím spolupráci různých technologií, především JavaScriptu, DOM a CSS. Jeho základní funkcionalita je úzce spojena s XmlHttpRequestObjectem (XHR), což je objekt sloužící pro komunikaci se serverem. Jeho největší předností je možnost posílání asynchronních požadavků na server a možnost nastavení call back funkce, která se zavolá poté, co přijde odpověď ze serveru. Problematickou oblastí AJAXu je jeho kompatibilita s prohlížeči, s níž se setkáváme už při použití XHR, kde mají různé rodiny prohlížečů jeho vlastní implementaci. S problémem kompatibility jsme se setkali i v případě modelu boxů a při použití CSS. Je ovšem nutné zdůraznit, že tyto problémy nepředstavují nepřekonatelnou překážku. Jejich jediný skutečný dopad je jen na vývoj, kdy je nutné zvlášť rozebírat jednotlivé případy (chceme-li, aby náš program správně fungoval ve všech prohlížečích). Vzhledem ke skutečnosti, že byla v projektu TiCKER na straně serveru implementována veškerá byznys logika, bylo nutné řešit způsob propojení stávajícího serveru TiCKER a nového webového front-endu. Ze tří alternativ, které jsme rozebírali v této práci, se nabízí jako nejvhodnější varianta PHP proxy nebo Enterprise Service Bus. V obou případech se stávající API serveru TiCKER rozšíří o webové služby, na něž se bude připojovat PHP proxy nebo ESB. Dále jsme se zabývali výběrem vhodného formátu pro přenos dat mezi serverem a klientem. XHR je v tomto směru velmi flexibilní a umožňuje pracovat s různými formáty přenášených dat. K nejpoužívanějším z nich patří v současnosti XML, což je nativní formát pro XHR, a JSON. Náš test ukázal, že mezi rychlostmi parsování dat ve formátu JSONu a ve formátu XML neexistuje žádný významný rozdíl. XML prohrává ve velikosti přenášených dat, i když je nutné podotknout, že otázka velikosti toku dat je pro naší cílovou skupinu uživatelů málo podstatná. Nicméně z naších měření vyplynulo, že velikost dat, které se přenesou během obchodní doby, je při použití XML dost velká, proto bude nutné data na serveru komprimovat.
80
HTTP (či HTTPS) protokol neumožňuje přímé posílání zpráv od serveru konkrétnímu klientovi. Tato funkcionalita se vyřeší nepřímo a to následovně: Na serveru se vytvoří fronty pro každého uživatele, do nichž se budou vkládat zprávy. Server se při obdržení požadavku od klienta podívá do příslušné fronty, a pokud v ní budou nějaké zprávy, přibalí je do odpovědi. Obchodní aplikace pracují s velmi citlivými daty, proto jsme věnovali pozornost otázce bezpečnosti. Na bezpečnost TiCKERWebu se díváme z pohledu zákazníka a samotného TiCKERu. Z pohledu zákazníka je nutné zajistit bezpečnost datového přenosu mezi klientskou aplikací a serverem a bezpečnost prováděných transakcí. Těchto požadavků lze docílit použitím protokolu HTTPS a konfirmačních emailů či SMS zpráv. Z pohledu TiCKERu spočívá bezpečnost v zabránění odběru dat jedním uživatelem vícekrát najednou a také zabránění brute force útoků na účty uživatelů. Navrhli jsme řešení obou těchto problémů. Je taktéž vhodné zajistit náš kód proti krádeži. Ovšem naše studium této problematiky ukázalo, že 100-procentní ochrana proprietárního kódu TiCKERWebu je neřešitelným problémem. Také jsme se zabývali implementací dvou nejdůležitějších komponent front-endu OP: tabulky s kurzy a grafy. Tabulka s kurzy se implementuje velmi jednoduše s použitím XHR a DOM. V případě grafů je situace podstatně složitější. V současné době existují dvě cesty: Použití knihovny na straně serveru, která bude generovat statické obrázky a posílat je klientovi, nebo implementace pomocí SVG. V první variantě bude knihovna generovat statické obrázky, jež se budou posílat klientovi. Ten bude pomocí XHR pravidelně obnovovat obrázky na stránce, čímž vznikne iluze plynulého obnovování grafů. Ve druhé variantě používáme dynamicky vyvíjecí technologii SVG. Obě řešení mají svoje klady a zápory, jež byly diskutovány v jednotlivých kapitolách. Naše testy však ukázaly, že použití externí knihovny na straně serveru pro generování grafů je velmi nevhodné z hlediska výkonnosti serveru. Zvláště se to projevuje u tickových grafů. Vytížení, jak naše měření ukázala, je tak velké, že při použití této knihovny bude nutné udělat velkou investici do HW serveru. Dále jsme probrali způsob implementace třídění tabulek podle hodnot ve sloupečcích, drag&drop a spuštění trigerů při dosažení ceny instrumentu předem definované limitní úrovně. Poukázali jsme na omezení počtu současně otevřených paralelních spojení, které dnešní prohlížeče mají. Navrhli jsme způsob řešení umožňující překonat toto omezení. Řešení spočívá v použití dvou XHR objektů, kdy jeden bude sloužit výhradně pro přenos dat a druhý pro GUI. Otestovali jsme schopnosti prohlížečů zobrazovat velké množství real-timeových dat. Naše testy ukázaly, že vybrané prohlížeče nemají problém s plynulým zobrazováním většího množství dat při použití AJAXu. Jen u v několika případech docházelo k nárůstu spotřeby RAM, ale ani tento nárůst nebyl takový, že by znemožnil práci klientské stanice. Jak se ale ukázalo, implementace real-timeových grafů pomocí knihovny, která bude generovat statické obrázky (v práci jsme použili knihovnu ChartDirector), je zcela nevýhodná jak z hlediska velké zátěže serveru, tak i sítě. Mnohem lepší řešení představuje varianta SVG. V diplomové práci jsme ukázali, že řešení front-endu v podobě webové aplikace poskytuje celou řadou předností oproti desktopovým analogům. V průběhu analýzy a návrhu jsme nenarazili na žádné omezující faktory, které by znemožnily implementaci TiCKERWebu jako celku nebo konkrétních prvků jeho funkcionality. Zvolená technologie AJAX i přes řadu svých omezení je vhodným a postačujícím nástrojem pro implementaci základních požadavků na TiCKERWeb definovaných na začátku diplomové práce.
81
Odkazy na použité zdroje [1] SW projekt TiCKER (2006): Technická dokumentace. MFF UK, Praha. [2] Wikipedia (2008): Financial Market. http://en.wikipedia.org/wiki/Financial_market [3] Darie C., Brinzarea B., Chereches-Tosa F., Bucica M. (2006): AJAX and PHP: Building Responsive Web Applications. Packt Publishing Ltd., Birmingham UK. [4] Graham P. (2001): The Other Road Ahead. http://www.paulgraham.com/road.html [5] Crane D., Pascarello E., James D. (2006): Ajax in Action. Manning Publications Co., Greenwich, CT USA. [6] Rich Internet Applicaton Statistics (2008): Adobe Flash vs MS Silverlight. http://riastats.com/ [7] Adobe (2008): About Adobe Flash Player. http://www.adobe.com/products/flash/about/ [8] Web Standards (2008): Acid Test 3. http://acid3.acidtests.org/ [9] Adobe (2008): Adobe Flash Player PC Penetration. http://www.adobe.com/products/player_census/flashplayer/PC.html [10] Sun Microsystems: Applets. http://java.sun.com/applets/ [11] Wikipedia (2008): Dynamic HTML. http://en.wikipedia.org/wiki/Dynamic_HTML [12] Heilmann Ch. (2006): From DHTML to DOM Scripting. http://icant.co.uk/articles/fromdhtml-to-dom/from-dhtml-to-dom-scripting.html [13] Shannon R. (2007): DHTML Explained. http://www.yourhtmlsource.com/javascript/dhtmlexplained.html [14] Wikipedia (2008): Ajax. http://en.wikipedia.org/wiki/Ajax_(programming) [15] W3Schools (2008): Browser Statistics. http://www.w3schools.com/browsers/browsers_stats.asp [16] Hammond J. (2008): How to Choose an RIA Path: AJAX or Adobe? http://ajax.syscon.com/node/400296 [17] Hayre J., Kelath J. (2006): Ajax Security Basics. http://www.securityfocus.com/infocus/1868/2 [18] Garrett J. J. (2005): Ajax: A new Approach to Web Applications. http://www.adaptivepath.com/ideas/essays/archives/000385.php [19] Crane D., Pascarello E., James D. (2006): Ajax in Action. Manning Publications Co., Greenwich, CT USA. [20] Wikipedia (2008): XMLHttpRequest. http://en.wikipedia.org/wiki/XMLHttpRequest [21] Boutell T. (2006): What is the maximum length of a URL? http://www.boutell.com/newfaq/misc/urllength.html [22] Sun Microsystems (2008): The Java EE 5 Tutorial. http://java.sun.com/javaee/5/docs/tutorial/doc/bnayn.html [23] W3C (2004): HTTP 1.1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html [24] W3C (2008): The XMLHttpRequest Object. http://www.w3.org/TR/XMLHttpRequest/ [25] Andrews M., Whittaker A. (2006): How to Break Web Software: Functional and Security Testing of Web Applications and Services. Addison-Wesley Professional, New York. 82
[26] Aditus Consulting (2008): JpGraph. http://www.aditus.nu/jpgraph/index.php [27] Advanced Software Engineering (2007): ChartDirector. http://www.advsofteng.com/ [28] Max Planck Institute for Solar System Research (2008): DISLIN. http://www.mps.mpg.de/dislin/ [29] MayaVi (2007): The MayaVi Data Visualizer. http://mayavi.sourceforge.net/index.html [30] ReportLab (2008): ReportLab. http://www.reportlab.org/ [31] W3C (2008): Scalable Vector Graphics. http://www.w3.org/Graphics/SVG/ [32] Adobe (2008): Adobe to Discontinue Adobe SVG Viewer. http://www.adobe.com/svg/eol.html [33] Advanced Software Engineering (2007): ChartDirector. http://www.advsofteng.com/cdphp.html [34] W3C (2008): Paths. http://www.w3.org/TR/SVG/paths.html [35] Langridge S. (2007): Sortable. http://www.kryogenix.org/code/browser/sorttable [36] Mrdjenovic M. (2006): SortedTable. http://friedcellcollective.net/outbreak/jssortedtable/ [37] Kruse M. (2007): Table Sorting. http://www.javascripttoolbox.com/lib/table/ [38] Scriptaculous (2008): Scriptaculous. http://script.aculo.us/ [39] Isocra Consulting (2008): Dragging and dropping table rows in Javascript. http://www.isocra.com/2007/07/dragging-and-dropping-table-rows-in-jsavascript/ [40] DHTML eXtensions (2008): Grid. http://dhtmlx.com/docs/products/dhtmlxGrid/index.shtml
