Principy dynamických webových aplikací

Principy dynamických webových aplikací

Zeptáte-li se současných studentů informatiky, co si představují pod pojmem počítačový program či aplikace, zřejmě jen málokterý jím bude rozumět jediný spustitelný soubor, ze kterého se zavede kód procesu pro operační systém. S propojením počítačů do celosvětové sítě, s příchodem mobilních zařízení jako PDA či „chytré„ mobilní telefony, se standardizací komunikačních protokolů a aplikačních vrstev se význam pojmu aplikace posunuje. V současné době se aplikací rozumí spíše sada komponent a skriptů pracujících na straně serveru i v klientských prohlížečích, komunikujících s databázovým strojem a prostřednictvím HTTP serveru zprostředkovávajících informace klientům. Podobu webové aplikace tak získávají služby jako např. hledání v telefonním seznamu, nalezení místa na mapě, vyhledávání autobusových či vlakových spojů apod. Tento koncept aplikací se začíná uplatňovat i mimo prostředí rozlehlého internetu. Veškeré existující nástroje, znalosti a zkušenosti programátorů lze uplatnit i pro aplikace pracující v prostředí lokálních sítí (intranetů) a stejnou podobu tam může získat třeba účetní systém či skladová agenda firmy. Dokonce i na lokálním počítači existuje několik aplikací, které pro vytvoření uživatelského rozhraní používají stejný koncept, tedy řadu HTML stránek. S dalším rozvojem různých oborů informatiky, jako jsou bezdrátové sítě, přenosné počítače s nízkou spotřebou apod., se tento trend bude dále posilovat.

Aplikace počítačů v průmyslu vykazují často až podivuhodnou rezistenci proti přílivu nejnovějších metod zpracování dat a otevřených standardů (tato rezistence je často dobře odůvodněna požadavky na maximální spolehlivost a robustnost, naproti tomu stejně často hlavní příčina spočívá v neochotě naučit se cokoliv nového i tehdy, když by nová metoda výrazně zvýšila užitečnost aplikace a zlevnila řešení). Přesto je výhodnost internetových a intranetových řešení pro množství aplikací natolik zřejmá, že začínají pronikat i do tohoto konzervativního odvětví. Webový prohlížeč (WWW browser) je dnes přítomen na každém počítači a stejně tak každý počítač v podnikové sféře je zapojen do sítě. Možnost zpřístupnit vizualizaci a popř. i řízení průmyslového procesu z libovolného počítače se tak pro zákazníky stává velkým lákadlem.

Nelze však od vizualizace v prostředí webového prohlížeče očekávat stejné možnosti jako od aplikačního programu pracujícího na lokálním počítači. V prostředí prohlížeče je uživatel omezen internetovými standardy formátů dokumentů a obrázků, možnostmi programování (skriptování), standardy pro zabezpečení apod. Další omezení se týkají např. dob reakce systému na požadavky na komunikaci s PLC nebo měřicími jednotkami apod. Zatímco lokálně běžící aplikace musí být schopna řídit komunikaci v reálném čase a popř. reagovat na zpoždění či poruchy komunikace, realizovat stejnou funkci (se srovnatelnou dobou odezvy) v prostředí webového prohlížeče je téměř nemožné. Přitom platí jedno pravidlo – čím širší má být okruh klientů schopných k aplikaci přistoupit (např. pomocí různých typů prohlížečů pracujících na různých operačních systémech), tím více omezeními bude aplikace zatížena. Extrémem může být např. aplikace pracující na miniaturních zobrazovačích mobilních telefonů, pro jejichž tvorbu je nutné vystačit se základním kódem HTML a jediným formátem obrázků.

Přítomnost zabudovaného HTTP serveru, díky němuž mohou k aplikaci přistupovat uživatelé prostřednictvím webových prohlížečů, byla jedním z důvodů pojmenování programového systému pro rychlý vývoj průmyslových vizualizačních a řídicích aplikací Control Web. Ačkoliv v první verzi systému Control Web 3 byl HTTP server vhodný spíše pro menší aplikace v rámci intranetu, narůstající požadavky zákazníků vedly k podstatnému rozšíření množiny funkcí, usnadnění programového řízení, zpřístupnění hlaviček protokolu HTTP, zvýšení robustnosti (např. detekci a odražení pokusů o získání kontroly nad serverem útokem typu „buffer overrun„¹⁾) apod. Všechny tyto inovace vedly k verzi HTTP serveru v systému Control Web 5, způsobilé plnohodnotně pracovat nejen jako webová brána do technologického procesu, ale také v roli podnikového webového serveru s kompletním redakčním systémem, schopným obsloužit velké množství klientů. Protože statické, „ručně“ tvořené HTML stránky již neodvratně patří minulosti, na tuto práci nestačí HTTP server sám, ale potřebuje k tomu další komponenty systému Control Web, především pro přístup k SQL databázím. Klíčovou roli při tvorbě takových webových aplikací sehrává výkonný skriptovací jazyk systému Control Web (obr. 1).

Generování HTML stránek

Přístup k HTML stránkám je dnes již považován za naprostý základ počítačové gramotnosti – v žádném kursu používání počítače se s webovým prohlížečem nelze minout. Povědomí o tom, co se za službou WWW (World Wide Web) skrývá, ale už zdaleka není běžné, i když samotný princip je velmi jednoduchý.

Aby si dva počítače mohly vyměňovat data, musí oba používat stejný dorozumívací jazyk. Protokol užívaný při komunikaci mezi klientem a serverem služby WWW nese označení HTTP (HyperText Transfer Protocol). V prostředí internetu jsou používány i další protokoly, např. SMTP (Simple Mail Transfer Protocol) pro přenos elektronické pošty, FTP (File Transfer Protocol) pro přenos souborů apod. Nedejme se ale zmýlit názvem protokolu: HTTP lze použít k přenosu jakýchkoliv dat, nejen hypertextových dokumentů. Pomocí HTTP lze přenášet obrázky, spustitelné binární soubory, komprimované archivní soubory apod. Protože server služby WWW komunikuje s klienty pomocí protokolu HTTP, bývá také nazýván HTTP server²⁾. Pominou-li se technické detaily navazování síťového spojení na portu služby HTTP serveru, celé kouzlo WWW spočívá v odesílání požadavků protokolem HTTP k serveru z klientské aplikace, na které server odesílá v tomtéž protokolu odpovědi. Základním požadavkem je požadavek typu get – získej data. O jaká data má klient zájem, určuje tzv. URL (Universal Resource Locator). URL má v prostředí WWW podobnou funkci jako jméno souboru na lokálním počítači – pojmenovává zdroj dat. URL ale navíc může nést další informace a parametry pro server.

To, jak s daty naložit, je už záležitost klientské aplikace (webového prohlížeče). Poskytne-li server textový soubor formátovaný podle pravidel HTML (zkráceně HTML soubor; obdobně HTML stránka je dokument vytvořený podle pravidel HTML), prohlížeč jej zformátuje podle značek v souboru obsažených. Značky určují např. nadpisy, dělení odstavců apod. HTML stránka ale může obsahovat další data, např. obrázky. Obrázky nejsou obsaženy přímo v textu HTML souboru, ale ve stránce je na ně uveden pouze odkaz v podobě URL. Klient pošle další dotaz serveru s danou URL a server odpoví blokem dat, tentokráte obsahujícím požadovaný obrázek. Vrácený obrázek pak klient zobrazí v rámci stránky.

Podobnost URL se jménem souboru svádí k představě, že HTTP server pouze převede URL obdrženou od klientské aplikace na jméno lokálního souboru a tento soubor jí vrátí. V případě statické webové aplikace je tomu skutečně tak – všechny HTML dokumenty, obrázky a další soubory tvořící aplikaci jsou připraveny na disku a HTTP server je čte a odesílá klientům. Nevýhodou takové aplikace ale je velmi pracná údržba. Jakákoliv změna v řadě dokumentů provázaných hypertextovými odkazy je obtížně proveditelná a zdlouhavá. Žádná rozsáhlejší webová aplikace takto konstruována není – prostě z důvodu naprosté neudržovatelnosti. Řešení je zřejmé: na místo statické struktury souborů na straně serveru běží aplikace, která obsahy stránek vytváří algoritmicky.

Jako příklad lze zmínit úvodní stránku webové aplikace, která má obsahovat odkazy na články vložené za poslední týden. Ruční údržba takové stránky by znamenala neustálé sledování nově vložených článků a dopisování odkazů na ně do HTML souboru představujícího úvodní stránku a také odmazávání starších odkazů. Naproti tomu u stránky tvořené kódem procedury probíhá vše automaticky. Procedura se dotáže SQL serveru na články s datem vložení nejpozději sedm dní nazpět a algoritmicky vytvoří HTML dokument, který odešle klientu. Klientská aplikace nemůže rozlišit, jak HTML dokument, který jí poslal server, vznikl, a vlastně to ani nepotřebuje. Jestliže dokument odpovídá pravidlům HTML, může jej korektně zobrazit. To je celý vtip dynamické webové aplikace.

Pro ilustraci uveďme základní příklad dynamické tvorby kořenové stránky v systému Control Web 5:

Odešle-li webový prohlížeč serveru dotaz s URL ’/’ (základní nebo tzv. indexová stránka), server ví, že tento soubor nemá hledat na disku, ale pro jeho vytvoření má zavolat proceduru GenerateIndex. Kód této procedury vytvoří text stránky postupným voláním PutText. Webový prohlížeč obdrží HTML dokument:

a jak bylo řečeno dříve, není schopen rozlišit, zda tento dokument byl uložen v podobě souboru na disku, nebo zda byl vytvořen algoritmicky.

U jednoduché stránky nepřináší dynamické generování žádné zjevné výhody, snad mimo skutečnost, že celá webová aplikace může pracovat zcela bez přístupu na disk. Uvažme ale následující proceduru GenerateIndex:

V tomto případě je výhoda dynamického generování již zjevná. Především jediná procedura tvoří HTML text odpovídající tabulce nebo seznamu na základě nějaké podmínky. Dále stojí za zdůraznění, že délka stránky není předem dána, ale záleží na hodnotě proměnné lines. Na samém konci stránky je zobrazeno počítadlo přístupů, aktuální datum a čas. Každý klient vždy ze serveru přečte HTML dokument s jiným textem (lišící se minimálně zobrazeným počtem přístupů a také datem a časem), i když požádá o stejnou stránku.

Aplikace, nebo jen prohlížení dokumentů?

Prapůvod služby WWW leží v systému zpřístupňujícím vědcům dokumenty v evropském středisku jaderného výzkumu CERN. Možnost zabudovat do textu odkaz na jiný dokument (odtud název hyper-text) dělá z obyčejných textů jednoduchou aplikaci, reagující na přání uživatele – kliknutí na odkaz způsobí zavedení nového dokumentu do prohlížeče. Kdyby možnosti HTML zabudováním odkazů na jiné soubory do textu končily, asi by nebylo možné hovořit o aplikačním prostředí. Popularita WWW ale zapříčinila prudký vývoj HTML a postupně začaly přibývat možnosti nejen zabudování obrázků do dokumentu, přesnějšího formátování, ale také možnosti tvorby formulářů, v nichž uživatelé mohou zadávat data pro aplikaci. Vývoj se ale nezastavil a standard pro HTML obsahuje možnost psaní skriptů (skripty v HTML stránce představují programový kód, který je ve webovém prohlížeči vykonáván), kaskádní styly, dynamické HTML apod. Dnes tedy již jde o HTML jako relativně bohaté a mocné aplikační prostředí.

Nedílnou součástí definice protokolu HTTP je mimo požadavky na čtení dat ze serveru (metodou get) i zápis dat na server metodou put. V praxi se ale tato metoda nepoužívá, protože není podporována klientskými aplikacemi, ale především obsahuje množství bezpečnostních rizik – v principu je nemyslitelné, aby klientské aplikace ukládaly soubory na server na zadané URL. Proto je odesílání dat od klientu na server omezeno na dvě metody protokolu HTTP:

• lze použít metodu get s daty zakódovanými v URL,
• přímo k odesílání dat serveru je určena metoda post.

Poznamenejme, že protokol HTTP nedefinuje mechanismy zpracování dat. Záleží výhradně na serverové aplikaci, jak s daty naloží.

Ačkoliv metoda post byla původně navržena pro odesílání dat z HTML formulářů, byla rozšířena i o možnost odesílání celých souborů. Na rozdíl od metody put ale v tomto případě URL neurčuje, kam daný soubor na serveru uložit, ale spíše definuje, která část serverové aplikace bude soubor zpracovávat. Jak se souborem naložit, je opět záležitostí implementace serverové aplikace – např. může uložit soubor do databáze apod.

