Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00410 004850 14473141 na godz. na dobę w sumie
Google App Engine. Kod w chmurze - książka
Google App Engine. Kod w chmurze - książka
Autor: Liczba stron: 312
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3565-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Wykorzystaj potencjał chmur obliczeniowych!

Czy nie masz już dość zmartwień związanych z wydajnością i dostępnością Twoich serwerów? Wiecznych dyskusji z administratorami o ilości zużytego czasu procesora, pamięci RAM i powierzchni dyskowych? A może trapią Cię problemy z dostawcami internetu? Chmury to odpowiedź na Twoje bolączki! W każdej chwili będziesz miał na wyciągnięcie ręki taką ilość zasobów, jakiej dokładnie potrzebujesz - i tylko za nią zapłacisz.

Dzięki tej książce poznasz tajniki korzystania z chmury Google App Engine. Mogą ją wykorzystać programiści języków Python oraz Java. Chmura ta oferuje naprawdę bogate zasoby. W trakcie lektury dowiesz się, jaki jest jej potencjał, jak monitorować użycie zasobów przez Twoją aplikację oraz jak zastosować wbudowane mechanizmy bezpieczeństwa. Autor skupia się na najważniejszych aspektach tworzenia aplikacji dla Google App Engine.

Jest to idealna pozycja dla wszystkich programistów języków Java i Python, chcących wykorzystać możliwości i elastyczność rozwiązań opartych na chmurze obliczeniowej Google App Engine.

