Tag Archives: gae

Äventyr i molnet – del 3

Posted on by

Inledning

Nu när det finns en första "Hello, World"-version av Eats-o-matic i drift, är det dags att fundera på allvar på den vidare utvecklingen.

För att det skall bli något så behövs det bland annat möjlighet att lagra data, samt ett ramverk för att skapa själva webbapplikationen med.

Jag har kollat igenom ett antal av de alternativ som finns för GAE och kommit fram till ett val som jag tror passar mig som utvecklare och Eats-o-matic som applikation.

Persistens

Vi tar det enkla beslutet först, val av persistensmekanism.

GAE erbjuder två programmeringsgränssnitt för att lagra data: Java Data Objects (JDO ) och Java Persistence Architecture (JPA). (Egentligen finns det ett tredje, lågnivågränssnittet mot Googles egna Big Tables. Men detta tänker jag inte ens beakta, för då har man låst sig hårt mot GAE:s driftsmiljö, vilket bär mig emot.)

JDO är en ganska gammal och beprövad standard, medan JPA är tämligen färskt. Varför JDO inte har fått större spridning förstår jag faktiskt inte. Det passar utmärkt för en stor mängd av tillämpningar. Det är heller ingen brist på effektiva, billiga och stabila implementationer.

(Vissa elaka tungor i blogosfären säger att Sun tog fram JPA efter starka påtryckningar från de ledande RDBMS-leverantörerna, vars produkter inte fungerar så bra med JDO.)

JDO togs ursprungligen fram som ett standard-API för att lagra data i stort sett vilket medium som helst, medan JPA mer eller mindre förutsätter att datat skall lagras i en relationsdatabas.

I GAE så hamnar datat i bägge fallen i BigTable, som varken är en objektdatabas eller en relationsdatabas.

I GAE så används i bägge fallen DataNucleus som verktyg för att vid byggtillfället modifiera dina persistenta klasser så att de går att lagra. Så valet mellan JDO och JPA avgörs av vilket API som passar applikationen bäst.

Jag har jobbat en del med JPA och Hibernate och MySQL, vilket inte var helt friktionsfritt. Det märks att objekt inte är rader i en tabell, utom i det mest triviala fallet. (Jag har lusläst Hibernatedokumentationen flera gånger, och är fortfarande inte säker på att jag förstår allt som står där…)

Jag har även jobbat med db4o, vilket var betydligt mer rättframt. db4o och JDO har väldigt lika programmeringsmodeller.

Så jag satsar mina pengar på JDO.

Kombon JDO + DataNucleus är speciellt tilltalande, eftersom DataNucleus kan använda i stort sett vad som helst för att persistera JDO-objekt; db4o, SQL-databaser, XML-filer, Excel-filer och så vidare.

Detta betyder att jag kommer att kunna enhetstesta min persistenskod mot en lokal db4o-fil, utan att behöva dra igång vare sig en separat db4o-server eller GAE:s integrationtestmiljö. Detta betyder tidsbesparingar!

Som sagt, persistensen överlåter jag med varm hand åt JDO.

Webbramverk

Här är valet betydligt svårare.

Jag är en gammal anhängare av Tapestry, som är ett komponentorienterat ramverk i samma skola som t.ex. Wicket och JSF. Jag har jobbat med Tapestry mer eller mindre kontinuerligt sedan 2003 fram till den dag som idag är.

Tyvärr fungerar inte senaste versionen av Tapestry (5.1) i GAE på grund av Tapestry använder en XML-parser som inte finns med på GAE:s white list.

Wicket lär också ha en del problem i GAE. Jag har bara hört det ryktesvägen och vet inte exakt vad de består i och om de oöverstigliga. Men eftersom jag inte kan Wicket så vill jag inte både lära mig Wicket och ta strulet med att få det att funka i GAE.

JSF har jag stött på i ett projekt, och lärt mig att avsky. Maken till krångligt ramverk får man leta efter. (JSF 2 lär vara bättre, men det har jag inte provat. Jag är inte heller lockad att prova.)

Sedan finns det c:a 100 stycken MVC-ramverk; Spring MVC, Struts, Struts 2 osv. Men har man en gång jobbat med ett komponentramverk så vill man inte tillbaka. Det känns helt enkelt inte bra.

Så mitt val är egentligen ett blindval: jag väljer ett ramverk som garanterat fungerar i GAE och som är komponentorienterat, men som jag aldrig har jobbat med: Google Web Toolkit (GWT).