Systém Control Web nabízí několik způsobů zpracování dat odeslaných uživateli na server.

Nejjednodušším je definování vazeb mezi jmény ovládacích prvků v HTML stránce a datovými prvky v aplikaci. Odešle-li uživatel data z formuláře do aplikace, patřičné datové prvky nabudou hodnot vyplněných ve formuláři.

Je-li část nebo celá HTML stránka tvořena kódem procedury, může programátor pomocí procedury GetURLData získat řetězec, který obsahuje jména a hodnoty ovládacích prvků z formuláře. Je pak na programátorovi, aby z tohoto řetězce získal patřičné hodnoty.

Protože GetURLData lze volat jen z procedury reagující na požadavek get, data zasílaná metodou post je možné zachycovat procedurou OnFormData. Tato procedura je volána vždy, když serveru přijdou data z formuláře, ať již metodou get nebo post.

Využívá-li aplikace rozšíření metody post dovolující uživatelům odesílat na server celé soubory, může využít událostní procedury OnPostFile.

Zde je možné konečně vysvětlit, odkud se vzaly hodnoty proměnných display_table a lines v předchozím příkladu. HTML formulář obsahuje pojmenované ovládací prvky, a když je formulář odeslán serveru, jména a hodnoty těchto ovládacích prvků jsou připojeny do URL:

V HTTP serveru potom stačí uvést mapování mezi jmény ovládacích prvků a jmény proměnných v aplikaci:

 forms
  item
   id = "line_count";
   output = lines;
  end_item;
  item
   id = "display_format";
   output = display_table;
  end_item;
 end_forms;
 ...
end_httpd;

Problémy může způsobovat nejednoznačnost definice chování serveru při odpovědi na metodu post v rámci standardu HTTP. Součástí post je totiž URL, definovaná atributem action v definici formuláře v HTML dokumentu. Podle definice tato URL ale slouží k identifikaci entity, jíž se data odesílaná v rámci post týkají. Není specifikováno, zda mají být data odkazované URL v post vrácena (stejně jako po get) či nikoliv. Zkušenosti z praxe ukázaly, že optimální chování serveru po post, maximálně ulehčující tvorbu webových aplikací, je chování odpovídající metodě get. Existují-li data odkazovaná v URL u post, jsou vrácena s kódem 200 OK, jestliže data neexistují, není vráceno hlášení 404 Not Found jako po get, ale 204 No Content.

Optimalizace toku dat po síti TCP/IP

Mechanismy vyrovnávacích pamětí, kdy jsou data uchovávána v místě potřeby a nikoliv pokaždé přenášena z místa vzniku, se ukázaly jako mocný způsob zrychlení a zefektivnění práce v mnoha technických i programových systémech. Například vyrovnávací paměť v procesoru mu umožní pracovat mnohonásobně rychleji, než by umožnila rychlost vnějších pamětí, vyrovnávací paměť disku zvýší jeho efektivní přenosovou rychlost apod.

Stejným způsobem mohou vyrovnávací paměti protokolu HTTP výrazně urychlit zpřístupnění webových stránek. Webové stránky obsahují mnoho statických obrázků, které se po dlouhou dobu nemění, a je zbytečné, aby je prohlížeč pokaždé ze serveru zaváděl. Z tohoto důvodu si každý prohlížeč uschovává určité množství dokumentů a obrázků na lokálním disku počítače, odkud je může zavést a zobrazit nepoměrně rychleji než po seberychlejší internetové síti.

V rámci internetu i intranetů se lze setkat se specializovanými servery pracujícími jako vyrovnávací paměť protokolu HTTP. Jestliže více klientů (např. v rámci podnikové sítě) nepřistupuje na vzdálený server přímo, ale prostřednictvím tzv. vyrovnávacího serveru (proxy server), může to výrazně zrychlit přístup k webovým stránkám. První klient způsobí zavedení stránek do vyrovnávacího serveru, u dalších klientů se vyrovnávací server pouze ubezpečí, zda data na původním serveru nebyla změněna, a jestliže ne, vrátí data ze své vyrovnávací paměti místo jejich pomalého přenosu přes internet. Oba mechanismy (vyrovnávací paměť webového prohlížeče i specializované vyrovnávací servery) jsou si velmi podobné a využívají velmi podobné metody.

Klíčovou otázkou v každém systému s vyrovnávací pamětí je zajištění konzistence dat. Jestliže se např. obrázek na serveru změní, bylo by od klientu chybné zobrazovat obrázek uložený v lokální vyrovnávací paměti. Ovšem klient nemá jinou možnost, jak zjistit aktuálnost své vyrovnávací paměti, než dotázat se serveru. S každým blokem dat přenášeným protokolem HTTP (pod blokem dat se rozumí např. HTML dokument, obrázek apod.) je přenášena informace o okamžiku jeho poslední modifikace. Klient tedy ví, jak starý je dokument uložený v lokální vyrovnávací paměti, musí jen zjistit stáří právě aktuálního dokumentu na serveru.

K tomu byla do protokolu HTTP zabudována další metoda, nazvaná head. Tato metoda odpovídá metodě get (obsahuje URL i další údaje v požadavku), ovšem klient očekává jako odpověď pouze hlavičku bloku dat. Protože hlavička obsahuje informace o čase poslední modifikace, může se klient rozhodnout, zda o data požádá tentokrát metodou get, nebo zda použije data z lokální vyrovnávací paměti.

Použití dotazu head může ušetřit zbytečné přenosy, jestliže ale dokument není aktuální, znamená prodloužení přenosu o jeden dotaz head a odpověď. Z tohoto důvodu bývá v prostředí internetu používána alternativní metoda. Klient požádá o data server metodou get, ale do protokolu uvede hlavičku informující server, aby data odeslal jen tehdy, jestliže byla modifikována od zadaného data odpovídajícího datu poslední modifikace dat v lokální vyrovnávací paměti. Server sám posoudí aktuálnost dat, a jsou-li k dispozici data novější, přímo odpoví. Jestliže ne, informuje klientskou aplikaci, že data nebyla modifikována, a žádná data neodesílá. Tento způsob zaručuje skutečně minimální zatížení sítě a optimální přenos dat. HTTP server v systému Control Web podporuje oba způsoby optimalizace přenosu.

Popsané mechanismy si lze velmi snadno představit u statických dokumentů uložených jako soubory. Okamžik poslední modifikace každého souboru je zapsán v souborovém systému a HTTP server jej může využít. Je-li ale dokument generován dynamicky, situace se velmi komplikuje:

• U dynamického generovaného dokumentu je okamžik poslední modifikace vždy nastaven na aktuální čas. Klient tedy nikdy nemůže mít aktuální verzi a vždy musí přenést data ze serveru.

• Ne vždy se ale dynamicky generovaná stránka skutečně liší od stránky generované předchozím dotazem. Jestliže např. algoritmus slouží pouze k dekódování URL a vrácení dat uložených v databázi, je zbytečné nastavovat okamžik poslední modifikace na aktuální datum a čas. Pomocí procedury SetLastModified může klient nastavit okamžik poslední modifikace a Control Web HTTP server automaticky vrátí data klientu nebo mu oznámí, že data nebyla modifikována. Ačkoliv u webových serverů nebývá limitní výkon počítače, ale kapacita přenosových linek, procedura generující stránku může voláním GetHeader zjistit hodnotu hlavičky If-Modified-Since a rozhodnout se, zda je zapotřebí stránku vygenerovat či ne. Nastaví-li voláním SetLastModified datum rovné datu v hlavičce If-Modified-Since nebo menší, server klientu odpoví kódem 304 Not Modified, a tak není nutné ztrácet čas vytvářením stránky.

• Jestliže algoritmus generující stránku pouze přesměruje tok dat do souboru voláním RedirectToFile jako okamžik poslední modifikace také nebude použit okamžitý čas, ale čas poslední modifikace souboru.,

Control Web dokáže dynamicky generovat dokumenty zcela bez zásahu uživatelského programu. Je-li třeba např. webovým prohlížečům přenášet okamžitou podobu nějakého virtuálního přístroje, lze to zajistit velmi jednoduchým mapováním URL obrázku na viditelný virtuální přístroj v aplikaci:

Kdykoliv se v HTML stránce objeví odkaz na obrázek img1, server nebude prohledávat disk (soubor s tímto jménem by ani nenalezl), ale vykreslí okamžitou podobu přístroje se jménem panel_energie. V tomto případě je okamžik poslední modifikace vždy nastaven na aktuální čas.

Control Web 5 jako HTTP server

Mocnost HTTP serveru zabudovaného do systému Control Web 5 dokazuje aplikace vyvinutá pro běh na serveru http://www.mii.cz. Aplikace obsahuje nejen „klientskou„ část, která zobrazuje data návštěvníkům serveru, ale taká administrativní část, umožňující pohodlnou správu celého serveru (obr. 2).

Serverová aplikace odpovídá všem nárokům na moderní informační webový server:

• Veškeré texty jsou ukládány ve formátu XML, užívajícím jednotnou definici typu dokumentů. Tím je zaručeno jednotné a konzistentní formátování v rámci všech stránek. Změnou transformací XML lze najednou změnit vzhled všech textů. Server tak zcela odděluje obsah dat a jejich formátování.

• Žádná data nejsou uložena staticky. Veškeré texty jsou generovány do formátu HTML ze zdrojových XML souborů dynamicky za běhu aplikace.

• Veškerá data jsou uložena v SQL databázi. Datový obsah tak lze jednoduše zálohovat či replikovat.

• Vzhled stránek je definován algoritmicky na základě struktury dat. Jestliže např. do nabídky firmy přibude nový produkt, stačí přidat do aplikace jeho popis a zařadit jej do patřičné kategorie. Anotace s odkazy na detailní popis se automaticky objeví v příslušné stránce s popisy produktů, popř. ve stránce novinek apod.

• Zcela automatizovaná je podpora vkládání obrázků do dokumentů. Index obrázků je uložen v databázi, a tak je potenciální výměna obrázků snadnou záležitostí. V rámci transformace XML do HTML jsou podle atributů spojených s obrázkem automaticky generovány malé či velké náhledy, odkazy na obrázek v plném rozlišení apod.

Tvůrci obsahu mají k dispozici administrativní rozhraní, umožňující měnit strukturu kategorií a přidávat či modifikovat články, popisy, obrázky apod. Celé rozhraní pracuje v rámci standardního webového prohlížeče, z důvodu bezpečnosti lze přístup k tomuto rozhraní omezit nejen jménem či heslem, ale také určitými IP adresami či maskami IP sítí.

Základní operace s kategoriemi (přepojování podkategorií, editace anotace apod.) jsou implementovány pomocí HTML formulářů. Nicméně editační možnosti ovládacích prvků HTML formulářů jsou natolik omezené, že pohodlná editace delších článků se složitějším formátováním je téměř nemožná. Proto systém nabízí stažení zdrojového tvaru článků ve formátu XML na lokální počítač, kde je možné článek editovat jakýmkoliv editorem XML. Poté je možné dokument opět nahrát na server. Serverová aplikace zkontroluje správnost odkazů a dostupnost obrázků, popř. vyzve uživatele k zadání umístění obrázků na lokálním počítači, automaticky je přenese na server a zařadí do databáze (obr. 3).

Aplikace http://www.mii.cz demonstruje pouze malou část schopností systému Control Web zaměřenou na tvorbu distribuovaných aplikací v prostředí internetu a intranetů pro uživatele používající webové prohlížeče. Velké množství dalších oblastí, jako např. tvorba distribuovaných aplikací založená na tlustých klientech, sdílených a synchronizovaných datových sekcích, automatické generování DHTML aplikací, pokročilá prostorová vizualizace procesů atd., ale mnohonásobně přesahuje možnosti tohoto článku.

Ing. Pavel Cagaš,
Moravské přístroje

Moravské přístroje, a. s.
Masarykova 1148
763 02 Zlín-Malenovice
tel.: 577 107 171
gsm/tel.: 603 498 498, 603 228 976
e-mail: info@mii.cz
http://www.mii.cz

¹⁾ Útok typu buffer overrun je pokus o zneužití přetečení vyrovnávací paměti – bufferu, které umožní spustit v postiženém počítači nežádoucí kód (pozn. red.).
²⁾ V literatuře, včetně časopisu Automa, se lze setkat také s označením webový server (pozn. red.).