My notes for another interesting BeJUG talk, on 9 June 2009, in Leuven.
Introduction to developing applications for Google App Engine
Cloud
IAAS: vitual hardware platform, need to install OS, java, application server, application,… No limitations, no locking BUT you have to manage it all yourself and no automatic scaling. Example is Amazon Elastic Cloud.
PAAS: virtual application server, no control over OS, run in sandbox. No server management, easy deployment, autmatic scaling BUT limited by the sandbox, can’t run existing apps as-is. Example is GAE.
SAAS: run an application in the cloud.
Intro
Sandbox + servlet container + application
with admin console and eveloper tools
bigtable (with JPA/JDO if you want)
services : memcache, URL fetch, mail, XMPP, Images, Google Accounts, Task Queues
You get a (free) subdomain http://yourappname.appspot.com
You can add your own domain name
Each request has a 30s timeout
Streaming responses are not allowed
JVM’s are started on demand, on app startup, after inactivity or when upscaling
Starting a JVM causes a “loading request”, the app is loaded during that request
Sandbox, you can’t
- write to the filesystem
- open sockets
- create threads
- invoke most System calls
- reflect on classes not belonging to the app
- use JRE classes not on the whitelist
Supported: JDO, JPA, JSF, JSP, Servlet 2.4, JAXB, XML apis, JAX-RS,…
Not supported: EJB, JAX-WS, JAX-RPC, JDBC, JCA, JMX, JMS, JNDI, RMI
GAE includes a staging environment (though accessing the same data store, so have to be careful)
Storing data
BigTable: distributed, highly scalable, not relational, schema-less, properties have one or more values
Kind => table
Key => primary key
Entity group => partition (usually on the same shard)
typed properties => columns
Entities are hierarchical, useful for “owned” relationships (eg a chapter can’t exist without a book)
Queries (JPQL)
Supports some filters >,>=,…
Each query uses an index
An index is combination of kind, properties, sort order etc
Transactions
- data store is transactional
- all writes are atomic
- only one entity group can be used in a transaction (as they can be on different physical servers)
within a transaction: serializable isolation
outside: get is read committed
queries are more subtle, commit is two milestones, (1) out in datastore, making entity visible, (2) update indexes
there is a low level JDBC like API, using GQL queries
JPA: add JPA and DataNucleaus jars, create persistence.xml, configure post-compilation class enhancement
JPA limitations: no joined inheritance, no single table inheritance (for now), no many-to-many relationships, no unowned one-to-many relationships, no join/aggregation/polymorphic queries
Constraining pages (security constraint in web.xml)
- Uses Google Accounts
- Require users to log-in
- Require the admin role (==developer on GAE) (only existing specific role)
Mail
- receiving mails is also possible (somename@appid.appspotmail.com)
- AppEngine will post this to a servlet /_ah/mail/address (page which is not accessible from outside)
Cron jobs
- tasks run on certain intervals (again a servlet is called on a specific URL, so 30s time limit)
- configure in WEB-INF/cron.xml
Task queues, can be used to split tasks in small chunks
- asynchronous, parallel background tasks
- modeled as web hooks (with data+code) (30s limit)
- custom queues can be created, can be throttled (rate) and can have a bucket size
Blobstore service to save files
- max 2GB
- upload by form POST, returns a blob key
- serve file using blob key
MemCache
- distributed in-memory cache, cross JVM instances
- JCache API (JSR-107)
- low level API
Easy out-of-container testing. Most services have in-memory versions.

Funny, I was searching for information about a specific GAE problem and I end up looking at notes about my own talk
I truly enjoy studying on this website , it has got fantastic posts .