Att GWT fungerar i GAE tar jag för givet, eftersom bägge är skapade av Google.

Jag har kollegor på Crisp som brukar hylla GWT, och jag litar på dem. Dessutom har jag därmed support på nära håll!

Jag tror även att GWT kommer att passa bra eftersom jag vill att Eats-o-matic skall få ett användargränssnitt mer likt en traditionell applikation än en webbapplikation. Ni vet, drag-and-droptab completion och liknande. Kort sagt, en Rich Internet Application…

Och eftersom jag inte är någon Javascript-guru men kan Java rätt så bra, så hoppas jag på att GWT:s javascriptabstraktion inte läcker allt för mycket, utan håller vad den lovar.

Sammanfattningsvis
Persistens: JDO
Webbramverk: GWT

Äventyr i molnet – del 1

Posted on by

Inledning

Det är mycket prat om Cloud Computing nuförtiden. Amazon EC2, Google App Engine, SpringSource CloudFoundry, och nu snart Windows Azure.

Detta är första delen i en serie som beskriver utvecklingen av Eats-o-matic, som kommer att köras på Google App Engine (GAE).

Häng med!

Gör det mest riskfyllda först

En bra princip inom agil systemutveckling är ju att göra det mest riskfyllda först, och i fallet GAE är det naturligtvis att driftsätta sin applikation.

Det här med applikationer i molnet, funkar det verkligen?Har jag brutit mot någon av programmeringsreglerna? Hur hanterar jag applikationen när den väl är i drift? Finns det driftstatistik? Hur kommer man åt loggarna?

Så många frågor, snabbaste sättet att få svar är att testa!

Så jag registrerade ett GAE-konto och skapade applikations-ID:t “eats-o-matic”.

Sedan skrev jag en webbapplikation (host, host), som jag deployade inifrån Eclipse.

Deployförfarandet var löjligt enkelt. Jag klickade på det blåa planet på knappraden, Eclipse frågade efter min GMail-address, lösenord samt GAE-identitet på applikationen.

Så snart applikationen var uppladdad fanns den tillgänglig på https://eats-o-matic.appspot.com.

Så, då var det “svåraste” avklarat!

Om Eats-o-matic

Jag vill inte avslöja för mycket om applikationen i förväg, för då kommer du bara att sno min idé! Men jag kan säga så mycket som att det har med mat att göra.

Å nej, inte ännu en receptsajt!

Lugn, bara lugn. Du kommer att få se! (Se där, ännu en anledning att följa denna blogg…)

Versionshantering i Google App Engine

GAE gör det möjligt att ha flera versioner av samma applikation i drift samtidigt. Man väljer i GAE-konsolen vilken som skall vara default. Detta gör det möjligt att förhandstesta en ny version innan den går live.

Du kan testa detta själv på följande länkar:

  1. https://4.latest.eats-o-matic.appspot.com/ (OBS: webbläsaren kommer kanske att varna för felaktigt SSL-certifikat!)
  2. https://5.latest.eats-o-matic.appspot.com/ (OBS: webbläsaren kommer kanske att varna för felaktigt SSL-certifikat!)

Går du till https://eats-o-matic.appspot.com/ får du den som jag har satt till default.

Alias

Det är ju trevligt om ens applikation har ett namn inom ens egen domän. Detta är väldigt lätt ordnat.
Lägg till ett CNAME som pekar på ghs.google.com i din DNS och lägg till detta alias i Google Apps-konsolen. Så man kommer även åt min app via http://eats-o-matic.hit.se, eftersom min privata Google Appsdomän heter hit.se.

Google Apps och Google App Engine, vad är skillnaden?

Google Apps är en samling molnbaserade tjänster (Software as a Service, SaaS) som Google erbjuder företag och organisationer:

  • Email (GMail)
  • Calendar
  • Chat (Google Talk)
  • Docs (ordbehandling, kalkyl och presentation)
  • Sites (wiki på steroider)
  • Apps (Google App Engine-applikationer)

Så man kan säga att GAE är en delmängd av Google Apps.
Härnäst

Jag kommer att skriva ett nytt blogginlägg varje gång som jag driftsätter en ny version, och skriva något om de erfarenheter som jag har gjort under den “sprinten”. Jag lovar inte någon speciell utgivningstakt, eftersom detta är ett hobbyprojekt. Hoppas ni har förstående för det.

Stay tuned…