Vývoj databázového IS a návrh jeho integrace do systému podpory krizového řízení

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Vývoj databázového IS a návrh jeho integrace do systému podpory krizového řízení Bakalářská práce

Autor:

Lukáš Tůma Informační technologie, manažer projektů IS

Vedoucí práce:

Praha

Ing. Radek Hofman, Ph.D.

Duben, 2012

Prohlášení Prohlašuji, že jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická verze práce je identická s její tištěnou verzi, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Praze dne 30.04.2012

Lukáš Tůma

Poděkování Rád bych poděkoval svému školiteli, Ing. Radkovi Hofmanovi, Ph.D. za odborné vedení, podnětné návrhy a pomoc při vypracování této bakalářské práce. Děkuji také Michalovi Ráčkovi za odborné rady. Jsem vděčný své rodině a přítelkyni Lence za podporu během celého období mého vzdělávání.

Anotace Práce se zabývá vývojem webové aplikace v jazyce Python s využitím platformy Google App Engine (GAE). Hlavní cíl práce je návrh a implementace databázového informačního systému pro konfiguraci atmosférického disperzního modelu pro simulaci šíření vzdušných škodlivin. Úvodní část je věnována úloze systémů pro podporu krizového řízení v radiační ochraně a zasazuje řešený problém do kontextu většího celku majícího za úkol převod existujícího systému do webového prostředí. Zbytek práce je věnován popisu platformy GAE, jazyka Python a vlastní vyvíjené aplikace se zaměřením na její objektově orientovaný návrh, logickou strukturu a implementační detaily. V závěru je provedena diskuze shrnující dosažené výsledky a možnosti integrace vyvinutého konfiguračního systému s disperzním modelem. Klíčová slova: disperzní model, Google App Engine, Python, Twitter Bootstrap Annotation The work presented here deals with the development of a web-based application in Python programming language using Google App Engine (GAE) platform. The core of the work consists of design and implementation of a databáze information system for configuration of an atmospheric dispersion model for simulation of aerial pollution propagation. The introduction is devoted to a concise description of the role of decision support systems in radiation protection. The analyzed problem is integrated into the context of a migration of an existing decision support system into web environment. The rest of the work concerns the description of GAE platform, Python language and the application developed, with particular focus on its object-oriented design, logical structure and implementation details. Final discussion summarizes the achieved results and the possibilities of the integration of the developed configuration systém into the dispersion model. Key words: dispersion model, Google App Engine, Python, Twitter Bootstrap

Obsah Úvod ...........................................................................................................................................6 Motivace práce .......................................................................................................................6 Úkoly práce ............................................................................................................................7 1 Metody řešení ..........................................................................................................................9 1.1 Google App Engine ..........................................................................................................9 1.1.1 Co je Google App Engine..........................................................................................9 1.1.2 Možnosti Google App Engine .................................................................................10 1.1.3 Vlastnosti Google App Engine ................................................................................11 1.1.4 Sandbox a vývojová prostředí .................................................................................11 1.1.4 Skladování dat .........................................................................................................14 1.1.6 Systém Google účtů a služby Google App Engine..................................................15 1.1.7 Kvóty a omezení Google App Engine.....................................................................17 1.2 Python.............................................................................................................................19 1.2.1 Python jako interpretovaný jazyk ............................................................................19 1.2.2 Python jako objektově orientovaný jazyk ...............................................................20 1.2.3 Python jako dynamický a silně typovaný jazyk ......................................................21 1.2.4 Syntaxe jazyka Python ............................................................................................22 1.3 Tvorba aplikace a administrátorská konzole ..................................................................23 1.3.1 Postup tvorby aplikace ............................................................................................23 1.3.2 Administrátorská konzole........................................................................................28 2 Struktura aplikace ..................................................................................................................37 2.1 Modul main ....................................................................................................................38 2.2 Modul db_model ............................................................................................................43 2.2.1 Datový model ..........................................................................................................43 2.2.2. Jak funguje datový model.......................................................................................45 2.3. Modul logika .................................................................................................................46 2.3.1 Funkce modulu logika .............................................................................................46 2.3.2 Třídy modulu logika ................................................................................................48 2.4 Design aplikace...............................................................................................................49 3 Návod k obsluze ....................................................................................................................50 4 Interakce s disperzním modelem ...........................................................................................57 4.1 Současné použití a možnosti rozšíření ...........................................................................57 4.2 Ukázka výpočtu podle vytvořené konfigurace ...............................................................59 Závěr.........................................................................................................................................61 Seznam použité literatury .........................................................................................................62

5

Úvod Motivace práce Únik radioaktivních látek do ovzduší je nejhorší možný scénář, v jaký může vyústit nehoda na jaderném zařízení. Přestože se jedná o velmi nepravděpodobnou událost, její následky mají závažné dopady pro široké okolí jaderného zařízení a jeho obyvatele. Aktuální informace o prostorovém rozložení radionuklidů v životním prostředí, případně krátkodobé předpovědi vývoje radiační situace, jsou v případě takového úniku nutné pro zajištění podpory krizového řízení. Úkolem krizového řízení je návrh a následná implementace vhodných protiopatření, jejichž rozsah a okolnosti nastolení jsou definovány legislativou pro různé fáze radiační havárie [28]. Potřeba aktuálních informací je akutní zejména v takzvané časné fázi radiační havárie, kdy se radioaktivní vlečka pohybuje nad terénem a způsobuje vnější ozáření z mraku a vnitřní ozáření z inhalace. Typická protiopatření k ochraně obyvatel v této fázi jsou ukrytí, jodová profylaxe a v závažných případech je možné i nařízení evakuace. Pro první odhady rozsahu zasaženého území se používá takzvaných atmosférických disperzních modelů. Atmosférický disperzní model je nějaký numerický kód umožňující simulaci šíření škodlivin v atmosféře na základě zadaných vstupních podmínek, např. [25], [34]. Typicky je výpočet prováděn na zvolené výpočetní síti (pravoúhlé nebo polární), kdy hodnoty zájmových veličin jsou vyčíslovány v uzlových bodech této sítě. Výsledky mohou být následně vykresleny na mapové pozadí a vyhodnoceny [27], [32]. Atmosférické disperzní modely bývají součástmi velkých softwarových balíků, souhrnně označovaných jako systémy podpory krizového řízení. Jedná se o velmi komplexní systémy umožňující například vyhodnocování radiační situace v pozdějších fázích nehody, nalezení vhodných evakuačních tras, odhad kontaminace zemědělských produktů v oblastech zasažených radioaktivním spadem nebo třeba odhad ekonomických škod způsobených zastavením výroby v průmyslových podnicích [26]. Současný trend přesunu dříve typických desktopových aplikací na internet spolu s rozvojem mobilních datových přenosů se nevyhýbají ani oblasti systémů podpory krizového řízení. To dokazuje

například

systém

IXP

