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. [phone]
e-mail: [e-mail]
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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 u2ytkowników ................................................... 69
5.2. Us(uga Users — obs(uga u2ytkowników .................................................... 70
5.3. Integrujemy obs(ug& u2ytkownikó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ó2nych widoków przy u2yciu 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(ywaj7cy ........................................ 108
7.5. Za(7czanie 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 Jav7 i GWT — pocz7tki ............................................................ 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*9 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Spis tre"ci

!

7

Rozdzia& 11. Konstruowanie interfejsów u(ytkownika w Javie .... 163

11.1. Czemu GWT? .................................................................................... 163
11.2. Konstruowanie interfejsu u2ytkownika w GWT ..................................... 165
11.3. O2ywianie interfejsu — obs(uga zdarze: ............................................... 171
11.4. O2ywianie 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 u2yciu 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. Zarz7dzanie w(asn7 aplikacj7 ................................................................ 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

39

Rozdzia& 3.

Pierwsza prawdziwa
aplikacja w chmurze

tym rozdziale zbudujemy nasz7 pierwsz7, bardziej z(o2on7 aplikacj&

w Pythonie — pokój czatu. W trakcie pracy spróbujemy odpowiedzie9

na nast&puj7ce pytania:

W jaki sposób aplikacje w chmurze korzystaj7 z protoko(u HTTP i jak si&

komunikuj7?

Jak mo2na zintegrowa9 zwyk(y program napisany w Pythonie z protoko(em

HTTP tak, by dzia(a( w chmurze?

Czym ró2ni si& zarz7dzanie danymi i zmiennymi w chmurze od tradycyj-

nych technik?

3.1. Podstawowa aplikacja czatu

Jak ju2 wspomnia(em, w tym rozdziale b&dziemy pracowa9 nad us(ug7 czatu napi-

san7 w Pythonie. S7dz&, 2e jest to dobry przyk(ad, cho9by z uwagi na to, 2e ka2dy

z nas kiedy* korzysta( z takiej aplikacji. Cho9 ten rodzaj us(ug upowszechni( si&

dawno temu, posiada wiele cech charakterystycznych dla programu w chmurze.
Przetwarzanie w chmurze jest wyj7tkowe i intryguj7ce dlatego, i2 w praktyce wszyst-

kie utworzone w niej programy s7 przeznaczone dla wielu u2ytkowników. Naprawd&

w tym *rodowisku nie da si& skonstruowa9 dobrej aplikacji bez wzi&cia pod uwag&

metod zarz7dzania danymi dla du2ej liczby klientów.

W

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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-

rzy9 t& us(ug&, musimy rozwa2y9 wszystkie formy interakcji mi&dzy u2ytkownikami,

a tak2e sposoby przechowywania i odzyskiwania trwa(ych danych. Musimy te2

zaimplementowa9 wiele kana(ów dla ró2nych dyskusji. Dzi&ki mo2liwo*ciom App

Engine, budowa podstawowej wersji takiego programu i stopniowe dodawanie

nowych funkcji jest spraw7 prost7.
Zignorujemy na razie kwesti& interfejsu u2ytkownika (zajmiemy si& nim w roz-

dziale 7., „Poprawianie wygl7du 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ór7 póLniej po(7czymy

z interfejsem. Nie zrobimy tego wszystkiego w jednym rozdziale. Przejdziemy przez

kolejne etapy kreowania programu, krok po kroku, tak by* pod koniec tej ksi72ki

móg( sam napisa9 omówiony tu kod.
Podstawowa aplikacja czatu nie jest skomplikowana — wystarczy j7 sobie wyobrazi9.

Interfejs u2ytkownika czatu jest zwykle do*9 prosty — powinien zawiera9 dwa pola —

jedno, wy*wietlaj7ce transkrypcj& rozmowy i drugie, do wpisywania tekstu. W polu

transkrypcji powinny znaleL9 si& — u(o2one w chronologicznej kolejno*ci — wszystkie

wiadomo*ci wys(ane do czatu, ka2da oznaczona nazw7 u2ytkownika i czasem nadania.

Podstawowy interfejs programu winien wygl7da9 podobnie do szkieletu z rysunku 3.1.

Rysunek 3.1.

Szkic interfejsu u0ytkownika

Teraz, gdy orientujemy si&, jak interfejs powinien wygl7da9, mo2emy przej*9 do

fazy planowania jego budowy. Nim jednak zaczniemy si& zastanawia9, jak zaprojek-

towa9 nasz7 aplikacj& w chmurze, przeanalizujmy, jak wygl7da 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

interesuj7ce nas funkcje; na razie nie dodamy nawet jednej linijki kodu typowego

dla App Engine.

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

41

Czego zatem potrzebujemy? Patrz7c na pole rozmów, mo2emy doj*9 do wniosku, 2e

ka2dy czat tworzy wirtualn7 przestrze:, któr7 u2ytkownicy mog7 odwiedza9 i opusz-

cza9. Po wej*ciu na czat ka2dy z nich mo2e wys(a9 wiadomo*9. Wszystkie wcze-

*niej wys(ane wiadomo*ci b&d7 od razu widoczne dla ka2dej nowo przyby(ej osoby.

Z powy2szej analizy wynika, 2e powinni*my wzi79 pod uwag& trzy podstawowe

obszary: przestrze: wirtualn7, u2ytkowników oraz wiadomo*ci.
Chcemy, by w naszej przestrzeni u2ytkownicy mieli dost&p do wielu tematów kon-

wersacji, 2eby mogli sami zdecydowa9, z kim chc7 rozmawia9 i o czym. Przestrze:

wyznaczon7 dla jednego tematu nazwiemy pokojem. W ka2dym pokoju mo2e

doj*9 do trzech wydarze: — kto* mo2e do niego wkroczy9, kto* mo2e go opu*ci9

i kto* mo2e wys(a9 w nim wiadomo*9. By ca(7 rzecz troch& upro*ci9, powiedzmy,

2e zamiast uaktualnia9 wpis za ka2dym razem, gdy jaka* osoba wy*le wiadomo*9,

ka2dy u2ytkownik musi sam za27da9 transkrypcji wiadomo*ci raz na jaki* czas.

Przyk(adow7 implementacj& naszego pokoju mo2esz zobaczy9 poni2ej. Nie ma ona

nic wspólnego z aplikacj7 chmurow7. Programy tworzone w chmurze zachowuj7

si& w zupe(nie inny sposób i dlatego musz7 by9 inaczej pisane. Dalej w ksi72ce

b&dziemy budowa9 program w App Engine, który b&dzie w stanie wykona9 to samo,

co ten, który zaprezentowano poni2ej, ale w chmurze danych. Przyjrzyjmy si&,

w czym dok(adnie tkwi podstawowa ró2nica.

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)

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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(ugiwa9 pewn7 grup& u2ytkowników. Ka2dy u2ytkownik

ma przypisane imi& i jest zalogowany w pewnej grupie pokoi. U2ytkownik mo2e

wej*9 do pokoju, opu*ci9 go lub wys(a9 wiadomo*9. Je*li dana osoba nie wesz(a do

konkretnego pokoju, nie ma prawa wys(a9 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

u2ytkownika. Pojedyncza wiadomo*9 musi zawiera9 odwo(anie do osoby, która j7

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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 sprawdLmy, czy nasz program w ogóle dzia(a i jak si&

prezentuje. Utwórzmy w kodzie kilku u2ytkownikó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&puj7c7 tre*9:

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 s7 stanowczo zbyt

rozwlek(e, a tekst przyda(oby si& lepiej sformatowa9, by by( bardziej czytelny, lecz

przynajmniej uda(o si& nam zapewni9 wszystkie podstawowe komponenty ka2dego

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 rozs7dne, przynajmniej dla tradycyjnych aplikacji. Gdy

jednak projektujesz programy w chmurze, musisz wykona9 jeden dodatkowy krok.

W zwyk(ych programach tego typu nale2y rozplanowa9 logik& przetwarzania danych

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

44

Cz,"- II • Python i Google App Engine — programowanie aplikacji

oraz interfejs u2ytkownika. Naturalnie, równie2 przy programowaniu aplikacji

w chmurze musisz wzi79 te czynniki pod uwag&, ale dodatkowo trzeba te2 dla niej

utworzy9 protokó&.
Ka2de zaplecze programu chmurowego dzia(a na pojedynczym serwerze b7dL ich

skupisku w jakim* centrum danych. Z kolei interfejs u2ytkownika jest uruchamiany

w przegl7darce internetowej. Podstawow7 funkcj7 protoko(u jest zapewnienie komu-

nikacji mi&dzy nimi, przez co program sprawia wra2enie, jakby w ca(o*ci dzia(a( na

komputerze klienta.
Wi&kszo*9 aplikacji dzia(aj7cych 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, i2 nim zaczniesz pisa9 w(asn7 aplikacj&, musisz

wpierw zaprojektowa9 protokó( „nawarstwiony” na HTTP. W tym kontek*cie s(owo

„nawarstwianie” oznacza, 2e Twój protokó( powinien by9 zbudowany tak, by ka2d7

interakcj& zachodz7c7 w programie mo2na by(o zapisa9 w odniesieniu do HTTP.

To w(a*nie stanowi jeden z g(ównych czynników wyró2niaj7cych programowanie

w chmurze w*ród innych jego form — aplikacje chmurowe bazuj7 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 u2yciu aplikacji. Prawd7 jest, 2e szczególnie wtedy, je*li nie

jeste* przyzwyczajony do pracy z HTTP, protokó( mo2e Ci si& wyda9 troch& sier-

mi&2ny i nieprzyst&pny, lecz — jak si& póLniej przekonasz — mo2na z jego pomoc7

tworzy9 bogate formy interakcji.
By9 mo2e wiesz ju2 co nieco o tym protokole. Warto jednak po*wi&ci9 chwil& na

krótkie przypomnienie, gdy2 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 27da: i odpowiedzi typu klient-serwer. Innymi

s(owy, to w(a*nie dzi&ki niemu dowolne dwie strony mog7 si& ze sob7 komunikowa9.

Jedn7 z nich nazywamy klientem, drug7 — serwerem. Ka2da z tych stron pe(ni

inne funkcje. W protokole HTTP klient inicjalizuje komunikacj&, wysy(aj7c 27da-

nia na serwer; z kolei serwer przetwarza te 27dania i wysy(a z powrotem odpowiedzi

dla klienta. Protokó( HTTP zajmuje si& opisywaniem sposobu, w jaki klient wysy(a

27dania i otrzymuje odpowiedzi.
Oeby upro*ci9 ca(y proces, ka2de 27danie jest wycentrowane na zasobach. W tym

kontek*cie zasobem jest wszystko to, czemu przyznano w sieci nazw&. Do ka2dego

zasobu odnosimy si& za pomoc7 ujednoliconego formatu adresowania zasobów

URL (ang. Universal Resource Locator). Adres URL pe(ni funkcj& podobn7 do

*cie2ki do pliku, lecz mo2na si& w nim odnie*9 do wielu rzeczy — plików, ca(ych

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

45

programów, ludzi, procesów i do wszystkiego, co tylko sobie wyobrazisz. Ka2de

zapytanie na serwerze jest w istocie pro*b7 o otrzymanie potrzebnych danych lub

o mo2liwo*9 ich przes(ania do zasobu.
Co wi&cej, ka2de 27danie HTTP od strony klienta wywo(uje konkretn7 metod, po

stronie serwera. (Jest to troch& myl7ce, ale wbrew przyj&temu nazewnictwu „metody”

stosowane w tym przypadku nie maj7 nic wspólnego z „metodami” u2ywanymi

w programowaniu obiektowym). W HTTP wyró2niamy cztery podstawowe metody

(oraz ponad tuzin rozszerze:, których jednak nie b&d& omawia(, poniewa2 nie przy-

dadz7 si& w naszej aplikacji).

GET

Wysy(a na serwer pro*b& o mo2liwo*9 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 2e otrzymana odpowiedL zawiera je-

dynie metadane. Przyk(adowo móg(by* skorzysta9 z tego 27dania, by zada9

pytanie: „Jak wielki jest ten zasób”, bez potrzeby przesy(ania go w ca(o-

*ci. Co prawda, niewiele aplikacji u2ywa metody

HEAD

, lecz z pewno*ci7 jest

czasem przydatna.

PUT

Przechowuje dane w okre*lonym zasobie. Dzia(anie tej metody polega na

przes(aniu informacji na serwer, by zachowa9 j7 w zdefiniowanej przestrzeni.

W odpowiedzi serwer wysy(a informacj& zwrotn7, czy interesuj7ce dane uda(o

si& zapisa9.

POST

Przesy(a dane do dzia(aj7cego na serwerze programu. O7dania typu

POST

s7 troch& dziwne. Pozornie ró2nica 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 27dania typu

GET

i

PUT

by(y

interpretowane jako pro*by o przes(anie lub przechowanie danych. Dlatego

te2, aby uruchomi9 program na serwerze, potrzebna by(a oddzielna metoda,

która prosi(aby o jego inicjalizacj&. Jednak w nowoczesnych systemach zarówno

27da:

PUT

, jak i

POST

u2ywa si& zamiennie.

Ka2de 27danie HTML, czy to wygenerowane przez Twoj7 przegl7dark&, czy prze-

tworzone przez App Engine, sk(ada si& z trzech cz&*ci. Oto one.

Linia 27dania, z(o2ona z metody HTTP, po której wyst&puje adres URL

zasobu i, kolejno, specyfikacja wersji protoko(u. W wi&kszo*ci przypadków

Twoja przegl7darka wysy(a 27dania typu

GET

, w wersji specyfikacji

HTTP/1.1

.

Sekwencje linijek nag&ówków zawieraj7cych metadane o 27daniu (takie

jak specyfikacja zawarto*ci —

Content-Type

— z której korzystali*my

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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*9 27da: przegl7darek

b&dzie podawa9 swoj7 wersj& (w tzw. nag(ówku u2ytkownika — ang.
user-agent header) i jaki* identyfikator (nag(ówek From:). Ponadto na

nag(ówki mog7 sk(ada9 si& odniesienia do plików cookie, identyfikatory

j&zykowe, adresy sieciowe itp. Wewn7trz nag(ówka mo2e si& znaleL9

wszystko, bowiem serwery i tak po prostu ignoruj7 zawarto*9 tych, których

nie s7 w stanie rozpozna9.

Cia(o (ang. body) dokumentu sk(adaj7ce si& z dowolnego potoku danych.

Cia(o i nag(ówki s7 od siebie odseparowane pust7 lini7 — bez jakiejkolwiek tre*ci.

Ogólnie rzecz bior7c, cia(o 27da: typu

GET

i

HEAD

jest puste. Spójrz na poni2sze przy-

k(adowe 27danie

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 27dania HTML na serwer odpowiada on podobnie skonstruowan7

wiadomo*ci7. Ró2nica polega na tym, 2e zamiast linii 27dania serwer otwiera swoj7

odpowiedL tzw. wierszem stanu. Rozpoczyna si& on od kodu stanu i wiadomo-

*ci stanu, gdzie zawarte s7 informacje, czy 27danie zosta(o wykonane, a je*li nie, to

z jakiego powodu. Typowy wiersz stanu generowany przez us(ug& w chmurze ma

posta9

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*ci7.

Kod stanu zawsze sk(ada si& z trzech cyfr. Pierwsza z nich ustala ogólny rodzaj

odpowiedzi. I tak:

1

oznacza „odpowiedL informuj7c7”.

2

oznacza pomy*lne zako:czenie 27dania.

3

oznacza przekierowanie — klient otrzymuje wiadomo*9 o po(o2eniu danego

zasobu w innym miejscu. Proces przekierowania mo2na by adekwatnie pod-

sumowa9 zdaniem: „Nie ma tu poszukiwanej przez Ciebie informacji,

ale znajdziesz j7 pod nast&puj7cym adresem URL”.

4

wskazuje na b(7d po stronie klienta (np. kod

404

oznacza, 2e klient domaga

si& dost&pu do zasobu nieistniej7cego w danym miejscu na serwerze).

5

wskazuje na b(7d po stronie serwera (np. gdy uruchomiony na nim program

wykona nieprawid(ow7 operacj&).

Oto przyk(adowa odpowiedL serwera na przedstawione powy2ej 27danie

GET

:

HTTP/1.1 200 OK
Date: Sat, 26 Jun 2009 21:41:13 GMT
Content-Type: text/html Content-Length: 123

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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& 27danie-odpowiedL. Za(ó2my, 2e do wysy(ania

wiadomo*ci w naszym czacie wykorzystujemy metod&

POST

. Wtedy nasze zapytanie

mog(oby wygl7da9 nast&puj7co:

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: [e-mail]

<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&puj7c7 wiadomo*9:

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 zmapowa9 podstawowe wykonywane przez ni7 ope-

racje na 27dania i odpowiedzi HTTP.
W wersji, nad któr7 b&dziemy pracowa9, pominiemy kwesti& rejestracji — utwo-

rzymy jedynie pojedynczy pokój i je*li uda si& z nim po(7czy9, automatycznie poja-

wimy si& w nim. W tej chwili nie musimy si& przejmowa9 u2ytkownikami nowymi

i opuszczaj7cymi pokój.
WyobraL sobie, 2e korzystasz z pokoju. Co chcia(by* w nim robi9?
Po pierwsze, przyda(oby si& zobaczy9 nowe wiadomo*ci w naszym pokoju. Prze-

k(adaj7c to na zasad& dzia(ania protoko(u HTTP, pokój naszego czatu jest zasobem,

którego zawarto*9 chcesz zobaczy9. Oczywi*cie, do tego celu *wietnie si& nada

metoda

GET

, która pomo2e pobra9 zawarto*9 czatu i j7 wy*wietli9.

Chcemy te2 mie9 mo2liwo*9 wysy(ania wiadomo*ci, wobec czego b&dziemy potrze-

bowa9 sposobu na zakomunikowanie naszemu programowi przez przegl7dark&,

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 0Edanie. Cia=o wiadomo@ci zwrot-
nej na ogó= zawiera 0Edane dane.

301 Moved permanently

(zasób przeniesiono na sta0e)

HEdany zasób nie znajduje si; ju0 pod okre@lonym adresem URL i ka0da
nowa pro@ba o jego udost;pnienie powinna byL przes=ana pod nowy
adres.

303 See other

(znajdziesz w innym miejscu)

HEdane zasoby znajdujE si; w innym miejscu i mogE byL odzyskane za
pomocE metody

GET

, wys=anej pod inny adres URL. Adres ten winien

byL zawarty w nag=ówku po=o0enia wiadomo@ci zwrotnej. Rzeczony
kod pojawia si; cz;sto w odpowiedzi na 0Edania typu

PUT

— po tym,

jak zapytanie to zosta=o pomy@lnie przetworzone, serwer informuje
klienta, gdzie mo0e szukaL potrzebnych zasobów bezpo@rednio.

401 Unauthorized

(brak uwierzytelnienia)

Samo 0Edanie by=o poprawne, lecz nie zawiera=o danych uwierzytel-
niajEcych, które sE wymagane w celu otrzymania dost;pu do zasobu.
U0ytkownik mo0e wykorzystaL inne zapytania, by zdobyL niezb;dne
informacje i ponowiL to 0Edanie.

403 Forbidden

(dost8p zabroniony)

HEdanie by=o sformu=owane poprawnie, lecz dost;p do zasobów zosta=
zabroniony. Kod ten dzia=a tak samo jak kod

401

, z tE ró0nicE, 0e albo

nawet po uwierzytelnieniu dany u0ytkownik nie ma dost;pu do zasobów,
albo dost;p dla wszystkich uwierzytelnionych u0ytkowników jest
wzbroniony.

404 Not found

(nie odnaleziono)

HEdanego zasobu nie odnaleziono w okre@lonej lokacji sieciowej.

500 Internal Server Error

(wewn8trzny b09d serwera)

Ka0dy b=Ed 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=owE operacj;, przeglEdarka 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=Ed np. w nazwie
adresu URL 0Edania

POST

.

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

49

2eby zamie*ci( wpisan7 przez nas w aktywnym polu wiadomo*9. I znów nasz pokój

czatu jest zasobem, ale w tym wypadku masz w nim umie*ci9 tre*9. Wobec tego,

do wykonania zadania musimy u2y9 metody

PUT

lub

POST

. Decyzja, z której skorzy-

stamy, zale2y od tego, czy chcemy zast7pi9 zawarto*9 zasobu, czy po prostu wys(a9

tam komunikat. Naturalnie wysy(anie wiadomo*ci mie*ci si& bardziej w tej drugiej

definicji. Nie chcemy zast7pi9 wiadomo*ci w naszym pokoju, chcemy natomiast

przekaza9 do naszej aplikacji informacj&, 2e ma wy*wietli9 now7 wiadomo*9. Dlatego

te2 u2yjemy 27dania

POST

.

W ten sposób zdefiniowali*my struktur&, na podstawie której zbudujemy program.

Naszym jedynym zasobem b&dzie pokój czatu. U2ytkownicy b&d7 mogli pobra9

zawarto*9 tego zasobu za pomoc7 zapytania

GET

i wtedy zapoznaj7 si& z jego zawar-

to*ci7. Potrzebujemy innego zasobu — aktywnego procesu, do którego osoby b&d7

wysy(a9 27dania

POST

, by umie*ci9 wiadomo*ci na czacie.

Teraz musimy rozwa2y9 implementacj& elementarnego interfejsu u2ytkownika.

W jaki sposób u2ytkownik b&dzie dodawa( dane do naszej aplikacji? Jasne jest, 2e

trzeba b&dzie zapewni9 tak7 mo2liwo*9. Najpro*ciej utworzy9 na stronie formu-

larz, który zostanie wype(niony zawarto*ci7 po ka2dym logowaniu u2ytkownika do

pokoju. Strona czatu ma si& wi&c sk(ada9 z tytu(u na górze, obszaru rozmów, w któ-

rym wy*wietlane b&d7 kolejne wiadomo*ci, oraz pola wpisów z przypisan7 nazw7

u2ytkownika, gdzie ka2da osoba b&dzie mog(a doda9 swoj7 tre*9.
Aby uruchomi9 powy2sz7 aplikacj& w App Engine, b&dziemy musieli utworzy9

(na podstawie klasy

RequestHandler

) dwa handlery 27da: — jeden, który zaim-

plementuje metod&

GET

do odzyskiwania zawarto*ci pokoju z serwera, oraz drugi,

wykorzystuj7cy metod&

POST

, w celu dodania tre*ci do czatu.

Strona g(ówna naszego czatu b&dzie prezentowa9 si& podobnie do tej z rozdzia(u 2.,

„Pocz7tek”. Podstawowa ró2nica polega na tym, 2e dodamy do niej dynamiczne

elementy — wszystko to, co mo2e si& przyda9 do wy*wietlania i wysy(ania wiado-

mo*ci. Dlatego te2 nie mo2emy po prostu ponownie wykorzysta9 uprzednio zapre-

zentowanego kodu HTML; trzeba b&dzie troch& do niego dopisa9. W pierwszej

wersji czatu zadeklarujemy zmienn7 globaln7, 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)

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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>(Dok4adny 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 27dania

POST

jest dla nas czym* nowym, lecz dzi&ki frameworkowi webapp

czynno*9 ta jest prosta. W handlerze 27dania

GET

przes(aniamy metod&

get

klasy

bazowej

RequestHandler

. Analogicznie, dla 27dania

POST

nadpisujemy metod&

post

tej klasy. Klasa bazowa

RequestHandler

zapewnia to, 2e gdy metoda

post

zostaje

wywo(ana, pola utworzonego obiektu s7 wype(niane wszelkimi potrzebnymi danymi.

Je*li chcemy uzyska9 informacje z pól formularza, które wys(a(y 27danie

POST

,

wystarczy, 2e wywo(amy metod&

get

, korzystaj7c z etykiety wype(nionej w formu-

larzu. W naszym kodzie nazw& u2ytkownika i tre*9 wiadomo*ci otrzymamy bez-

po*rednio z 27dania

POST

. U2yjemy ich do utworzenia obiektu wiadomo*ci, który

dodamy do globalnej listy wszystkich wypowiedzi u2ytkownikó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( aplikacj2 na jej
# w+asny adres, aby j( od,wie%y-, co spowoduje wy,wietlenie nowej wiadomo,ci.
self.redirect('/')

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

51

Teraz wystarczy wszystko z(o2y9 w jeden program. Zrobimy to w dwóch etapach.

Na pocz7tek napiszemy fragment kodu, który spowoduje powstanie obiektu apli-

kacji i przerzuci wszelkie 27dania do naszych handlerów. Nast&pnie utworzymy

plik app.yaml. Dopiero wtedy b&dziemy mogli sprawdzi9, czy nasz program dzia(a.
Plik app.yaml ma prawie tak7 sam7 tre*9 jak poprzednio. Zmieni(em, co prawda,

nazw& pliku programu, wobec czego musimy równie2 zmieni9 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(kuj7c si& aplikacj7 dev_appserver.py, tak jak w poprzed-

nim rozdziale), naszym oczom uka2e si& prosty, acz funkcjonalny czat. Pora go

wypróbowa9. Dzia(a wy*mienicie! Teraz mo2emy go swobodnie przes(a9 na serwery

App Engine. Tak jak wcze*niej, robimy to za pomoc7 polecenia

appcfg.py update

.

Na rysunku 3.2 wida9 efekt pracy naszej aplikacji. Prezentuje si& ona dok(adnie tak,

jak na serwerze lokalnym. Wys(a(em z jej pomoc7 dwie wiadomo*ci, u2ywaj7c dwóch

ró2nych nazw u2ytkownika, i otrzyma(em przyzwoicie wygl7daj7c7 konwersacj&.
Musia(em jednak na chwil& odej*9 od komputera, by wyk7pa9 mego synka i u(o2y9

go do snu. Gdy wróci(em, wys(a(em kolejn7 wiadomo*9. Efekt mo2esz podziwia9

na rysunku 3.3.
Wszystkie dawne wiadomo*ci znikn&(y! Pole tre*ci nie zawiera 2adnych wiado-

mo*ci poza t7, któr7 w(a*nie wys(a(em. Nie napisali*my przecie2 w naszym skrypcie

nic, co mog(oby spowodowa9 wykasowanie wiadomo*ci. Nie mo2e robi9 nic poza

dodawaniem nowych. Co si& wi&c sta(o z tymi zaginionymi? Gdzie si& podzia(y?

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

52

Cz,"- II • Python i Google App Engine — programowanie aplikacji

Rysunek 3.2.

Aplikacja czatu w akcji

Rysunek 3.3.

Aplikacja czatu po d=u0szej przerwie

OdpowiedL brzmi — nigdzie. Dostali*my pstryczka w nos, gdy2 nie wzi&li*my pod

uwag& podstawowej ró2nicy mi&dzy aplikacj7 pisan7 w chmurze a tradycyjn7. Otó2,

pisz7c program bezpo*rednio dla serwera, jeste* *wiadom, 2e ka2de 27danie zosta-

nie przez niego obs(u2one. Zwykle, korzystaj7c z interpretera Pythona, wysy(amy

na serwer 27danie do przetworzenia i mamy pewno*9, 2e b&dzie aktywny przez

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Rozdzia% 3. • Pierwsza prawdziwa aplikacja w chmurze

!

53

ca(y czas. Gdy jednak wysy(asz 27danie na serwer w chmurze, jest ono przenoszone

na dowolny serwer w dowolnym centrum danych. Nie ma 2adnej gwarancji, 2e

dwa 27dania zostan7 przes(ane na ten sam serwer, czy nawet na serwer znajduj7cy

si& na tym samym kontynencie.
A je*li nawet jakim* cudem tak si& stanie, znów nie masz 2adnych gwarancji, 2e

serwer b&dzie przetwarza( kod Pythona przez ca(y ten czas. We frameworkach bazu-

j7cych na chmurze, takich jak webapp, wszelkie handlery 27da: s7 niezale2ne od

stanu, co oznacza, i2 raczej nie mo2esz liczy9 na to, 2e Twoje zmienne zostan7

zapami&tane. Musisz wi&c budowa9 swoje aplikacje tak, jakby ka2de nowe 27danie

by(o uruchamiane przez nowy interpreter Pythona.
Naprawd& mieli*my wielkie szcz&*cie, 2e nasza aplikacja w ogóle zadzia(a(a w chmu-

rze. Gdy uruchomimy j7 lokalnie, program dev_appserver korzysta wy(7cznie z jed-

nego interpretera, dlatego te2 aplikacja dzia(a bez zarzutu. Po za(adowaniu na

serwer App Engine jest program uruchamiany w chmurze. Po przes(aniu pierw-

szego 27dania losowy serwer uruchomi( interpreter Pythona, by je wykona9. Gdy

wys(a(em pierwsz7 napisan7 wiadomo*9, by(o to równoznaczne z otrzymaniem jej

w formie kolejnego 27dania przez t& platform&. G(ówny komputer App Engine roz-

pozna(, 2e na jednym z serwerów jest obecnie w(7czony interpreter Pythona, który

obs(u2y( w(a*nie 27danie 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, 2e interpreter Pythona, który uruchomi( mój czat, by(

za d(ugo w stanie oczekiwania, wi&c go wy(7czy(. Dlatego te2 kolejna wys(ana przez

mnie wiadomo*9, miast zosta9 przetworzona przez starsz7 instancj&, uruchomi(a

now7.
Problem ten trzeba obej*9. Z tego wzgl&du w przysz(o*ci, buduj7c nasze aplikacje,

b&dziemy musieli wyrazi9 jasno, w jaki sposób chcemy zarz7dza9 danymi wspó(-

dzielonymi przez ró2ne 27dania. Nie mo2emy polega9 na zmiennych w modu(ach

i klasach. Musimy wyraLnie okre*li9, kiedy chcemy, by nasze informacje zosta(y

zapisane i kiedy mamy je odczyta9.
P(ynie z tego prosta lekcja — zwyczajne metody przechowywania danych nie maj7

w chmurze zastosowania. Na szcz&*cie, webapp oferuje ca(kiem niez(7, trwa(7 us(ug&

znan7 jako Datastore. Porozmawiamy o niej w nast&pnym rozdziale.

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

54

Cz,"- II • Python i Google App Engine — programowanie aplikacji

2ród3a

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.

Artyku3 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 stosowan7 platform7 dewelopersk7 — jednym

z frameworków Google App Engine. Niektóre mechanizmy App Engine

zapo2yczy(y z niej wiele rozwi7za:.

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.

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 27dania, 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(uchuj7ce, 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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*9, 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Skorowidz

! 309

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 27da: 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

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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

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 u2ytkownika, 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Skorowidz

! 311

<description>, 263
<schedule>, 263
<url>, 263

pola tekstowe, 165
polimodel, 235, 236
ponowne u2ycie, 95
POST, 50
PostalAddressProperty, 226
postMessage, 297
programowanie funkcyjne, 57
protokó(, 44
przepe(nienie bufora, 279
przyciski, 165

opcji, 165

put(), 62
Python, 27

Q

queue.xml, 272

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*9 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 to2samo*ci, 152
typ 27dania, 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

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ

Czytaj dalej...

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

Y

Yahoo, 252

Z

zdalne wywo(ania procedur, 143
znacznik

extends, 84
servlet, 256
servlet-mapping, 256
showmessage, 85
z(o2ony, 78

R

27dania POST, 50

Kup ksiąĪkĊ

Pole

ü ksiąĪkĊ