MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
DIPLOMOVÁ PRÁCE
Cloud computing řešení IT podpory pro malé a střední společnosti
Kotlík Martin
Brno 2010
Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, kterou jsem při vypracovávání používal, nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: doc. RNDr. Tomáš Pitner, Ph.D.
Poděkování Děkuji doc. RNDr. Tomáši Pitnerovi, Ph.D. za všechny cenné rady a připomínky k této práci. Také za jeho trpělivost a příjemné konzultace.
Shrnutí Úkolem studenta je nastudování požadavků firem na systém IT podpory a zhodnotit jaká řešení může daná firma použít. Popsat, kdy je výhodnější použít řešení založené na cloud computing než hostované či lokální, a zároveň zmínit i nevýhody těchto řešení. Dalším úkolem bude vybrat si jednu z platforem pro cloud computing, vytvořit netriviální systém jako ukázku řešení IT podpory pro firmy a zároveň demonstrovat možnosti této platformy. Aplikace by měla implementovat některé prvky běžné v podobných IT systémech nezaložených na cloud computingu.
Klíčová slova Google App Engine, PaaS, Java, Cloud Computing, Eclipse, Firm, GWT, Google Apps
OBSAH 1
Úvod ............................................................................................................................................................................... 1
2
Potřeby firmy ............................................................................................................................................................. 2 2.1
Požadavky na firemní systém.................................................................................................................... 2
2.1.1 2.2 3
Nabízená řešení / kritéria výběru řešení ............................................................................................. 4
Cloud Computing ...................................................................................................................................................... 6 3.1.1
Modely nasazení .................................................................................................................................... 8
3.1.2
Distribuční model SAAS, PAAS a AAAS ..................................................................................... 10
3.2
Výhody a nevýhody cloudu ..................................................................................................................... 11
3.3
Platforma jako služba ................................................................................................................................ 14
3.3.1
Amazon Web Services ...................................................................................................................... 15
3.3.2
Force.com Platform ........................................................................................................................... 16
3.3.3
Windows Azure Platform ............................................................................................................... 16
3.4 4
Požadavky zaměstnanců .................................................................................................................... 4
Porovnání různých systémových řešení ............................................................................................ 17
Google App Engine (GAE) .................................................................................................................................. 20 4.1
Prostředí Google App Engine.................................................................................................................. 21
4.1.1 4.2
Sandbox.................................................................................................................................................. 22
Podporované jazyky, vývojové IDE, použité technologie ........................................................... 23
4.2.1
Python..................................................................................................................................................... 23
4.2.2
Prostředí Java runtime .................................................................................................................... 24
4.2.3
App Engine Java SDK a vývojové prostředí ............................................................................. 26
4.3
Ukládání dat ................................................................................................................................................... 27
4.3.1
Databáze Bigtable .............................................................................................................................. 28
4.3.2
Java Data Interface (JDI) ................................................................................................................. 29
4.4
Služby poskytované GAE .......................................................................................................................... 30
5
4.5
Kvóty a poplatky za používání aplikací .............................................................................................. 34
4.6
Administrační rozhraní ............................................................................................................................. 35
4.7
App Engine pro business .......................................................................................................................... 37
Ukázková aplikace ................................................................................................................................................ 38 5.1
Použité technologie .................................................................................................................................... 38
5.1.1
Google Web Toolkit ........................................................................................................................... 39
5.1.2
Google Apps.......................................................................................................................................... 42
5.2
Textový rozbor ............................................................................................................................................. 43
5.3
Use case diagram a popis ......................................................................................................................... 44
5.4
Diagram entit a rozložení ......................................................................................................................... 46
5.5
Implementace aplikace ............................................................................................................................. 47
5.5.1
Přihlášení do aplikace ...................................................................................................................... 48
5.5.2
Práce uvnitř systému........................................................................................................................ 51
5.5.3
Budoucí vylepšení a rozšíření....................................................................................................... 52
6
Závěr ........................................................................................................................................................................... 54
7
Použitá literatura .................................................................................................................................................. 55
8
Příloha A.................................................................................................................................................................... 57
9
Příloha B.................................................................................................................................................................... 58
1 ÚVOD Rozhodl jsem se zpracovat diplomovou práci na téma cloud computing a vývojová prostředí kolem něj. Domnívám se, že v dnešní dynamické době, kdy je potřebné rychle reagovat na požadavky trhu a upravovat vlastnosti firemního systému podle potřeb zákazníků, ať se jedná o počet přístupů uživatelů k systému, velikost datového úložiště či výpočetní výkon, který je na něj kladen, jsou právě cloud computing služby tím směrem, kterým se bude vývoj a implementace nových aplikací pro společnost ubírat. Je možné, že celé nadšení kolem cloud computing služeb je pouze dočasné a že za pár let nikdo nebude vědět, o jakou technologii se tenkrát jednalo. Proto je potřeba vzít v úvahu všechny klady a zápory, které tyto služby přináší a vytvořit si svůj názor. Moje diplomová práce by se proto měla zaměřit především na tyto problémy: zjistit potřeby společností a jak pomocí cloud computingu tyto nároky splnit, dále rozebrat jednotlivé složky cloudu a popsat, co obsahují. Úkolem práce je také zjistit, zda jsou platformy založené na cloud computingu na takové úrovni, která by programátorům umožnila programovat systémy stejné, nebo alespoň podobné těm založeným na jiných programových řešeních. Pro vytvoření ukázkové aplikace jsem si vybral platformu „Google App Engine“ (GAE), jelikož je s některými omezeními poskytován zdarma a mohl jsem jí tak bezplatně zkoušet a zkoumat. Na této platformě se pokusím vystavět systém, který by byl určen pro menší firmy, právě kvůli tomu, že malé firmy si často nemůžou dovolit zpočátku investovat do nákladných technologií a zdlouhavých procesů vývoje. Tento systém by měl demonstrovat schopnosti GAE a několika dalších služeb, které rozšíří jeho funkcionalitu.
1
2 POTŘEBY FIRMY Systém pro IT podporu je důležitou součástí jakékoliv firmy. Je prostředkem k řešení vzniklých problémů, plánování schůzek, ukládání dat, reportování chyb a podobných důležitých procesů v podniku. Není jednoduché napsat seznam potřeb firmy, které by měl splňovat firemní systém, a to hned z několika důvodů. Každá firma je jiná a zasahuje do jiného obchodního sektoru, tedy má i jiné požadavky na obsah systému. Dále se bude s největší pravděpodobností v průběhu času měnit (zvětšovat, rozšiřovat svoje služby, měnit zaměření) a s ní i její potřeby a takových podobných problémů by nás jistě napadlo ještě mnoho dalších. Rozhodl jsem se proto, že převedu firemní potřeby na obecnější rovinu a rozeberu je z pohledu postupů a specifikací, které jsou dané obecně a je potřeba je dodržovat. Hlavním kritériem, které by měl každý firemní systém splňovat je, že by měl firmě účelně sloužit a efektivně zvyšovat její produktivitu. Existuje mnoho faktorů, které je potřeba vzít v úvahu a přizpůsobit je tvorbě firemního systému. Často se o tyto problémy ve firmě stará určitá specializovaná skupina lidí, nazývaná „IT organizace“, která postupuje podle sad doporučení a praktik pro poskytování IT podpory. Ve většině firem je to právě IT organizace, která zajišťuje optimalizaci a efektivitu firemních procesů. S rostoucí komplexností a náročností úkolů rostou i požadavky na IT organizaci ve firmě. Tyto požadavky jsem upravil do podoby, které se vztahují k firemnímu systému. Nyní si uvedeme některé podstatné body, které by měly zajistit plynulý chod IT systému.
2.1 Požadavky na firemní systém Udržení IT infrastruktury v chodu – IT systém bude podporovat a zefektivňovat mnoho firemních procesů, tím pádem se firma stává na něm závislá a každý 2
výpadek může způsobit výrazné snížení výkonnosti společnosti. To by přineslo finanční ztráty, ztráty zákazníků, atd. Z tohoto důvodu je důležité zajistit, aby systém byl dostatečně stabilní a chráněný proti výpadkům. Zvyšování přidané hodnoty – Firemní systém je ve firmě vnímán jako podpůrná složka a jako taková by měl přinášet firmě určitou přidanou hodnotu. Každá služba systému by měla být prověřena, že přináší určitou hodnotu, pokud ne, neměla by se vůbec implementovat. Stejně je to i s nově zaváděnými službami, které by měly být prospěšné pro celou organizaci. Snižování ceny – Investice firmy do vývoje systému přináší pro firmy nemalé náklady. Tyto náklady rostou s novými technologiemi, zrychleným životním cyklem programového vybavení, komplexností řešení a různými legislativními požadavky. Je proto důležité, aby byl systém řízen efektivně a ve finálním důsledku přinášel zisky, ne výdaje. Snižování komplexnosti – Z různých důvodů, ať už historických nebo technologických, se IT infrastruktura skládá z různých řešení, které je nutno navzájem propojit. Postupem času tak vzniká příliš komplexní řešení, kde každý systém musí být propojen se všemi ostatními a data jsou uložena na více místech. Cílem je tedy minimalizovat přenosy dat a centralizovat správu. Sladění s potřebami organizace – V minulosti IT organizace neimplantovaly technologie tak, aby byly správně svázané s firemními procesy. Proto se ne vždy podařilo sladit požadavky firmy s těmito procesy. Je proto důležité definovat a zajistit služby, že jsou svázané s příslušnými firemními procesy a nové IT služby jsou zaváděny na základě jasně definovaných principů, které jsou v souladu se strategií firmy. Sladění legislativních požadavků – V rámci různých průmyslových odvětví je nutné splnit určité požadavky dané legislativou či jinou regulací. Jde například o farmacii, energetiku, apod. Tyto požadavky se můžou průběžně měnit a jejich nesplnění má mnoho negativních následků. Je tedy nutné systém vyvinout s ohledem na požadavky příslušných zákonů a jiných regulací. 3
Zajištění bezpečnosti – V současném konkurenčním prostředí je nutné chránit vlastní data a informace. Mohlo by dojít ke zneužití informací, krádeži nebo jejich poškození. Je proto nutné, aby systém použitý pro jejich sdílení, byl adekvátně chráněn proti takovým zásahům.
2.1.1 Požadavky zaměstnanců Z pohledů uživatelů jsou požadavky na systém podstatně jednodušší a přímočaré, týkající se většinou grafického rozhraní a pohodlnosti ovládání. Požadavky uživatelů na systém definoval V. Sklenák (1) jako následující: nejkratší doba odezvy od zadání dotazu uživatele a odpovědí systému uchovávání užitečných údajů, účelné uživatelské rozhraní v jeden okamžik může pracovat se stejnými daty/dokumenty více uživatelů trvalost uchovávání a minimalizace redundance dat dotazovací jazyk blízký přirozenému jazyku možnost zabezpečeného přístupu co nejjednodušší vyhledávání s minimálními nároky na učení uživatele efektivní přidávání, rušení a aktualizace dat (resp. dokumentů) trvalá dostupnost bez jakýchkoliv časových omezení
2.2 Nabízená řešení / kritéria výběru řešení V dnešní době dostupného a rychlého internetu se rozdíly mezi aplikacemi pro web a desktop stírají a klasické programy se stále více blíží „chytrým“ webovým stránkám. Není tedy divu, že většina společností se uchýlila k webovému řešení pro svůj systém pro IT podporu. Do nedávné doby ovšem neměly firmy příliš na výběr při samotném vytváření systému, bylo třeba mít vlastní zázemí ve firmě, servery a zaměstnance, kteří se o ně starali. Na těchto serverech se následně budoval nějaký informační systém či jiný program. O provoz serverů se bylo nutno dále starat a vynakládat další nemalé částky na udržení jejich bezproblémového chodu.
4
Proto se firmy začaly častěji přiklánět k webovému řešení IT podpory, které vyžadovalo menší náklady a počáteční investice. Nyní mají na výběr ze dvou řešení. Vybudovat systém pomocí webových technologií na hostovaných serverech, kde je potřeba si všechny technologie nainstalovat a přizpůsobit a doufat, že se jejich požadavky na systém v blízké době nezmění, nebo můžou využít nových služeb cloud computingu a přizpůsobit se nabízeným technologiím poskytovatele, za což jim bude odměnou flexibilní prostředí a možnost celé úsilí zaměřit pouze na kvalitní vytvoření aplikace.
5
3 CLOUD COMPUTING
Obrázek 3.1: Zobrazení cloud computingu1
Základní myšlenka cloud computingu sahá až do roku 1961, kdy John McCarthy2 vyjádřil, že by bylo možné výpočetní úlohy organizovat jako veřejnou službu. Název „mrak“(cloud) byl převzat od telefonních společností, do roku 1990 přednostně nabízejících datové okruhy pro přímé spojení mezi dvěma síťovými uzly, které začaly propagovat svoje privátní virtuální sítě (VPN)3 se srovnatelnou kvalitou, ale mnohem nižší cenou. Odkloněním přenosů k vyvážení využití byli schopni využít celkovou šířku pásma sítě mnohem efektivněji. Symbol mraku byl použit jako znázornění bodů, mezi kterými byla oddělena zodpovědnost poskytovatele od uživatele. Cloud computing později rozšířil tyto hranice na pokrytí serverů, stejně tak jako infrastruktury.
1
Zdroj obrázku - http://en.wikipedia.org/wiki/Cloud_computing
http://computinginthecloud.wordpress.com/2008/09/25/utility-cloud-computingflashback-to-1961prof-john-mccarthy/ 2
3
http://en.wikipedia.org/wiki/Virtual_Private_Network
6
Firma „Amazon“1 byla jednou z klíčových společností ve vývoji cloud computingu. Když roku 2001 po skončení internetové horečky2 firma modernizovala svá datová centra, tak zjistila, že v dlouhodobém měřítku používají jen 10 % svého výkonu (tedy až na výjimečné větší zátěže), stejně jako se tento jev prokázal později u ostatních velkých firem na světě. Analytici zjistili, že firma těmito nevyužívanými kapacitami přichází ročně o nemalé peníze. Toto zjištění a další postupný rozvoj cloud architektury vyústil v roce 2006 v rozhodnutí firmy Amazon poskytnout ostatním přístup ke svým zdrojům pomocí Amazon Web Services3 a stali se tak prvním poskytovatelem cloud služeb. V roce 2007 se přidaly firmy IBM a Google4, současně s nimi i několik univerzit a začali vyvíjet velké množství výzkumných projektů zabývajících se cloud computingem. Během poloviny roku 2008 se začalo utvářet spojení mezi dvěma skupinami lidí. Jedna skupina IT služby požadovala a druhá skupina je nabízela, což bylo přesně vhodné období pro rozvoj cloud computingu. Firmy začaly uvažovat jinak a místo svého hardwaru a softwaru začali využívat služeb třetích stran, za které platily pravidelné měsíční poplatky. V úplném základu by se dal cloud computing přirovnat k novému obchodnímu modelu a nové uživatelské zkušenosti. Je to pojetí sdílené infrastruktury, v němž jsou rozsáhlé zdroje počítačových systémů propojeny a společně poskytují služby IT. To vyhovuje vysokým výkonnostním nárokům dynamického webu, kde jsou obrovské objemy informací zpracovávány ve zlomcích sekund. Uživatelům IT nabízí cloud computing rychlý přístup k všem možným druhům informací, bez ohledu na to, z jakého zařízení ke cloudu přistupují. Pracovníci, partneři a zákazníci požadují přístup k sofistikovaným aplikacím a důraz kladou zejména na jednoduchost jejich použití. Pokud jde o přesnou definici spojení slov „cloud computing“, stále ještě existují určité nejasnosti. Pokusím se tedy uvést svojí definici. Cloud computing je nové paradigma, ve kterém třetí strany, takzvaní „poskytovatelé cloud služeb“ CSP (cloud service providers), nabízejí hardwarové a softwarové služby. Dalo by se tedy říci, že jde o poskytování škálovatelné výpočetní techniky, která je dostupná na dálku a přes
1
http://www.amazon.com/
2
http://cs.wikipedia.org/wiki/Internetová_horečka
3
http://aws.amazon.com/
4
http://www.ibm.com/cz/cs/ a http://www.google.cz/
7
internet. Tyto služby mohou být poskytovány v rámci firmy (privátní cloud) nebo třetí stranou (veřejný cloud). Architektura platformy cloud computingu však může být také hybridní, poté v sobě integruje privátní i veřejné platformy. Dnes jsou s cloud computingem nejvíce spojovány velké webové aplikace. Jako příklad lze uvést Google Apps1, Microsoft Live Office2 či právě vyvíjený operační systém Google Chrome OS3.
3.1.1 Modely nasazení
Obrázek 3.2: Modely cloud computingu
Klasickým modelem cloud computingu je „Veřejná cloud infrastruktura“. Ta je poskytnuta a nabídnuta široké veřejnosti jako výpočetní služba přes webové rozhraní či služby. Tyto služby nám nabízí většinou poskytovatel třetí strany, často za malé poplatky. V dnešní době je jedním z nejdůležitějších kritérií při přechodu firem na cloud služby bezpečnost a záruka. Tyto záruky jsou nyní obvykle řešeny dohodami o úrovni služby s poskytovateli cloud computingových řešení. Výzkumy agentury Gartner
1
http://www.google.com/apps/
2
http://office.microsoft.com/cs-cz/office_live/default.aspx
3
http://www.google.com/chrome
8
Research1 ukazují, že do roku 2013 bude záruka kvality a úrovně služeb nejdůležitějším faktorem pro 90% ze všech společností, které budou využívat služby cloudu. Hlavní samostatnou oblastí je zabezpečení dat. Některá data například nesmí opustit podnik nebo určitou geografickou lokalitu. Dohled a posouzení toho, které pracovní úlohy lze provozovat ve veřejném cloudu a které musí být zachovány na interní infrastruktuře, má proto zásadní význam. Pro mnoho společností byl právě ohled na bezpečnost dat hlavním důvodem k vybudování „Privátní cloud infrastruktury“, která je provozována výhradně za firewallem. Tímto způsobem si mohou společnosti udržet dostatečnou úroveň bezpečnosti a zároveň řízením přístupu mohou poskytnout přístup svým zaměstnancům nebo dalším uživatelům z okolních sítí, jako například obchodním partnerům a společníkům. Větší podniky mohou mít část svého IT systému umístěny na veřejných cloudech, ale stále potřebují vlastní infrastrukturu kvůli bezpečnosti, odolnosti a legislativním požadavkům, jimž standardizovaná řešení nemohou vyhovět. Těmto omezeným požadavkům nejlépe vyhovuje „Hybridní cloud computing“. Spojením privátního a veřejného cloudu v hybridní získá společnost kontrolu, lepší zabezpečení a odolnost privátního cloudu spolu s flexibilitou veřejného cloudu. Předpokládá se do budoucna, že hybridní řešení bude představovat majoritu ze všech cloudů. Speciálním případem cloudu je „Komunitní cloud computing“. Jedná se o model, kdy je cloud infrastruktura sdílena mezi několika organizacemi, skupinou lidí, kteří ji využívají. Tyto organizace může spojovat bezpečnostní politika nebo stejný obor zájmu. Příkladem takového cloudu je například „Gov Cloud“2 od firmy Google.
1
http://www.gartner.com/technology/home.jsp
2
http://www.govtech.com/gt/724044
9
3.1.2 Distribuční model SAAS, PAAS a AAAS Distribuční model se zabývá tím, co je v rámci služby nabízeno, obvykle software, hardware či jejich kombinací. Tyto služby jsou uspořádány ve vrstvách, ale vzájemně nejsou zcela autonomní a některé služby zasahují do více vrstev.
Obrázek 3.3: Vrstvy distribučního modelu cloud computingu1
Úplně v základu celé infrastruktury musí být nějaké hardwarové a softwarové vybavení, které slouží a je speciálně navrženo pro fungování cloud computingu. Nad tímto vybavením se nachází první vrstva „Infrastruktura jako služba“ (IAAS Infrastructure as a Service). V této vrstvě služeb poskytovatel nabízí počítačovou infrastrukturu, typicky se jedná o virtualizaci. Raději než aby si zákazník kupoval servery, software, datová centra a síťová vybavení, tak si tyto zdroje může koupit jako plně funkční vzdálené služby. Za tyto služby se obvykle platí jen tolik, kolik zákazník spotřebuje zdrojů za určité časové období. Nad touto vrstvou IAAS je vrstva „Platforma jako služba“ (PAAS - Platform as a Service). Poskytovatel v PAAS vrstvě distribuuje výpočetní platformu a kompletní prostředky pro podporu celého životního cyklu tvorby a poskytování webových aplikací a služeb. Uživatel nemusí znát nic dalšího a nemusí se zajímat o nákup či správu spodních vrstev hardwaru a softwaru.
1
Zdroj obrázku - http://markusklems.sys-con.com/
10
Poslední vrstvou je „Software jako služba“ (SAAS - Software as a Service). Vrstva SAAS poskytuje uživateli aplikace, které jsou licencovány a pronajímány uživateli za poplatky. Tyto aplikace jsou dostupné přes webové rozhraní, což eliminuje nutnost instalovat a spouštět aplikace na lokálních počítačích a ulehčí správu a technickou podporu.
3.2 Výhody a nevýhody cloudu Jako každá technologie i cloud computing má své výhody a nevýhody. Nyní bych rád zmínil alespoň několik hlavních bodů z obou kategorií, aby byly vidět, s jakými problémy se budou muset uživatelé potýkat a jaké úskalí tato technologie skýtá. Mezi hlavní výhody cloud computingu patří: Lepší finanční přehled – Implementace IT kapacit vyžaduje obvykle velkou počáteční investici, zejména do hardwarové části. Poskytovatelé často nabízejí účtovací model na základě toho, kolik jste využili systémových prostředků. Účtují podle toho, kolik času vaše společnost stráví v cloud systému nebo podle toho, kolik spotřebuje zdrojů (připojení, přenesená data, zaplnění skladovacího prostoru). V modelu peněžního toku1 jsou následně všechny tyto položky zavedeny a přehledně zobrazeny, což umožňuje firmě získat podrobný a hlavně přehledný a přesný soupis jejích výdajů. To může vést firmu k přehodnocení poptávky po IT službách a jejich optimalizaci. Spolupráce a sdílení schopností – Cloud computing poskytuje nové možnosti spolupráce a sdílení. Jako příklad můžu uvést generální opravu emailového systému, používání wiki, virtuálních ploch a webových konferencí. Takové formy spolupráce urychlují a zlepšují komunikaci mezi jednotlivými podniky i rámci jedné firmy, jakožto i produktivitu práce s nimi. Rychlé poskytování a pružné škálovnání – Poskytovatel nabízí okamžitý přístup k široké škále služeb. Ještě důležitější je ovšem, že budete moci nastavit způsob
1
http://en.wikipedia.org/wiki/Cash_flow
11
škálování, jak budete své IT používat. Zda to bude nahoru, či dolů záleží jen na vás a na vašich obchodních potřebách. Díky poskytnuté flexibilitě lze snadno a pružně reagovat na měnící se obchodní požadavky. Nižší náklady na řízení – Vaše IT služby jsou umístěny v cloud computing prostřední a poskytovatel se o ně stará jménem vaší organizace v rámci centralizované správy. Mohou tak získat velké úspory v rámci rozlohy a celkově se tak snižují náklady na IT služby. Zaměření se na podstatné – Poskytovatelé budou spravovat kompetence a služby, které nejsou klíčové pro většinu vedení firem a pro jejich podnikání. To znamená, že pozornost se může přesunout od problémů, jako neustálé opravování softwaru a jiných počítačových problémů k novým strategickým cílům a technologiím, které jsou důležité pro podnikání a dosahování obchodních cílů. Ohled na životní prostření – Virtualizace aplikací několika serverů vede k vyššímu využití výpočetního výkonu a nižším ztrátám
vznikajícím
z nečinnosti. Počítače se pak mohou přesunout do výpočetních center, které pohání „zelená energie“ (solární, termální) a které používají nízkoenergetická zařízení. Tato opatření mohou přispět k úsporám na životním prostřední. Pokud se cloud computing aplikuje na správných místech a s rozvahou, může přinést konkrétní výhody. Není ovšem ideální pro každou situaci a skýtá řadu rizik, na které je potřeba dát si pozor, zejména pokud se jedná o veřejný cloud. Nedostatečná průhlednost a soulad se zákony – Žádná společnost neprojde klientským auditem schopností, pokud nemůže prokázat, kdo všechno má přístup k informacím a jak zabrání neoprávněnému přístupu. Aby tyto požadavky bylo možné uspokojit, je nutné od poskytovatele vyžádat a prozkoumat nezávislou auditorskou zprávu ještě před tím, než začne odebírat jejich služby. Poskytovatel by měl také udržovat dostatečný monitoring a záznamy přístupů do systému.
12
Vlastnictví dat a ochrana osobních údajů – Poskytovatelé mohou nakládat s vašimi daty jinak, než bylo původně zamýšleno. To zahrnuje neoprávněné prohledávání a profilování. Pokud je duševní vlastnictví firmy rozloženo geograficky přes několik států nebo i světadílů, můžou vznikat neočekávané problémy, které mohou například omezit její právní nárok na náhradu škody. Je tedy potřeba dopředu specifikovat a mít smluvně domluveno, jaké zeměpisné rozložení dat je pro společnost přípustné a které není. Existují vlády v EU, které zakazují předávání některých osobních údajů mimo hostitelské země, což může mít také různé právní důsledky. Například v USA platí zákon Patriot Act1, který říká, že americká vláda může získat přístup k datům uloženým na amerických serverech. Omezená rychlost a dostupnost – Abyste mohli využívat cloud služby, je přístup k internetu rozhodující. Při velkém zatížení provozu nebo špatně navrhnuté aplikaci může docházet ke zpoždění, které se negativně projeví na chování služby. Je tedy nutné se s poskytovatelem služby dohodnout na maximální délce přijatelného zpoždění. Omezená záruka na úroveň služeb – Většina prodejců sice poskytuje tzv. service credits za výpadky služby, ale škody napáchané po dobu výpadku už můžou být závažné a nevratné. Opět by měl být definován proces o tom, jak se budou řešit případné spory. Licenční modely a účtování – Existuje celá řada modelů, jakým způsobem licencovat a účtovat cloud computing (jedna licence, sdílená licence, dočasné užívání, či platba podle užívání). Ať je již jakýkoliv model aplikován na veřejný, privátní či hybridní cloud, tak zákaznická organizace musí dobře chápat, jaký má profil a podle toho ustanovit licenční a účtovací model. Širokopásmé připojení a další náklady – Širokopásmé připojení pro rozsáhlé aplikace a pro cloud služby se může i v dnešní době ještě docela prodražit. Pokud například plánujete přemístit velkou databázi (v rámci terabytů) do
1
http://www.fincen.gov/statutes_regs/patriot/
13
cloud prostředí, tak se náklady na její přesunutí prostřednictvím internetu výrazně zvýší. Závislosti na jednom prodejci – v oblasti cloudu není často zaručena přenositelnost mezi více poskytovateli. Je potřeba si tedy zajistit, aby poskytovatel zajistil zálohu vašich dat v přenositelné formě.
3.3 Platforma jako služba Do PaaS vrstvy se řadí většina vývojových prostředí založených na cloud computingu.
PaaS je v podstatě virtuální sadou nástrojů se všemi pokročilými
prostředky potřebnými k vytváření, testování a nasazování vlastního softwaru pro jakékoliv účely. Namísto nákupu stavebních bloků aplikací a jejich instalace na vlastním hardwaru, využívají uživatelé služby PaaS integrované webové vývojové prostředí, jako jsou .Net1 nebo Java, pomocí nichž mohou rychle vytvořit přesně to, co potřebují. V některých případech mohou dokonce obratem prodat to, co vytvořili nebo své řešení nabídnout jako službu pro jiné společnosti. Šlo by tedy říci, že PaaS představuje prostředí, ve kterém se vyvíjí určitá aplikace, která je po jejím dokončení nabízena jako služba SaaS. Jako příklady dnešních nejznámějších PaaS můžu uvést Amazon Web Services, Windows Azure Platform2, na jiném přístupu založený Force.com platform3, nebo Google App Engine4, na který se zaměřím primárně a podrobněji ho popíši až v kapitole „4. Google App Engine (GAE)“
1
http://www.microsoft.com/NET/
2
http://www.microsoft.com/windowsazure/
3
http://www.salesforce.com/platform/
4
http://code.google.com/appengine/
14
Obrázek 3.4: Služby poskytovatelů znázorněné podle vrstev1
3.3.1 Amazon Web Services Jednou z prvních platforem, která byla uvedena do provozu, byla Amazon Web Services (AWS). Společnost Amazon hledala možnosti, jak využít volné serverové kapacity, které sama využívala jen přes svátky, především kolem vánočních svátků. Služby AWS proto, jak vidíme na obrázku 3.4, zasahují i do jiných vrstev cloud modelu. Amazon ve svých Web Services nabízí např. úložiště S3 (Simple Storage Service), které nabízí relativně neomezený úložný prostor a službu CDN - Content Delivery Network, při níž jsou data kopírována do uzlových serverů po celém světě a uživatelům jsou vždy poskytována z nejbližšího uzlu. Další klíčovou službou je EC2 (Elastic Computer Cloud), která nabízí virtuální servery. AWS dále poskytuje dvě databázové služby, „SimpleDB“ (jednoduchá key-value databáze) a nedávno spuštěná RDS (Relational Database Service). Náročnějším zákazníkům nabízí vlastní privátní cloud, „load ballancer“, „fulfillment service“ (službu kompletace zásilek a distribuce k zákazníkům), platební brány a další služby včetně např. "pronájmu pracovní síly", kdy
1
Zdroj obrázku - http://markusklems.sys-con.com/
15
si můžete pomocí služby „Mechanical Turk“1 najmout lidi k tomu, aby dělali práci, kterou stroj nezvládne - například pro ohodnocení relevance výsledků vyhledávání.. Pro všechny tyto služby existuje API (Application Programming Interface), neboli aplikační programové rozhraní, takže je možné jejich provoz řídit programově - např. podle potřeby spouštět další servery.
3.3.2 Force.com Platform PaaS od firmy Salesforce se jmenuje Force.com Platform. Tato platforma podobně jako AWS zasahuje do více vrstev modelu cloudu. Hlavní rozdíl spočívá v tom, že neposkytuje svojí infrastrukturu, ale aplikace. Samotná tvorba vlastních aplikací probíhá v přehledném grafickém rozhraní, které umožňuje sestavit funkčně relativně rozsáhlý software bez nutné znalosti jakýchkoliv programovacích jazyků či jiných, jinak potřebných technologií. Aplikace jsou tedy jakousi nadstavbou již existujících aplikací firmy Salesforce, provozovaných na jejích serverech. Force.com umožňuje návrh vlastní aplikační logiky za použití programovacího jazyka Apex2 (jazyk podobný Javě, který byl vytvořen primárně pro firmu Salesforce.com) nebo Visualforce3 (metajazyk syntaxí podobný XML, který slouží pro budování rozhraní pro technologie HTML4, AJAX5 a Flex6)
3.3.3 Windows Azure Platform Platforma Azure od společnosti Microsoft7 byla oficiálně ohlášena v roce 2008 a od ledna 2010 vstoupila do komerčního stádia, měsíc poté byla zpoplatněna. Celá
1
https://www.mturk.com/mturk/welcome
2
http://www.salesforce.com/landing/apex.jsp
3http://wiki.developerforce.com/index.php/Introducing_Visualforce_-
_Create_Any_User_Interface_as_a_Service 4
http://www.w3.org/standards/techs/http
5
http://www.w3schools.com/ajax/
6
http://www.adobe.com/products/flex/
7
http://www.microsoft.com/cze/
16
platforma je koncipována jako operační systém pro globální infrastrukturu serverů a datových center, založených na službách situovaných na nejnižší úrovni a jako základní podpůrný pilíř architektury, služby jádra pro cloud virtualizaci, škálovatelné služby a úložný prostor. Azure se skládá ze tří základních pilířů: Windows Azure – jde o operační prostředí, umožňující pružné hostování aplikací, řízení služeb a správu místa pro uložení dat včetně zajištění rozsáhlého škálování. SQL Azure – ve svém konceptu se jedná o relační databázi poskytovanou formou služeb. Technologicky se jedná o rozšíření funkcionality databázové platformy SQL Server1. Databáze jsou virtuální, takže se uživatel nemusí starat o administraci, zabezpečení, zálohování ani replikace. AppFabric – Primárním úkolem AppFabric je starat se o bezpečné propojení mezi službami, tedy nasazení aplikace a definování její konektivity. Kromě toho zahrnuje i „caching“ paměti pro zvýšení výkonu, workflow hostování a sledování konektivity. Windows Azure je v současnosti provozován na šesti datových centrech, rozdělených na tři páry, které se mezi sebou vzájemně replikují. Jeden pár je umístěn v Severní Americe, druhý v Evropě a třetí v Asii. Počty center budou s narůstajícím počtem uživatelů přibývat. Služby Azure nejsou bezplatné, nebudu zde ale uvádět ceny, protože jsou proměnlivé. Vypočítávají se jako u běžné cloud služby (použitý výpočetní čas, disková kapacita, výkon, atd.).
3.4 Porovnání různých systémových řešení Obecně cloud computing přináší užitek jak malým, tak i velkým firmám. Malé firmy se díky cloud computingu mohou vyhnout dalším investicím do infrastruktury IT. Začínající firmy platí pouze za služby IT, které využívají a platí jen takovou kapacitu využitých prostředků, jakou potřebují. Velké firmy mohou využít hybridní cloud pro bezpečné uložení vlastních dat. Kdy je však vhodné využít cloud platformu pro vývoj
1
http://www.microsoft.com/cze/sqlserver2008/default.mspx
17
softwaru a kdy se vyplatí využít jiné řešení, ať už se jedná o hostované řešení či umístění na lokálním serveru? Pokusím se nejdůležitější body shrnout do tabulky. Cloud computing Technologie Většinou nové nebo
Bezpečnost
Hostované řešení
Lokální server
Technologie, které
Záleží na nás, jakou
upravené technologie,
nabízí poskytovatel na
technologii zvolíme a jak
se kterými je potřeba se
svém webovém
ji naimplementujeme.
naučit zacházet.
prostoru.
Na veřejném cloudu je
Většinou na dobré
Servery jsou umístěny
bezpečnost
úrovni, záleží opět na
většinou za naším
nedostatečná, lepším
poskytovateli.
firewallem, bezpečnost
řešením je privátní
je tedy dostatečná
cloud. Databáze
Nové nebo upravené
Využívá různé komerční Je možná implementace
virtuální databáze,
i volně šiřitelné
jakékoliv dostupné
které jsou upravené
databáze.
databázové technologie.
speciálně pro danou PaaS. Umístění
Servery jsou
Servery jsou
Servery jsou umístěny
serverů
provozovány v centrech
provozovány
v dané společnosti.
rozmístěných po celém
v centrech, většinou na
světě.
jednom místě.
Dostupnost obvykle
Dostupné téměř vždy.
Interně dostupné téměř
přes spolehlivou
Při výpadku je
vždy. Vlastní personál se
internetovou linku.
provedena rychlá
stará o správný chod.
Dostupnost
obnova.
18
Cena
Platí se jen za to, co se
Platí se měsíční
Velká počáteční
využije, ceny jsou proto
pronájem, většinou
investice, poté se platí
různé a uživatel platí
pevná částka.
elektrická energie a
jen to, co použije. Správa
správa zařízení.
Zákazník se nemusí o
Zákazník si většinu
Všechny věci, od
nic starat. O vše se stará
nastavení a technologii
nasazení serveru po
poskytovatel.
implementuje sám.
instalace, si zákazník zařizuje sám.
Tabulka 1: Srovnání jednotlivých systémových řešení
19
4 GOOGLE APP ENGINE (GAE) Google App Engine nebyl první PaaS službou, ani dnes již není nejnovější produkt, přesto jsem si zvolil právě GAE, a to kvůli mému kladnému vztahu k firmě Google a jejím produktům. Dalším důvodem bylo, že v podstatě jako jediný nabízí téměř všechnu funkcionalitu zdarma a byl jsem tedy omezen jen dodatečnými limity, které ve své práci ještě podrobněji popíši1. První beta verze platformy App Engine od firmy Google vznikla v dubnu roku 2008. Vznikla jako reakce na rozmáhající se fenomén Cloud computingu a také z důvodu, že servery Googlu, stejně jako ostatní velké společnosti, nevyužívají plně svoji výpočetní kapacitu. Na začátku se jednalo o prostředí, které překvapivě podporovalo pouze jazyk Python2, který není přeci jenom dnes příliš rozšířený. U firmy Google je ale Python vcelku běžným jazykem a jde od roku 2006 po C++3 a Javě4 o třetí podporovaný jazyk5, což znamená, že vývojáři mohou vyvíjet aplikace pro Googlu v tomto jazyce. Během dalších měsíců vydal Google další verze GAE a na jaře roku 2009 byla přidána podpora jazyku Java. Nutno říci, že podpora Javy byla přidána i na četné žádosti komunity, která se vytvořila okolo App Engine. Tato komunita se od roku 2008, kdy čítala přibližně 10 tisíc vývojářů, značně rozrostla na dnešních 250 tisíc.
1
O omezeních GAE v kapitole 4.5 Kvóty a poplatky za používání aplikací
2
http://www.python.org/
3
http://www.cplusplus.com/info/description/
4
http://java.sun.com/
http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm - zpráva o jazyku Phyton a jeho podpoře u firmy Google. 5
20
Obrázek 4.1: Růst počtu vývojářů na platformě GAE1
4.1 Prostředí Google App Engine Struktura App Engine je velmi odlišná od typického webového aplikačního serveru. Nejdůležitějším prvkem je, že GAE zakazuje vaší aplikaci jakýkoliv přístup k fyzické infrastruktuře, která leží pod aplikační vrstvou. Zabraňuje vám otvírat sockety, spouštět procesy na pozadí (výjimkou je softwarový démon CRON2) a používat některé další rutinní operace, které jsou považovány vývojáři aplikací za běžné v jiných prostředích.
Tato omezení jsou v App Engine převážně z toho důvodu, aby byla
zachována jeho vysoká škálovatelnost a spolehlivost. Za tato omezení nám ovšem App Engine nabídne na oplátku možnost vybudovat aplikace rychle a s následujícími vlastnostmi: Dynamická webová obsluha s plnou podporou pro běžné webové technologie. Perzistentní datové úložiště s dotazovacím jazykem, řazením výsledků a transakcemi pro zajištění konzistence. Automatické škálování a vyvažování zátěže.
1
Zdroj Obrázku - http://googleappengine.blogspot.com/
2
http://code.google.com/intl/cs-CZ/appengine/docs/java/config/cron.html
21
Rozhraní pro autentizaci uživatelů a posílání elektronické pošty pomocí Google účtů. Plnohodnotné lokální vývojové prostředí, které simuluje Google App Engine na vašem počítači. Zpracování úloh ve frontě mimo rámec webového dotazu. Naplánované úlohy pro spouštění událostí v App Engine v daný čas nebo v pravidelných intervalech. Toto nejsou všechny vlastnosti, ani omezení, které jsou v GAE obsaženy. Vybral jsem jen některé, které demonstrují, že i přes některá omezení nám tato platforma přináší velké výhody a vyplatí se nám tato omezení dodržovat.
4.1.1 Sandbox Každá aplikace je spuštěna v bezpečném prostředí, které poskytuje pouze omezený přístup ke spodním funkcím operačního systému. Toto prostředí se nazývá „sandbox“. Daná omezení umožní App Enginu rozdělit webové dotazy pro aplikace na více serverů zároveň a upravovat běh serverů podle požadavků webového provozu. Sandbox izoluje vaši aplikaci ve svém vlastním bezpečném a spolehlivém prostředí, které je nezávislé na hardwaru, operačním systému a fyzickém umístění webového serveru. Jako příklady omezení uvedu: Aplikace nemůže zapisovat do souborového systému. Je dovoleno pouze čtení souborů, a to navíc jen souborů, které byly nahrány spolu s aplikací. Aplikace musí k práci se všemi daty, které si chce udržet mezi dotazy, použít datové úložiště App Engine, memcache nebo jinou službu poskytovanou platformou. Aplikace může komunikovat s ostatními počítači pomocí poskytované služby URL fetch a emailových služeb. Ostatní počítače můžou být připojeny k aplikaci pouze přes HTTP (nebo HTTPs) dotazy na standardních portech. Kód aplikace může běžet pouze jako odpověď webového dotazu, úlohy na pozadí nebo naplánované úlohy a musí vrátit odpověď do 30 sekund. Aplikace také nemůže vytvářet více vláken, ani podprocesy.
22
4.2 Podporované jazyky, vývojové prostředí a použité technologie Google App Engine podporuje v základu dva jazyky pro psaní aplikací. Jedná se o Javu a Python, později se ukáže, že to není zcela přesná informace vzhledem tomu, že lze na Java platformě lze spustit i jiné programovací jazyky, které nejsou oficiálně podporovány. Obě prostředí, jak Java, tak Python, jsou budována tak, aby bylo zaručeno, že vaše aplikace budou fungovat rychle, bezpečně a bez jakéhokoliv ovlivnění ostatními aplikacemi v systému.
4.2.1 Python Prvním z jazyků, pro který je App Engine přizpůsoben, je Python. Já jsem se rozhodl aplikaci implementovat v jazyce Java, proto se budu věnovat jazyku Python pouze okrajově. GAE Python runtime prostředí dovolí implementovat vaše aplikace, které můžete programovat pomocí jazyku Python a ty se následně spouštějí na speciálně optimalizovaném Python interpretu. Prostředí App Engine obsahuje bohatou nabídku rozhraní a nástrojů pro vývoj webových aplikací v Pythonu. Tato nabídka čítá modelovací rozhraní, lehce použitelné vývojové rámce (framework) a nástroje pro správu a přístup k datům aplikace. Také můžete využít nabídky vyspělých knihoven a vývojových rámců třetích stran pro vývoj webových aplikací, jako je Django1. Nyní prostředí Python runtime používá Python verzi 2.5.2. Novější verze Python 3 je plánována do budoucích vydání. Aplikace psaná v Pythonu musí být naprogramována výhradně tímto jazykem, nejsou podporována běžná rozšíření v podobě kusů kódu v jazyce C2. Poskytována jsou rozhraní na straně serveru pro datový sklad, Google účty, URL fetch a emailovou službu. App Engine také poskytuje webový rámec nazvaný „webapp“, který pomáhá vytvořit nový projekt. S webovým serverem komunikují aplikace vytvořené v Pythonu pomocí CGI3 standardu. Když
1
http://www.djangoproject.com/
2
http://cs.wikipedia.org/wiki/C_(programovací_jazyk)
3
http://www.w3.org/CGI/
23
server obdrží dotaz na vaší aplikaci, spustí ji s daty dotazu v proměnných prostředích. Jako reakci na dotaz aplikace zapíše odpověď na standardní výstupní proud dat, včetně HTTP hlaviček a obsahu. Nyní jako příklad ukážu jednoduchý program „Hello world“ napsaný v Pythonu, který lze spustit na GAE. Soubor programu je pojmenován „helloworld.py“: print 'Content-Type: text/plain' print '' print 'Hello, world!'
Dále je pro správné fungování programu nutný soubor app.yaml, který kromě dalších věcí určuje, který řídící (handler) skript má být použit pro které URL. application: helloworld version: 1 runtime: python api_version: 1 handlers: - url: /.* script: helloworld.py
Tyto soubory postačí spustit v lokálním prostředí nebo nahrát na server a jednoduchá aplikace je kompletní.
4.2.2 Prostředí Java runtime Dalším jazykem, který je oficiálně podporován, je Java. Aplikace pro Google App Engine lze v Javě vyvíjet v Java runtime prostředí pomocí běžných webových vývojových nástrojů a API standardů. Vaše aplikace bude komunikovat s prostředím pomocí standardu „Java Servlet“1 a může používat například takové běžné webové technologie, jako jsou „JavaServer Pages“2 (JSPs), ale i další Java Enterprise technologie, samozřejmě s jistými omezeními. Java runtime nyní využívá verzi Java 6. a „Google App Engine Software Development Kit“ (GAESDK) pro Javu podporuje vývoj aplikací buď ve verzi 5. nebo 6.
1
http://java.sun.com/products/servlet/
2
http://java.sun.com/products/jsp/
24
Samotný App Engine spouští aplikaci na Java Virtual Machine (JVM). JVM je spuštěn v bezpečném prostředí (sandbox), které ho odděluje od ostatních aplikací v systému. JVM má tu výhodu, že na něm lze spustit nejen Javu, ale i takzvané Javabased jazyky, tedy jazyky upravené, aby fungovaly na JVM. Jako příklad lze uvést JRuby, založené na jazyce Ruby, Quercus (PHP), nebo Rhino (JavaScript). Na stránkách firmy Google je kompletní seznam jazyků podporovaných z části, podporovaných i nepodporovaných.1 Každá aplikace vyvíjená pro GAE v Javě musí mít danou stromovou strukturu souborů a adresářů. Soubory aplikace, včetně zkompilovaných tříd, JAR soubory2, statické soubory a konfigurační soubory jsou poskládány v adresářové struktuře, která používá standardní rozložení WAR3 pro Java webové aplikace. Tato struktura je následující: _NázevAplikace_/ src/ ...Java zdrojový kód... META-INF/ ...ostatní konfigurace... war/ ...JSPs, obrázky, dative soubory... WEB-INF/ ...konfigurace aplikace... lib/ ...JAR pro knihovny... classes/ ...zkompilované třídy...
Aby byl patrný rozdíl mezi oběma jazyky, vytvořím nyní program „Hellou world“ i v jazyku Java.
Nejprve je třeba vytvořit servlet „Helloworld.java“, který obsahuje
následující kód: package guestbook import java.io.IOException; import javax.servlet.http.*; public class GuestbookServlet extends HttpServlet { public void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { resp.setContentType("text/plain"); resp.getWriter().println("Hello, world"); } }
Dalšími soubory, které jsou nezbytné k fungování programu, jsou dva konfigurační soubory „web.xml“ a „appengine-web.xml“. Primárním účelem web.xml
1
http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine
2
http://en.wikipedia.org/wiki/JAR_(file_format)
3
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WCC3.html
25
(web application deployment descriptor) je, aby potom, co server obdrží požadavek, určil, která servletová třída má být zavolána. Vypadá takto: <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5"> <servlet> <servlet-name>guestbook <servlet-class>guestbook.GuestbookServlet <servlet-mapping> <servlet-name>guestbook
/guestbook <welcome-file-list> <welcome-file>index.html
App Engine potřebuje ještě druhý konfigurační soubor, aby mohl určit, jak nahrát soubory na server a jak je správně spustit. Obsahuje ID a verzi vaší aplikace, poté statické soubory (např. obrázky, CSS styly1) a zdrojové soubory (např. JSP soubory a ostatní aplikační data.). Struktura souboru vypadá následovně:
1
4.2.3 App Engine Java SDK a vývojové prostředí Základní věcí pro fungování vývojového prostředí na lokálním počítači je App Engine SDK2 a samozřejmě „Java SE Development Kit“3 určený pro váš operační systém. Po nainstalování těchto dvou balíků je vám zajištěn běh aplikací vytvořených pro GAE.
1
http://www.w3.org/Style/CSS/
2
http://code.google.com/intl/cs-CZ/appengine/downloads.html
3
http://java.sun.com/javase/downloads/index.jsp
26
Poté, co je vytvořena správná adresářová struktura a vše korektně zpracováno, spustí se aplikační server Jetty1, který simuluje prostředí App Enginu a jeho služeb, včetně omezení na jeho bezpečné běhové prostředí, datového skladu a služeb. Výhoda ladění programu v lokálním prostředí spočívá v serveru, který nekompiluje kód ihned, ale až před spuštěním stránky, což nám umožňuje přepisovat data ve zdrojovém kódu bez nutnosti restartovat server. Toto pravidlo platí bohužel jen na klientské straně programu, pokud měníme data na straně serveru nebo samotnou konfiguraci aplikace, tak je restart nutný. Nejpohodlnějším a nejrychlejším způsobem, jak vytvářet aplikace pro GAE, je propojení některého známého vývojového prostředí s App Enginem. Oficiálně podporovaným prostředím je Eclipse IDE2. Po nainstalování GAE SDK přímo v aktualizacích programu se vám zpřístupní průvodce, který za vás vytvoří požadovaný základ projektu i s jeho počáteční konfigurací. V průvodci je implementovaná i možnost přidání základního nastavení pro „Google Web Toolkit“ (GWT)3. Dostupné jsou i pluginy třetích stran pro jiné Java IDE, jako je například NetBeans4 a IntelliJ5. Po vyzkoušení tohoto zásuvného modulu pro NetBeans jsem ale došel k názoru, že je příliš složitý a nepřináší tolik výhod jako oficiální plugin.
4.3 Ukládání dat Vybudovat vlastní distribuovaný datový sklad může být velmi obtížné. Uživatelé mohou komunikovat s jakýmkoliv z webových či databázových serverů. Dotaz od uživatele na server může být zpracován jiným serverem než předchozí a servery můžou být rozprostřeny do jiných data center, dokonce i do jiných zemí, což vyžaduje implementovat procesy, které chrání bezpečnost a zabezpečení dat i jejich synchronizaci. Také hardware a software, který je nutný k vybudování tak rozsáhlé infrastruktury je velmi drahý. App Engine poskytuje výkonné distribuované datové
1
http://jetty.codehaus.org/jetty/
2
http://www.eclipse.org/
3
http://code.google.com/intl/cs-CZ/webtoolkit/
4
http://kenai.com/projects/nbappengine/pages/Home
5
http://plugins.intellij.net/plugin/?id=4254
27
úložiště, které nám umožňuje využívat dotazovací jazyky a používat transakce. Tyto všechny problémy řeší úložiště platformy GAE na pozadí a umožňuje nám zaměřit se pouze na implementaci byznys logiky. Datové úložiště GAE je postaveno na dvou základních technologiích „Bigtable“ a „Google file system“ (GFS)1.
4.3.1 Databáze Bigtable Databáze Bigtable je vysoce distribuovaná a škálovatelná služba pro ukládání a správu strukturovaných dat. Byla vytvořena speciálně, aby mohla pracovat s obrovským množstvím dat na tisících různých serverů po celém světě. Bigtable je ta samá služba, kterou používá sama firma Google pro více než 60 svých aplikací včetně indexování webu, Google Finance2, nebo Google Earth3. Datový sklad využívá také GFS k ukládání dat a záznamových souborů. GFS je plně škálovatelný a proti chybám odolný souborový systém, určený pro velké, distribuované a datově náročné aplikace jako například Google služby Gmail4 a Youtube5. Původně byl sice GFS vyvinut pouze k ukládání procházených dat a vyhledávaných indexů, ale nyní ho Google využívá ve velkém množství svých produktů. První důležitá věc, kterou je třeba vědět o vnitřní struktuře databáze Bigtable je, že to není klasická relační databáze. GAE datový sklad ukládá a provádí dotazy nad datovými objekty, které zde nazýváme „entity“. Každá entita má jednu nebo více „vlastností“ neboli pojmenovaných hodnot jednoho z několika podporovaných datových typů. Jedna vlastnost může odkazovat na jinou entitu. Datový sklad může vykonávat několik operací v jedné transakci a vrátit zpět změny celé transakce, pokud transakce selže. Tato vlastnost je důležitá právě ve velkých distribuovaných webových systémech, kde může ve stejný čas přistupovat nebo manipulovat se stejnými daty více uživatelů a tomu musí být zabráněno, aby nedošlo k nekonzistenci. Zavádíme tedy tzv. „skupiny entit“, které slouží k tomu, abychom mohli v aplikaci určit, které entity patří
1
http://labs.google.com/papers/gfs.html
2
http://www.google.com/finance
3
http://earth.google.com/intl/cs/
4
https://mail.google.com/
5
http://www.youtube.com/
28
k sobě a budou uloženy dohromady na jednom skladě. To je prováděno z důvodu, že každá transakce může být spuštěna jen v rámci jedné skupiny entit, aby byla zaručena efektivita celé operace. Jak již bylo řečeno, tato databáze používá, na rozdíl od tradičních databází, distribuovanou architekturu, aby umožnila dobře zvládnout škálování velkých datových souborů. V aplikacích App Enginu můžeme specifikovat, jak budou data distribuována tak, že popíšeme vzájemné vlastnosti mezi objekty v naší aplikaci a definujeme indexy pro vyhledávání.
4.3.2 Java Data Interface (JDI) Entity uložené v datovém skladu jsou „bez schématu“, to znamená, že dvě entity stejného typu nemusí mít ty samé vlastnosti (properties), nebo používat ty samé hodnotové typy pro tytéž vlastnosti. Za to, že entity budou vyhovovat schématu, když je bude potřeba použít, je odpovědná pouze sama aplikace. K ukládání a získávání informací z datového skladu nám slouží JDI. Datový sklad podporuje dvě standardní Java rozhraní: „Java Data Objects“ (JDO)1 a „Java Persistence API“ (JPA)2. Tato rozhraní jsou v Google App Engine implementována pomocí „DataNucleus Access Platform“, což je volně šiřitelná implementace těchto standardů. Tato rozhraní obsahují způsoby, jak definovat třídy, aby je bylo možné uložit do databáze. Datový sklad také poskytuje nízko-úrovňové
rozhraní,
které
nám
umožní
implementovat
jiné
oficiálně
nepodporované rozhraní, nebo jeho metody můžeme použít rovnou v aplikaci. Pokud budeme používat metody rozhraní, musíme počítat s tím, že naše aplikace nebude moci být přesunuta na jinou databázi, protože tyto metody a postupy jsou specifické pouze pro Bigtable. App Engine SDK obsahuje implementaci JDO verze 2.3 pro komunikaci s datovým skladem. Rozhraní JDO může pracovat nad různými databázemi, to je velmi důležité v situaci, kdy hodláme aplikaci přesunout nad jinou architekturu. Pro komunikaci s databází slouží jazyk JDOQL, aplikace totiž nepodporuje klasické SQL3 dotazy. Naštěstí
1
http://java.sun.com/jdo/index.jsp
2
http://java.sun.com/developer/technicalArticles/J2EE/jpa/
3
http://www.w3schools.com/sql/default.asp
29
je JDOQL syntaxí velmi podobný SQL, ale samozřejmě, jako všude v GAE, s jistými omezeními. Rozhraní JPA je implementováno pouze ve starší verzi 1.0 a platí pro něj podobné podmínky jako pro JDO. Záleží tedy pouze na uživateli, zda se rozhodne pro rozhraní JDO, JPA nebo pro řešení jiným oficiálně nepodporovaným způsobem.
4.4 Služby poskytované GAE Služby sloužící k poskytování přístupu k datovému skladu nejsou jediné, které GAE nabízí. Stejně jako u datového skladu, i zde se GAE snaží nabídnout nám upravené rozhraní, ke komunikaci se službami co nejvíce podobnými standardním Java rozhraním. To by mělo ulehčit migraci aplikace do App Engine nebo její přesouvání na jiný systém. Každá služba také poskytuje kompletní nízko-úrovňové rozhraní pro implementaci, ať už pro definování nových přístupových rozhraní nebo pro přímý přístup. Služby GAE jsou následující: Memcache service App Engine poskytuje rychlou vyrovnávací paměť, umístěnou před robustním, perzistentním datovým úložištěm, kterou můžeme využít k určitým krátkodobým paměťovým úkonům. Využívat takovouto paměť je vhodné v případech, kdy aplikace spouští několikrát dotazy nad stejnou skupinou dat. Například při vyhledávání v aplikaci, která podle parametrů určuje a zobrazuje instituce v okolí daného místa, se může stát, že několik uživatelů zadá stejné hledání za sebou, v takovém případě je dobré mít předchozí výsledky uloženy v krátkodobé paměti. Při takto podobných dotazech, se program může prvně podívat do krátkodobé paměti a až potom načítat z datového skladu. Nastavit dobu, po které budou data z krátkodobé paměti vymazány, lze dvěma způsoby. Zaprvé je možné nastavit relativní čas v sekundách od doby, kdy byl výsledek vyhledán nebo nastavit pevný (absolutní) čas na přesnou dobu. „Memcache API“ podporuje rozhraní pro JCache. JCache je standard, který poskytuje rozhraní pro data uložená v krátkodobé paměti. Data jsou uložena v Java kolekci „map“1. Tímto způsobem lze do páru klíč/hodnota uložit a získat Java třídu
1
http://java.sun.com/javase/6/docs/api/java/util/Map.html
30
nebo objekt jakéhokoliv typu. Můžeme tak získat data relace, výsledky dotazů, nebo skupiny dat, které můžou být použity během dalšího běhu aplikace. URL Fetch service Aplikace vybudované pomocí GAE můžou komunikovat s ostatními systémy pomocí HTTP a HTTPs volání. Tato služba běží na Google síťové infrastruktuře, je rychlá a spolehlivá, avšak má několik omezení. Například lze přistupovat ke zdrojům na jiných webech, pouze pokud jsou otevřené pro porty 80(HTTP) a 443(HTTPs), jiné porty služba URL Fetch nepodporuje. Při práci s URL Fetch se tedy nelze připojit přímo k webu, ale je nutné odeslat požadavek přes službu a dále pokračovat, až když přijde odpověď, kterou následně zpracováváme podobně jako ve standardní Javě. Takto můžeme zpracovávat datové proudy z různých serverů a využívat je dále v naší aplikaci. Images service Služba, která nám dovolí vkládat obrázky a dále s nimi manipulovat se jmenuje „Image service“. Běžné operace s obrázky, které lze pomocí Images service provádět, jsou zvětšování a zmenšování, otáčení kolem své osy, převrácení horizontálně i vertikálně a oříznutí části obrazu. K netradičním operacím patří speciální úprava „I’m feeling lucky“, která se pokusí pomocí speciálního algoritmu automaticky upravit barvy, kontrast i světlo na obrázku. Velikost obrázků zpracovávaných službou je omezena na jeden megabyte. Google Accounts V Google App Engine máme dvě možnosti jak si poradit s autentizací uživatelů. Jedna možnost je využít služby MemCache a vytvořit zcela své přihlašovací rozhraní, zabezpečení a strukturu uživatelů. Toto řešení je ve velkém počtu případů zbytečné, protože můžeme použít řešení druhé a tím je využít službu „Google Accounts“, která slouží k autentizaci uživatelů pomocí účtů Google. Aplikace vytvořená na GAE a používající službu Google Accounts pozná, zda je uživatel, který ji má spuštěnou, přihlášen pod Google účtem a pokud ne, může ho přesměrovat na přihlašovací obrazovku, kde se může do aplikace přihlásit, nebo pokud nemá založený Google účet, může si ho zde vytvořit. Po dobu, po níž je uživatel v systému přihlášen může aplikace získat některé informace o uživateli. Nejedná se ale o informace čistě soukromé, jde pouze o emailovou adresu, jméno a přezdívku.
31
Aplikace může také jednoduše rozlišit, zda se po přihlášení jedná o běžného uživatele nebo o administrátora. Poté lze v konfiguraci aplikace (soubor „web.xml“) nastavit, do kterých sekcí aplikace je vyžadován autentizovaný přístup, do kterých sekcí mají přístup běžní uživatelé a do kterých má přístup pouze administrátor. Tato nastavení lze využívat i na lokálním vývojovém prostření, které simuluje jednoduché přihlašování podobné Google systému. Mail API První služba, která nám umožní komunikovat s okolím, se jmenuje „Mail API“. Tato služba implementuje rozhraní Javamail, které umožňuje posílat emailové zprávy přímo z aplikace. Využíváno je rozhraní Google účtů a jeho vlastnosti získat emailovou adresu přihlášeného uživatele, tato adresa poté funguje jako adresa odesílatele. Rozhraní Mail API je plně implementováno, s výjimkou možnosti připojovat se k ostatním emailovým službám za účelem přijímání a odesílání zpráv. Můžeme tedy rozesílat jeden email více adresátům, formátovat zprávu ve formátu HTML a připojovat ke zprávám přílohy daných typů, které jsou sice omezeny, ale v plně dostačujícím rozsahu. Počet zpráv odeslaných za dané časové období (1 min) je omezen, nejen pro zabránění přehlcení provozu, ale hlavně jako obrana proti uživatelům, kteří by chtěli GAE využívat jako nástroj k rozesílání spamu1. Také velikost přílohy emailu je omezena jedním megabytem. XMPP Service Pokud je i emailová služba málo interaktivní, mají uživatelé možnost implementovat do svých aplikací službu „XMPP“, která je založena na protokolu XMPP a slouží běžně jako „instant messaging“, tedy ke komunikaci v reálném čase. Při odesílání zprávy pomocí této služby musí uživatel, který je určen jako adresát, autorizovat aplikaci, aby byla zpráva korektně doručena. To je velký rozdíl oproti emailovému API, které poslalo zprávu jinému uživateli, ať už si to přál či nikoliv. Aplikace využívá webové
jméno
dané
aplikace
ke
komunikaci
s dalšími
klienty
ve
tvaru
„jmé
[email protected]“, z čehož plyne, že tato služba nemůže být provozována na lokálním serveru a pro správný chod je nutné ji nahrát na servery GAE.
11
http://cs.wikipedia.org/wiki/Spam
32
Pro příjem zprávy lze využít Jabber klient1. Do komunikačního klienta je nutné nejprve přidat uživatele, který představuje naši aplikaci a má jméno ve tvaru uvedené v předchozím odstavci. Pokud komunikujeme opačným směrem a Google App Engine obdrží zprávu služby XMPP, tak vytvoří HTTP dotaz typu POST, který je směrován na URL
cestu
„/_ah/xmpp/message/chat/“.
Parametry
POST
dotazu
následně
zpracováváme dál v aplikaci. Task Queues (Zkušební) Poslední dvě nabízené služby jsou na rozdíl od ostatních zatím pouze v testovacím provozu. To znamená, že nejsou ještě dokončeny všechny vlastnosti rozhraní a jejich specifikace. Jejich knihovny jsou zatím zařazeny v testovacím balíčku a nejsou zpětně kompatibilní s verzemi v předchozích vydáních SDK. Pomocí rozhraní „Task Queues“ může naše aplikace pracovat i mimo rámec HTTP dotazu uživatele. Služba musí být ovšem uživatelem inicializována. Práce je vykonávána na pozadí a rozhraní ji rozdělí do malých a oddělených jednotek zvaných „Tasks“, tyto malé jednotky jsou zařazeny do jedné nebo více front. App Engine automaticky rozpozná, zda je v nějaké frontě nová úloha a vykoná ji až ve chvíli, kdy jsou dostupné požadované systémové prostředky. Příkladem využití může být například agregátor datových proudů, který musí automaticky a periodicky získávat data z několika internetových zdrojů. Blobstore (Zkušební) Druhou novou službou je „Blobstore“. Toto rozhraní nám umožní pracovat s datovými objekty zvanými „blob“, které můžou být mnohem větší než sobory o maximální velikosti, které nám GAE dovolí ukládat do datového skladu. Tyto objekty jsou vytvářeny nahráním souboru pomocí HTTP dotazů do App Enginu, uživateli je vrácen tzv. blob key, který následně slouží jako identifikátor daného objektu. Tato služba dovolí uživatelům nahrávat soubory až do velikosti dvou gigabytů, je tedy vhodná pro soubory videí a velkých obrázků. Aplikace čte uložené hodnoty část po části pomocí volání rozhraní a tyto části jsou velké přibližně jeden megabyte. Služba využívající takto velké datové prostory již ovšem není nabízena společností Google zdarma a je nutné při plánování užívání služby Blobstore přejít na placený tarif.
1
http://www.jabber.cz/
33
4.5 Kvóty a poplatky za používání aplikací Jednou z hlavních výhod společnosti Google je jejich cenová politika. Většina aplikací je nabízena zdarma nebo za mírné poplatky. Stejný přístup je použit i u Google App Engine, který využívá systém kvót a placených omezení. Každá aplikace využívá určité množství zdrojů, které GAE rozděluje na šířku pásma, výpočetní čas procesoru, uložená data a odeslané emaily. Tyto zdroje mohou být využívány do určitého maxima neboli kvóty. Tyto kvóty nám zajistí, že naše aplikace nepřekročí daný rozpočet a že ostatní aplikace spuštěné na App Enginu nebudou mít vliv na výkon naší aplikace. Každý výpočetní zdroj je porovnáván se dvěma druhy kvót: placenou a fixní. Zdroj
Jednotky
Cena za jednotku
Odchozí šířka pásma
gigabyte
$0.12
Příchozí šířka pásma
gigabyte
$0.10
Výpočetní čas CPU
CPU hodina
$0.10
Uložená data
gigabyte za měsíc
$0.15
Obeslaní příjemci
příjemce
$0.0001
Tabulka 2: Poplatky za výpočetní zdroje
Placená kvóta značí omezení maximálního množství zdrojů nastavené administrátory aplikace, které můžeme použít, abychom zabránili překročení rozpočtu na provoz aplikace. Každá z aplikací má určité množství každé placené kvóty zdarma, placený provoz je v základním nastavení vypnut. Zvýšit hodnoty placené kvóty můžeme tak, že povolíme placený provoz a manuálně nastavíme své maximální hodnoty využívaných zdrojů, které omezují naší aplikaci. Tyto operace se provádějí v administračním rozhraní 1. Fixní kvóta udává maximální možné použitelné zdroje nastavené App Enginem, aby bylo možné zajistit integritu celého systému. Tyto limity označují hranice
1
Informace o administrační rozhraní v kapitole 4.6 Administrační rozhraní.
34
architektury GAE a je nutné aplikace upravit do takové podoby, aby tyto limity nepřesahovaly. Kdyby nebyly zavedeny fixní limity, mohlo by se stát, že jedna aplikace bude využívat příliš mnoho zdrojů, které by následně chyběly ostatním aplikacím. Obě kvóty jsou vždy měřeny po dobu 24 hodin, začínající o půlnoci pacifického času a následně jsou po čtyřiadvaceti hodinách opět vynulovány. Jako další omezení placené a fixní kvóty používá App Engine „minutové kvóty“. Tyto kvóty stanovují, jak velké výpočetní zdroje může aplikace spotřebovat za minutu. Slouží převážně k ochraně naší aplikace, která by spotřebovala všechny své denní kvóty během krátké chvíle a zároveň i ostatních aplikací, které by mohly mít problém s přístupem k daným zdrojům. Celkem tedy App Engine používá 4 kvóty. Pokud aplikace překročí danou kvótu, tak se požadovaný zdroj stane nedostupným a aplikaci se vrátí jako odpověď chybová zpráva webového prohlížeče. Uživatel musí poté počkat do doby, než budou kvóty vynulovány a zdroje zpřístupněny. Zdroj
HTTP dotaz
Základní kvóta (zdarma)
Placená kvóta
Denní limit
Minutový
Denní limit
Minutový
1 300 000
limit 7 400 dotazů
43 000 000 dotazů
limit 30 000
dotazů
Tabulka 3: Příklad kvóty u HTTP dotazů
dotazů
4.6 Administrační rozhraní Přístup ke kompletní správě a přehledu o našich vystavených webových aplikacích, postavených na GAE, nám poskytuje Google App Engine administrační konzole. Rozhraní této konzole se nachází na webových stránkách1 splečnosti Google. Správa aplikací Pomocí administračního rozhraní můžeme jednoduše vytvářet nové aplikace. Každá nová aplikace musí mít unikátní jméno, které následně slouží jako jedinečný identifikátor. Vytvořené aplikace jsou automaticky umístěny na webovou adresu „identifikátor_aplikace.appspot.com“. Toto hostování aplikace je nabízeno společností
1
Webová adresa administrační konzole GAE: https://appengine.google.com/
35
Google zdarma. Pokud chceme umístit aplikaci na svojí vlastní doméně, lze to provést v nastavení aplikace. Spolupráce týmu Autor aplikace může v záložce „oprávnění“ přidat další uživatele, kteří tím získají možnost přistupovat do administračního rozhraní určené aplikace a mohou nahrávat nový kód na server. Přidáním několika dalších lidí ve složce oprávnění nám jednoduše vznikne tým vývojářů, kteří budou moci spolupracovat na vývoji aplikace. Přehled nad aplikací Administrační konzole nám poskytuje kompletní přehled nad přístupovými daty aplikace a také umožňuje zobrazit logování. Soubory logování jsou dva, jeden nám zobrazuje logy samotné aplikace a druhý slouží k logování procesu nahrávání aplikace na server. Několik grafů a přehledných zobrazení nám dává ucelený přehled o využívaných výpočetních zdrojích. Z nich můžeme analyzovat, zda aplikace funguje správně nebo zda využívá některé zdroje ve větším množství než ostatní. V záložce administrační konzole „CRON úlohy“ a „seznamy úkolů“ vidíme natavení těchto dvou služeb a jejich status. Datový sklad Přímo ve webovém rozhraní můžeme také procházet všechny nahrané soubory. Dále nám umožňuje zobrazit entity uložené v databázi a spravovat indexy databázových dotazů. V sekci „statistiky datového skladu“ je nám přehledně vypsáno procentuální rozložení využívaných datových typů entit a také rozložení jednotlivých entit vzhledem k celkové velikosti datového skladu. Správa verzí aplikace Při nahrávání aplikace na GAE server musíme zvolit, o jakou vývojovou verzi aplikace jde. Jednotlivé verze lze zobrazit v aplikační konzoli. Jedna z verzí musí být nastavena jako základní a je spouštěna při zadání webové adresy aplikace. Poplatky Správu finančních prostředků umožňuje sekce „nastavení poplatků“. Zde správce aplikace nastaví vlastní limity pro využívání zdrojů a prostředků. Každé účtovací období je automaticky vytvořen výpis využitých zdrojů s kompletními cenami
36
za poskytované služby. Tyto výpisy jsou uloženy v sekci „platební historie“ a mohou sloužit například jako dokumenty pro finanční oddělení společnosti.
4.7 App Engine pro business Na konferenci firmy Google dne 19. května 2010 byla ohlášena podniková verze Google App Engine nazvaná „Google App Engine for Business“(GAEB). Podle představitelů společnosti Google jde o reakci na požadavky organizací vytvářet a umísťovat zákaznické aplikace v prostředí cloudů. GAEB řeší absenci některých parametrů
požadovaných
firemními
vývojáři.
Nové
řešení
nabízí
centrální
administrátorskou konzoli pro správu všech firemních aplikací, záruku pro 99,9% dostupnost aplikace či pokročilou technickou podporu. Administrátoři aplikací mají v GAEB rovněž možnost nastavit bezpečnostní pravidla pro přístup k firemním aplikacím. Cena za používání GAEB je v současnosti osm dolarů za jednoho uživatele na měsíc a každá společnost zaplatí maximálně tisíc dolarů. Nyní je produkt dostupný pouze omezenému počtu, ale během konce roku 2010 bude uveden pro neomezené množství uživatelů. Další významným prvkem, který bude teprve uveden do provozu, je možnost hostovat SQL databáze, které budou moci vývojáři používat jako alternativu k nyní používané BigTable. Také bude přidána podpora protokolu SSL1, který umožní pomocí šifrovaní zabezpečit komunikaci s vlastními aplikacemi. Společnost Google zvažuje i poskytnutí možnosti nasadit v prostředí App Engine také Java aplikace, a to integrací nástroje RAD (Rapid Application Development) Spring Roo2 od společnosti VMware3, se kterou je v úzkém partnerském vztahu. Google App Engine pro Business by měl tedy v budoucnu nabídnout vhodnou alternativu pro ty, kteří upřednostňují programovací jazyk Java a chtějí pomocí něj budovat aplikace na cloudu.
1
http://cs.wikipedia.org/wiki/Secure_Sockets_Layer
2
http://www.vmware.com/company/news/releases/vmware-google.html
3
http://www.vmware.com/company/
37
5 UKÁZKOVÁ APLIKACE Pro praktickou prezentaci jsem vytvořil ukázkovou aplikaci, která využívá služeb a technologií cloud computingu. Aplikaci jsem nazval „GAE Project Centre“ a je zamýšlena pro firmu, která by zadávala a spravovala projekty partnerských firem externím zaměstnancům. Tato aplikace má převážně sloužit jako demonstrační program a ukázka některých možností cloud computingu, je ovšem založená na nových a moderních technologiích a bylo by možné ji rozvíjet dále do plně funkční a otestované verze, která by se dala využít i v praktickém provozu. Pro provoz GAE Project Centre byla určena doména „comare.eu“ a samotná aplikace je umístěna na webové adrese http://www.comare.eu/.
5.1 Použité technologie Rozhodl jsem se, že při vytváření aplikace využiji pouze služeb firmy Google, abych zjistil, zda je možné pouze pomocí nich vybudovat použitelný webový systém. Klientská strana aplikace je sestavena pomocí rámce Google Web Toolkit, který zajišťuje moderní vzhled a pokročilé uživatelské pohodlí, vytvořené například asynchronní komunikací AJAX. Na straně serveru aplikace využívá Google App Engine a jako v současné době jediná možná databáze byla zvolena BigTable. Služby a možnosti celé aplikace byly rozšířeny pomocí služeb Google Apps, které do aplikace přinášejí další prvky nezbytné pro IT systém. Jako programovací jazyk jsem využil převážně Javu a některé prvky HTML a kaskádových stylů. Projekt byl psán ve vývojovém prostředí Eclipse, do kterého byl nainstalován Google App Engine plugin pro snadnější psaní, testování, úpravy kódu a následné nahrávání zkompilovaného kódu na webový server. Použitá verze Google App
38
Engine SDK pro Javu je 1.3.3.1 a Google Web Toolkit SDK ve verzi 2.0.3. Tyto technologie nám zaopatřují kompletní prostředí pro vývoj a umístění aplikace.
5.1.1 Google Web Toolkit Prvním z produktů firmy Google, který jsem začlenil do vývoje ukázkové aplikace, je Google Web Toolkit (GWT). Ve své podstatě je GWT rámcem, ve kterém si uživatel může jednoduše vytvořit webovou aplikaci, složenou ze znovupoužitelných UI komponent (komponent uživatelského rozhraní) vykreslovaných jako HTML a logiky ve formě jazyku JavaScript na straně webového prohlížeče a asynchronního volání serverové logiky skrze AJAX. To vše využíváme na platformě Java s využitím jazyka a v případě App Engine některých knihoven. Programátor, který vytváří aplikaci pomocí GWT, píše zdrojový kód v jazyce Java, tento kód je po zkompilování automaticky přeložen do JavaScriptu. Hlavní výhodou tohoto přístupu je kompatibilita. V dnešní době je na trhu velké množství webových prohlížečů a je jen na uživateli, jaký zvolí. Mezi způsoby vykreslování webových prvků prohlížeči, se i přes snahu vývojářů vyskytují jisté odlišnosti, o které se většinou musí starat sám programátor. GWT tuto starost přebírá na sebe a jeden program vyvinutý pomocí něj bude vypadat stejně na širokém spektru prohlížečů.
5.1.1.1 Jak GWT funguje Jedním z dalších důvodů, proč používat vývojové prostředí, je, že nám dokáže spojit obě rozšíření a vytvořit základní projekt s využitím jak Google Web Toolkit, tak Google App Engine. Pokud tedy pracujeme s GWT ve vývojovém prostředí Eclipse, je nám po zadání jména a vybrání verze SDK vytvořena základní struktura projektu. V této struktuře je důležitým souborem „nazev_aplikace.gwt.xml“, který slouží pro základní nastavení GWT a v kterém specifikujeme, jaký soubor nám bude sloužit jako vstupní bod do systému. Jsou zde také obsaženy základní implementace, styly a určení balíčků aplikace, které budou následně při kompilaci přeloženy.
39
Panely a widgets UI komponenty, které GWT využívá, se dají rozdělit do dvou hlavních skupin „panely“ a „widgets“1. Widgety je skupina základních UI komponent, jako jsou tlačítka, tabulky, vstupní políčka, rozbalovací seznamy a podobně. Ve skupině panely se nalézají komponenty sloužící k nastavení rozložení aplikace. Hlavním prvkem v nově vytvořené aplikaci je „kořenový panel“, který musí být umístěn do aplikace jako první, poté tento kořenový panel rozdělujeme pomocí dalších panelů. Do takto vzniklé struktury můžeme volně vkládat jednotlivé widgety. Vznikne nám tedy komplexní prostředí složené z jednotlivých prvků. Každé komponentě, sestavené pomocí GWT, lze přiřadit styl nebo manipulátor (handler). Přiřazením stylů lze měnit, podobně jako kaskádovými styly vlastnosti komponent, jejich velikost, vzhled, či vnitřní písmo. Manipulátor přiřazený některé z komponent slouží k vyvolání určité události. V GWT rozlišujeme 2 druhy manipulátorů: ty, které reagují na událost vyvolanou stlačením klávesy počítače a ty, které reagují na některou z událostí vyvolanou myší. Manipulátory většinou v aplikaci slouží k asynchronní komunikaci, kdy daná komponenta čeká na určenou událost a pokud je tato událost vyvolána, spustí se kód, který je předem definován. Komunikace GWT se serverem Aby aplikace běžící v prohlížeči dokázala komunikovat se serverem, tedy volat aplikační logiku, je třeba implementovat nějakou formu vzdáleného volání metod, takzvané „Remote Procedure Call“ (RPC). V prostředí webového prohlížeče je nejlepší cestou použít posílání souborů formátu XML před HTTP protokol, nejlépe asynchronní cestou pomocí modulu XMLHttpRequest2. Díky RPC se nám volání serverové logiky jeví jako lokální a programátorům je usnadněna práce s kódem. Volání serveru je dáno následujícím rozložením rozhraní a tříd.
Widget lze přeložit pouze jako „věcička“, což se mi nezdá jako vhodný překlad, budu proto používat anglickou verzi slova. 1
2
http://www.w3.org/TR/XMLHttpRequest/
40
Obrázek 5.1: RPC přehled z hlediska serverového a klientského kódu
Aby byla aplikace schopná komunikovat se serverem, musí vývojář vytvořit dvě rozhraní na straně klienta a jednu třídu na straně serveru, které implementují zbylé rozhraní a třídy definované již v základním balíku a následně si mohou předávat objekty či proměnné, pomocí nichž probíhá komunikace.1
5.1.1.2 Verze 2.0 Jedním z důvodů, proč jsem se rozhodl použít GWT, bylo i vydání nové verze GWT rámce s pořadovým číslem 2.0, která vyšla v prosinci 2009. Nová verze nabízí nový způsob budování rozhraní „UiBinding“ a pokročilé možnosti testování aplikace. Vývojové prostředí Nyní je možné testovat aplikaci přímo v našem oblíbeném prohlížeči. Vývojové prostředí je založeno na zásuvném modulu, který je nutné nainstalovat do prohlížeče a následně slouží jako most mezi aplikací a rozhraním. Při změně kódu na straně klienta ve vývojovém prostředí stačí pouze obnovit stránku v prohlížeči a nově napsaný kód je překompilován a načten do prohlížeče. Toto vylepšení nám mnohonásobně urychlí práci, protože nemusíme při změnách restartovat Java ladící program. Do spuštěného
1
Zdrojový kód komunikace RPC je uveden v příloze B.
41
vývojového módu se lze připojit z více prohlížečů různých druhů a urychlit tak testování aplikace. UiBinder Pomocí UiBinderu lze vytvářet uživatelské rozhraní tak, že oddělíme vizuální aspekty rozhraní od ostatní aplikační logiky. Deklarativně píšeme uživatelské rozhraní pomocí kódu HTML a widgetů do UiBinder XML šablony a následně ji spojíme se souborem třídy Java, ve kterém je aplikační logika. Kromě těchto dvou inovací byl vylepšen i GWT kompilátor1, který nyní rozděluje kód při kompilaci na více částí a urychluje tak celý proces. Byly přidány nové panely pro lepší a snadnější rozložení rozhraní a nový způsob přidávání zdrojů do aplikace za běhu.
5.1.2 Google Apps Google Apps2 je webová služba založená na technologii aplikace jako služba (AAAS), která nám poskytuje kancelářský balík aplikací dostupných díky cloud technologii odkudkoliv a bez ohledu na to, jaký operační systém používáme. Data zpracovávaná aplikacemi Google Apps jsou uložena na zabezpečených serverech firmy Google, takže uživatel, který si službu zaplatí, nemusí do vybavení hardwaru vkládat žádné další větší finanční prostředky. Základní varianta služby je dokonce zadarmo, stačí si vytvořit pouze účet a dále jen využívat možností Google Apps. Pro větší společnosti je však výhodné zakoupit si vyšší placenou verzi služby, se kterou dostanou záruku dostupnosti, větší úložný prostor, integraci služeb pomocí API rozhraní s existujícím prostředím IT a nepřetržitou technickou podporu. Pokud máme zaplacenou vlastní internetovou doménu, můžeme nastavit a převést aplikace a správu Google Apps pomocí DNS3 záznamů tak, aby byly směrovány na danou adresu. Takto nám vznikne prostředí, ve kterém máme připravené pokročilé kancelářské aplikace a kde může dále neomezeně pracovat. Zákazník není limitován jen
1
http://code.google.com/intl/cs-CZ/eclipse/docs/gwt_compile.html
2
http://www.google.com/apps/intl/cs/business/index.html
3
http://www.dns-info.cz/dns/index.html
42
výběrem ze základních aplikací, které ovšem ve většině případů stačí na běžný provoz, ale může si na Google Marketu dokoupit další aplikace vytvořené externími uživateli. Gmail pro firmy Gmail pro firmy nabízí 25 GB úložného prostoru na uživatele, výkonné filtrování spamu a spolupráci s externími zařízeními. Získáme tak svého emailového klienta se zabudovaným komunikátorem, který může přenášet po internetu, kromě klasických emailů také hlas a obraz. Kalendář Google Webová aplikace Kalendář umožní uživatelům účinně spolupracovat, ulehčí jim plánování schůzek a zpřehlední jejich osobní úkoly. Pokud je to nastavením povoleno, tak uživatel Kalendáře může zobrazit více kalendářů svých kolegů přes sebe a jednoduše tak zjistit, kdy mají kolegové volný čas. Výhodou je i přístup do aplikace z mobilního zařízení. Dokumenty Google Dokumenty, tabulky a prezentace jsou dostupné na webovém rozhraní Google Dokumentů. S jednotlivými soubory lze pracovat odkudkoliv a lze je také sdílet s libovolným počtem uživatelů a současně tak kooperovat na jedné práci. Díky tomu, že je soubor umístěn na serveru, tak máme jistotu, že se jedná o aktuální verzi dokumentu. Uživatelé nejsou omezeni ani formátem souborů a jejich nekompatibilitou s operačními systémy, protože vše probíhá mimo uživatelův operační systém. Nevýhoda při používaní Google Apps by mohla vzniknout, pokud by uživatel nebyl delší dobu v dosahu internetového spojení, či pokud by zákazník nechtěl svěřit data společnosti Google. Výběr použití Google Apps tedy záleží na konkrétní společnosti, zda se bude takovými situacemi zabývat či nikoliv.
5.2 Textový rozbor Při výběru zaměření ukázkové aplikace jsem musel vzít v úvahu několik faktorů, které omezovaly moje možnosti. Jedná se o malou či střední firmu, to znamená firmu do několika desítek zaměstnanců, kteří nemusí být v jedné pracovní budově. Taková firma chce mít aplikaci co nejrychleji vytvořenou, aby mohla uvést svoje pracovní plány do provozu, protože se bojí se o své místo na trhu. Také však nemá obvykle dostatek 43
financí, aby si mohla dovolit kupovat drahé hardwarové vybavení a zaplatit si rychlý vývoj aplikace. Na druhou stranu, pokud podnikatelský záměr podaří, je nutné stávající systém rozšířit a získat nový prostor v databázi. Webové aplikace Google Apps by měly zajistit rychlé vybudování webových kancelářských aplikací, které jsou v každé společnosti, ať už je to velká korporace, či malá začínající firma, potřebné. Zároveň by měly umožnit uživatelům mobilitu a možnost práce s firemními dokumenty odkudkoliv na světě. Google Web Toolkit by se měl postarat o rychlé sestavení aplikace a díky jeho systému modulů i o případné budoucí rozšíření funkcionality. A poslední, ale určitě ne nejméně důležitý Google App Engine zajistí chod vlastní aplikace pro konkrétní firmu tak, že v počátku by měla malé firmě stačit neplacená verze GAE a v případě potřeby by šla snadno rozšířit dále. Žádná z uvedených služeb a technologií nepotřebuje ke svému chodu speciální hardware, ani větší finanční prostředky a právě kvůli těmto důvodům jsem zvolil technologie od společnosti Google.
Aplikace GAE Project Centre by měla být určena pro malou firmu, kterou pro zjednodušení popisu nazvu „Společnost“, která se stará o rozdělování a spravování projektů od partnerských firem. Společnost si nejdříve zajistí firmy, které budou chtít využít jejich služby a sepíše s nimi smlouvu, tím Společnosti vzniknou zákazníci, od kterých dostává zakázky. Zároveň manažeři Společnosti shánějí dobré pracovníky, kteří jsou ochotni v případě zakázky pro ně pracovat. Každý nový pracovník se stává externím zaměstnancem Společnosti. Pokud Společnost získá od zákazníků nový projekt, tak některý z manažerů vybere vhodné zaměstnance a přiřadí je k projektu. Každý projekt má tedy 3 fáze: nově zadaný, ve fázi rozpracování a dokončený projekt. Když je projekt hotový, může se vyřadit z databáze Společnosti.
5.3 Use case diagram a popis Role uživatelů, kteří budou komunikovat se systémem nebo systém s nimi, jsou tedy tři: Administrátor systému, Manažeři Společnosti a Externí zaměstnanci.
44
Administrátor systému, který nese zodpovědnost za vkládání externích entit do systému, má práva provádět operace vložení zaměstnance nebo zákaznické firmy a může provést i jejich odstranění. Přidává také zprávy do systému, ve kterých informuje manažery o nových zaměstnancích či společnostech, případně jakékoliv jiné události. V neposlední řadě nese zodpovědnost za správu domény, nastavení aplikací a upravování účtů manažerů. Roli administrátora vykonává v základním nastavení systému pouze jeden účet „admin“. Administrátor má však práva zvolit si další správce systému, kteří mu budou moci pomáhat s přibývající prací, tak je zajištěna rozšiřitelnost při rozrůstání firmy. Druhou rolí v systému je Manažer, který je zodpovědný za shánění zaměstnanců a zákaznických společností, tyto záznamy potom pošle administrátorovi buď pomocí pošty, nebo zprávy na nástěnce a ten je zadá do systému. Každý manažer má tedy přístup ke své emailové schránce, svému kalendáři a dokumentům. Manažer si může zobrazit detaily zaměstnance, ve kterých přímo vidí, na kterých projektech zaměstnanec pracuje. A pokud je situace urgentní, lze mu přímo okna z aplikace odeslat mail, bez zbytečného vstupu do emailové schránky. Nejdůležitějším úkolem manažera je spravovat projekty. Lze přidat nový projekt, otevřít existující, přidat nebo odebrat zaměstnance z projektu, upravit parametry a také projekt smazat.
45
Poslední rolí je Zaměstnanec, který nemá vlastní přístup do systému, je veden pouze jako entita. Se zaměstnancem manažeři komunikují pomocí emailu a samotný systém jim zasílá v pravidelných intervalech zprávy o jejich projektech podle záznamů v databázi.
5.4 Diagram entit a rozložení Databáze Bigtable sice není relační, ale dá se namodelovat pomocí vztahů entit. Jednotlivé tabulky reprezentují entity a hodnoty uvnitř jsou atributy těchto entit. Každá entita uložená v databázi Bigtable musí mít primární klíč, který je u atributu nazván „PK“.
První entita „Company” reprezentuje zákaznickou společnost v systému. Společnost je uložena v databázi podle primárního klíče „key“ který je vygenerován z třídy Company a unikátního jména společnosti. Dalšími atributy entity jsou „ico“, které reprezentuje ekonomické identifikační číslo společnosti a „contact“, obsahující nějaký druh kontaktu na společnost (v aplikaci webové stránky). Posledním atributem, který obsahuje klíče entity Projekt, které má společnost zadána a slouží v databázi Bigtable jako cizí klíč, je množina „companyProjects“ Druhá entita v systému reprezentuje jeden projekt a je nazvána „Project“. Má vygenerován primární klíč „key“ ze svého jména třídy a unikátního jména projektu. 46
Projekt má zadáno jméno společnosti, pro kterou je vypracováván v atributu „company“. Tento atribut nám zároveň buduje vztah 1:N mezi entitami Project a Company. Jedna společnost může mít zadáno nula až N projektů a jeden projekt může být vykonáván přesně pro jednu firmu. Dalším atributem Projektu je „startDate“, reprezentující datum začátku vykonávání projektu. Atribut „Status“ slouží pro identifikaci stádia projektu, zda byl projekt právě zadán, pracuje se na něm, nebo byl ukončen. Množina klíčů „assignedEmployees“ entity „Employee“ je zde uložena jako cizí klíč a také identifikátor vztahů mezi oběma relacemi. Další entita „Employee“ je definována jako externí zaměstnanec Společnosti. Primární klíč Zaměstnance je vygenerován jako klíč ze třídy Zaměstnanec a z unikátního emailového účtu, který je zadán. Entita dále obsahuje jméno „name“, příjmení „surname“ a pozici „position“, ke které je zaměstnanec přiřazen. Posledním atributem entity je množina klíčů entity Projekt „assignedProjects“, reprezentující projekty, na nichž zaměstnanec pracuje.
Dvě skupiny klíčů assignedProjects a
assignedEmployess nám v databázi Bigtable značí vztah mezi oběma entitami M:N. Tedy jeden zaměstnanec může pracovat na žádném, nebo neomezeně projektech a projekt může být přidělen žádnému nebo neomezeně zamestncům. Poslední entitou v systému, kterou popíši je „MsgNews“, ta je určena pro ukládání zpráv na hlavní stránce aplikace. Entita stojí sama o sobě, a proto není identifikována klíčem, ale jako primární klíč je přiřazeno unikátní číslo generované datovým skladem. Atribut entity je název zprávy „title“, datum vytvoření zprávy „createDate“ a uživatel, který zprávu vložil. Samotný text zprávy je vložen do databáze ve formátu „Text“. Text je speciální datový typ databáze Bigtable, který slouží k ukládání String řetězců delších než 500 znaků. V systému se nachází ještě několik entit, ale ty jsou strukturou podobné těm popsaným a nemají složitější vztah s okolními entitami, proto popis vynechám. Většina atributů v entitách není nijak přísně kontrolována, protože jsou zadávány autorizovanou osobou, která je znalá práce se systémem.
5.5 Implementace aplikace Nyní uvedu některé důležité webové adresy, které budeme potřebovat při práci s aplikací GAE Project Centre. 47
GAE Project Centre – http://gaecentre.comare.eu/ Nastavení Google Apps - https://www.google.com/a/cpanel/comare.eu/ Admin konzole GAE - http://www.appengine.google.com/a/comare.eu/ Na doménu „comare.eu“ je přiřazena a nastavena standardní verze služby Google Apps, kterou aplikace využívá pro některé svoje funkce a lze je snadno propojit s aplikacemi postavenými na GAE. Tyto služby je možné nastavovat na adrese uvedené v seznamu. Rozhraní samotné aplikace GAE Project Centre je umístěno na subdoméně domény comare.eu, protože zatím není možnost přesměrovat aplikaci přímo na doménu. Lze používat i adresu „http://www.comare.eu“, ze které je na webovou adresu aplikace dotaz přesměrován přímo. Do administrační konzole Google App Engine se dá přistoupit na webové adrese uvedené výše v seznamu. Zde můžeme vidět všechna nastavení a spotřebované výpočetní zdroje aplikace.
5.5.1 Přihlášení do aplikace Po zadání webové adresy aplikace je spuštěn kód aplikace. První ze služeb, kterou program kontaktuje, je správy uživatelů. V naší aplikaci je služba nastavena tak, aby uživatele autentizovala vhledem k doméně „comare.eu“ a službě Google Apps. Není zde možnost vytvoření nového uživatele, protože se jedná o uzavřenou firmu a uživatele může přidávat pouze administrátor. Na doméně jsou nyní vytvořeni čtyři uživatelé. Dva administrátoři (admin, ivos) a dva manažeři (tomas, jan). Všechna přístupová hesla jsou stejná a znějí „engine“. Po zkontrolování přihlášeného uživatele nebo případném přesměrování na přihlašovací stránku, se zobrazí hlavní strana aplikace GAE Project Centre. Rozhraní aplikace je vybudováno pomocí GWT a jeho UiBinding. Hlavní panel se dělí na další 4 panely a každý z nich obsahuje další panely, či widgety, které se opět mohou skládat z dalších prvků GWT. Tímto způsobem nám vzniká komplexní rozhraní složené z jednotlivých prvků. V jazyce Java je většinou implementován každý panel jako jedna třída se stejnou funkcionalitou.
48
Obrázek 5.2: Uživatelské rozhraní aplikace GAE Project Centre
Vrchní panel Ve vrchním panelu je umístěno logo společnosti a platformy Google App Engine, dále je po přihlášení uživatele nastaven odkaz „logout“ na správnou hodnotu, který uživatele opět přesměruje na přihlašovací stránku. Posledním odkazem je „About“, který otevře nové okno nad aplikací a vypíše informace o programu. Pravý panel V pravém panelu je umístěn komunikátor, který by měl sloužit ke komunikaci mezi více přihlášenými uživateli. Zprávy jsou aktualizovány buď po přidání nového příspěvku, nebo po určitém časovém úseku. Je vypisováno pouze posledních 20 zpráv, aby aplikace nepřenášela příliš velké datové objemy. Dále na pravém panelu umístěn webový rámec, který načítá agendu z veřejného kalendáře přihlášeného uživatele. Centrální panel Centrální panel je určen k zobrazování vybraného obsahu z okolních menu. Na rozdíl od ostatních panelů není určen velikostí, ale přizpůsobuje se okolí. Pokud potřebujeme vyměnit centrální panel za jiný, přistoupíme k hlavnímu „root“ panelu, získáme odkaz na centrální panel, jenž je jeho potomkem a tento odkaz odebereme. Na jeho místo můžeme vložit jiný požadovaný panel podobným způsobem.
49
Levý panel Levý panel reprezentuje v programu menu aplikace a má dva druhy rozložení. Jeden, který je načten každému běžnému uživateli systému a druhý, který se načte, pouze pokud je uživatel veden jako administrátor. Druhé rozložení přidává do menu další panel, obsahující nástroje na správu uživatelů, společností a zaměstnanců. Panely v menu otevírají další nabídky, které jsou rozděleny podle podobného zaměření. V těchto nabídkách se skrývají buď statické, nebo dynamicky vytvářené odkazy na další prvky aplikace. Admin section Administrátorský panel Admin section poskytuje správci aplikace možnost vytvářet a mazat společnosti, uživatele a zaměstnance. Vyjma administrátorského jsou v nabídce menu další čtyři ovládací panely. Company První panel je určen pro odkazy Společnosti. V současném stavu aplikace je zde implementována vývěska, na kterou může kdokoliv z uživatelů přispět svým článkem. Rozdíl oproti komunikátoru v pravém okně je trvalost příspěvků, text není omezen velikostí pětiset znaků a vkládaný text příspěvku může být ve formátu HTML nebo dokonce zkopírován z jiné stránky i se všemi textovými HTML prvky. Office tools Tento panel slouží jako seznam rychlých odkazů k externím službám Google Apps, které jsou k aplikaci připojeny. Uživatel používá stejné přístupové jméno a heslo jako do aplikace, proto ho nemusí již zadávat a je rovnou připojen do aplikací. Nyní jsou implementovány služby tři: Google mail, kalendář a dokumenty. Pokud by si firma přála přidat další služby, jako například album fotografií, lze to jednoduše provést. Employees Panel Employees nám zobrazí všechny zaměstnance vytvořené v systému. Pokud vybereme jednoho zaměstnance ze seznamu, zobrazí se nám v centrálním panelu, vypíší se nám informace o něm a také seznam projektů, ke kterým je momentálně přidělen. V tomto panelu může také uživatel zaslat zaměstnanci mail přímo z formuláře a bez nutnosti zadávat jakoukoliv adresu.
50
Projects V posledním panelu Projects vidíme odkaz na vytváření a editaci projektů, pod tímto odkazem je vypsán seznam firem ve stromové struktuře, kdy každá firma zobrazuje počet projektů, které má zadány v systému a po otevření podnabídky je vidět i rozdělení do skupin podle stavu ve kterém se projekt nachází. Oba panely Employees a Projects jsou vytvářeny dynamicky a je nutné po vytvoření nového prvku v databázi obnovit nabídku kliknutím na odkaz „Reload users“ nebo „Reload projects“. Tuto špatnou funkcionalitu způsobuje panel, který reprezentuje nabídku menu. Na rozdíl od ostatních panelů neumí při přepnutí jednotlivých částí menu spustit jakýkoliv manipulátor. Po otevření odkazu „Add/Edit projects“ se nám v centrálním panelu otevře výpis všech projektů s možností přidání nového nebo vymazání současného projektu. Po vložení projektu a obnovení menu se nám projekt přidá do stromové struktury ke správné firmě a stavu. Kliknutím na jeden uzel stromu se nám otevře v centrálním panelu příslušný výpis požadovaných projektů. Na panelu vidíme informace o projektu, které můžeme libovolně upravovat a ukládat do databáze. V bočním seznamu jsou vypsáni všichni zaměstnanci Společnosti a uživatel systému je jedním kliknutím může přiřadit k práci na projektu.
5.5.2 Práce uvnitř systému Jedním z mechanismů, které v aplikaci pracují bez účasti uživatele, je plánování úloh pomocí služby CRON. V aplikaci GAE Project Centre je tento mechanismus upraven tak, aby každý den o půlnoci vytvořil soupis zaměstnanců a projektů, které jsou jim přiřazeny, tyto soupisy spojil do jednotlivých zpráv a každému zaměstnanci odeslal soupis projektů, na kterých aktuálně pracuje. V implementované verzi, kdy jsou všechny zaměstnanecké účty pouze fiktivní, odesílá CRON všechny maily na adresu administrátora. Nastavení CRON se provádí přes XML soubor přidaný k aplikaci, který v daný čas aktivuje uvedený servlet.
51
/gaecentre/cronjob <description>Cron job that send emails to employees every day. <schedule>every day 00:00
Další práci, kterou musí program zastat na pozadí je práce s databází. Aplikace musí udržovat konzistenci dat pomocí vlastní logiky. V relaci M:N mezi entitami Employee a Project je tedy potřeba při každé operaci vložení či vymazání instance provést kód, který upraví i ostatní entity. Pokud tedy například přidáváme nový projekt, musí se vykonat následující zjednodušený kód programu: addProject(Project project) { project.getAssignedEmployees.add(employee.getKey()); employee.getAssignedProjects.add(project.getKey); }
Při takových operacích je důležité zapisovat záznamy o těchto operacích, k tomu v aplikaci slouží služba „logger“, která spolupracuje s GAE. Nejdříve nastavíme, pro jakou třídu jsou záznamy vytvářeny a poté, v jaké úrovni má logger zapisovat, zda chybové, informační, nebo varovné. Logger LOG = Logger.getLogger (ProjectServiceImpl.class.getName()); LOG.log(Level.INFO, "User" + getUserEmail() + "removeed project.");
Aplikace používá pro asynchronní komunikaci RPC. Nevýhodou tohoto přístupu je, že musíme mít 2 objekty stejného typu, jeden na straně klienta a druhý na straně serveru z důvodu serializace přenášených objektů. Z toho důvodu je nutné jednotlivé hodnoty entity přepisovat do druhé a naopak.1
5.5.3 Budoucí vylepšení a rozšíření V budoucnu by se aplikace mohla dočkat rozšíření o přístup zaměstnanců do systému. Muselo by se ale vypracovat nové přihlašovací rozhraní, které by dovolovalo omezit přístup určitým uživatelům do určitých částí aplikace. Zaměstnanci by mohli v systému zadávat například své odpracované hodiny nebo případně komunikovat s nadřízenými. Ať již s rozšiřující se firmou nebo s přístupem zaměstnanců do systému,
1
Příklad takového postupu je v části Příloha B.
52
bude nutné také ochránit přístup v databázích pomocí transakcí, které nyní byly díky malému počtu zaměstnanců a nízkému počtu editací v databázi vynechány z implementace. Rozšíření aplikace je tedy možné, nejen po stránce funkcionální, ale i vzhledové, díky způsobu budování uživatelské rozhraní, do kterého snadno přidáme další widgety a nové panely.
53
6 ZÁVĚR Cílem této práce bylo zjistit, zda je cloud computing a platformy založené na této technologii na takové úrovni, aby bylo možné na nich vytvářet IT systémy pro malé a střední firmy a zjistit, kdy je takovéto řešení vhodné. Služby cloud computingu jsou v prostředí internetu teprve krátkou chvíli a už si stihly vybudovat silnou pozici. To svědčí o vzrůstající oblibě, čehož si všimli i poskytovatelé těchto služeb a nabízejí produkty založené na tomto principu stále častěji. Mohu hodnotit pouze část trhu, jelikož jsem důkladně prozkoumal pouze platformu od společnosti Google a částečně platformu Windows Azure. Domnívám se ale, že spojení Javy, popřípadě jazyka.Net s možnostmi cloud computingu je velkou výhodou pro vývojáře a že se většina z nich zaměří právě na tyto dvě platformy. Mezi velké nevýhody Google App Engine patří občasné výpadky datového skladu, se kterými jsem se také setkal při práci s aplikací, jako i nezabezpečené internetové spojení s aplikacemi spouštěnými na této platformě. Obě tyto věci ale řeší verze Bussiness pro GAE, která byla nedávno oznámena. Když k výhodám cloud computingu přidáme možnost hostovat na standardní databázi SQL a pohodlné spojení s Google Apps službami, tak nám vzniká velice silný nástroj pro tvorbu internetových aplikací, určených přesně pro malé a střední firmy, které potřebují flexibilitu a dobrou cenovou nabídku. Z mého pohledu tedy výhody cloud platformy převyšují jeho nevýhody, a proto by se tyto technologie měly zařadit nastálo mezi ty, které nám poskytují možnosti tvorby internetových aplikací dnes.
54
7 POUŽITÁ LITERATURA 1. Sklenák, Vilém. Data, informace, znalosti a Internet. Praha : Vyd. 1, 2001. 80-7179409-0. 2. Connect: Cloud Computing. Kudělka, Tomáš. Praha : Cpress, 2009, Sv. 11. 3. Connect: Výzvy v řízení IT. Vitouš, Martin. Praha : Cpress, 2010, Sv. 2. 4. Kingová, Julia. PaaS slibuje revoluci ve vývoji softwaru. Computerworld. [Online] 2010. http://computerworld.cz/vyvoj/paas-slibuje-revoluci-ve-vyvoji-softwaru-5423. 5. Malý, Martin. Amazon AWS. Lupa.cz. [Online] 2010. http://www.lupa.cz/clanky/amazon-aws/. 6. Roche, Kyle a Douglas, Jeff. Beginning Java Google App Engine. New York : Apress, 2010. 978-1-4302-2553-9. 7. Ciurana, Eugene. Developing With Google App Engine. New York : Apress, 2008. 9781-4302-1831-9. 8. O'Reilly. Programming Google App Engine. Sebastopol : O’Reilly Media, 2010. 978-0596-52272-8. 9. C.A.aut, Binildas. Service Oriented Java Business Integration. Birmingham : Packt Publishing, 2008. 978-1-847194-40-4. 10. Louda, Pavel. App Engine od Google je nově dostupný i pro vývojáře firemních aplikací. Computer World. [Online] 2010. http://computerworld.cz/software/appengine-od-google-je-nove-i-pro-vyvojare-firemnich-aplikaci-6830.
55
11. Pichlík, Roman. Google Web Toolkit. Interval.cz. [Online] 2006. http://interval.cz/clanky/google-web-toolkit/.
56
8 PŘÍLOHA A Přiložené CD Následuje soupis položek obsažených na přiloženém CD: Text diplomové práce ve formátu xdoc Tato práce ve formátu PDF Programové balíky SDK ke Google App Engine a Google Web Toolkit Vývojové prostředí Eclipse Kompletní kód aplikace GAE Project Centre včetně obrázků
57
9 PŘÍLOHA B Ukázka zdrojového kódu při práci s RPC. Na straně klienta: NewsBoard.java: newsService.getNewsMsg(new AsyncCallback
>() { public void onFailure(Throwable error) { // do something with error } public void onSuccess(List news) { // call next method } });
Na straně klienta: NewsBoardServiceAsync.java : public void getNewsMsg(AsyncCallback> async);
Na straně klienta: NewsBoardService.java: List getNewsMsg();
Na straně serveru (NewsBoardServiceImpl.java) PersistenceManager pm = PMF.get().getPersistenceManager(); List news = new ArrayList(); try { Query q = pm.newQuery(NewsMsg.class); q.setOrdering("createDate desc"); List newsQuery = (List) q.execute(); for (NewsMsg thenews : newsQuery) { NewsMsgData newsMsgData = new NewsMsgData(); newsMsgData.setTitle(thenews.getTitle()); newsMsgData.setContent(thenews.getContent().getValue()); newsMsgData.setCreateDate(thenews.getCreateDate()); newsMsgData.setUser(thenews.getUser().getNickname()+ " ("+thenews.getUser().getEmail()+")"); news.add(newsMsgData); } } finally { pm.close(); } return news;
58