(International

Exchange

Program –

„https://ixp.llnl.gov/web/signIn.html“) vyvíjený v Lawrence Livermore National Laboratory

6

v USA. Tento systém je implementován formou server-klient architektury, kdy na výpočetním serveru běží simulační modely, se kterými uživatel interaguje skrze webového klienta. Tento systém umožňuje simulaci vzdušného šíření jaderných i nejaderných škodlivin, například chlóru [24]. Dostupnost takové aplikace ve webovém prohlížeči libovolného zařízení se tak stává velmi lákavou například i pro složky hasičského záchranného systému.

Úkoly práce Jak již bylo řečeno, systémy podpory krizového řízení mají mnoho spolupracujících komponent. To je případ i českého systému HARP (HAzardous Radioactivity Propagation) lokalizovaného pro jaderné elektrárny Temelín a Dukovany [29], viz diagram architektury systému HARP na obrázku č. 1. Pro umožnění jeho plnohodnotného fungování ve webovém prostředí je nutné vypracovat uživatelské rozhranní pro každou z jeho komponent. Cílem této práce je vývoj webového rozhranní pro konfiguraci zdrojového členu segmentovaného gaussovského disperzního modelu pro simulování šíření jaderných škodlivin v atmosféře z elektrárny, v diagramu označeného jako „Model SGPM“. Systém již existuje v podobě desktopové aplikace [30]. Úkolem je přepracovat systém do podoby webové aplikace napsané v jazyce Python využívající platformu Google App Engine (GAE). Převedeny budou následující panely: 1. Základní nastavení systému: tento panel umožňuje konfiguraci základních parametrů, jako nadmořské výšky zdroje, typu modelu rozptylu a další. 2. Ochuzování vlečky: zde se konfigurují parametry pro suchou a mokrou depozici (odstraňování radioaktivity z mraku gravitačním usazováním na zemském povrchu, budovách, rostlinách, atd., a také vymývání atmosférickými srážkami). 3. Blízké objekty: zde se konfigurují blízko stojící objekty v areálu jaderné elektrárny ovlivňující počáteční fázi šíření, např. chladicí věže. 4. Segmenty nuklidů: na tomto panelu uživatel nastavuje požadované složení zdrojového členu pro simulaci šíření, tj. typy zastoupených radionuklidů a jejich zastoupení. Tyto čtyři panely budou doplněny o úvodní stránku umožňující vytváření nových konfigurací, správu stávajících konfigurací uložených v databázi a hlavně jejich export pro následné nahrání do modelu a provedení simulace. Dále bude popsána funkcionalita systému a bude vypracován uživatelský manuál. V závěrečné části práce bude provedena diskuze

7

součinnosti nového webového rozhranní se zbytkem systému a budou nastíněny možnosti dalšího rozvoje.

Obrázek č. 1: Diagram architektury systému HARP [31]

8

1 Metody řešení 1.1 Google App Engine Ačkoliv mají lidé k dispozici mnoho způsobů jak provozovat svoje webové stránky a aplikace na internetu, pokud nechtějí programovat v serverovém skriptovacím jazyce PHP, jejich možnosti volby se dosti zužují. Mohou zvolit pronájem svého vlastního virtuálního serveru, například s využitím služeb společnosti Amazon, jejíž Amazon Web Services poskytuje opravdu velkou skupinu služeb a nástrojů pro vývoj webových aplikací, nebo mohou využít například platformu Microsoft Azure. Já jsem si pro svoji webovou aplikaci zvolil Google App Engine. Důvodů, proč jsem si Google App Engine zvolil, je několik. Mít možnost provozovat svoji webovou aplikaci na serverech Googlu, navíc zdarma, je velmi lákavé. Umožňuje snadné nasazení a rychlý vývoj, hlavně kvůli nástroji Google App Engine SDK (software development kits), jak popisuji v kapitole 1.3 [9]. Tato služba také dovoluje uživateli využívat pro jeho aplikace moderního datového úložiště Googlu. Mně osobně se velmi zalíbila možnost volby programovacího jazyka Python jako serverového skriptovacího jazyka, jehož syntaxe je jednoduchá a velmi přehledná a dovoluje použití webového frameworku Django. Díky frameworku Django je pak možné používat tzv. templates jako šablony pro tvorbu dynamických webových stránek [21, s. 113]. Za hlavní výhody Google App Engine však považuji to, jak se stará o obsluhu aplikace, a také o to, jak jsou data z aplikace zálohovány. Při provozování webu pod touto službou se vám nestane, že by výkon serveru pro obsluhu aplikace nestačil a vy byste byli nuceni k upgradování. Se službou Google App Engine stačí zvolit jiné nastavení pro vybranou aplikaci a o ostatní se postará Google. Jak celá tato služba od společnosti Google funguje, jednotlivé její vlastnosti a možnosti, které nabízí, popisuji v této práci.

1.1.1 Co je Google App Engine Google App Engine je vývojová platforma, která umožňuje běh webových aplikací na infrastruktuře Googlu. Je dostupná jak pro operační systém Windows, tak i pro Mac OS X a Linux [2, s. 1]. Jednoduše řečeno, je to aplikační hosting nebo také, jak bývá nazýván, cloud computing hosting pro webové aplikace. Z hlediska distribučního modelu cloud computing spadá Google App Engine do kategorie Platform as a Service, to znamená, že tato platforma 9

je poskytovaná jako služba uživateli [5]. Tato služba je do určité úrovně k dispozici zdarma, nejsou zde žádné poplatky spojené s prvním použitím platformy nebo pravidelné poplatky za využívání této technologie, pokud uživatel dodržuje určitá omezení. Nad rámec těchto omezení se připlácí například za dodatečné navýšení skladovacího prostoru, využití času procesoru nebo za množství dat přenesených od/do aplikace přes zabezpečené spojení. Uživatel má samozřejmě možnost kontrolovat svoje kvóty a množství využívaných zdrojů. Po přihlášení se do tzv. Dashboard, což je webová stránka s přehledem aplikací, které má uživatel nahrány na server Googlu, si může člověk prohlížet data uložená pomocí aplikace do databáze, může zkoumat logy z přihlášení, různé chybové hlášky, nebo upozornění, které vznikly na základě provozu aplikace, atd., může si také právě s využitím Dashboard kontrolovat svoje kvóty, pomocí přehledných grafů, které jeho aplikace musí dodržet, pokud je vedená jako neplacená. Neplacené aplikace mohou mít až 5 milionů navštívení za měsíc [9]. Více k Dashboard uvedu níže v práci. Jako beta verze byla tato platforma poprvé spuštěna 7. dubna roku 2008 [5].

1.1.2 Možnosti Google App Engine Aplikace v Google App Engine je velmi jednoduché vyvíjet a spravovat, a také si člověk snadno poradí, pokud potřebuje svoji aplikaci rozšířit. Není problém, když se zvyšuje provoz na webové stránce, nebo když narůstá objem dat, které je nutno pomocí webové aplikace skladovat. Odpadá zde další komplikace, a to spravováni serveru. Aplikaci stačí nahrát na server Googlu, od toho okamžiku je připravená k provozu. Aplikace využívá standardně doménu „appspot.com“, ale s využitím Google Apps je také možné si aplikaci umístit na libovolnou vlastní doménu [9]. To má ovšem omezení v tom smyslu, že pokud využijete Google Apps k hostování své aplikace, nebudete moci využít zabezpečeného protokolu SSL, ten je podporován pouze na doméně „appspot.com“. Google App Engine podporuje aplikace využívající programovací jazyky Java, Python nebo Go [9]. Díky Java runtime environment může člověk vyvíjet vlastní aplikace s použitím standardních Java technologií včetně Java virtual machine, Java servlets a Java programovacího jazyka, a také s využitím dalších jazyků kompilovatelných pro Java virtual machine, to znamená JavaScript a nebo JRuby, což je java implementace interpretovaného skriptovacího jazyka Ruby [5]. Dalšími na Javě založenými programovacími jazyky, které jsou podporovány, jsou Groovy, Scala a Clojure. Dalším podporovaným jazykem je Python. Jelikož k vytvoření své aplikace jsem využil právě jazyka Python, rozeberu ho podrobněji

10

v kapitole 1.2. Vývojová prostředí Javy, Pythonu i Go jsou navržena tak, aby zajistila bezpečnost a rychlé spouštění aplikací bez toho, aniž by vznikaly problémy s jinými aplikacemi instalovanými v systému. Nicméně do budoucna plánuje Google přidat podporu dalších programovacích jazyků a chce, aby se Google App Engine stalo jazykově nezávislým.

1.1.3 Vlastnosti Google App Engine Google App Engine je navrženo tak, aby aplikace založené na této platformě dokázaly spolehlivě fungovat i při vyšším zatížení způsobeným velkým objemem dat. Z toho vyplývají jeho základní rysy. Podporuje dynamický web a s ním spojené webové technologie, trvalé uskladnění dat, na něj navazující dotazování, třídění a databázové transakce. Dále může programátor využít API pro autentizaci uživatelů, jež využije hlavně při přihlašování uživatelů do aplikace. Google App Engine totiž podporuje email a jeho možnosti díky Gmail API [2, s. 2]. Vývojáři se při procházení dokumentace setkají také s pojmem tzv. Cron job [3]. Slovo cron pochází ze slova chronograph tj., že se nějaký příkaz nebo skript pouští v počítači automatizovaně. Tohoto využívá i platforma Google App Engine, přidává totiž aplikacím podporu plánování úloh pro spouštění akcí v určeném čase a v pravidelných intervalech. Velkou výhodou je zajisté práce v offline režimu, to znamená, že si stačí nainstalovat App Engine SDK a tím veškerá starost pro uživatele končí. Poté, co si člověk napíše program, nebo část programu a chce ho otestovat pouze na localhostu, není donucen k dodatečné instalaci nějakého Apache http serveru, stačí pouze přes Google App Engine Launcher spustit jedním kliknutím aplikaci na svém počítači, je to plná simulace online enginu. Jak už bylo řečeno výše, tato technologie je multiplatformní, není tedy omezena pouze na majoritní operační systém Windows.

1.1.4 Sandbox a vývojová prostředí Co je to Sandbox? Je to vlastně takové chráněné prostředí pro aplikaci, které poskytuje omezený přístup k operačnímu systému běžícímu v pozadí [20, s. 88], [9]. Tato omezení umožňují App Enginu rozesílat žádosti webu na aplikaci přes vícero serverů, a také startovat a zastavovat servery tak, aby splnily požadavky provozu. Sandbox bezpečně a spolehlivě izoluje uživatelovu aplikaci, z toho poté plyne její nezávislost na hardwaru a operačním systému, a také na fyzickém umístění na webovém serveru. Některá omezení mohu popsat podrobněji. Tak například aplikace mohou přistupovat k jiným počítačům na internetu pouze přes službu Url Fetch, nebo emailové služby a naopak ostatní počítače v síti se mohou připojit 11

k aplikaci umístěné na webu pouze přes klasický HTTP, nebo zabezpečený HTTPS protokol na standardních portech. Dalším bezpečnostním omezením je nemožnost aplikace zapisovat do souborového systému. Aplikace může číst soubory avšak pouze ty, které byly společně s ní nahrány na web a pokud si stránky mezi sebou předávají nějaká data, musejí využívat tzv. Google App Engine Datastore nebo-li úložný prostor Googlu, poskytnutý pro Google App Engine aplikace. Jejich kód funguje pouze v reakci na požadavky webové stránky, na Task Queues – úlohy běžící na pozadí a nebo na naplánované úlohy, tzv. Cron jobs, o kterých jsem se již zmínil. Tato reakce má však jedno důležité omezení, pokud má vše fungovat správně, musí server dostat odpověď od aplikace do 60 vteřin, jinak vyhlásí chybu. Pokud se vrátím k vývojovému prostředí, tak z hlediska vývojového prostředí Java může programátor využít jak Java verzi 5, tak i verzi 6. Obě jsou balíčkem App Engine Java SDK podporovány [9]. Při vývoji je možné používat i Java nástroje na tvorbu webu a její API standardy. Aplikace mohou také komunikovat s technologiemi jako jsou Java Servlets a JavaServer Pages. Prostředí zahrnuje platformu Java SE Runtime Environment 6 a s ní spojené knihovny. Omezení související se Sandboxem jsou implementovány v Java virtual machine a cokoliv co bude přesahovat omezení Sandboxu nebude povoleno a skončí výjimkou. App Engine Java SDK v sobě obsahuje implementace Java Data Objects a Java Persistence API. Aplikace založené na Javě mohou k posílání emailových zpráv využívat rozhraní JavaMail se službou App Engine Mail. Pokud vývojář nechce programovat v Javě, nebo v jazycích založených na Javě, může využít jiný programovací jazyk, tím je Python. Google App Engine zahrnuje velké množství knihoven, API a dalších nástrojů pro tvorbu webových aplikací založených na Pythonu. Google pro tento interpretovaný programovací jazyk dává k dispozici také jednoduchý webový framework, nazývaný webapp a nástroje pro správu a přístup k datům v aplikaci [21, s. 99]. Samozřejmě je jen na programátorovi jestli se rozhodne pro tento framework, protože není jediný v nabídce. Člověk má možnost si vybrat z poměrně velké nabídky, takže dalším, na Pythonu založeným, webovým frameworkem je Django, což je open source projekt. K těm se řadí i frameworky Pylons a web2py a podpora je i pro objektově orientovaný CherryPy [20, s. 28]. Vývojové prostředí je standardně založeno na verzi Pythonu 2.5.2, ale Google App Engine dává možnost zkusit také Python 2.7.2 [9]. Jelikož současně s verzí Pythonu 2 existuje i verze 3, ta se však v některých věcech dosti liší, ale obě verze jazyka jsou vyvíjeny samostatně, tak Google prohlásil, že podpora pro Python 3 je zvažována a je naplánovaná na některou z příštích verzí vývojového prostředí. Kód, který je napsán v Pythonu, musí být 12

opravdu, tzv. čistý Python kód, protože rozšíření, která využívají programovací jazyk C, například CPython, nejsou podporována. CPython je implementace jazyka Python do jazyka C [19]. Jelikož zdrojový kód Pythonu je k dispozici veřejnosti, tak lze zabudovat interpret Pythonu do nějaké jiné aplikace napsané v jazyce C. Tímto se například dodává programům, které jsou založeny na kompilovaných programovacích jazycích, větší pružnost, Python zde pak slouží jako skriptovací jazyk. Pro toto však Google App Engine nemá podporu. Součástí vývojového prostředí pro Python jsou jeho standardní knihovny, ne všechny jejich funkce jsou ale k dispozici. Platí zde stejné omezení se Sandboxem jako u Javy [9]. Programátor může narazit na to, že některé moduly pro Python, které je zvyklý používat, nejsou podporovány. Je také možné spolu s aplikací nahrát na server knihovny „třetích stran“, které jsou implementovány v Pythonu a neodporují omezením, že by například využívaly nepodporovaný modul. Programátoři mohou využít také vývojového prostředí pro jazyk Go. Je to kompilovaný programovací jazyk, který vytvořila společnost Google. V tomto vývojovém prostředí je použita verze Go r60.3, jeho kompilátor i standardní knihovny [9]. Tento kompilátor je spouštěn automaticky, vývojář se o to tudíž nemusí starat. Stejně tak jako u Pythonu a Javy, i zde dochází k některým omezením v důsledku zavedení Sandboxu. Jak pro Javu, tak pro Python a Go nabízí Google balíčky, The App Engine software development kits (SDK), které v sobe zahrnují webový server, simulující běh kompletního App Engine na localhostu a má v sobě obsaženy i knihovny a rozhraní API, jež jsou k dispozici i na Google App Engine [9]. Tento emulovaný web server poskytuje zabezpečený Sandbox, včetně kontrol, které zabraňují použití nepovolených systémových zdrojů. Každé SDK nabízí nástroje pro nahrávání aplikací do App Engine. Já jsem programoval aplikaci pomocí editoru NotePad++ a vývojového prostředí Aptana Studio 3, které v sobě obsahuje plugin PyDev, sloužící k lepšímu vývoji aplikace psané v jazyce Python. Pokud však někdo vyvíjí v Javě, nabízí se mu Google plugin pro vývojové prostředí Eclipse, ten zajišťuje snadnější tvoření kódu, testování aplikace a její nahrávání na web. Struktura adresáře se zdrojovými soubory musí být stejná jako struktura aplikace na webu v App Engine. K tomu právě slouží SDK, které přenese kompletní soubory se zdrojovým kódem a zachovává adresářovou strukturu. Jediné, co je potřeba udělat při vývoji nové aplikace je, že si člověk pomocí administrátorského rozhraní, konzole, založí tuto novou aplikaci na Google App Engine. Přesný název poté musí mít aplikace i na lokálním počítači, kde dochází k jejímu vývoji. Založení aplikace probíhá také přes SDK, kde si člověk vybere její umístění na harddisku. K uploadu na web je zapotřebí vyplnit login a heslo, kterými jsou v tomto případě 13

přihlašovací údaje na Google účet. S nahráváním aplikace do online prostředí souvisí také číslo verze aplikace, protože jedna aplikace může být nahrána do Google App Enginu vícekrát, pokud má toto číslo jiné. Toho lze využít při vývoji novější verze stávající aplikace, která může zůstat aktivní a mohou k ní mít její uživatelé dále přístup. Nová verze aplikace bude například sloužit jako testovací, dokud se vývojář nerozhodne k vyřazení z provozu starší verze a jejímu nahrazení verzí novou.

1.1.4 Skladování dat S platformou Google App Engine má člověk k dispozici výkonný datový sklad, který podporuje dotazování a databázové transakce, toto datové skladiště je nazýváno Google Datastore. Nemá uspořádání jako tradiční relační databáze, je to tzv. Google Big Table [23]. Objekty v databázi – entity, jsou rozděleny do datových tříd a mají své atributy – vlastnosti. Na dotaz do databáze se nám může vrátit entita podle filtrovaného druhu, která může být například řazená podle určité hodnoty. V dokumentaci jsou k dispozici seznamy podporovaných typů vlastností. Ve své prácí používám vlastnosti typu: StringProperty, DateTimeProperty, ListProperty atd. Datový model entit je vždy určen aplikací, znamená to tedy, že si vývojář sám musí navrhnout tento datový model, tím je pak dána struktura databáze. Pokud bychom si chtěli tento datový model představit jako relační databázi, pak entity by tvořily řádky a vlastnosti by tvořily sloupce. Rozhraní jak Javy, tak i Pythonu poskytuje nástroje k vytvoření vlastní struktury datového modelu. Google Datastore je silně konzistentní a používá tzv. optimistické zpracování transakcí [9]. Obecně databázové transakce jsou příkazy, skupina příkazů, které uvedou databázi z jednoho stavu do druhého s tím, že musejí být dodrženy základní vlastnosti transakcí. Jsou jimi atomicita, izolovanost, trvalost a konzistence. Pokud transakce skončí s chybou, mělo by se vše vrátit do původního stavu. Příkladem transakce je situace, kdy jednomu uživateli odepíšu z účtu 100 Kč a budu je chtít připsat na účet druhého uživatele. Musím toto řešit v transakci, protože nesmí nastat stav, kdy jednomu částku odepíšu a druhému ji připsat nestihnu, protože dojde například k poruše hardwaru. Transakce optimistické předpokládají, že chyba nenastane, tudíž ji nebude nutné vracet zpět. Při zpracování transakce je sice vše zapsáno tzv. „napevno“, ale existuje možnost transakci vrátit zpět, protože je vytvářen seznam příkazů, který toto umožňuje [4]. Pokud nedojde k chybě, tento seznam se maže, pokud k chybě dojde, je použit k navrácení do předchozího stavu. Aplikace v Google App Engine může vykonávat vícero datových operací během jedné transakce. Google Datastore provádí transakce v rámci své distribuované sítě

14

s využitím tzv. skupin entit, kde všechny entity stejné skupiny jsou pohromadě z důvodu efektivnějšího provádění těchto databázových transakcí [9]. Google App Engine a jeho Datastore používá dotazovací jazyk, který napodobuje syntaxi jazyka SQL (Structures Query Language), Google ho nazývá GQL [23]. Příkaz pro výběr (Select) v GQL může být proveden pouze na jedné tabulce. GQL záměrně nepodporuje příkaz pro spojení (Join), protože se zdá být neefektivní, pokud jsou dotazy rozprostřeny po více než jednom stroji. Místo toho mohou být vytvořeny vztahy jeden-k-mnoha (one-tomany) a mnoho-k-mnoha (many-to-many) za použití ReferenceProperty [5], [6]. Tento nic nesdílející přístup pak umožňuje, aby selhal disk, ale ne celý systém. Přechod z relační databáze do datového úložiště vyžaduje změnu přístupu vývojářů při modelování jejich dat. Na rozdíl od relační databáze není API datového úložiště relační ve stylu SQL. Javová verze podporuje asynchronní, neblokující dotazy k čemuž používá Twig Object Datastore rozhraní. To pak nabízí alternativu k vláknům pro paralelní zpracovávání dat. Google App Engine nabízí dvě možnosti jak ukládat data. Obě mají své výhody i nevýhody [9]. První je tzv. High Replication Datastore, která používá systém založený na Paxosově algoritmu. Tato možnost nám dává nejvyšší možnou dostupnost dat jak pro čtení, tak pro zápis. Její nevýhodou je, že je pomalejší a náročnější na CPU čas. Druhá možnost je tzv. Master/Slave Datastore, která je založena na asynchronní replikaci dat mezi datovými centry. Data uložená do master datového centra jsou pak kopírována do slave datových center. To zaručuje vysokou konzistenci dat, nevýhoda je však v nedostupnosti dat během výpadku nebo plánovaného odstavení datového centra.

1.1.6 Systém Google účtů a služby Google App Engine Co se týká systému Google účtů, ten je možné do aplikace integrovat, čehož je možné využít pro autentizaci uživatelů [9]. Odpadá tedy nutnost si zakládat další účet ve vaší aplikaci. Stačí systém Google účtů implementovat do aplikace a uživatelé se pak mohou přihlašovat pomocí svého emailového účtu a hesla jaké používají u ostatních produktů společnosti Google, jako jsou například Gmail, Google Docs, Google Calendar atd. Je to usnadnění také pro programátory, ti nemusejí vymýšlet a navrhovat nový systém přihlašování a účtů, mohou využít nabízeného systému Googlu. Pokud není aplikace hostovaná na doméně „appspot.com“, ale je umístěna pod Google Apps, může využívat vlastností, které Google Apps nabízí. Nezapomíná se ani na administrátorský pohled na věc. Díky použitému API, v Google App Engine nazývané Users API je možné rozpoznat běžné uživatele

15

a administrátory, přispívá to ke snadnějšímu vytvoření těch částí aplikace, které by měly být přístupné pouze oprávněným uživatelům. Je nutné říci, že při využití tohoto Users API není možné se dostat k soukromým informacím uživatelů jako jsou hesla a další. Google App engine nabízí některé služby, které přispívají k lepší správě aplikací [9]. K těmto službám se řadí URL Fetch, která je využívána během přístupu aplikací ke zdrojům na internetu, jako jsou webové služby (např. Facebook, Twitter) a nebo nějaká sdílená data. Komunikace s těmito službami je tvořena pomocí HTTP nebo HTTPS protokolu a podporuje metody get, post, head, put a delete. Tato služba získává webové zdroje stejnou cestou jako ostatní produkty od Googlu, je založena na vysokorychlostní infrastruktuře Googlu. Ta je použita i u další služby nabízené pro Google App Engine. Do aplikací je možné začlenit i posílání emailů. Je to dovoleno díky službě App Engine Mail. Odesílání emailů je možné i více příjemcům najednou. Mohou obsahovat i přílohy a jako odesílatel je veden uživatel, resp. jeho email, který má danou aplikaci, z které je odeslán email, registrovanou v Google App Engine. Další možnost komunikace je přes protokol XMPP. Je tedy možné odesílat i přijímat zprávy do/z aplikací, které tento protokol využívají, například Google Talk. Dále je k dispozici služba Memcache [21, s. 193]. Funguje jako klasická cache paměť, která je použitelná pro data, jež využívá aplikace, která nepotřebujeme uchovat natrvalo. Tato Memcache se dá například využít pro data, která potřebujeme mít použitelná pro všechny instance aplikace. Jelikož tyto instance aplikace běží fyzicky na jiných serverech, často i v jiných zemích, potřebujeme mít někdy data k dispozici pro všechny tyto instance. K tomu pak slouží tato cache. K podrobnému vysvětlení pojmu „instance aplikace“ se dostanu níže v práci. Výhodné je využít tuto službu pokud potřebujeme vyšší výkon, protože operace čtení a zápis do Memcache je řádově rychlejší než do Datastore. Pokud například budu vědět, že nějaký dotaz je náročný na zpracování, uložím si jeho výsledek do Memcache, a když přijde do aplikace požadavek na ten samý dotaz, výsledek se vrátí rovnou z Memcache. Tato paměť má však omezenou velikost, musí se tedy používat s mírou a je třeba ji obnovovat, když se data změní, aby byla aktuální a vracela správné výsledky. Nezapomíná se ani na práci s obrázky, App Engine poskytuje API, které dovoluje měnit velikost, ořez, překlápění a rotaci obrázků ve formátu JPEG nebo PNG [9].

16

1.1.7 Kvóty a omezení Google App Engine Aplikace se ve službě Google App Engine dají provozovat zdarma, avšak musejí být dodržovány dané limity a kvóty provozu. Pokud je některé z těchto omezení překročeno, aplikace se stává nefunkční do doby, než je opět dané omezení uvolněno. Tyto kvóty provozu se většinou vztahují na dobu jednoho dne (24 hodin), každý z těchto limitů je však ještě definován na 1 minutu, daná věc nesmí překročit svůj počet za minutu. Toto má chrání aplikaci před přijímáním nadměrného množství zdrojů [9]. Po uplynutí dané doby jsou dosažené hodnoty resetovány. Pokud je provozování aplikace náročnější, je třeba si za prostředky, které uživatel využívá nad limit, připlatit. Placení v principu funguje tak, že si zaplatíme předem určenou částkou na týdenní navýšení limitu u zdroje, jehož bezplatný limit našim nárokům nestačí. Tímto si také určíme částku použitelnou na den. Z té je potom automaticky čerpáno, pokud nějaký jiný zdroj, který aplikace využívá, dosáhne denního bezplatného limitu. Limity a kvóty můžeme rozdělit na pevné a bezplatné. Pevné limity, které Google App Engine vyžaduje jsou následující. Uživatel, který je registrován v Google App Engine má možnost mít aktivních až 10 aplikací na svém účtu [8]. Samozřejmě aplikací je možné mít nahráno na serveru více, ale některé z nich musejí být ve stavu „disable“. Například když je aplikace vyzvána k obsloužení webového dotazu, musí se odpověď vrátit do 60 vteřin, jinak je vypsána chyba a proces je přerušen. Tato odpověď může mít maximální velikost 32 MB. Také počet nahrání aplikace na server je omezen, je to 1000 nahrání na den. S tím je spojený počet souborů, které daný projekt obsahuje, toto číslo je 10 000 souborů na jednu verzi dané aplikace. Každý z těchto souborů je limitován maximální velikostí 32 MB, avšak celková velikost aplikace nesmí přesáhnout 150 MB. Bezplatných limitů, které poskytuje Google App Engine je celá řada, zkusím tedy popsat alespoň některé z nich. Prvním omezením je tzv. Instance-hours, která je omezena na 28 hodin na den. Tento termín znamená, že Google App Engine účtuje čas po který je aplikace v provozu. Při každém webovém dotazu na aplikaci vznikne instance aplikace, která daný dotaz zpracovává. Tato instance aplikace je aktivní ještě asi 20 minut poté a čeká jestli nemá obsloužit další webový dotaz. Když takový dotaz přijde, obslouží ho, když ne, tak zaniká. K aktivaci těchto instancí ale dochází i například ze strany google robota. Těchto instancí aplikace vzniká více, v závislosti na tom, aby zvládly obsloužit všechny webové dotazy. Google App Engine dává tedy zadarmo 28 hodin na den běhu těchto instancí. Pro

17

bezplatné využívání aplikace je k dispozici datové úložiště 1GB. Pokud by byl tento prostor nedostačující, je možné si ho zaplatit a tím ho rozšířit na neomezenou velikost. Počet přístupů na webové stránky může být až 5 miliónů. Dále je zde omezení na služby emailu (Mail API Calls). Tento počet je 100 na den a představuje počet, kolikrát aplikace zavolá emailovou službu, aby odeslala email. Počet odeslaných emailů může být tedy 100, ovšem počet emailů odeslaných administrátorovi aplikace je nastaven na 5000 za den. Maximální velikost přílohy emailu je 100 MB na den, je to ale součet velikostí všech příloh. Celkový počet odeslaných příloh na den je 2000. Dále stručně popíši další limity. Outgoing a Incoming Bandwidth je množství dat, které odejde ven z aplikace jako „response“ a vrátí se jako „request“. Sem spadá obsluha statických souborů na webu, emailů, dat odeslaných a přijatých přes XMPP protokol popsaný výše, data přicházející a odcházející službou URL Fetch a další. S URL Fetch službou je spojené omezení jejího volání na 657 000 na den. Dále je zde tzv. Blob Storage, který umožňuje ukládat velké soubory, např. videa, velikosti až 2GB. Celková data uložená do Blob Storage za den jsou omezena na velikost 5 GB. Google App Engine poskytuje opravdu velké množství služeb a s nimi spojených bezplatných limitů, které jsou podrobně popsány na webu. Základní limity jsem shrnul v tabulce č. 1. Tabulka č. 1: Limity Google App Engine [8]

Pevné limity počet aplikací v Google App Engine čas na vrácení odpovědi na request maximální velikost odpovědi počet nahrání aplikace na server maximální velikost aplikace Bezplatné limity frontend instance hours velikost datového úložiště počet odeslaných emailů z aplikace počet volání služby URL Fetch maximální velikost souborů v Blob Storage

Omezení 10 60 vteřin 32 MB 1000 / den 150 MB Omezení 28 hodin / den 1 GB 100 / den 657 000 / den 5 GB / den

18

1.2 Python Pokud vytváříme webové aplikace pomocí vývojové platformy Google App Engine, můžeme si vybrat ze tří podporovaných programovacích jazyků. Jsou jimi Java, Python a Go. Já ve své aplikaci využívám jazyka Python, proto ho zde stručně popíši. Python vznikl v roce 1991, navrhl ho nizozemský programátor Guido van Rossum. Python je interpretovaný, objektově orientovaný, dynamický a silně typovaný jazyk a syntaxe tohoto jazyka je poměrně jednoduchá. Je to multiplatformní jazyk, který je vyvíjen jako open source projekt [19]. Z výše napsaného vyplývá, že je vhodný jak pro začátečníky, tak i pro zkušené programátory. Python je možné využít pro výuku programování, psaní prototypů aplikací, aplikací typu klient/server, menších GUI aplikací, síťových aplikací, webových aplikací, skriptů, utilit, systémových programů nebo pro práci s textovými dokumenty včetně XML [15].

1.2.1 Python jako interpretovaný jazyk Programovací jazyky se z hlediska překladu a způsobu spouštění dělí na kompilované a na interpretované. Kompilovaný jazyk, například jazyk C, se vyznačuje tím, že než dojde ke spuštění programu, celý kód je nejprve přeložen kompilátorem do strojového kódu. Toto sice přináší větší rychlost při následném spouštění, ale také náročnost na správně zapsaný kód [17]. Interpretované jazyky, nejen Python, ale i Basic, Java, Perl, využívají ke spuštění programu interpret, což je počítačový program, který nám umožňuje vykonávat zápis našeho algoritmu ve zdrojovém kódu. Interprety mohou pracovat různě. Například přímo interpretují zdrojový kód, toto dělají interprety jazyka Basic. Dalším způsobem je překlad zdrojového kódu do mezikódu, který je pak vykonáván interpretem jazyka. Skriptovací jazyky převádí zdrojový kód do mezikódu vždy při spuštění programu, to znamená, že mezikód je uložený v operační paměti. To má však nevýhodu déle trvajícího překladu, pokud je program větší. Jazyk Java má jiné řešení, zdrojový kód přeloží do mezikódu a uloží do souboru, toto je podobné kompilovaným jazykům, ale s tím rozdílem, že mezikód není závislý na architektuře procesoru, tudíž toto zajišťuje multiplatformní použití Javy. Interpret pak dostává k dispozici rovnou mezikód, který rychle načte. Python využívá oba výše zmíněné způsoby [15]. Zdrojový kód přeloží do mezikódu sám interpret, to nám dává možnost snadného spouštění aplikací. Tento mezikód je zároveň uložen do souboru, při dalším spuštění programu interpret kontroluje čas vzniku souboru, pozná tedy, jestli ve zdrojovém kódu byly provedeny změny, 19

pokud ano, tak zdrojový kód opět přeloží do mezikódu, starší soubor s mezikódem je smazán a nahrazen nově přeloženým, a ten pak následně spustí, pokud změny provedeny nebyly, už k překladu nedochází a mezikód je načten ze souboru. Zdrojový kód v programu Python má příponu „.py“, soubor s přeloženým mezikódem má příponu „.pyc“. Python nám tedy dává možnost psát větší programy jejichž programování je snadné jako u skriptovacích jazyků. Obecně jsou interpretované jazyky pomalejší než jazyky kompilované, ale přinášejí nám vyšší produktivitu programování, tj. programy se v nich píší rychleji a snadněji. Pokud budeme spouštět zkompilovaný program, půjde to rychleji než u programu interpretovaného. Z hlediska rychlosti vývoje aplikace, a zejména u rozsáhlejších programů, nám však interpretovaný jazyk usnadní práci. Cyklus „editace – interpretace – ladění“ bude trvat kratší dobu něž cyklus u kompilovaného jazyka, tj. „editace – kompilace – spuštění – ladění“ [11].

1.2.2 Python jako objektově orientovaný jazyk Zde bych zmínil něco málo o pojmu objektově orientované programování (dále jen oop), jehož nejdůležitější vlastnosti Python obsahuje. Je to dědičnost, polymorfismus a zapouzdření [22], [18]. Základním prvkem oop je objekt, což v Pythonu může být nejen třída nebo instance třídy, ale také uživatelské funkce, moduly a jednoduché typy (řetězce, seznamy, slovníky, čísla). V reálném světě si pod pojmem objekt můžeme představit prakticky cokoliv, já jsem si pro tento výklad vybral objekt psa. Pes je objekt, který má své „jméno“ a je nějak „velký“, umí také „běhat“ a „štěkat“. Stejně tak to bude v programu i se psem elektronickým, bude mít nějaké „jméno“ a „velikost“. V programování tomu říkáme, že objekt má atributy, a bude také „štěkat“ a „běhat“, což jsou jeho metody. Ve skutečnosti však máme v reálném světě mnoho psů, to znamená mnoho objektů stejného typu. Jako předpis pro tvorbu objektů stejného typu definujeme pojem třída, což je vlastně vzor jak vytvořit daný objekt. Pokud budeme mít jezevčíka a bernardýna, tak oba jsou instancemi třídy pes. Pojem třída lze však v tomto případě ještě více rozebrat. Od třídy pes totiž žádné instance tvořit nemůžeme, protože žádní obecní psi neexistují. Vždy totiž půjde o psa, který patří do nějaké rasy. Třída pes bude tedy abstraktní třídou. Vysvětlení je následující: pokud se náš jezevčík bude jmenovat Punťa a bernardýn Fík, tak Punťa bude instancí třídy jezevčík a Fík bude instancí třídy bernardýn. Tímto se dostáváme k pojmu dědičnost. Punťa i Fík umí oba štěkat i běhat, oba jsou totiž psi, mají tedy stejné metody, které podědili od abstraktní třídy pes. Každý má, ale jinou „velikost“, tu sice také podědili od abstraktní třídy pes, protože ale jeden je vytvořen podle podtřídy jezevčík a druhý podle podtřídy bernardýn, je každý jinak velký.

20

Obecně lze tedy říci, že každá podtřída dědí stav a metody od své nadtřídy, ale neznamená to, že by svou nadtřídou byly omezeny, mohou si své atributy a metody přidávat a měnit. Pojem zapouzdření si můžeme vysvětlit následovně. Když si zvolíme nějaký objekt, volíme ho protože víme, že má nějakou metodu. Tuto metodu potřebujeme zavolat, nezajímá nás tedy to, jak se tato metoda provede, jestli daný objet na tuto metodu využívá i jiného objektu. Zapouzdření se obvykle používá k ukrytí proměnných objektu před ostatními objekty v programu. To nám dovolí změnit vlastní implementaci, aniž by to ovlivnilo další části programu, které objekt používají. Nemusí se ale vždy jednat o skrytí proměnných, zapouzdření lze uplatnit i na metody. Potom tedy jiné objekty nemohou volat metody daného objektu. Lze tedy říci, že objekt má možnost řídit to, zda jiné objekty mohou přistupovat k jeho metodám a proměnným [18]. Další vlastnosti oop je polymorfismus. Tato vlastnost umožňuje například jednomu objektu volat jeho metodu s různými parametry nebo více objektům z různých tříd volat metodu, která má stejný význam v kontextu. Python je sice objektově implementovaný, to znamená, že je to objektově orientovaný jazyk, ale je s ním možné i strukturované programování, což člověk využije hlavně u menších projektů nebo když se učí programovat, protože návrh oop programu, hierarchie tříd atd. je náročnější [15]. Znamená to tedy, že nám poskytuje větší možnosti při návrhu programu a pokrývá tak větší spektrum úloh, na jejichž řešení je vhodný.

1.2.3 Python jako dynamický a silně typovaný jazyk Programovací jazyky máme buď se statickým, nebo s dynamickým typováním [15]. Při dynamickém typování je typ proměnné určen její hodnotou a to většinou až za běhu programu, to znamená, že ke kontrole dochází až za běhu programu a ne při kompilaci. To nám umožňuje do proměnné přiřazovat hodnoty s různým datovým typem. Programovací jazyky s dynamickým typováním bývají zároveň jazyky interpretovanými, jsou proto pomalejší než jazyky s typováním statickým. Statické typování se pozná podle toho, že už pří deklaraci proměnné musíme určit o jaký datový typ se jedná. Na chybu lze tedy přijít už při kompilaci do strojového kódu. Avšak tato vlastnost je nevýhodou, protože do proměnné můžeme ukládat pouze hodnoty stejného datového typu, což nás často může nutit k vytváření složitého kódu. Toto typování umožňuje lepší optimalizaci programu na výkon. Příkladem statického typování je například jazyk C++. Programovací jazyk může mít také silné, nebo slabé typování. Rozdíl je v tom, že silné typování nedovolí programátorovi dávat dohromady dva různé datové typy. Python nám proto

21

vypíše chybu, když se budeme snažit sčítat datový typ integer s datovým typem string. Naopak v jazyce C++ lze součet zapsat tak, že při kompilaci nedojde k odhalení chyby a poté při spuštění programu se nám vrátí nějaký nesmyslný výsledek součtu [15].

1.2.4 Syntaxe jazyka Python Syntaxe jazyka je jednoduchá, přehledná a snadno čitelná [15]. Výsledný kód je pak kratší a dá se snadněji pochopit. Python nám svoji syntaxí pomáhá k tomu, abychom dělali méně chyb. Například pří definici funkce odpadá nutnost umístit tělo funkce do složených závorek jako v jazyce C++, toto je zde nahrazeno odsazením, což opět vede k přehlednosti kódu. Na koncích řádku se nepíše středník, v podmínce „if“ nelze použít „=“ (přiřazení), takže nemůže dojít k tomu, že bychom zaměnili přiřazení za porovnání („==“). V Pythonu také najdeme jen tři základní konstrukce pro řízení programu. Jsou to konstrukce „if, elif, else“ pro podmíněné vykonávání programu. Konstrukce „for, else“ pro opakované vykonávání programu a konstrukce „while“ pro opakované vykonávání programu s podmíněným počtem cyklů [15]. Jednoduchá ukázka syntaxe Pythonu #algoritmus najde pětimístné číslo, které se rovná součtu pátých mocnin svých číslic for i in range(10000, 100000, 1): #i nabývá hodnot od 10 000 do 99 999 cislo = str(i) #převod číslice na řetězec soucet=0 #není potřeba určit datový typ proměnné for pozice in cislo: soucet += (int(pozice))**5 #int() převod parametru na integer if soucet == i: print i, ",", >>> 54748, 92727, 93084 #výsledná čísla

22

1.3 Tvorba aplikace a administrátorská konzole 1.3.1 Postup tvorby aplikace V této kapitole se pokusím popsat, jak vytvořit aplikaci, která poběží pod službou Google App Engine. Vytvoření nové aplikace a její zprovoznění na webu je velmi jednoduché a člověk se s ním sžije snadno a rychle. Nejprve je potřeba, aby si programátor založil účet u Googlu, což je podmínka, bez které není možné nahrávat a tudíž provozovat svoji aplikaci na serverech Googlu. Email a login je nutné zadat nejen jako ověření při uploadování aplikace, ale také pokud se chcete dostat do administrátorského rozhraní, které má každá aplikace provozovaná v Google App Engine k dispozici. Dalším bodem v postupu tvorby aplikace je stažení Google App Engine SDK. Tento software development kit je na webu Google Developers k dispozici pro všechny tři podporované programovací jazyky: Python, Java a Go, pro platformy Windows, Mac OS X i Linux. Google App Engine SKD obsahuje jednoduchý a přehledný Launcher, pomocí kterého si vytvoříme aplikaci.

Obrázek č. 2: Google App Engine SDK Launcher

Přes menu Launcheru si vytvoříme novou aplikaci, je nutné zadat její jméno a adresář, kde bude umístěna. Jelikož SDK obsahuje i lokální běhové prostředí, které simuluje skutečný

23

provoz na serveru, je možné si při tvorbě aplikace vybrat na jakém portu localhostu daná aplikace poběží.

Obrázek č. 3: Tvorba nové aplikace

Po stisku tlačítka „create“ se nám na daném umístění vytvoří adresář s názvem aplikace a v něm několik souborů. Pokud používáte jazyk Python, v adresáři se objeví soubor „main.py“, který bude obsahovat kód aplikace. Dále jsou zde soubory s příponou “.yaml“. Soubor „app.yaml“ je konfigurační soubor aplikace zapsaný v jazyce Yaml. Jazyk YAML Ain't Markup Language (YAML) je jazyk pro zápis strukturovaných dat ve formě textového souboru. Jeho výhodou je snadná čitelnost [2, s. 6]. Ukázka konfiguračního souboru app.yaml application: engineapp version: 1 runtime: python api_version: 1 handlers: - url: /files static_dir: files - url: /favicon\.ico static_files: files/img/favicon.ico upload: files/img/favicon\.ico - url: .* script: main.py

24

Tento soubor se dělí na několik částí: ƒ

Application uvádí název aplikace, takový jaký jsme zvolili při tvorbě aplikace.

ƒ

Version určuje verzi aplikace, je možné mít několik verzí stejné aplikace a posléze se rozhodnout, kterou verzi spustit na serveru.

ƒ

Runtime uvádí použitý programovací jazyk.

ƒ

Api version je verze API Google App Engine.

ƒ

Handlers nám slouží pro nakonfigurování vzorů URL a způsobů jakými budou obsluhovány. První nastavení nám říká, že všechny požadavky, jejíchž cesta v URL bude začínat „/files“ budou brány jako požadavky na statické soubory [16]. To znamená, že je možné si do adresáře „files“ umístit soubory typu „.css“, obrázky, icony. Poslední nastavení udává obsluhu všech požadavků, v tomto případě se o všechno bude starat skript „main.py“. Samozřejmě konfigurační soubor nám dává více možností. Můžeme si zde například nastavit, k jakým adresám se dostane pouze administrátor.

Pokud chceme aplikaci nahrát na server, stačí v Launcheru vybrat danou aplikaci a kliknout na tlačítko „Deploy“. Launcher nás poté vyzve k zadání emailu a loginu. Google App Engine SDK poskytuje ještě jednu možnost uploadu aplikace na web. Kromě Launcheru lze využít také konzolové utility „appcfg.py“. Tuto možnost využijeme například, když budeme chtít obejít neustálé zadávání loginu a hesla při uploadu aplikace na web. Nástroje „appcfg.py“ je nutné použít také v případě, že při uploadu aplikace pomocí Launcheru došlo k přerušení, a to pokud třeba omylem zavřete okno Launcheru. Nový příkaz „deploy“ pak nelze provést dokud se nespustí „appcfg.py“ s možností „rollback“ pro aplikaci, která byla ve svém procesu nahrávání na server přerušena. Ovšem abychom mohli aplikaci uploadovat, musíme ji nejprve vytvořit i v administrátorské konzoli na webu, kam se dostaneme pomocí svého Google účtu.

Obrázek č. 4: Administrátorská konzole

25

Po stisku tlačítka „Create Application“ se nám objeví stránka, kde provedeme základní nastavení aplikace.

Obrázek č. 5: Nová aplikace na webu

Zde vidíme kolik nám ještě zbývá aplikací k vytvoření. Počet aktivních aplikací je omezen, jak jsem popsal v kapitole 1.1.7. Aplikaci musíme pojmenovat stejně jako ji máme pojmenovanou u sebe na localhostu. Můžeme také nastavit způsob přihlašování uživatelů a ukládání dat, viz kapitola 1.1.4. Na obrázku č. 2 je vidět, že Google App Engine Launcher nám poskytuje seznam všech aplikací, které máme na disku. Menu Launcheru dává také možnost mazání již vytvořeného projektu, nesmaže ho však z disku, ale jen z prostředí lokálního Google App Engine. Pokud si nějakou aplikaci stáhneme, můžeme ji poté pomocí Launcheru také přidat do svého Google App Engine. V menu edit/Preference můžeme nastavit cestu k programovacímu jazyku, k umístení Google App Engine SDK a nebo k textovému editoru, který používáme pro vývoj.

26

Obrázek č. 6: Předvolby Google App Engine Launcher

Jednotlivé aplikace mohou mít také svá specifická nastavení, například lze k aplikaci přidat volbu, aby se při novém spuštění na localhostu smazala databáze, což se mně při vývoji velmi hodilo. Google App Engine Launcher nabízí také řadu ovládacích prvků, viz obrázek č. 2. ƒ

Run spustí vybranou aplikaci na jednoduchém lokálním webovém serveru, každá aplikace má pak od svého vzniku přiřazen port, tzn. že jich může běžet součastně více najednou.

ƒ

Stop zastaví vybranou aplikaci.

ƒ

Browse se aktivuje, pokud danou aplikaci spustíme, po jeho stisknutí se nám otevře defaultní webový prohlížeč se spuštěnou aplikací.

ƒ

Logs otevře konzoli logu. V logu se vypisují všechny požadavky na aplikaci, dále také hlášky typu „info“ nebo „warning“. Já jsem log využíval hlavně při vývoji aplikace. Importoval jsem si do svého skriptu modul „logging“ a s využití jeho metody „info()“ pak kontroloval správnost kódu. Například řetězec, který je zapsán do metody „info()“ (logging.info(‘řetězec‘)) je vypsán i do logu.

ƒ

SDK Console poskytuje některé nástroje administrátorské konzole na localhostu. Můžeme si například prohlížet data uložená aplikací do databáze, apod. Podrobně o těchto možnostech píšu v kapitole 1.3.2.

ƒ

Edit otevře k editování konfigurační soubor app.yaml.

ƒ

Deploy nahraje vybranou aplikaci na server Googlu.

ƒ

Dashboard otevře ve webovém prohlížeči uživatelovu administrátorskou konzoli, přehled všech aplikací a možností s nimi spojenými, které náležení danému Google účtu, který využívá Google App Engine.

27

1.3.2 Administrátorská konzole Do své administrátorské konzole se uživatel Google App Engine dostane přes web Google Developers nebo, jak jsem již popsal výše, přes Google App Engine Launcher. Konzole je rozdělena do několika částí [7]. Na úvodní stránce má uživatel přehled o svých aplikacích nahraných na serveru. Na obrázku č. 4 výše je vidět, které aplikace jsou aktivní, přístupné z webu, nebo které jsou ve stavu „disable“, nahrané na webu, ale nepřístupné pro web. U každé aplikace v tomto přehledu je také vidět jestli má nastavené nějaká pravidla pro placení jejích služeb a jak je řešeno ukládání dat na server. Po kliknutí na vybranou aplikaci se otevře stránka Google App Engine, kde jsou formou záložek v menu rozmístěny nástroje na správu aplikace. Jsou rozděleny do čtyř kategorií: Main, Data, Administration a Billing. V této kapitole stručně popíšu vlastnosti jednotlivých nástrojů. Main V kategorii Main jsou tyto nástroje správy aplikace: Dashboard, Instances, Logs, Versions, Backends, Cron jobs, Task Queues a Quota Details. ƒ

Dashboard volně přeloženo jako přístrojová deska, viz obrázek č. 7. Je to základní přehled o aplikaci. V horní části je dropdown menu umožňující výběr jednoho z jedenácti grafů prezentující aplikaci. Např. dotazy typu request, využití času procesoru, využití paměti, atd. V prostřední části je stručný přehled o spuštěných instancích aplikace, to vysvětlím níže. Ve spodní části je přehled o tom, zda je aplikace provozována zdarma, nebo jako placená . Dále je zde graficky, procentuálně i číselně zobrazeno využití zdrojů aplikace.

28

Obrázek č. 7: Dashboard Google App Engine

ƒ

Instances ukazuje podrobný přehled všech spuštěných instancí aplikace. Jak jsem již nastínil v kapitole 1.1.7, při každém webovém dotazu na aplikaci, ať už ze strany uživatelů aplikace a nebo například google robota, se spustí instance aplikace, která daný dotaz obsluhuje. Počet těchto instancí se odvíjí od počtu dotazů a náročnosti na jejich obsluhu. V této záložce má uživatel možnost podívat se, kolik instancí je spuštěných, kolik která instance obsluhuje dotazů, jak je stará, kolik využívá paměti. Je zde možnost instanci zavřít. Pokud není zavřena ručně, sama po určité době, když nedostane další dotaz k obsluze, zaniká. To, jak instance aplikace ovlivňují denní kvóty pro bezplatný provoz aplikace, jsem popsal v kapitole 1.1.7.

Obrázek č. 8: Instance aplikace v Google App Engine

ƒ

Logs jsou logy z aplikace. Uživateli dává tato záložka možnost zobrazení všech dotazů typu request na aplikaci a nebo jen dotazů, které jsou označeny jako „warning“, „info“, „error“ atd. Každý log má své detaily o tom, z jaké IP adresy, v kolik hodin

29

a přes jaký webový prohlížeč dotaz přišel. V podrobném výpisu je také uvedeno, jaká instance tento dotaz obsloužila.

Obrázek č. 9: Logy aplikace v Google App Engine

ƒ

Versions je záložka, kde má uživatel přehled o jednotlivých verzích vybrané aplikace. V přehledné tabulce je jasně znázorněno počet verzí, kdy a kým byla daná verze nahrána na server a jaké používá runtime prostředí. Tabulka dává možnost vybrat si určitou verzi aplikace a poté ji smazat, nebo z ní vytvořit defaultní verzi, tedy verzi, která je určena do ostrého provozu.

ƒ

Backends v Google App Engine představuje speciální pojem. Obecně pojem backend označuje část webové aplikace, která se stará o administraci webu a zpracování dat [1]. Ovšem v tomto případě si pod tímto pojmem musíme představit instance aplikace určené na zpracování dlouhoběžících requestů na pozadí. Využívají se pro aplikace, které jsou náročnější na výkon a na paměť. Vztahují se na ně jiné limity, například odpověď na webový dotaz, která je omezena na 60 vteřin pro instance aplikace normálního typu, pro tyto backends instance neplatí.

30

ƒ

Cron Jobs, v této záložce je přehled o cron jobech, což jsou vlastně Scheduled tasks, úlohy běžící na pozadí, které se spouštějí v předem naplánovaný čas. V Google App Engine se spouští požadavek na konkrétní URL.

ƒ

Task Queues jsou také úlohy, které běží na pozadí. Jedná se například o zpracování dotazu, u kterého nepotřebujeme hned zobrazit výsledek. Tento dotaz je tedy součástí nějaké úlohy, která se řadí do fronty a Google App Engine tyto úlohy ve frontách postupně zpracovává. V této záložce je tedy přehled o nadefinovaných úlohách pro vybranou aplikaci. Pro bezplatné provozování aplikace je možné mít ve frontě zařazeno až 1 000 000 úloh za den, které ještě nebyly zpracovány. Avšak počet volání Task Queue API, které obsluhuje tuto službu je omezeno na 100 000 za den [8].

ƒ

Quota Details záložka zobrazuje velmi podrobné detaily ohledně využívání zdrojů aplikace, viz obrázek č. 10. Tyto zdroje jsou zde rozděleny do jednotlivých kategorií podle API, do který spadají. Jsou to: Request, Storage, Mail, UrlFetch, Image Manipulation, Memcache, XMPP, Channel, Task Queue a Deployments. Dosažené hodnoty se resetují jednou za 24 hodin a na tomto přehledu je i uvedeno, kolik hodin zbývá do začátku nového účtovacího období.

Obrázek č. 10: Quota Details aplikace v Google App Engine

Data V kategorii Data jsou tyto nástroje správy aplikace: Datastore Indexes, Datastore Viewer, Datastore Statistics, Blob Viewer, Prospective Search, Datastore Admin a Memcache Viewer. ƒ

Datastore Indexes představuje přehled indexů. Indexy si lze představit jako speciální datovou strukturu, která je nutná pro zpracování dotazu do databáze. Každý dotaz tedy musím mít svůj index, který v sobě obsahuje hodnoty, podle kterých se do databáze

31

dotazuje. Index tyto hodnoty seřadí tak, aby se dotaz provedl co nejlépe. Pro základní jednoduché dotazy tvoří Google App Engine indexy sám [6]. Pro složitější dotazy je třeba tyto indexy vytvořit do souboru „index.yaml“, který je součásti aplikace a nahrává se s ní na server. Tyto indexy je pak možné spravovat právě v administrátorské konzoli v záložce Datastore Indexes. Pokud programátor nechce zapisovat tyto indexy do souboru manuálně, lze v soubotu „index.yaml“ nastavit, aby byly indexy generovány automaticky. Poté je však nutné všechny dotazy spustit na lokálním serveru, aby je Google App Engine SDK mohlo do souboru zapsat. ƒ

Datastore Viewer je záložka s přehledem dat uložených v databázi. Data jsou zobrazena ve formě tabulek, kde řádky tvoří jednotlivé entity a sloupce pak vlastnosti entit. Jednotlivé tabulky jsou tedy zobrazením datových tříd obsahujících tyto entity a vlastnosti. Mezi tabulkami lze přepínat pomocí rolovací nabídky. Je zde také nabídka na vytvoření GQL dotazu, což je obdoba jazyka SQL, pomocí něhož je možné specifikovat zobrazení dat v tabulce například podle vybrané vlastnosti. Pokud chceme některá data z databáze smazat, v této záložce je k dispozici nástroj na jejich odstranění. Jednotlivé entity v tabulkách lze upravovat i vytvářet je jako nové.

Obrázek č. 11: Datastore Viewer v Google App Engine

ƒ

Datastore Statistics ukazuje grafické využití Datastore ve formě koláčových grafů-. K dispozici jsou dva grafy, které zobrazují využití datového úložiště. První je z pohledu datových typů jednotlivých vlastností dat, druhý je rozdělením datového úložiště podle datových tříd. Nad grafy je možné si vybrat, kterou datovou třídu si chceme zobrazit, a tím také změnit tabulku pod grafy, která zobrazuje podrobné informace o jednotlivých vlastnostech datové třídy a jejich velikostech.

32

Obrázek č. 12: Datastore Statistics v Google App Engine

ƒ

Blob Viewer se týká dat typu Byte string long. Jak jsem již popisoval v kapitole 1.1.7, některá data, jako jsou obrázky nebo videa, lze do aplikace nahrávat pomocí služby Blobstore. Tato služba pak, například z nahraného videa, vytvoří tzv. „blob“. Tyto „bloby“ je možné si prohlížet přes Blob Viewer.

ƒ

Prospective Search je experimentální služba. Je to jakési prohledávání, které funguje tak, že uživatel má sadu dotazů. Proti této sadě dotazů pošle data, tomu se říká „stream“ - proud dat, které tečou přes dotazy. V závislosti na tomto jsou pak k dispozici výsledky [13].

ƒ

Datastore Admin je zatím také ve vývoji a je označená jako experimentální služba. Uživatel Google App Engine by s využitím této služby měl být schopen vytvářet zálohy pro entity ve svých datových třídách, které má uloženy v datovém úložišti. Tyto zálohy uloží označené entity, poté co se uživatel rozhodne obnovit zálohu. Entity existující v době zálohování budou nahrazeny zálohou a entity nově přidané zůstanou zachované [7]. S využitím Datastore Admin je také možné kopírovat entity mezi aplikacemi, které má uživatel ve svém účtu a nebo mazat entity podle jejich příslušnosti k datové třídě.

ƒ

Memcache Viewer souvisí se službou Memcache. Na této záložce je k dispozici přehled o tom, kolikrát byl veden dotaz do cache, kolikrát byly data nalezeny, jejich počet, celková velikost a stáří poslední přidané. Tyto hodnoty si lze i zobrazit.

33

Administration V kategorii Administration jsou tyto nástroje správy aplikace: Application Settings, Permissions, Blacklist, Admin Logs. ƒ

Application Settings je záložka, která je rozdělena do několika oddílů. Prvním z nich je Basic, kde je základní přehled o aplikaci. Je zde možné měnit jen některé nastavení aplikace, jakou je doba exspirace dat cookies a nebo titul aplikace, který se zobrazuje uživatelům přihlášeným do aplikace. Ostatní volby, například jméno aplikace, způsob ukládáni dat, se nastavují při vytváření nové aplikace. Druhým oddílem je Performance, kde se dá ovlivňovat výkon a vznik nových instancí pro aplikaci. Je možné si vybrat ze tří výkonových tříd instancí: F1 (600 MHz, 128 MB), F2 (1200 MHz, 256 MB) a F4 (2400 MHz, 512 MB) [7]. Tímto nastavením jakoby ovlivníme výkon serveru, na kterém vybraná aplikace běží. Tyto tři možnosti jsou k dispozici i pro potřeby neplatících uživatelů Google App Engine, avšak je třeba dbát na to, že například při použití výkonové třídy F4 je denní limit 28 hodin, pro celkový běh instancí aplikace, spotřebováván čtyřikrát rychleji než při nastavení třídy F1. V tomto oddíle lze také nastavit minimální a maximální počet instancí, které budou pro aplikaci k dispozici. Minimální počet si mohou nastavit jen platící uživatelé. Nastavení maximálního počtu mohou ovlivňovat i uživatelé, kteří si za jejich aplikaci neplatí. Výhodou je, že se tyto nastavené instance aplikace vytvářejí již při načtení aplikace, jsou tedy připravené na provoz aplikace a nevznikají tak delší časy při obsluze webových dotazů. V základu je nastaven automatický počet maximálních instancí. Dalším nastavením je možné ovlivnit minimální dobu, kterou bude čekat webový dotaz na obsloužení instancí aplikace. Pokud bude tato hodnota nízká, a počet dotazů bude vysoký, bude i počet vzniklých instancí aplikace vyšší z důvodu rychlého obsloužení provozu aplikace. Tímto nastavením lze tedy snižovat náklady na provoz aplikace, protože při nastavení delšího času čekaní pro webové dotazy bude vznikat méně instancí aplikace. Webový dotaz bude čekat na to, aby ho zpracovala již vzniklá instance a nebude vyžadovat vznik nové. Nevýhoda tohoto řešení je ve zvýšení doby odezvy aplikace na požadavky, které na ni bude mít uživatel aplikace. Ve třetím oddíle si uživatel nastavuje dobu, po kterou sou uchovávány logy z provozu aplikace. Pro placené aplikace je možné kromě doby uchovávání nastavit i maximální velikost logu.

34

Ve čtvrtém je přehled o aktivovaných službách, které aplikace využívá. Jsou to služby, které dotazují aplikaci jinými protokoly než je protokol HTTP. Například Mail API, a XMPP API. V dalším je možné aktivovat, nebo naopak vypnout službu Datastore Admin, kterou jsou již popisoval výše v této kapitole. V šestém oddíle je možné nastavit jinou doménu. Pokud chce uživatel provozovat aplikaci na jiné doméně než je „appspot.com“ lze k tomu použít službu Google Apps. V Google Apps si stačí vytvořit účet a přidat tam doménu, kterou uživatel vlastní. Služba Google Apps ověří, zda-li je uživatel opravdu vlastníkem domény, a poté již stačí aplikaci namapovat na tuto doménu. Ve zbývajících oddílech záložky Application Settings se dá zakázat, nebo povolit, aby aplikace zapisovala do datového úložiště. Dále je možné celou aplikaci smazat a nebo ji uvést do stavu „disable“. K možnostem zde patří i vytvoření nové aplikace, která je vlastně kopií současné, protože využívá většiny jejího konfiguračního nastavení. Pokud má uživatel ve vybrané aplikaci uložená data typu blob, může využít poslední nabídky. Tou je možnost kopírování blobů mezi aplikacemi. ƒ

Permissions je záložka s přehledem uživatelů aplikace, kteří mají přístup do administrátorské konzole, a jejich uživatelských práv. Oprávnění jsou zde tři a to: Viewe, Developer a Owner. Uživatel s uživatelskými právy Viewer má možnost prohlížet administrátorskou konzoli pro vybranou aplikaci. Developer může pomocí administrátorské konzole aplikaci také editovat. A Owner je vlastník aplikace, má tedy možnosti aplikaci, kromě prohlížení a upravování přes webové rozhraní, také smazat. V jeho pravomoci je přizvat nové uživatele na vývoj aplikace a měnění jejich uživatelských práv. Všichni uživatelé s výše popsanými právy si mohou celý kód aplikace stáhnout přes konzolové rozhraní „appcfg.py“. Vlastník aplikace může tuto funkcí na této záložce zakázat.

ƒ

Blacklist nabízí přehled o blacklistech definovaných v soubotu „dos.yaml“. Tato služba nabízí možnost zablokování přístupu k aplikaci konkrétní IP adrese nebo k celé podsíti.

ƒ

Admin Logs je speciální log, který se týká pouze akcí administrátorů aplikace. Log obsahuje záznamy provedené jak v administrátorské konzoli, tak i akce provedené přes Google App Engine SDK. Bývají zde uvedeny záznamy jako uploadovaní nové verze aplikace, editace položek v databázi, změna v nastavení aplikace atd.

35

Billing V kategorii Billing jsou tyto nástroje správy aplikace: Billing Settings a Billing History. ƒ

Billing Settings se, jak název napovídá, týká jen placených aplikací provozovaných v Google App Engine. V horní části záložky je uveden status aplikace, zda-li je placená či nikoliv. Pokud je aplikace ve verzi free, právě zde je možné převést aplikaci na placenou a využívat tak navýšených limitů. Zpřístupní se tak administrátorské nástroje pro placenou aplikaci, mimo jiné i již, v kapitole 1.1.7, zmíněný denní paušál pro zdroje využívané aplikací.

ƒ

Billing History záložka je přehled všech událostí souvisejících s placením zdrojů, které aplikace využívá nad rámec limitů definovaných pro bezplatné používání aplikace. Pro aplikace typu free je zde k dispozici historie tzv. „usage reports events“. Tyto výpisy ve formě tabulek ukazují jak, a které zdroje využila vybraná aplikace, viz obrázek č. 13. Například na tomto obrázku je vidět, že aplikace k datu 12.04.2012 využila jen 1,54 hodiny, z celkových 28 hodin přidělených pro bezplatné nasazení, pro zdroj aplikace Fronted Instance Hours.

Obrázek č. 13: Billing History v Google App Engine

36

2 Struktura aplikace V této kapitole se budu věnovat tomu, jak webová aplikace, která je produktem této bakalářské práce, funguje, jaké nástroje Google App Engine využívá a jak je uspořádaná. Aplikace je v rámci Google App Engine pojmenovaná jako „project-havar“, je to tzv. Application Indentifier a v celém systému aplikací registrovaných pod Google App Engine musí být jedinečný. K tomuto názvu je přiřazena doména „appspot.com“. Aplikace je tedy přístupná na URL adrese „http://project-havar.appspot.com/“. Uživatelé však mohou využívat i zabezpečené spojení. Aplikace je přístupná i na adrese „https://project-havar.com“, protože společnost Google poskytuje v rámci Google App Engine také certifikát k ověření identity vzdáleného počítače. Vystavitelem tohoto certifikátu je Google Internet Authority. V nastavení každé aplikace, v Dashboard, je možné přiřadit aplikaci také jinou doménu, viz kapitola 1.3.2. Já jsem k tomuto využil služby Google Apps, kam jsem si přiřadil svoji doménu „luciasch.com“. Podle pokynů a návodů Googlu jsem následně vytvořil doménový alias pro „project-havar.appspot.com“. Aplikace je tedy přístupná i přes URL adresu „http://bakalarska-prace.luciasch.com/“. Tabulka č. 2: Seznam URL adres webové aplikace

URL adresa webové aplikace http://project-havar.appspot.com/ http://bakalarska-prace.luciasch.com/ https://project-havar.appspot.com/ Aplikace je tvořena třemi hlavními soubory se zdrojovým kódem. Jsou jimi „main.py“, „logika.py“ a „db_model.py“. Vedle těchto souborů jsou v kořenovém adresáři aplikace také soubory „index.yaml“ a konfigurační soubor „app.yaml“, jejichž funkci popisuji v kapitolách 1.3.2 a 1.3.1. Aplikace obsahuje i dva podadresáře. První je „files“, což je adresář obsahující statické soubory: obrázky, soubory typu css a soubor „manual.pdf“. Druhým podadresářem

je

„templates“,

obsahující

„konfigurace.dat“.

37

soubory

typu

html

a

soubor

2.1 Modul main Modul main je hlavním souborem se zdrojovým kódem aplikace. Obsluhuje totiž všechny požadavky URL. Jak uvádím v kapitole 1.3.1, toto je nastaveno v konfiguračním souboru „app.yaml“. Je vytvořen v momentě, kdy je vytvořena nová aplikace. Pokud je soubor „main.py“ otevřen v textovém editoru, je vidět, že na začátku modulu jsou importované další moduly, které jsou zde nutné proto, aby bylo možné využívat třídy, metody a funkce použité v tomto modulu main. Tabulka č. 3: Seznam importovaných modulů

Název importovaného modulu a způsob jeho importu do main.py from google.appengine.ext import webapp from google.appengine.ext.webapp import util from google.appengine.ext import db import os from google.appengine.ext.webapp import template import logika import db_model import logging Webapp Je modul starající se o obsluhu frameworku Webapp. Webapp je WSGI (Web Server Gateway Interface) kompatibilní framework, který je poskytován v Google App Engine SDK. Aplikace, která využívá tohoto frameworku je tvořena ze dvou částí. 1. První jsou třídy, které se starají o obsluhu jednotlivých URL adres. Tyto třídy využívají metody, které jsou definované ve třídě RequestHandler umístěné v modulu webapp, viz tabulka č. 4. Příklad definice třídy Prvni class Prvni(webapp.RequestHandler): def get(self): self.response.headers['Content-Type'] = 'text/html' self.response.headers['Cache-Control'] = "public" self.response.out.write(““)

38

Z příkladu je jasné, že třída Prvni dědí od třídy RequestHandler umístěné v modulu webapp. Dále je zde vidět, že třída Prvni přepisuje metodu get, kterou podědila. Jako odpověď se vrací html stránka se základní strukturou html tagů. Tabulka č. 4: Seznam metod a atributů třídy RequestHandler[25]

Metoda

Atribut

Název get() post() put() head() options() delete() trace() handle_exception() error() redirect() initialize() Název request response

2. Druhou část tvoří funkce main, ve které je vytvořena instance třídy WSGIApplication. V této třídě se definuje mapování jednotlivých URL adres na třídy, jež se budou starat o jejich obsluhu, viz bod 1). Příklad definice funkce main def main(): application = webapp.WSGIApplication([('/', Nulta), ('/prvni', Prvni),],debug=True) util.run_wsgi_app(application)

Na tomto příkladu je vidět, že URL „/“ je namapovaná na třídu Nulta a URL „/prvni“ je namapovaná na třídu První. Toto mapovaní tvoří argument třídy WSGIApplication. Argument debug určuje v jakém módu poběží aplikace, v tomto příkladu je debug=True a znamená to, že se do webového prohlížeče budou zapisovat všechny výjimky. Pokud je funkce main zavolána, je WSGIApplication spuštěna pomocí metody run_wsgi_app. Ve své aplikaci mám definováno několik takových tříd, které obsluhují požadavky na jednotlivé URL adresy používané aplikací.

39

Tabulka č. 5: Seznam tříd modulu main

Název třídy Nulta Prvni Druha Treti Ctvrta About Chyba1 Chyba2 Chyba3 Chyba4 Konfigurace Soubor

Obsluhovaná URL „/“ „/prvni“ „/druha“ „/treti“ „/ctvrta“ „/about“ „/chyba“ „/chyba“ „/chyba“ „/chyba“ „/konfigurace“ „soubor“

Jakmile dojde k zadání konkrétní URL adresy, je vytvořena instance konkrétní třídy, která se má postarat o daný požadavek. Je vytvořena včetně atributů request a response, jež definuje třída RequestHandler a jsou to vlastně vstupní a výstupní data. Tedy například pokud si uživatel aplikace klikne na položku Základní parametry v menu, která má adresu „bakalarskaprace.luciasch.com/prvni“, obsluhuje tento požadavek třída Prvni. Template Google App Engine SDK obsahuje webový framework Django, napsaný v programovacím jazyce Python, a je tak možné využít některých komponent tohoto frameworku. Díky modulu template máme k dispozici šablonovací systém z Djanga, který nám dává spoustu možností jak pracovat s daty v šabloně. Příklad použití modulu template class Titulek(webapp.RequestHandler): def get(self): self.response.headers['Content-Type'] = 'text/html' self.response.headers['Cache-Control'] = "public" template_path = os.path.join(os.path.dirname(__file__), "templates/titulek.html") parametrs = {} parametrs['titulek_stranky'] = u"bakalářská práce" self.response.out.write(template.render(template_path, parametrs))

40

Na tomto příkladu je třída Titulek, která se stará o vypisování hodnot do obsahu stránky. Pokud dojde k zadání URL adresy, kterou tato třída obsluhuje, do webového prohlížeče zobrazí stránku „titulek.html“, což je v našem případě šablona. ƒ

template_path určuje který html soubor použít jako šablonu

ƒ

parametrs je slovník (v Pythonu je to datový typ dictionary), který obsahuje klíče a jim odpovídající hodnoty. Podle klíče se poté vypisuje daná hodnota do šablony.

Příklad šablony

Do slovníku parametrs jsme si uložili hodnotu „bakalářská práce“ pod klíčem „titulek_stranky“. V šabloně „titulek.html“ je pak mezi tagy