Rok / Year: 2013
Svazek / Volume: 15
Číslo / Number: 6
Možnosti implementace webové distribuované simulace The implementation options for the web-based distributed simulation Štěpán Karták, Jan Hřídel
[email protected] ,
[email protected] Fakulta elektrotechniky a informatiky, Univerzita Pardubice
Abstrakt: Článek se věnuje problematice webových simulací. Obsahuje možnosti realizace a přehled dostupných technologií, distribuovaných simulačních modelů běžících v rámci internetového prohlížeče bez další softwarové podpory. V druhé části je uveden způsob praktické realizace distribuovaných webových simulací při výuce na Fakultě elektrotechniky a informatiky Univerzity Pardubice.
Abstract: The paper discusses the web-based simulation. It contains the implementation options and review of available technologies, distributed simulation models running within the web-browser without additional software support. The second part of this paper shows how to realize the practical implementation of distributed web-based simulations in teaching at the Faculty of Electrical Engineering and Informatics of the University of Pardubice.
VOL.15, NO.6, DECEMBER 2013
Možnosti implementace webové distribuované simulace Štěpán Karták, Jan Hřídel Fakulta elektrotechniky a informatiky, Univerzita Pardubice Email:
[email protected] ,
[email protected]
Abstrakt – Článek se věnuje problematice webových simulací. Obsahuje možnosti realizace a přehled dostupných technologií, distribuovaných simulačních modelů běžících v rámci internetového prohlížeče bez další softwarové podpory. V druhé části je uveden způsob praktické realizace distribuovaných webových simulací při výuce na Fakultě elektrotechniky a informatiky Univerzity Pardubice.
1 Úvod Webové prohlížeče jsou dnes součástí běžného života. V posledních letech prodělaly značný rozmach, došlo ke sjednocení standardů – především JavaScriptu a dnes obstojí jako platforma pro realizaci celé řady aplikací, které bylo dříve nutné řešit tzv. desktopovou aplikací – aplikací závislou na operačním systému, architektuře procesoru, aj. Webový prohlížeč tyto závislosti překonává a vytváří ideální multiplatformní běhové prostředí, které s rozšířením podpory HTML5 obsahuje již minimum překážek pro nasazení aplikací, dříve jinak řešených jako klasický desktopový software. Pro realizaci distribuované simulace jsou zásadní dva prvky: • Výpočetní výkon – JavaScript dnes v tomto ohledu neklade téměř žádná omezení, optimalizace je značná a výrobci prohlížečů se předhání v rychlejším zpracování JavaScriptového kódu. • Možnosti komunikovat libovolně po síti – právě omezené možnosti prohlížečů do nedávna limitovaly možnost použití pro distribuovanou simulaci webový prohlížeč. Dnes je situace jiná, nové „síťové“ standardy HTML5 jsou rozšířené a použití internetových prohlížečů již nic nebrání. V následujících kapitolách rozebereme jednotlivé technologické možnosti, kterými dnešní moderní prohlížeče disponují. Všechny informace jsou obecně použitelné pro jakýkoliv typ synchronizace logických procesů. Následující text se zaměřuje, především v druhé části věnované výuce, na metodu zasílání nulových zpráv na požádání s uplatněním výhledu. Pro názornější a přívětivější formu výuky počítačových distribuovaných simulací byl navržen a implementován software, který umožňuje aktivní zapojení skupiny studentů. Právě zatraktivnění výuky a zjištění, jakým způsobem lze v prostředí webového prohlížeče realizovat síťovou komunikaci bylo motivací pro implementaci dále detailněji popsané aplikace v kapitole 4. 1 Tento článek se zaměřuje na metodu synchronizace zasílání nulových zpráv na požádání a některé pasáže jsou tomuto podmíněny. Obecné informace o síťových možnostech webových prohlížečů,
2 Dostupné technologie Cílem webové simulace je využít ekosystém webového prohlížeče s minimálním zapojením externích prvků (různých appletů, rozšíření, atp.). Činnost distribuovaných výpočetních uzlů vyžaduje komunikaci mezi jednotlivými logickými procesy po síti v obou směrech, tomuto záměru nejlépe odpovídá architektura peer-topeer, viz obrázek 1 1.
Zdroj: Autoři
Obrázek 1: Schéma peer-to-peer komunikace Obousměrnou komunikací je myšleno, pro ukázku v architektuře klienti-server, že klient je schopen kontaktovat server a zároveň server dokáže kontaktovat klienta libovolně, tedy nad rámec standardní odpovědi na HTTP požadavek. Tato druhá podmínka nebyla do příchodu HTML5 splněna a jediné realizovatelné řešení komunikace, čistě v rámci funkcionality prohlížeče, bylo periodické dotazování na server, zda nemá k dispozici zprávy, které čekají na doručení klientovi. Schéma takové komunikace je znázorněno na obrázku 2.
Zdroj: Autoři
Obrázek 2: Schéma komunikace klienti-server 2.1 Nové HTML5 technologie Přibližně od roku 2013 lze používat stabilní verze HTML5 součástí prohlížečů WebSocket a WebRTC (viz tabulka 1), které a jistě i další, jsou obecně použitelné pro jakoukoliv realizaci synchronizace logických procesů.
408
VOL.15, NO.6, DECEMBER 2013 Tabulka 1: Přehled dostupných technologií pro síťovou komunikaci Technologie / řešení
Komunikace SerPeervertoklient peer
WebSocket
Ano
Ne
WebRTC
(Ano)
Ano
JavaScript (před HTML5)
Ne
Ne
Java Applet
Ano
(Ano)
Adobe Flash Player
Ano
Ano
Microsoft Silverlight
* **
Prohlížeče Opera
Firefox
IE
Chrome
Řešení výlučně technologiemi prohlížečů 12.10 11 10 14 -
22
-
23
Použitelné od * IV 2012 VII 2013
Od začátku, problémy se standardy Produkty třetích stran
Ano
Ano
Nezávislé na prohlížeči ** Nezávislé na prohlížeči
-
Win / OS X
2008
Win / OS X
Win
2009
Poznámka
-
Použitelné na platformě mobilních zařízení
Ano Ano
Stav před HTML5
Ano
Vyžaduje Java Virtual Machine Vyžaduje Adobe Flash Player Významná vazba na technologie Microsoftu. V poslední době MS usiluje o přechod na HTML5.
Ne
Ne
Ne
Dle majoritního zastoupení prohlížečů Lze se setkat s problémem načtení appletů v závislosti na způsobu použití v kódu (tagy
, <embed>, )
přidávají prohlížeči podporu komunikace server-klient, jež je zásadní, a bez které nelze vytvořit efektivní distribuovaný simulační model – ať již s jakoukoliv technikou synchronizace. Podpora peer-to-peer komunikace řeší přímou podporu vzájemné komunikace logických procesů, která doposavad byla možná pouze zprostředkovaně přes frontu na serverovém prvku, či vůbec ne, vzhledem k vysoké komunikační režii, která by vznikla. 2.1.1 WebSocket Technologie WebSocket nám dává možnost provozovat síťové spojení odpovídající standardnímu chování desktopových aplikací, které známe již léta – síťové sockety vytvářejí obousměrné spojení dvou aplikací (klient 1 může kontaktovat klienta 2 a naopak). V rámci webových aplikací to znamená, že webové stránka (klient 1) naváže spojení se serverem (odpovídá klientovi 2) a toto spojení je obousměrné – již není potřeba žádné fronty (viz obrázek 2), server posílá zprávy přímo klientovi otevřeným spojením. Toto řešení samozřejmě vyžaduje server. Na serverovou část nejsou kladeny žádné zvláštní požadavky, je pouze nutné dodržovat protokol WebSocket a k dispozici máme celou řadu hotových open-source prostředků od PHP (například knihovna Ratchet) přes Python (např. framework Tornado) po Javu (např. TooTallNate) či C# (knihovna Alchemy Websockets). Řešení pomocí této technologie dokáže zcela nahradit do nedávné doby (příchod HTML5, WebSocket ve Firefoxu a Chrome od dubna 2012 – více viz tabulka 1) nutnost používat pluginy do prohlížečů. Více detailů týkajících se síťové komunikace bude popsáno v následující kapitole.[4]
2.1.2 WebRTC Tato technologie značně rozšiřuje možnosti webového prohlížeče v rámci možností síťové komunikace. Je zde možné realizovat peer-to-peer komunikaci bez účasti serveru (server je vyžadován pro navázání spojení, což je ovšem u peer-to-peer komunikace standardní). WebRTC přímo implementuje použití protokolu ICE (Interactive Connectivity Establishment) [9] pro překonání problémů se směrováním při komunikaci s klientem v lokální síti používající NAT překlad adres IP. Více viz následující kapitola 3.2. Ve výsledku je vhodné zkombinovat WebRTC pro peer-topeer komunikaci mezi klienty s technologií WebSocket pro komunikaci se serverem (např. autorizační, …). Touto sestavou dostaneme univerzální síťově dostupnou platformu založenou na čistě webových technologiích bez nutnosti používat rozšíření prohlížečů a softwaru třetích stran. Na závěr k WebRTC je vhodné zmínit, že se tato technologie stále vyvíjí a některé prvky se v rámci různých prohlížečů nemusí chovat 100% korektně či obsahují prvky rozdílné. Pro většinu těchto problémů existuje čistě JavaScriptové řešení překonávající aktuální rozdíly prohlížečů.[3] 2.2 Technologie třetích stran Až do příchodu HTML5 (první publikovaná verze byla v roce 2008, vývoj však probíhá dodnes) nebylo možné realizovat distribuovanou simulace ve webovém prohlížeči bez produktů třetích stran. Následuje přehled majoritních pluginů – appletů (tento termín bude v dalším textu též používán) – do běžně dostupných prohlížečů.
409
VOL.15, NO.6, DECEMBER 2013 2.2.1 Java Applet Použitelné je řešení Java Applet, které v rámci prohlížeče zobrazuje plnohodnotnou „libovolnou“ aplikaci napsanou v programovacím jazyce Java. Přes všechno pohodlí s obecně známým jazykem Java je vývoj síťové aplikace zkomplikován bezpečnostními politikami Javy. Java Virtual Machine (JVM) rozlišuje dva druhy appletu, dle omezení přístupu k hostitelskému počítači: sandbox a privileged. Sandbox applet je standardní applet, na který je kladena celá řada omezení. Nejzásadnějším omezením pro použití síťové aplikace je fakt, že síťové spojení lze navázat pouze s počítačem (serverem) poskytujícím samotný Java Applet (je to ochrana před CSFR – Cross-site request forgery – bude zmíněno v kapitole 3.1) a i v tomto případě je uživatel před načtením appletu vyzván, zda chce applet připojený k síti načíst.
Zdroj: Autoři
Obrázek 4: Znázornění Adobe Flash peer-to-peer komunikace point-to-point
Zdroj: Autoři
Obrázek 3: Schéma vzájemné komunikace za použití sandbox Java Appletů Zde vidíme zásadní omezení v tom, že není možné realizovat čisté spojení typu peer-to-peer. Je možné realizovat spojení klient-server (viz obrázek 3). Druhým režimem JVM při použití v appletu je režim privileged. Tento typ appletu je podepsán certifikační autoritou, díky tomu je považován za „bezpečný“ pro koncového uživatele (počítač) a odpadají omezení režimu sandbox. Z toho vyplývá, že v privileged režimu je možné vytvořit applet funkčností rovnající se běžné Java aplikaci. Existuje ještě třetí možnost spuštění appletu, a to přes soubor JNLP. Připojením JNLP souboru k Java Appletu (při spuštění v rámci tagu či jiném). V tomto souboru lze nastavit bezpečností politiky pro plný přístup k hostitelskému OS. V řadě případů je i přesto vyžadována certifikace appletu – přístup k požadovaným prostředkům je zamítnut.[5] 2.2.2
V Adobe Flash Player jsou definovány dva možné způsoby užití peer-to-peer komunikace. Prvním typem komunikace je point-to-point, který zcela splňuje požadavky distribuované simulace, v tomto případě komunikace mezi klienty vždy probíhá mezi dvěma klienty – komunikace unicast v rámci skupiny (viz obrázek 4). Oproti tomu typ komunikace many-to-many pracuje na principu multicast, každá zpráva je odeslána všem klientům ve skupině (viz obrázek 5 – šedě jsou znázorněny počítače, které obdrží zprávu, aniž by jim byla adresována). Nevýhodou může být použití protokolu RTMFP, který je vystavěn nad protokolem UDP (předpokládá se primárně použité pro multicast komunikaci a streamování dat – video, audio), který má své opodstatnění v architektuře many-to-many a streamování dat, ale pro zasílání zpráv komunikací point-to-point (vyžadujeme) vhodný být nemusí, ale samozřejmě závisí na konkrétní realizaci a funkčních požadavcích na výsledný simulační model.
Adobe Flash
Technologie Adobe Flash byla původně vyvinuta pro realizaci především vektorové grafiky a animací (koncepce s časovou osou) na webové stránce. S příchodem HTML5 potřeba Flash Playeru odpadá, neboť vykreslovat grafiku v rámci webové stránky je možné pomocí tagu , případně SVG obrázky. Pro realizaci distribuované simulace je zajímavou vlastností realizace síťových spojení. Flash Player přímo podporuje peerto-peer spojení, z tohoto pohledu je ideálním kandidátem pro realizaci.
Zdroj: Autoři
Obrázek 5: Znázornění Adobe Flash peer-to-peer komunikace many-to-many Při použití komunikace server-klient, která se netýká komunikace v rámci domény (CSFR – Cross-site request forgery –
410
VOL.15, NO.6, DECEMBER 2013 bude zmíněno v kapitole 3.1) je nutné specifikovat bezpečnostní politiky v policy file. Toto nastavení je jednodušší než v případě Java Appletu, není vyžadována certifikační autorita. 2.2.3 Microsoft Silverlight Tato technologie je koncipována stejně jako Adobe Flash Player. V době před HTML5 prvky rozšiřovala, jako plugin třetí strany, možnosti pro tvůrce webových stránek o možnost realizace bitmapové i vektorové grafiky, přehrávání videa a audia a samozřejmě, pro řešení webové simulace, pokročilejší síťové funkce. U technologie Microsoft Silverlight je potřeba zmínit, že poslední aktualizace je verze 5 (prosinec 2011) a další vývoj nebude pokračovat. Společnost Microsoft počítá s podporou do roku 2021. Z tohoto pohledu je technologie použitelná ještě řadu let, ale bez perspektivy. Microsoft Silverlight je založen na platformě .NET, a umožňuje komunikovat po síti s omezeními podobnými Java Appletům či Adobe Flash – opět především ochrana před CSFR. Jsou zde také dva typy režimů, ve kterých Silverlight běží: sandbox (standardní stav) a trusted application. V obou případech je nutné specifikovat bezpečností politiky v policy file. [8] 2.3 Další rozšíření Existují další, často minoritně zastoupená, rozšíření (či jiným způsobem řešená integrace) do prohlížečů. Výběr nejznámějších: • Apache/Adobe Flex – využívá běhového prostředí platformy Adobe Flash, s tím rozdílem, že se zaměřuje primárně na tvorbu aplikací (Rich Internet Applications), nikoliv prezentací (původní účel Adobe Flash) dělenou na snímky. Z tohoto pohledu se může jednat o zajímavou alternativu k Adobe Flash (Playeru) – tvorba aplikace připomíná vytváření HTML stránky, která ale ve výsledku funguje zcela stejně jako Adobe Flash, neboť právě toto běhové prostředí Adobe/Apache Flex používá, z toho plyne, že jsou zde stejná síťová omezení. • Java FX – lze komunikovat po síti, ale obecně není vhodná, neboť tato nadstavba standardní Javy SE se soustřeďuje na vizuální prezentaci. Není zde důvod použít Java FX na místo Java Appletů (Java SE).
serveru. V tomto případě hovoříme o činnosti/spojení v rámci domény a komunikace klient-server probíhá oboustranně bez problémů. Pokud potřebujeme realizovat spojení serveru mimo doménu (server, ze kterého nebyl plugin stažen), musíme zpravidla vhodně nastavit tzv. policy files – soubory obsahující definici bezpečnostních zásad (tj. definice povolených a zakázaných funkcí či operací a síťových přístupů). V těchto souborech je nutné explicitně povolit volání klienta z konkrétního serveru či obecněji definované skupiny serverů. Grafické znázornění CSFR viz obrázek 6. 3.2 Peer-to-peer komunikace přes NAT Tato, pro distribuovanou simulaci nejvhodnější architektura, může narazit na problém vzájemného spojení klientů, pokud se vyskytují za NAT (Network Address Translation) routery. V tomto případě jsou klienti v lokální síti a s veřejnou sítí komunikují přes NAT routery, které pro ně tvoří bránu do veřejné sítě. Při tomto řešení je problém s adresací klienta za NAT routerem, neboť v pohledu z veřejné sítě klient není viditelný (je viditelný pouze NAT router), a je tedy nedosažitelný. V tomto případě není možné přímo vytvořit peer-to-peer spojení. Problém je možné překonat například použitím protokolu ICE [9], přestože možností je více. Tento je zde uveden z důvodu implicitního využití technologií WebRTC. Předpokládá se použití inicializačního serveru, který zprostředkuje spojení (standardní stav v rámci peer-to-peer komunikace, běžně je minimálně třeba autorizace klienta vstupujícího do (distribuovaného) systému.[7]
3 Síťová komunikace v rámci veřejné sítě V této části se podíváme na dva hlavní, a značně omezující problémy, se kterými musíme počítat, pokud budeme využívat síťovou komunikaci nejen v internetovém prohlížeči. Zdroj: Autoři
3.1 Cross-site request forgery (CSFR, XSRF) Jedná se o typ útoku, kdy je na straně klienta kontaktována aplikace na vykonání nějaké akce (často s cílem získat informace), či obecně použitá jako brána do systému pro útočníka. Pluginy do internetových prohlížečů možnost takovéhoto útoku řeší automaticky v rámci aplikovaných bezpečnostních politik – zpravidla pracují s myšlenou, že server může kontaktovat klienta, pouze pokud je klientská (část) aplikace stažena z dotyčného
Obrázek 6: Cross-site request forgery V dále uvedeném algoritmu předpokládáme 2 počítače/klienty A a B a jejich zařazení za maximálně jeden NAT router (ne port-forwarding router) z pohledu veřejné sítě. Následující postup ICE protokolu je zjednodušen – pouze základní náhled na problematiku, se kterou se architekt distribuované simulace přes peer-to-peer spojení musí vypořádat (viz obrázek 7):
411
VOL.15, NO.6, DECEMBER 2013 Klient A kontaktuje přes port X STUN server. STUN odešle zpět číslo portu Y, ze kterého byl klientem A kontaktován. Pokud klient na základě odpovědi (shoda čísla komunikačního portu požadavku klienta na STUN a čísla portu v odpovědi STUN serveru) zjistí, že počítač je dostupný z veřejné sítě (má veřejnou adresu IP – v tomto případě se port X = Y) není problém v komunikaci – klient může navázat spojení a ICE protokol končí. 2. Pokud klient, na základě odpovědi STUN serveru zjistí, že není veřejně dostupný (čísla portů požadavku a odpovědi si neodpovídají, tedy X ≠ Y), klient A odešle přes inicializační server číslo veřejného portu Y, na kterém se ho podařilo STUN serveru kontaktovat, klientovi B se kterým bude komunikovat. 3. Kroky 1 a 2 provede i klient B. 4. Klienti A a B naváží spojení na veřejných IP a portech, které si přes inicializační server poslaly. 5. Pokud přímá komunikace klientů A a B není možná (blokuje ji NAT router, firewall, …) přichází na řadu TURN server, který bude mezi klienty fungovat jako spojovací prvek. TURN server bude přeposílat zprávy z jednoho klienta na druhý. Tento stav již neodpovídá peer-to-peer architektuře, ale klient-server-klient síťové topologii. Použití TURN serveru není ideální, je zde vysoká latence a zátěž na samotný server, ale je to v tomto případě jediné řešení, jak spojit klienty A a B. Tento stav je ale spíše výjimečný, běžně je možné použít pouze STUN protokol. Pro realizátora distribuovaného řešení je zásadní, že STUN i TURN servery jsou k dispozici jako open-source a pro známé programovací jazyky (Java, C#, C++, …) jsou dostupné knihovny, které protokol ICE jsou schopné zrealizovat. 1.
Zdroj: Autoři
Obrázek 7: peer-to-peer spojení
4 Distribuovaná simulace ve výuce Fakulta elektrotechniky a informatiky Univerzity Pardubice usiluje o zapojení studentů do praktické výuky distribuované simulace. V rámci této filozofie jsou připraveny dokumenty a jiné podklady popisující procedury a rozhraní, dle kterých jsou vytvářeny distribuované simulační modely samotnými studenty.
Studenti realizují pouze logické procesy, ostatní prvky infrastruktury (serverové prvky, apod.) jsou sdíleny z univerzitních zdrojů. Cílem práce studentů je vytvořit schůdné podmínky pro realizaci studentských prací. Z tohoto důvodu bylo zavedeno: • Realizace v programovacím jazyce Java, který je na univerzitě vyučován od prvního ročníku – je studentům důvěrně známý. • Zavedení „veřejného“ serverového síťového prvku v rámci univerzitní sítě. Tento prvek jde, do určité míry, proti myšlence peer-to-peer sestavy klientů, která je vhodná pro distribuované simulace, má ale praktické důvody. Důvody zavedení tohoto prvku jsou uvedeny v další kapitole. • Zadání přesných specifikací jednotlivých zpráv, pomocí kterých logické procesy komunikují (a kterým rozumí serverový prvek). Stejně tak jsou zveřejněny XML schémata XML konfiguračních souborů.[6]
4.1 Princip komunikace Vhodné je použití síťové architektury peer-to-peer, neboť logické procesy primárně komunikují mezi sebou, a žádný centrální prvek (server) nepotřebují (vyjma případů inicializace spojení, …). Realizované distribuované modely jsou zatíženy školním prostředím, kde je nutné sledovat činnosti studentů, a provádět účtování jejich práce. Z tohoto důvodu realizujeme spojení klient-server-klient. Toto, ne zcela optimální řešení, přináší několik problémových faktorů, které musíme brát v potaz: • Zvyšuje se komunikační režie celého modelu (místo jednoho spojení klient-klient musíme realizovat dvě spojení klient-server a server-klient). • Server je dalším výpočetním uzlem, jehož odezva (ať již síťová, či výpočetní) zpomaluje výslednou činnost distribuovaného simulačního modelu. Navržené řešení ale naopak obsahuje celou řadu výhod: • Centrální prvek lze rychle, jednoduše a účelně použít pro účtování činnosti celého modelu i jednotlivých logických procesů. • Komunikaci se serverovým prvkem lze v rámci výuky použít pro debugování síťového chování (zasílaných zpráv) logického procesu vůči svému okolí (komunikujeme vždy přes jeden známý prvek – který provoz loguje a tím nám dává odezvu stavu reálného síťového provozu), vytvořeného studentem. • Komunikace v Javě (Java applet) typu klient-server je zcela přirozená a neklade na tvůrce zbytečné nároky, oproti komunikaci peer-to-peer (problémy s NAT servery, bezpečnostní politiky v rámci ochrany přes CSRF, atd.). Výsledná komunikace při odeslání zprávy od LP1 pro LP2 přes server je zobrazena na obrázku 8 (oranžově jsou znázorněny odpovědi serveru o stavu přijetí/přeposlání k adresovanému klientovi).
412
VOL.15, NO.6, DECEMBER 2013 Tento souhrn možností je dostatečný pro libovolnou (vzhledem k zapojení XML) realizaci distribuovaného modelu.[2] 4.2.1 Synchronizace logických procesů Dokumentace obsahuje popis synchronizačních zpráv – používáme metodu zasílání nulových zpráv na vyžádání s uplatněním výhledu. Tuto metodu podrobně popisujeme v článku [1].
Zdroj: Autoři
Obrázek 8: Síťová komunikace 4.2 Koncepce a možnosti distribuovaných modelů Celé řešení je koncipováno pro použití v akademickém prostředí – převážně studenty a odbornými pracovníky. Z tohoto důvodu jsme vytvořili dokumentaci popisující procesy komunikace mezi logickými procesy, struktury předávaných dat a podmínky zařazení logického procesu do systému. Tento dokument podrobně specifikuje možnosti a zapojení logických procesů s přihlédnutím k možnosti rozšíření (především XML konfigurace) bez nutnosti změn v systému. Logické procesy jsou koncipovány tak, aby komunikovaly přes server – účtování a přeposílání zpráv z důvodu obejití bezpečnostních politik jednotlivých klientů. Jak již bylo uvedeno, logické procesy uvažujeme jako realizované pomocí appletů v prohlížeči (i když toto není ve skutečnosti povinné – jakýkoliv jiný program splňující specifikované podmínky a rozhraní lze použít jako logický proces). Každý logický proces, který studenti vytvoří, odpovídá jednomu appletu. Pro správu simulačních modelů je vytvořeno administrační rozhraní (viz obrázek 9) pro správce, které pracuje se zavedenými omezeními, pravidly a restrikcemi popsanými v dokumentaci: • Logický proces: o libovolné (jsou zde kladeny podmínky na spojení – viz další body) řetězení appletů, o vícenásobné použití appletu v rámci jedné simulace, o přiřazení logickému procesu „pracovní stanici“ 2 – umožní přiřadit logickému procesu obsluhu a jednoduše ji kontaktovat, o definice možností nastavení pro konkrétní LP • Entity zapojené v distribuovaném prostředí: o rozlišování typů. • Spojování logických procesů: o rozlišování vstupních a výstupních bodů, o restrikce při spojování logických procesů založená na požadavcích na konkrétní typ (či typy) entit. • Globální nastavení konkrétní simulace: o výchozí čas, o násada generátoru náhodných čísel (opakovatelnost sezení simulace). • Možnost editace konfigurace pomocí XML souborů nad rámec běžných (výše popsaných) možností editace.
Zdroj: Autoři
Obrázek 9: Administrační rozhraní ve webovém prohlížeči 4.3 Zapojení studentů do výuky Distribuovaná simulace je, ze své podstaty, realizována jako množina logických procesů provozovaných autonomně, ale navzájem komunikujících. Tento přístup přímo aplikujeme na skupinu studentů. Optimální průběh realizace studentského řešení distribuovaného simulačního modelu: 1. Studenti jsou rozděleni do skupin. 2. Každá skupina obdrží zadání složitějšího modelu. 3. Model musí studenti dekomponovat na jednodušší logické celky, tj. budoucí logické procesy. V tuto chvíli existuje reálná představa o logickém uspořádání výsledného modelu. 4.
5.
Studenti zahájí programování jednotlivých logických procesů, zpravidla aplikujeme metodou „Jeden student, jeden logický proces“. Studenti jsou nuceni realizovat svá řešení dle předem známých postupů a rozhraní popsaných v dokumentaci.
5 Závěr Článek uvádí čtenáře do problematiky webové simulace a hlavně nových HTML5 možností internetových prohlížečů, se kterými již lze realizovat webovou simulaci pouze s použitím prohlížeče, tedy bez doplňujícího softwaru třetích stran – tzn. pluginů. Byly představeny síťové architektury peer-to-peer (v roli klientů jsou prohlížeče) a klient-server-klient (uplatněné
2 Jednoduchý záznam obsahující jméno a e-mailovou adresu pracovníka.
413
VOL.15, NO.6, DECEMBER 2013 v praxi) jako použitelné pro distribuovanou webovou simulaci. Představena byla množina požadavků na specifikaci distribuovaného simulačního modelu pro zcela obecné použití a ukázka administračního prostředí pro vytváření a správu simulací. Webová simulace přináší perspektivu vytváření logických procesů zapojených v rámci veřejné sítě (např. sítě Internet) bez ohledu na platformu či architekturu procesoru. Softwarovou platformu, standardně realizovanou jako instalovanou desktopovou aplikaci, nahradí internetový prohlížeč, který je dnes zdarma dostupný na běžném počítači připojeném do sítě Internet. Při vytváření webového simulačního modelu nemusíme řešit (vyjma problémů, zpravidla vzešlých z bezpečnostních důvodů, se síťovým provozem) žádné doprovodné vývojové problémy týkající se běhového prostředí (již zmíněná desktopová aplikace). Bezpečností politiky zavedené v rámci prohlížečů či pluginů mohou být „nepříjemné“, nicméně přímo řeší zabezpečení klienta a při použití „standardního“ běhové prostředí (desktopová aplikace) bychom tyto bezpečností rizika museli řešit vlastními silami. Při použití platformy webového prohlížeče se tedy můžeme soustředit na hlavní cíl, tj. budování distribuovaných simulačních modelů běžících v internetovém prohlížeči a nemusíme řešit standardní bezpečnostní rizika, která jsou spojena s desktopovými aplikacemi. Moderní technologie HTML 5 a JavaScript nám navíc otevírají možnost přenést webové distribuované simulace z klasických počítačů a notebooků nejen na mobilní zařízení typu tablety a chytré telefony, ale dnes už také i na chytré televizory.
Literatura [1] Hřídel J., Karták Š. Web jako platforma pro simulaci. Elektrorevue [online]. 2012, 2012/69, ISSN: 1213-1539, [cit. 2013-08-20]. Dostupné z: http://www.elektrorevue.cz/cz/clanky/informacni-technologie/0/web-jakoplatforma-pro-simulaci-1/ [2] Karták Š., Softwarový nástroj pro konfigurování distribuovaných simulačních modelů využívajících webovou simulaci. Pardubice 2013, Diplomová práce. Univerzita Pardubice [3] WebRTC [online]. 2013 [cit. 2013-09-30]. Dostupné z: http://www.webrtc.org/ [4] WebSocket.org [online]. [cit. 2013-09-30]. Dostupné z: http://www.websocket.org/ [5] Martin D., Rajagopalan S., Rubin A., Blocking Java Applets at the Firewall, Boston University, Boston MA, Dostupné z: http://avirubin.com/block.java.pdf [6] Hřídel J., Karták Š., Web-based simulation in teaching. European Simulation and Modelling Conference 2013. Belgie, 2013, s. 109-113, ISBN: 978-90-77381-79-3. [7] Fox, G., Peer-to-peer networks. Computing in Science & Engineering 2001, 3: s. 75-77. [8] Macdonald, Matthew. Pro Silverlight 5 in C#: 4th Edition. Apress, 2012. ISBN 978-1-4302-3479-1. [9] RFC 5245: Interactive Connectivity Establishment (ICE). [online]. [cit. 2013-09-15]. Dostupné z: http://tools.ietf.org/html/
414