Skorzystaj z darmowych zasobów Google App Engine!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Code in the Cloud Tłumaczenie: Maciej Reszotnik ISBN: 978-83-246-3565-8 Copyright © 2011 Pragmatic Programmers, LLC. All rights reserved. Copyright © 2012 by Helion S.A. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from the Publisher. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/googap Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treĂci CzÚĂÊ I Google App Engine — przygotowania do pracy Rozdziaï 1. WstÚp ................................................................................ 11 1.1. Czym jest chmura obliczeniowa? ............................................................... 11 1.2. Systemy programowania w chmurze obliczeniowej ...................................... 17 1.3. PodziÚkowania ......................................................................................... 20 Rozdziaï 2. PoczÈtek ........................................................................... 21 2.1. Zakïadanie konta Google App Engine ...................................................... 21 2.2. Konfiguracja Ărodowiska programistycznego ............................................... 23 2.3. Uruchamianie programu napisanego w Pythonie na platformie App Engine ... 26 2.4. Monitorowanie stanu wïasnej aplikacji ....................................................... 33 CzÚĂÊ II Python i Google App Engine — programowanie aplikacji Rozdziaï 3. Pierwsza prawdziwa aplikacja w chmurze ................. 39 3.1. Podstawowa aplikacja czatu ...................................................................... 39 3.2. Podstawy HTTP .................................................................................... 43 3.3. Mapowanie czatu na HTTP .................................................................... 47 Rozdziaï 4. ZarzÈdzanie danymi w chmurze ................................... 55 4.1. Czemu nasz czat nie zadziaïaï? ................................................................. 55 4.2. Utrwalanie danych czatu .......................................................................... 58 6  Google App Engine. Kod w chmurze Rozdziaï 5. Obsïuga kont uĝytkowników w Google App Engine ... 69 5.1. Wprowadzenie do obsïugi uĝytkowników ................................................... 69 5.2. Usïuga Users — obsïuga uĝytkowników .................................................... 70 5.3. Integrujemy obsïugÚ uĝytkowników z czatem ............................................... 72 Rozdziaï 6. PorzÈdkowanie kodu — oddzielenie interfejsu uĝytkownika od logiki .................................. 75 6.1. Praca z szablonami — podstawy ............................................................... 76 6.2. Budowa róĝnych widoków przy uĝyciu szablonów ....................................... 81 6.3. Obsïuga wielu pokoi czatu ........................................................................ 86 Rozdziaï 7. Poprawianie wyglÈdu interfejsu — szablony i CSS .... 93 7.1. Wprowadzenie do CSS ............................................................................ 94 7.2. Nakïadanie stylów CSS na tekst ............................................................... 96 7.3. Ukïady stron w CSS .............................................................................. 101 7.4. Budowa interfejsu w oparciu o ukïad pïywajÈcy ........................................ 108 7.5. ZaïÈczanie arkusza stylów do aplikacji App Engine ................................. 112 Rozdziaï 8. Interakcja ...................................................................... 115 8.1. Podstawy tworzenia interaktywnych usïug ................................................ 116 8.2. Wzorzec projektowy MVC ..................................................................... 118 8.3. Niezakïócona komunikacja z serwerem ..................................................... 121 CzÚĂÊ III Programowanie na platformie App Engine w Javie Rozdziaï 9. Google App Engine i Java ............................................. 131 9.1. Wprowadzenie do GWT ........................................................................ 132 9.2. Praca z JavÈ i GWT — poczÈtki ............................................................ 135 9.3. Zdalne wywoïania procedur w GWT ...................................................... 143 9.4. Testowanie i przesyïanie aplikacji GWT do chmury ................................. 148 Rozdziaï 10. ZarzÈdzanie danymi po stronie serwera ................. 149 10.1. TrwaïoĂÊ danych w Javie ....................................................................... 150 10.2. GWT i przechowywanie trwaïych obiektów ........................................... 154 10.3. Pobieranie trwaïych obiektów w GWT .................................................. 157 10.4. Klient i serwer — komunikacja ............................................................. 160 Spis treĂci  7 Rozdziaï 11. Konstruowanie interfejsów uĝytkownika w Javie .... 163 11.1. Czemu GWT? .................................................................................... 163 11.2. Konstruowanie interfejsu uĝytkownika w GWT ..................................... 165 11.3. Oĝywianie interfejsu — obsïuga zdarzeñ ............................................... 171 11.4. Oĝywianie UI — uaktualnianie widoku ................................................. 176 11.5. GWT — podsumowanie ...................................................................... 178 Rozdziaï 12. Aplikacja Javy po stronie serwera ........................... 181 12.1. Wypeïnianie luk — obsïuga pokoi czatu ................................................ 181 12.2. Projektowanie interakcji: inkrementacja .................................................. 186 12.3. Uaktualnianie klienta ............................................................................ 194 12.4. Warstwa administracji czatu .................................................................. 195 12.5. Uruchamianie i przesyïanie aplikacji ...................................................... 196 12.6. Strona serwera — zakoñczenie .............................................................. 199 CzÚĂÊ IV Google App Engine — wyĝsza szkoïa jazdy Rozdziaï 13. Datastore — wyĝsza szkoïa jazdy: typy wïaĂciwoĂci ......................................................... 203 13.1. Tworzenie usïugi systemu plików ........................................................... 204 13.2. Modelowanie systemu plików: pierwsze kroki ......................................... 207 13.3. Typy wïaĂciwoĂci — lista ...................................................................... 224 13.4. Typy wïaĂciwoĂci — podsumowanie ...................................................... 227 Rozdziaï 14. Datastore — wyĝsza szkoïa jazdy: zapytania i indeksy ..................................................... 229 14.1. Indeksy i zapytania w Datastore ............................................................ 230 14.2. Elastyczniejsze modele Datastore .......................................................... 235 14.3. Transakcje, klucz i grupy encji .............................................................. 237 14.4. Polityka i modele spójnoĂci ................................................................... 239 14.5. Pobieranie inkrementalne ...................................................................... 242 Rozdziaï 15. Usïugi Google App Engine .......................................... 245 15.1. Szybki dostÚp do danych i usïuga Memcache ......................................... 246 15.2. DostÚp do danych: usïuga pobierania adresów URL .............................. 251 15.3. Komunikacja z czïowiekiem: poczta elektroniczna i komunikatory ............ 252 8  Google App Engine. Kod w chmurze 15.4. Wysyïanie i odbieranie poczty elektronicznej .......................................... 256 15.5. Usïugi — podsumowanie ..................................................................... 259 Rozdziaï 16. Serwerowe przetwarzanie w chmurze .................... 261 16.1. Terminarz zadañ i App Engine cron ..................................................... 262 16.2. Dynamiczne inicjalizowanie zadañ przy uĝyciu kolejkowania ................... 266 16.3. Serwerowe przetwarzanie w chmurze — podsumowanie ......................... 272 Rozdziaï 17. Bezpieczeñstwo i usïugi App Engine ........................ 275 17.1. Bezpieczeñstwo .................................................................................... 275 17.2. Podstawowe zabezpieczenia .................................................................. 276 17.3. Bezpieczeñstwo — stopieñ zaawansowany ............................................. 283 Rozdziaï 18. Administracja aplikacjÈ w chmurze ........................ 291 18.1. Monitorowanie ..................................................................................... 291 18.2. Rzut oka na Datastore .......................................................................... 295 18.3. Logi i debugowanie .............................................................................. 296 18.4. ZarzÈdzanie wïasnÈ aplikacjÈ ................................................................ 297 18.5. Nabywanie zasobów ............................................................................. 299 Rozdziaï 19. Podsumowanie ............................................................ 301 19.1. Podstawowe pojÚcia w chmurze ............................................................. 301 19.2. Idee typowe dla App Engine ................................................................ 302 19.3. Co dalej? ............................................................................................. 304 Skorowidz .......................................................................................... 307 Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  39 Rozdziaï 3. Pierwsza prawdziwa aplikacja w chmurze W komunikujÈ? tym rozdziale zbudujemy naszÈ pierwszÈ, bardziej zïoĝonÈ aplikacjÚ w Pythonie — pokój czatu. W trakcie pracy spróbujemy odpowiedzieÊ na nastÚpujÈce pytania:  W jaki sposób aplikacje w chmurze korzystajÈ z protokoïu HTTP i jak siÚ  Jak moĝna zintegrowaÊ zwykïy program napisany w Pythonie z protokoïem HTTP tak, by dziaïaï w chmurze?  Czym róĝni siÚ zarzÈdzanie danymi i zmiennymi w chmurze od tradycyj- nych technik? 3.1. Podstawowa aplikacja czatu Jak juĝ wspomniaïem, w tym rozdziale bÚdziemy pracowaÊ nad usïugÈ czatu napi- sanÈ w Pythonie. SÈdzÚ, ĝe jest to dobry przykïad, choÊby z uwagi na to, ĝe kaĝdy z nas kiedyĂ korzystaï z takiej aplikacji. ChoÊ ten rodzaj usïug upowszechniï siÚ dawno temu, posiada wiele cech charakterystycznych dla programu w chmurze. Przetwarzanie w chmurze jest wyjÈtkowe i intrygujÈce dlatego, iĝ w praktyce wszyst- kie utworzone w niej programy sÈ przeznaczone dla wielu uĝytkowników. NaprawdÚ w tym Ărodowisku nie da siÚ skonstruowaÊ dobrej aplikacji bez wziÚcia pod uwagÚ metod zarzÈdzania danymi dla duĝej liczby klientów. 40  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji Prostym, wrÚcz typowym przykïadem takiego programu jest wïaĂnie czat. By utwo- rzyÊ tÚ usïugÚ, musimy rozwaĝyÊ wszystkie formy interakcji miÚdzy uĝytkownikami, a takĝe sposoby przechowywania i odzyskiwania trwaïych danych. Musimy teĝ zaimplementowaÊ wiele kanaïów dla róĝnych dyskusji. DziÚki moĝliwoĂciom App Engine, budowa podstawowej wersji takiego programu i stopniowe dodawanie nowych funkcji jest sprawÈ prostÈ. Zignorujemy na razie kwestiÚ interfejsu uĝytkownika (zajmiemy siÚ nim w roz- dziale 7., „Poprawianie wyglÈdu interfejsu: szablony i CSS” — strona 93) i sku- pimy siÚ na tzw. „zapleczu” naszej aplikacji. Od tej pory skoncentrujemy siÚ na tworzeniu podstawowej logiki dla naszego programu, którÈ póěniej poïÈczymy z interfejsem. Nie zrobimy tego wszystkiego w jednym rozdziale. Przejdziemy przez kolejne etapy kreowania programu, krok po kroku, tak byĂ pod koniec tej ksiÈĝki mógï sam napisaÊ omówiony tu kod. Podstawowa aplikacja czatu nie jest skomplikowana — wystarczy jÈ sobie wyobraziÊ. Interfejs uĝytkownika czatu jest zwykle doĂÊ prosty — powinien zawieraÊ dwa pola — jedno, wyĂwietlajÈce transkrypcjÚ rozmowy i drugie, do wpisywania tekstu. W polu transkrypcji powinny znaleěÊ siÚ — uïoĝone w chronologicznej kolejnoĂci — wszystkie wiadomoĂci wysïane do czatu, kaĝda oznaczona nazwÈ uĝytkownika i czasem nadania. Podstawowy interfejs programu winien wyglÈdaÊ podobnie do szkieletu z rysunku 3.1. Rysunek 3.1. Szkic interfejsu uĝytkownika Teraz, gdy orientujemy siÚ, jak interfejs powinien wyglÈdaÊ, moĝemy przejĂÊ do fazy planowania jego budowy. Nim jednak zaczniemy siÚ zastanawiaÊ, jak zaprojek- towaÊ naszÈ aplikacjÚ w chmurze, przeanalizujmy, jak wyglÈda pisanie klasycznego programu czatu na zwykïym serwerze. Z tego wzglÚdu zajmiemy siÚ najpierw pro- gramowaniem w Pythonie szkieletowej aplikacji, która bÚdzie posiadaïa wszystkie interesujÈce nas funkcje; na razie nie dodamy nawet jednej linijki kodu typowego dla App Engine. Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  41 Czego zatem potrzebujemy? PatrzÈc na pole rozmów, moĝemy dojĂÊ do wniosku, ĝe kaĝdy czat tworzy wirtualnÈ przestrzeñ, którÈ uĝytkownicy mogÈ odwiedzaÊ i opusz- czaÊ. Po wejĂciu na czat kaĝdy z nich moĝe wysïaÊ wiadomoĂÊ. Wszystkie wcze- Ăniej wysïane wiadomoĂci bÚdÈ od razu widoczne dla kaĝdej nowo przybyïej osoby. Z powyĝszej analizy wynika, ĝe powinniĂmy wziÈÊ pod uwagÚ trzy podstawowe obszary: przestrzeñ wirtualnÈ, uĝytkowników oraz wiadomoĂci. Chcemy, by w naszej przestrzeni uĝytkownicy mieli dostÚp do wielu tematów kon- wersacji, ĝeby mogli sami zdecydowaÊ, z kim chcÈ rozmawiaÊ i o czym. Przestrzeñ wyznaczonÈ dla jednego tematu nazwiemy pokojem. W kaĝdym pokoju moĝe dojĂÊ do trzech wydarzeñ — ktoĂ moĝe do niego wkroczyÊ, ktoĂ moĝe go opuĂciÊ i ktoĂ moĝe wysïaÊ w nim wiadomoĂÊ. By caïÈ rzecz trochÚ uproĂciÊ, powiedzmy, ĝe zamiast uaktualniaÊ wpis za kaĝdym razem, gdy jakaĂ osoba wyĂle wiadomoĂÊ, kaĝdy uĝytkownik musi sam zaĝÈdaÊ transkrypcji wiadomoĂci raz na jakiĂ czas. PrzykïadowÈ implementacjÚ naszego pokoju moĝesz zobaczyÊ poniĝej. Nie ma ona nic wspólnego z aplikacjÈ chmurowÈ. Programy tworzone w chmurze zachowujÈ siÚ w zupeïnie inny sposób i dlatego muszÈ byÊ inaczej pisane. Dalej w ksiÈĝce bÚdziemy budowaÊ program w App Engine, który bÚdzie w stanie wykonaÊ to samo, co ten, który zaprezentowano poniĝej, ale w chmurze danych. Przyjrzyjmy siÚ, w czym dokïadnie tkwi podstawowa róĝnica. basechat.py class ChatRoom(object): Pokój rooms = {} def __init__(self, name): self.name = name self.users = [] self.messages = [] ChatRoom.rooms[name] = self def addSubscriber(self, subscriber): self.users.append(subscriber) subscriber.sendMessage(self.name, Uĝytkownik s doïÈczyï do dyskusji. subscriber.username) def removeSubscriber(self, subscriber): if subscriber in self.users: subscriber.sendMessage(self.name, Uĝytkownik s opuĂciï pokój. subscriber.username) self.users.remove(subscriber) def addMessage(self, msg): self.messages.append(msg) 42  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji def printMessages(self, out): print out, Lista wiadomoĂci: s self.name for i in self.messages: print out, i Aplikacja czatu musi obsïugiwaÊ pewnÈ grupÚ uĝytkowników. Kaĝdy uĝytkownik ma przypisane imiÚ i jest zalogowany w pewnej grupie pokoi. Uĝytkownik moĝe wejĂÊ do pokoju, opuĂciÊ go lub wysïaÊ wiadomoĂÊ. JeĂli dana osoba nie weszïa do konkretnego pokoju, nie ma prawa wysïaÊ w nim wiadomoĂci. basechat.py class ChatUser(object): Uĝytkownik biorÈcy udziaï w czacie def __init__(self, username): self.username = username self.rooms = {} def subscribe(self, roomname): if roomname in ChatRoom.rooms: room = ChatRoom.rooms[roomname] self.rooms[roomname] = room room.addSubscriber(self) else: raise ChatError( Nie znaleziono pokoju s roomname) def sendMessage(self, roomname, text): if roomname in self.rooms: room = self.rooms[roomname] cm = ChatMessage(self, text) room.addMessage(cm) else: raise ChatError( Uĝytkownik s nie jest zarejestrowany w pokoju s (self.username, roomname)) def displayChat(self, roomname, out): if roomname in self.rooms: room = self.rooms[roomname] room.printMessages(out) else: raise ChatError( Uĝytkownik s nie jest zarejestrowany w pokoju s (self.username, roomname)) Najprostszym komponentem naszego czatu bÚdzie wysyïanie wiadomoĂci przez uĝytkownika. Pojedyncza wiadomoĂÊ musi zawieraÊ odwoïanie do osoby, która jÈ zamieĂciïa, oraz informacje o czasie, w którym zostaïa wysïana. basechat.py class ChatMessage(object): Pojedyncza wiadomoĂÊ wysïana przez uĝytkownika czatu def __init__(self, user, text): self.sender = user self.msg = text Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  43 self.time = datetime.datetime.now() def __str__(self): return Od: s o godzinie s: s (self.sender.username, self.time, self.msg) W celu przetestowania naszej aplikacji napiszmy szybko program gïówny, tzn. fragment kodu odpowiedzialny za to, by coĂ robiïa. Na razie pomiñmy kwestiÚ interakcji — zamiast tego sprawděmy, czy nasz program w ogóle dziaïa i jak siÚ prezentuje. Utwórzmy w kodzie kilku uĝytkowników, przypiszmy ich do odpowied- nich pokojów i sprawmy, by wysïali jakieĂ wiadomoĂci. basechat.py def main(): room = ChatRoom( Main ) markcc = ChatUser( MarkCC ) markcc.subscribe( Main ) prag = ChatUser( Prag ) prag.subscribe( Main ) markcc.sendMessage( Main , Hej! Jest tu kto? ) prag.sendMessage( Main , Tak, ja tu jestem. ) markcc.displayChat( Main , sys.stdout) if __name__ == __main__ : main() Po uruchomieniu caïoĂci otrzymujemy nastÚpujÈcÈ treĂÊ: Lista wiadomoĂci: Main Od: MarkCC o godzinie 2011-08-21 14:09:22.735000: Uĝytkownik MarkCC doïÈczyï do dyskusji. Od: Prag o godzinie 2011-08-21 14:09:22.735000: Uĝytkownik Prag doïÈczyï do dyskusji. Od: MarkCC o godzinie 2011-08-21 14:09:22.735000: Hej! Jest tu kto? Od: Prag o godzinie 2011-08-21 14:09:22.735000: Tak, ja tu jestem. To nie prezentuje siÚ zbyt spektakularnie. Znaczniki czasowe sÈ stanowczo zbyt rozwlekïe, a tekst przydaïoby siÚ lepiej sformatowaÊ, by byï bardziej czytelny, lecz przynajmniej udaïo siÚ nam zapewniÊ wszystkie podstawowe komponenty kaĝdego czatu (pokoje, rejestracjÚ w usïudze oraz wiadomoĂci). 3.2. Podstawy HTTP PodejĂcie, które obraliĂmy do projektowania i implementacji naszego bardzo okro- jonego czatu, jest caïkiem rozsÈdne, przynajmniej dla tradycyjnych aplikacji. Gdy jednak projektujesz programy w chmurze, musisz wykonaÊ jeden dodatkowy krok. W zwykïych programach tego typu naleĝy rozplanowaÊ logikÚ przetwarzania danych 44  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji oraz interfejs uĝytkownika. Naturalnie, równieĝ przy programowaniu aplikacji w chmurze musisz wziÈÊ te czynniki pod uwagÚ, ale dodatkowo trzeba teĝ dla niej utworzyÊ protokóï. Kaĝde zaplecze programu chmurowego dziaïa na pojedynczym serwerze bÈdě ich skupisku w jakimĂ centrum danych. Z kolei interfejs uĝytkownika jest uruchamiany w przeglÈdarce internetowej. PodstawowÈ funkcjÈ protokoïu jest zapewnienie komu- nikacji miÚdzy nimi, przez co program sprawia wraĝenie, jakby w caïoĂci dziaïaï na komputerze klienta. WiÚkszoĂÊ aplikacji dziaïajÈcych w chmurze i praktycznie wszystkie programy App Engine zbudowano w oparciu o protokóï HTTP (ang. Hypertext Transfer Pro- tocol). Przekïada siÚ to na fakt, iĝ nim zaczniesz pisaÊ wïasnÈ aplikacjÚ, musisz wpierw zaprojektowaÊ protokóï „nawarstwiony” na HTTP. W tym kontekĂcie sïowo „nawarstwianie” oznacza, ĝe Twój protokóï powinien byÊ zbudowany tak, by kaĝdÈ interakcjÚ zachodzÈcÈ w programie moĝna byïo zapisaÊ w odniesieniu do HTTP. To wïaĂnie stanowi jeden z gïównych czynników wyróĝniajÈcych programowanie w chmurze wĂród innych jego form — aplikacje chmurowe bazujÈ na interakcji klient-serwer z wykorzystaniem protokoïu HTTP. Z tego wzglÚdu prawidïowe nawarstwianie wïasnego programu na HTTP jest kluczem do opracowania wydajnej i przyjemnej w uĝyciu aplikacji. PrawdÈ jest, ĝe szczególnie wtedy, jeĂli nie jesteĂ przyzwyczajony do pracy z HTTP, protokóï moĝe Ci siÚ wydaÊ trochÚ sier- miÚĝny i nieprzystÚpny, lecz — jak siÚ póěniej przekonasz — moĝna z jego pomocÈ tworzyÊ bogate formy interakcji. ByÊ moĝe wiesz juĝ co nieco o tym protokole. Warto jednak poĂwiÚciÊ chwilÚ na krótkie przypomnienie, gdyĝ opanowanie podstaw jego funkcjonowania bÚdzie nie- zbÚdne przy omawianiu dziaïania programów w App Engine. Zatem, nim przej- dziemy do napisania protokoïu, powtórzmy elementarne informacje o HTTP. HTTP jest prostym protokoïem ĝÈdañ i odpowiedzi typu klient-serwer. Innymi sïowy, to wïaĂnie dziÚki niemu dowolne dwie strony mogÈ siÚ ze sobÈ komunikowaÊ. JednÈ z nich nazywamy klientem, drugÈ — serwerem. Kaĝda z tych stron peïni inne funkcje. W protokole HTTP klient inicjalizuje komunikacjÚ, wysyïajÈc ĝÈda- nia na serwer; z kolei serwer przetwarza te ĝÈdania i wysyïa z powrotem odpowiedzi dla klienta. Protokóï HTTP zajmuje siÚ opisywaniem sposobu, w jaki klient wysyïa ĝÈdania i otrzymuje odpowiedzi. ¿eby uproĂciÊ caïy proces, kaĝde ĝÈdanie jest wycentrowane na zasobach. W tym kontekĂcie zasobem jest wszystko to, czemu przyznano w sieci nazwÚ. Do kaĝdego zasobu odnosimy siÚ za pomocÈ ujednoliconego formatu adresowania zasobów URL (ang. Universal Resource Locator). Adres URL peïni funkcjÚ podobnÈ do Ăcieĝki do pliku, lecz moĝna siÚ w nim odnieĂÊ do wielu rzeczy — plików, caïych Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  45 programów, ludzi, procesów i do wszystkiego, co tylko sobie wyobrazisz. Kaĝde zapytanie na serwerze jest w istocie proĂbÈ o otrzymanie potrzebnych danych lub o moĝliwoĂÊ ich przesïania do zasobu. Co wiÚcej, kaĝde ĝÈdanie HTTP od strony klienta wywoïuje konkretnÈ metodÚ po stronie serwera. (Jest to trochÚ mylÈce, ale wbrew przyjÚtemu nazewnictwu „metody” stosowane w tym przypadku nie majÈ nic wspólnego z „metodami” uĝywanymi w programowaniu obiektowym). W HTTP wyróĝniamy cztery podstawowe metody (oraz ponad tuzin rozszerzeñ, których jednak nie bÚdÚ omawiaï, poniewaĝ nie przy- dadzÈ siÚ w naszej aplikacji). GET Wysyïa na serwer proĂbÚ o moĝliwoĂÊ pobrania informacji z zasobu i prze- sïanie ich do klienta. HEAD Wysyïa proĂbÚ o podanie przez serwer informacji o danym zasobie. Dziaïa wiÚc podobnie do metody GET, z tym ĝe otrzymana odpowiedě zawiera je- dynie metadane. Przykïadowo mógïbyĂ skorzystaÊ z tego ĝÈdania, by zadaÊ pytanie: „Jak wielki jest ten zasób”, bez potrzeby przesyïania go w caïo- Ăci. Co prawda, niewiele aplikacji uĝywa metody HEAD, lecz z pewnoĂciÈ jest czasem przydatna. PUT Przechowuje dane w okreĂlonym zasobie. Dziaïanie tej metody polega na przesïaniu informacji na serwer, by zachowaÊ jÈ w zdefiniowanej przestrzeni. W odpowiedzi serwer wysyïa informacjÚ zwrotnÈ, czy interesujÈce dane udaïo siÚ zapisaÊ. POST Przesyïa dane do dziaïajÈcego na serwerze programu. ¿Èdania typu POST sÈ trochÚ dziwne. Pozornie róĝnica miÚdzy metodami POST i PUT wydaje siÚ marginalna. Wywodzi siÚ ona z pierwszych lat funkcjonowania Internetu, kiedy to wiele serwerów sieciowych byïo uruchomionych na maïych kompute- rach prywatnych. W owych serwerach wszystkie ĝÈdania typu GET i PUT byïy interpretowane jako proĂby o przesïanie lub przechowanie danych. Dlatego teĝ, aby uruchomiÊ program na serwerze, potrzebna byïa oddzielna metoda, która prosiïaby o jego inicjalizacjÚ. Jednak w nowoczesnych systemach zarówno ĝÈdañ PUT, jak i POST uĝywa siÚ zamiennie. Kaĝde ĝÈdanie HTML, czy to wygenerowane przez TwojÈ przeglÈdarkÚ, czy prze- tworzone przez App Engine, skïada siÚ z trzech czÚĂci. Oto one.  Linia ĝÈdania, zïoĝona z metody HTTP, po której wystÚpuje adres URL zasobu i, kolejno, specyfikacja wersji protokoïu. W wiÚkszoĂci przypadków Twoja przeglÈdarka wysyïa ĝÈdania typu GET, w wersji specyfikacji HTTP/1.1.  Sekwencje linijek nagïówków zawierajÈcych metadane o ĝÈdaniu (takie jak specyfikacja zawartoĂci — Content-Type — z której korzystaliĂmy 46  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji w podrozdziale 2.3, „Uruchamianie programu napisanego w Pythonie na platformie App Engine”, na stronie 26). WiÚkszoĂÊ ĝÈdañ przeglÈdarek bÚdzie podawaÊ swojÈ wersjÚ (w tzw. nagïówku uĝytkownika — ang. user-agent header) i jakiĂ identyfikator (nagïówek From:). Ponadto na nagïówki mogÈ skïadaÊ siÚ odniesienia do plików cookie, identyfikatory jÚzykowe, adresy sieciowe itp. WewnÈtrz nagïówka moĝe siÚ znaleěÊ wszystko, bowiem serwery i tak po prostu ignorujÈ zawartoĂÊ tych, których nie sÈ w stanie rozpoznaÊ.  Ciaïo (ang. body) dokumentu skïadajÈce siÚ z dowolnego potoku danych. Ciaïo i nagïówki sÈ od siebie odseparowane pustÈ liniÈ — bez jakiejkolwiek treĂci. Ogólnie rzecz biorÈc, ciaïo ĝÈdañ typu GET i HEAD jest puste. Spójrz na poniĝsze przy- kïadowe ĝÈdanie GET: GET /rooms/chatter HTTP/1.1 User-Agent: Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101 Host: ´markcc-chatroom-one.appspot.com Po wysïaniu ĝÈdania HTML na serwer odpowiada on podobnie skonstruowanÈ wiadomoĂciÈ. Róĝnica polega na tym, ĝe zamiast linii ĝÈdania serwer otwiera swojÈ odpowiedě tzw. wierszem stanu. Rozpoczyna siÚ on od kodu stanu i wiadomo- Ăci stanu, gdzie zawarte sÈ informacje, czy ĝÈdanie zostaïo wykonane, a jeĂli nie, to z jakiego powodu. Typowy wiersz stanu generowany przez usïugÚ w chmurze ma postaÊ HTTP/1.1 200 OK, gdzie fragment HTTP/1.1 okreĂla, z jakiego protokoïu serwer skorzystaï, 200 jest kodem stanu, a sïowo OK jego wiadomoĂciÈ. Kod stanu zawsze skïada siÚ z trzech cyfr. Pierwsza z nich ustala ogólny rodzaj odpowiedzi. I tak: 1 oznacza „odpowiedě informujÈcÈ”. 2 oznacza pomyĂlne zakoñczenie ĝÈdania. 3 oznacza przekierowanie — klient otrzymuje wiadomoĂÊ o poïoĝeniu danego zasobu w innym miejscu. Proces przekierowania moĝna by adekwatnie pod- sumowaÊ zdaniem: „Nie ma tu poszukiwanej przez Ciebie informacji, ale znajdziesz jÈ pod nastÚpujÈcym adresem URL”. 4 wskazuje na bïÈd po stronie klienta (np. kod 404 oznacza, ĝe klient domaga siÚ dostÚpu do zasobu nieistniejÈcego w danym miejscu na serwerze). 5 wskazuje na bïÈd po stronie serwera (np. gdy uruchomiony na nim program wykona nieprawidïowÈ operacjÚ). Oto przykïadowa odpowiedě serwera na przedstawione powyĝej ĝÈdanie GET: HTTP/1.1 200 OK Date: Sat, 26 Jun 2009 21:41:13 GMT Content-Type: text/html Content-Length: 123 Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  47 html body p MarkCC: Hej, jest tu kto? /p p Prag: Tak, ja tu jestem. /p /body /html Przeanalizujmy wspólnie sekwencjÚ ĝÈdanie-odpowiedě. Zaïóĝmy, ĝe do wysyïania wiadomoĂci w naszym czacie wykorzystujemy metodÚ POST. Wtedy nasze zapytanie mogïoby wyglÈdaÊ nastÚpujÈco: POST /submit HTTP/1.1 User-Agent: Mozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101 Host: markcc-chatroom-one-pl.appspot.com From: markcc.pol@gmail.com ChatMessage User MarkCC /User Date June 26, 2009 16:33:12 EDT /Date Body Hej, jest tam kto? /Body /ChatMessage Gdyby zakoñczyïo siÚ powodzeniem, otrzymalibyĂmy nastÚpujÈcÈ wiadomoĂÊ: HTTP/1.1 303 See other Date: Sat, 20 Aug 2011 21:41:13 GMT Location: http://markcc-chatroom-one-pl.appspot.com/ 3.3. Mapowanie czatu na HTTP W celu zmiany naszej napisanej w Pythonie aplikacji, tak aby dziaïaïa w chmurze App Engine, musimy wpierw zmapowaÊ podstawowe wykonywane przez niÈ ope- racje na ĝÈdania i odpowiedzi HTTP. W wersji, nad którÈ bÚdziemy pracowaÊ, pominiemy kwestiÚ rejestracji — utwo- rzymy jedynie pojedynczy pokój i jeĂli uda siÚ z nim poïÈczyÊ, automatycznie poja- wimy siÚ w nim. W tej chwili nie musimy siÚ przejmowaÊ uĝytkownikami nowymi i opuszczajÈcymi pokój. Wyobraě sobie, ĝe korzystasz z pokoju. Co chciaïbyĂ w nim robiÊ? Po pierwsze, przydaïoby siÚ zobaczyÊ nowe wiadomoĂci w naszym pokoju. Prze- kïadajÈc to na zasadÚ dziaïania protokoïu HTTP, pokój naszego czatu jest zasobem, którego zawartoĂÊ chcesz zobaczyÊ. OczywiĂcie, do tego celu Ăwietnie siÚ nada metoda GET, która pomoĝe pobraÊ zawartoĂÊ czatu i jÈ wyĂwietliÊ. Chcemy teĝ mieÊ moĝliwoĂÊ wysyïania wiadomoĂci, wobec czego bÚdziemy potrze- bowaÊ sposobu na zakomunikowanie naszemu programowi przez przeglÈdarkÚ, 48  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji HTTP — kody stanu W standardzie HTTP zdefiniowano wiele kodów stanów, które wykorzystuje siÚ w przesyïanych przez serwer wiadomoĂciach zwrotnych. Oto kilka naj- czÚĂciej spotykanych. 200 OK PomyĂlnie odebrano i przetworzono ĝÈdanie. Ciaïo wiadomoĂci zwrot- nej na ogóï zawiera ĝÈdane dane. 301 Moved permanently (zasób przeniesiono na staïe) ¿Èdany zasób nie znajduje siÚ juĝ pod okreĂlonym adresem URL i kaĝda nowa proĂba o jego udostÚpnienie powinna byÊ przesïana pod nowy adres. 303 See other (znajdziesz w innym miejscu) ¿Èdane zasoby znajdujÈ siÚ w innym miejscu i mogÈ byÊ odzyskane za pomocÈ metody GET, wysïanej pod inny adres URL. Adres ten winien byÊ zawarty w nagïówku poïoĝenia wiadomoĂci zwrotnej. Rzeczony kod pojawia siÚ czÚsto w odpowiedzi na ĝÈdania typu PUT — po tym, jak zapytanie to zostaïo pomyĂlnie przetworzone, serwer informuje klienta, gdzie moĝe szukaÊ potrzebnych zasobów bezpoĂrednio. 401 Unauthorized (brak uwierzytelnienia) Samo ĝÈdanie byïo poprawne, lecz nie zawieraïo danych uwierzytel- niajÈcych, które sÈ wymagane w celu otrzymania dostÚpu do zasobu. Uĝytkownik moĝe wykorzystaÊ inne zapytania, by zdobyÊ niezbÚdne informacje i ponowiÊ to ĝÈdanie. 403 Forbidden (dostÚp zabroniony) ¿Èdanie byïo sformuïowane poprawnie, lecz dostÚp do zasobów zostaï zabroniony. Kod ten dziaïa tak samo jak kod 401, z tÈ róĝnicÈ, ĝe albo nawet po uwierzytelnieniu dany uĝytkownik nie ma dostÚpu do zasobów, albo dostÚp dla wszystkich uwierzytelnionych uĝytkowników jest wzbroniony. 404 Not found (nie odnaleziono) ¿Èdanego zasobu nie odnaleziono w okreĂlonej lokacji sieciowej. 500 Internal Server Error (wewnÚtrzny bïÈd serwera) Kaĝdy bïÈd serwera, który pojawiï siÚ w trakcie przetwarzania zapyta- nia, zwróci kod stanu 500. W kontekĂcie App Engine, jeĂli Twój wïasny kod zawiesi siÚ lub wykona nieprawidïowÈ operacjÚ, przeglÈdarka po stronie klienta otrzyma wïaĂnie tÚ informacjÚ. 501 Not implemented (brak wsparcia) Zapytanie prosi o wykonanie operacji nieobsïugiwanej przez serwer. Komunikat tego typu otrzymasz, gdy popeïnisz bïÈd np. w nazwie adresu URL ĝÈdania POST. Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  49 ĝeby zamieĂciï wpisanÈ przez nas w aktywnym polu wiadomoĂÊ. I znów nasz pokój czatu jest zasobem, ale w tym wypadku masz w nim umieĂciÊ treĂÊ. Wobec tego, do wykonania zadania musimy uĝyÊ metody PUT lub POST. Decyzja, z której skorzy- stamy, zaleĝy od tego, czy chcemy zastÈpiÊ zawartoĂÊ zasobu, czy po prostu wysïaÊ tam komunikat. Naturalnie wysyïanie wiadomoĂci mieĂci siÚ bardziej w tej drugiej definicji. Nie chcemy zastÈpiÊ wiadomoĂci w naszym pokoju, chcemy natomiast przekazaÊ do naszej aplikacji informacjÚ, ĝe ma wyĂwietliÊ nowÈ wiadomoĂÊ. Dlatego teĝ uĝyjemy ĝÈdania POST. W ten sposób zdefiniowaliĂmy strukturÚ, na podstawie której zbudujemy program. Naszym jedynym zasobem bÚdzie pokój czatu. Uĝytkownicy bÚdÈ mogli pobraÊ zawartoĂÊ tego zasobu za pomocÈ zapytania GET i wtedy zapoznajÈ siÚ z jego zawar- toĂciÈ. Potrzebujemy innego zasobu — aktywnego procesu, do którego osoby bÚdÈ wysyïaÊ ĝÈdania POST, by umieĂciÊ wiadomoĂci na czacie. Teraz musimy rozwaĝyÊ implementacjÚ elementarnego interfejsu uĝytkownika. W jaki sposób uĝytkownik bÚdzie dodawaï dane do naszej aplikacji? Jasne jest, ĝe trzeba bÚdzie zapewniÊ takÈ moĝliwoĂÊ. NajproĂciej utworzyÊ na stronie formu- larz, który zostanie wypeïniony zawartoĂciÈ po kaĝdym logowaniu uĝytkownika do pokoju. Strona czatu ma siÚ wiÚc skïadaÊ z tytuïu na górze, obszaru rozmów, w któ- rym wyĂwietlane bÚdÈ kolejne wiadomoĂci, oraz pola wpisów z przypisanÈ nazwÈ uĝytkownika, gdzie kaĝda osoba bÚdzie mogïa dodaÊ swojÈ treĂÊ. Aby uruchomiÊ powyĝszÈ aplikacjÚ w App Engine, bÚdziemy musieli utworzyÊ (na podstawie klasy RequestHandler) dwa handlery ĝÈdañ — jeden, który zaim- plementuje metodÚ GET do odzyskiwania zawartoĂci pokoju z serwera, oraz drugi, wykorzystujÈcy metodÚ POST, w celu dodania treĂci do czatu. Strona gïówna naszego czatu bÚdzie prezentowaÊ siÚ podobnie do tej z rozdziaïu 2., „PoczÈtek”. Podstawowa róĝnica polega na tym, ĝe dodamy do niej dynamiczne elementy — wszystko to, co moĝe siÚ przydaÊ do wyĂwietlania i wysyïania wiado- moĂci. Dlatego teĝ nie moĝemy po prostu ponownie wykorzystaÊ uprzednio zapre- zentowanego kodu HTML; trzeba bÚdzie trochÚ do niego dopisaÊ. W pierwszej wersji czatu zadeklarujemy zmiennÈ globalnÈ, która przyjmie listÚ wysïanych wiado- moĂci. Po zaïadowaniu strony wyĂwietlimy je wszystkie. chattwo/chattwo.py class ChatMessage(object): def __init__(self, user, msg): self.user = user self.message = msg self.time = datetime.datetime.now() def __str__(self): return s ( s): s (self.user, self.time, self.message) 50  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji Messages = [] class ChatRoomPage(webapp.RequestHandler): def get(self): self.response.headers[ Content-Type ] = text/html charset=UTF-8 self.response.out.write( html head title Witaj w pokoju czatu MarkCC w App Engine /title /head body h1 Witaj w pokoju czatu MarkCC w App Engine /h1 p (Dokïadny czas Twojego logowania to: s) /p (datetime.datetime.now())) # Wysyïanie wiadomoĂci na serwer. global Messages for msg in Messages: self.response.out.write( p s /p msg) self.response.out.write( form action= method= post div b Twój nick: /b textarea name= name rows= 1 cols= 20 /textarea /div p b Twoja wiadomoĂÊ /b /p div textarea name= message rows= 5 cols= 60 /textarea /div div input type= submit value= WyĂlij wiadomoĂÊ /input /div /form /body /html ) Obsïuga ĝÈdania POST jest dla nas czymĂ nowym, lecz dziÚki frameworkowi webapp czynnoĂÊ ta jest prosta. W handlerze ĝÈdania GET przesïaniamy metodÚ get klasy bazowej RequestHandler. Analogicznie, dla ĝÈdania POST nadpisujemy metodÚ post tej klasy. Klasa bazowa RequestHandler zapewnia to, ĝe gdy metoda post zostaje wywoïana, pola utworzonego obiektu sÈ wypeïniane wszelkimi potrzebnymi danymi. JeĂli chcemy uzyskaÊ informacje z pól formularza, które wysïaïy ĝÈdanie POST, wystarczy, ĝe wywoïamy metodÚ get, korzystajÈc z etykiety wypeïnionej w formu- larzu. W naszym kodzie nazwÚ uĝytkownika i treĂÊ wiadomoĂci otrzymamy bez- poĂrednio z ĝÈdania POST. Uĝyjemy ich do utworzenia obiektu wiadomoĂci, który dodamy do globalnej listy wszystkich wypowiedzi uĝytkowników. chattwo/chattwo.py def post(self): chatter = self.request.get( name ) msg = self.request.get( message ) global Messages Messages.append(ChatMessage(chatter.encode( utf-8 ), msg.encode( utf-8 ))) # Po tym, jak dodaliĂmy naszÈ wiadomoĂÊ do czatu, przekierujmy naszÈ aplikacjÚ na jej # wïasny adres, aby jÈ odĂwieĝyÊ, co spowoduje wyĂwietlenie nowej wiadomoĂci. self.redirect( / ) Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  51 Teraz wystarczy wszystko zïoĝyÊ w jeden program. Zrobimy to w dwóch etapach. Na poczÈtek napiszemy fragment kodu, który spowoduje powstanie obiektu apli- kacji i przerzuci wszelkie ĝÈdania do naszych handlerów. NastÚpnie utworzymy plik app.yaml. Dopiero wtedy bÚdziemy mogli sprawdziÊ, czy nasz program dziaïa. Plik app.yaml ma prawie takÈ samÈ treĂÊ jak poprzednio. Zmieniïem, co prawda, nazwÚ pliku programu, wobec czego musimy równieĝ zmieniÊ odpowiedni wpis w konkretnym polu. chattwo/app.yaml application: markcc-chatroom-one-pl version: 1 runtime: python api_version: 1 handlers: - url: /.* script: chattwo.py A oto fragment kodu Pythona specyficzny dla frameworka webapp. chattwo/chattwo.py chatapp = webapp.WSGIApplication([( / , ChatRoomPage)]) def main(): run_wsgi_app(chatapp) if __name__ == __main__ : main() JeĂli go uruchomimy (posiïkujÈc siÚ aplikacjÈ dev_appserver.py, tak jak w poprzed- nim rozdziale), naszym oczom ukaĝe siÚ prosty, acz funkcjonalny czat. Pora go wypróbowaÊ. Dziaïa wyĂmienicie! Teraz moĝemy go swobodnie przesïaÊ na serwery App Engine. Tak jak wczeĂniej, robimy to za pomocÈ polecenia appcfg.py update. Na rysunku 3.2 widaÊ efekt pracy naszej aplikacji. Prezentuje siÚ ona dokïadnie tak, jak na serwerze lokalnym. Wysïaïem z jej pomocÈ dwie wiadomoĂci, uĝywajÈc dwóch róĝnych nazw uĝytkownika, i otrzymaïem przyzwoicie wyglÈdajÈcÈ konwersacjÚ. Musiaïem jednak na chwilÚ odejĂÊ od komputera, by wykÈpaÊ mego synka i uïoĝyÊ go do snu. Gdy wróciïem, wysïaïem kolejnÈ wiadomoĂÊ. Efekt moĝesz podziwiaÊ na rysunku 3.3. Wszystkie dawne wiadomoĂci zniknÚïy! Pole treĂci nie zawiera ĝadnych wiado- moĂci poza tÈ, którÈ wïaĂnie wysïaïem. Nie napisaliĂmy przecieĝ w naszym skrypcie nic, co mogïoby spowodowaÊ wykasowanie wiadomoĂci. Nie moĝe robiÊ nic poza dodawaniem nowych. Co siÚ wiÚc staïo z tymi zaginionymi? Gdzie siÚ podziaïy? 52  CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji Rysunek 3.2. Aplikacja czatu w akcji Rysunek 3.3. Aplikacja czatu po dïuĝszej przerwie Odpowiedě brzmi — nigdzie. DostaliĂmy pstryczka w nos, gdyĝ nie wziÚliĂmy pod uwagÚ podstawowej róĝnicy miÚdzy aplikacjÈ pisanÈ w chmurze a tradycyjnÈ. Otóĝ, piszÈc program bezpoĂrednio dla serwera, jesteĂ Ăwiadom, ĝe kaĝde ĝÈdanie zosta- nie przez niego obsïuĝone. Zwykle, korzystajÈc z interpretera Pythona, wysyïamy na serwer ĝÈdanie do przetworzenia i mamy pewnoĂÊ, ĝe bÚdzie aktywny przez Rozdziaï 3. • Pierwsza prawdziwa aplikacja w chmurze  53 caïy czas. Gdy jednak wysyïasz ĝÈdanie na serwer w chmurze, jest ono przenoszone na dowolny serwer w dowolnym centrum danych. Nie ma ĝadnej gwarancji, ĝe dwa ĝÈdania zostanÈ przesïane na ten sam serwer, czy nawet na serwer znajdujÈcy siÚ na tym samym kontynencie. A jeĂli nawet jakimĂ cudem tak siÚ stanie, znów nie masz ĝadnych gwarancji, ĝe serwer bÚdzie przetwarzaï kod Pythona przez caïy ten czas. We frameworkach bazu- jÈcych na chmurze, takich jak webapp, wszelkie handlery ĝÈdañ sÈ niezaleĝne od stanu, co oznacza, iĝ raczej nie moĝesz liczyÊ na to, ĝe Twoje zmienne zostanÈ zapamiÚtane. Musisz wiÚc budowaÊ swoje aplikacje tak, jakby kaĝde nowe ĝÈdanie byïo uruchamiane przez nowy interpreter Pythona. NaprawdÚ mieliĂmy wielkie szczÚĂcie, ĝe nasza aplikacja w ogóle zadziaïaïa w chmu- rze. Gdy uruchomimy jÈ lokalnie, program dev_appserver korzysta wyïÈcznie z jed- nego interpretera, dlatego teĝ aplikacja dziaïa bez zarzutu. Po zaïadowaniu na serwer App Engine jest program uruchamiany w chmurze. Po przesïaniu pierw- szego ĝÈdania losowy serwer uruchomiï interpreter Pythona, by je wykonaÊ. Gdy wysïaïem pierwszÈ napisanÈ wiadomoĂÊ, byïo to równoznaczne z otrzymaniem jej w formie kolejnego ĝÈdania przez tÚ platformÚ. Gïówny komputer App Engine roz- poznaï, ĝe na jednym z serwerów jest obecnie wïÈczony interpreter Pythona, który obsïuĝyï wïaĂnie ĝÈdanie tej samej aplikacji i w tej chwili nie jest zajÚty — z tego powodu przesïaï je do niego. Niestety, gdy odszedïem od monitora na kwadrans, w pewnym momencie jedna z usïug App Engine wykryïa, ĝe interpreter Pythona, który uruchomiï mój czat, byï za dïugo w stanie oczekiwania, wiÚc go wyïÈczyï. Dlatego teĝ kolejna wysïana przez mnie wiadomoĂÊ, miast zostaÊ przetworzona przez starszÈ instancjÚ, uruchomiïa nowÈ. Problem ten trzeba obejĂÊ. Z tego wzglÚdu w przyszïoĂci, budujÈc nasze aplikacje, bÚdziemy musieli wyraziÊ jasno, w jaki sposób chcemy zarzÈdzaÊ danymi wspóï- dzielonymi przez róĝne ĝÈdania. Nie moĝemy polegaÊ na zmiennych w moduïach i klasach. Musimy wyraěnie okreĂliÊ, kiedy chcemy, by nasze informacje zostaïy zapisane i kiedy mamy je odczytaÊ. Pïynie z tego prosta lekcja — zwyczajne metody przechowywania danych nie majÈ w chmurze zastosowania. Na szczÚĂcie, webapp oferuje caïkiem niezïÈ, trwaïÈ usïugÚ znanÈ jako Datastore. Porozmawiamy o niej w nastÚpnym rozdziale. CzÚĂÊ II • Python i Google App Engine — programowanie aplikacji 54  ½ródïa Dokumentacja RFC 2616: Hypertext Transfer Protocol — HTTP/1.1… http://www.w3.org/Protocols/rfc2616/rfc2616.html Opracowane przez konsorcjum W3C informacje o standardzie protokoïu HTTP. Artykuï Wikipedii poĂwiÚcony HTTP http://pl.wikipedia.org/wiki/Hypertext_Transfer_Protocol ZwiÚzïy, dokïadny opis protokoïu HTTP. Django http://www.djangoproject.com Django jest powszechnie stosowanÈ platformÈ deweloperskÈ — jednym z frameworków Google App Engine. Niektóre mechanizmy App Engine zapoĝyczyïy z niej wiele rozwiÈzañ. Django Nonrel http://www.allbuttonspressed.com/projects/django-nonrel Django Norrel to wariant frameworka Django, który uïatwia pracÚ z plat- formami nieopartymi o relacyjne bazy danych. Skorowidz @SuppressWarnings, 160 200 OK, 48 301 Moved permanently, 48 303 See other, 48 401 Unauthorized, 48 403 Forbidden, 48 404 Not found, 48 500 Internal Server Error, 48 A Admin Logs, 297, 299 adres URL ĝÈdania, 269 AIM, 252 AJAX, 115, 122 Amazon EC2, 17 Amazon S3, 18 app.css, 112 app.yaml, 28, 31, 51, 89, 112, 254, 278, 287 application, 29 runtime, 29 version, 29 appcfg.py, 26 update, 51 app-engine-patch, 305 appengine-web.xml, 254, 255 Application Setting, 297 Application Title, 298 ArrayList, 153 asynchroniczne przesyïanie, 144 Asynchronous JavaScript and XML (AJAX), 115 ataki hakerów, 284 bezpoĂrednie, 284, 285 cross-site scripting (XSS), 284, 286 DoS, 285, 287 podsïuchujÈce, 284 Atomic, Consistent, Isolated, Durable state (ACID), 240 auto_now_add, 61 B Backend usage, 294 Basically Available, Soft State, with Eventual consistency (BASE), 240 biblioteka, 245 Bigtable, 230 Billing History, 299 Billing Settings, 299 binary large object, 224 BlobProper, 224 Blogger, 12 BooleanProperty, 224 button, 165 ByteStringProperty, 224 C callback, 122 Cascading Style Sheets (CSS), 94 CategoryProperty, 226 ChatMessage, 60, 63, 73 ChatRoomCounted, 88 ChatRoomCountViewPage, 64 ChatRoomPage, 71, 80 chmura, 57 308  Google App Engine. Kod w chmurze chmura obliczeniowa, 11 ciaïo, 46 wiadomoĂci, 270 Classless Inter-Domain Routing (CIDR), 288 cloud computing, 11 code augmentation, 153 Common Gateway Interface (CGI), 26 Configured Services, 298 container widgets, 165 continuation passing style (CPS), 172 Cookie Expiration, 298 CPU Time, 294 cron, 263 cron.xml, 263, 264 CSS, 94 border, 110 clear, 110 color, 110 float, 110 padding, 110 background-color, 96 border, 105 dashed, 105 dotted, 105 double, 105 float, 103 grooved, 105 inset, 105 margin, 105 outset, 105 padding, 105 position, 106 ridge, 105 sans-serif, 97 solid, 105 text-decoration, 96 D dashboard, 34, 198, 291 Datastore, 230, 295, 304 admin, 280 choices, 280 GetUserRole, 280 Index Error, 280 privileged, 280 role, 280 StringPropert, 280 StringProperty, 280 UserRole, 280 Users, 280 Datastore Indexes, 295 Datastore Statistics, 295 Datastore Viewer, 295 Datastore wysokiej replikacji, 304 DateProperty, 224 DateTimeProperty, 224 datownik, 60 db.Model, 60, 61 db.StringProperty, 61 db.TextProperty, 61 deltatime, 85 Denial of Service (DoS), 285 Deploy to App Engine, 197 Details, 294 dev_appserver, 53 dev_appserver.py, 26, 29, 30, 51 DialogBox, 142 Disable Application, 298 Disable or Delete Application, 298 Disable/Re-Enable Datastore Writes, 298 Django, 70, 304 djangoappengine, 305 Document Object Model (DOM), 115 Domain Setup, 298 dos.yaml, 288 drop down, 165 dziedziczenie szablonów, 83 E Eclipse, 132, 150, 198 ekran logów, 36 Elastic Computing Cloud, 17 elastycznoĂÊ, 95 email(), 71 EmailProperty, 226 engine, 26 Estimated Time of Arival (ETA), 270 extends, 84 eXtensible Messaging and Presence Protocol (XMPP), 252 F FilesystemResourceHandler.get, 251 filtr ucieczki using | escape, 79 filtry relacyjne, 232 Skorowidz filtry równoĂci, 232 flexibility, 95 FloatProperty, 225 G Gadu-Gadu, 252 GeoPtProperty, 226 get_current_user(), 71 Go, 304 Google App Engine, 11, 58, 69 Application Identifier, 24 Application Title, 25 Authentication Options, 25 Billing Status, 293 Check Availability, 24 Create an Application, 23 Instances, 293 konfiguracja Ărodowiska programistycznego, 23 panel sterowania, 26, 33, 35 Resources, 34, 294 Settings, 294 Terms of Service, 25 uruchamianie programu, 26 zakïadanie konta, 21 Google Checkout, 299 Google MapReduce, 305 Google Storage, 304 Google Talk, 252 Google Web Toolkit (GWT), 131 GQL, 59, 62 Graphic User Interface (GUI), 119 grupy encji, 237 GWT, 178 H handler, 32 handler ĝÈdañ cron, 264 harmonogram cron, 266 HashSet, 153 hashtable, 245 header(), 270 High Replication Data, 294 High-replication Datastore, 304 HTML, 77 httplib, 251 Hypertext Transfer Protocol (HTTP), 44  309 I IBM Computing on Demand, 19 identity type, 152 IdentityType.APPLICATION, 152 IMProperty, 226 InboundEmailMessage, 258, 259 InboundMailHandler, 258 Incoming Bandwidth, Outgoing Bandwidth, 294 indeksy równoĂci, 232 index.yaml, 229 IntegerProperty, 225 Integrated Development Environment (IDE), 23 IsSerializable, 188 J Java ChatMessage, 150 Java Data Objects (JDO), 150 Java Virtual Machine (JVM), 132 java.net.URLConnection, 251 JavaScript, 115 javax.mail, 257 JDOQL, 157 order by, 159 parameters, 159 select, 158 where, 159 jÚzyki dynamiczne, 133 jÚzyki statyczne, 133 K kaskadowe arkusze stylów, 94 Key, 225 klasa ChatMessage, 60 db.DateTimeProperty, 61 db.Model, 60, 61 db.StringProperty, 61 klient, 44 klucz, 44 kody stanu HTTP, 48 200 OK, 48 301 Moved permanently, 48 303 See other, 48 401 Unauthorized, 48 403 Forbidden, 48 310  Google App Engine. Kod w chmurze kody stanu HTTP 404 Not found, 48 500 Internal Server Error, 48 501 Not implemented, 48 komponenty, 165 szkieletowe, 165 kontrolki, 165 kontynuacyjny styl programowania, 172 L LinkedList, 153 LinkProperty, 226 ListProperty, 225 listy rozwijane, 165 Logs with minimum severity, 36 M master.html, 84, 90 master-slave, 304 Memcache, 246 message, 61 metadanych, 134 metoda close(), 155 db.create_rpc, 241 email(), 71 equals(), 153 FilesystemResourceHandler.get, 251 GET, 45 get, 50, 64 getChats, 195 getObjectById, 157 HEAD, 45 header(), 270 initializeChats, 195 IsDir, 217 nickname(), 70 o.put(), 155 param(), 269 payload(), 270 POST, 45 post, 50 put(), 86 PUT, 45 SetAttribute, 216 user_id(), 71 xmpp.get_resence, 253 PersistenceManager.makePersistent(o), 155 put(), 62 url(), 269 Microsoft Azure, 19 moc obliczeniowa, 22 model ekspando, 60 model expando, 236 modele spójnoĂci, 239 Model-View-Controller (MVC), 115 monitorowanie, 291 MSN, 252 MSN Chat, 252 MVC, 115 Kontroler, 119 Model, 119 Widok, 119 N name, 272 nazwa zadania, 269 Network Time Protocol (NTP), 191 nickname(), 70 O obiekt RPC, 241 obiekt uĝytkownika, 70 obiekty modelu dokumentu, 116 oczekiwany czas wykonania zadania, 270 odseparowanie zagadnieñ, 95 ograniczenia opïywania, 103 P pagecontent, 86 param(), 269 parametry CGI, 269 parametry nagïówków, 270 payload(), 270 PChatMessage, 235, 295 PChatRoom, 295 Permissions, 297, 298 persistence key, 183 PersistenceManager, 154 PersistenceManagerFactory, 154 PhoneNumberProperty, 226 platformy chmurowe, 58 podelementy XML, 263 Skorowidz  311 description , 263 schedule , 263 url , 263 pola tekstowe, 165 polimodel, 235, 236 ponowne uĝycie, 95 POST, 50 PostalAddressProperty, 226 postMessage, 297 programowanie funkcyjne, 57 protokóï, 44 przepeïnienie bufora, 279 przyciski, 165 opcji, 165 put(), 62 Python, 27 queue.xml, 272 Q R radio button, 165 rate, 272 RatingProperty, 226 read_policy, 241 Recepients Emailed, 294 Re-enable application now, 298 ReferenceProperty, 225 remote procedure call (RPC), 135, 143 Representative State Transfer (REST), 205 RequestHandler, 32, 50, 258 required=true, 60 ResourceAttribute, 234 reusablity, 95 równoĂÊ obiektów, 232 run_wsgi_app, 33 S samoczynne wykrywanie inicjalizacji, 195 SDK Pythona, 25 Secure Socket Layer (SSL), 284 security-level, 234 selektor, 96 SelfReferenceProperty, 225 Separation of Concerns (SoC), 95 serwer, 44 serwlet, 265 Simple Storage Service, 18 Software Development Kit (SDK), 21 SQL Injection, 286 SSL, 305 Stack, 153 Stored Data, 294 StringProperty, 225 system szablonów, 31 szablony, 76 szeregowanie, 232 T tablicy rozdzielcza, 291 task queues, 266 template processors, 31 template.renderer, 80 templates, 76 text box, 165 TextProperty, 225 time, 61 TimeProperty, 224 timestamp, 60, 61 total-storage-limit, 272 transakcje, 155 TreeSet, 153 trwaïa przestrzeñ przechowywania, 56 typ danych date, 60 number, 60 reference, 60 string, 60 typ toĝsamoĂci, 152 typ ĝÈdania, 269 typy elementarne, 224 U Universal Resource Locator (URL), 44 urllib, 251 urllib2, 251 user, 60 user_id(), 71 user-agent header, 46 usïuga, 70, 245 Users, 70 usuwanie typów, 159 312  Google App Engine. Kod w chmurze V Vector, 153 Versions, 297, 299 VerticalPanel, 142 W warstwa administracyjna, 276 web.xml, 256, 266 webapp, 27, 31, 51, 53, 69, 76 WebDAV, 204 webhooks, 253 widgety, 165 wiersz stanu, 46 WSGIApplication, 89 wxWindows, 245 wzmocnienie kodu, 153 wzorzec REST, 205 X X-App Engine-QueueName, 270 X-App Engine-TaskName, 270 X-Appengine-TaskRetryCount, 271 XMLHttpRequest, 122, 123 Yahoo, 252 Y Z zdalne wywoïania procedur, 143 znacznik extends, 84 servlet, 256 servlet-mapping, 256 showmessage, 85 zïoĝony, 78 ¿ ĝÈdania POST, 50
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Google App Engine. Kod w chmurze
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: