Lately I have been looking into and playing around with the Google App Engine. In this post I want to give a little introduction to the Google App Engine, why it can be interesting and how to work with it.
First I want to describe what the Google App Engine is in a few sentences. But nobody does a better job at explaining than Wikipedia so I’ll just give you a quote instead 🙂
Google App Engine is a platform for developing and hosting web applications in Google-managed data centers. It was first released as a beta version in April 2008.
Google App Engine is cloud computing technology. It virtualizes applications across multiple servers and data centers. Other cloud-based platforms include offerings such as Amazon Web Services and Microsoft’s Azure Services Platform.
Google App Engine is free up to a certain level of used resources. Fees are charged for additional storage, bandwidth, or CPU cycles required by the application.
To sum this quote up in a few words: Google App Engine is free hosting for Java! For so long technologies like PHP have been very cheap (if not free) to host. To host a Java web application on the other hand, you always have to pay good money for it. Probably the biggest reason is that for PHP, it’s easy to have many websites on one server since those websites are just a bunch of standalone scripts. A Java website on the other hand, is an entire application, so the best way to host this is to get a dedicated server with an application server installed. Dedicating an entire server to host your website usually isn’t as cheap as hosting a PHP website.
Why use the Google App Engine?
Next to the fact that Google App Engine is free to use, what else is interesting about it, you ask? Well, let me tell you! Actually, Google App Engine offers you a lot of features which can help your application in different ways. Below are a few examples of features I find the most helpful.
The first thing you will see when you start using the Google App Engine is the Dashboard. The dashboard has both an online version and a local development version.
The online version of the dashboard allows you to see all sorts of information about your deployed application. You can for example see application logging (filtered by INFO, WARN, etcetera), but also configured cron jobs, the content of your data store and quota details.
The local development dashboard is kind of a stripped down version of the online one. It helps you control your locally running instance of the application. Using the dashboard you can for example simulate incoming emails, simulate incoming XMPP messages and view running cron jobs.
Google offers you a service to easily manipulate images. The most common image operations are supported, like: resizing, cropping, flipping, enhancing colors and contrast.
Using Google’s JPA or JDO implementation you can access the datastore. You can also use an SQL-like query language to access the store directly.
Cron jobs / task queues
Instead of using a framework like Quartz to schedule jobs, Google App Engine takes care of executing jobs for you. You simply enter a cron-like expression and a URL to call and your job is configured.
You also have a task queue at your disposal. Your application code can add tasks to a task queue which will be executed later in the future, asynchronously. An example use case is that you don’t want clients to wait for an email to be sent before he sees the next page. Instead you can put the email task on the task queue and the email will be sent asynchronously.
Security using Google accounts
Why use a security framework like Spring Security when Google lets you use their own authentication system? When you configure your application to use Google authentication, only people with a Google account are able to login to the application. You can also configure one or more accounts to be the administrator. Administrators could have access to certain parts of the application other users can’t access.
Service for receiving email
Google offers a service that allows your application to receive emails! When an email comes in, a URL is called with the email in the POST body. The body of the request is just the plain mime message text as it was received.
Applications on the Google App Engine
To run your own application on the Google App Engine, it has to follow some guidelines in order to properly function. When I was building a sample application, I sometimes found myself writing workarounds to work with for example the JPA and mailing facilities of the Google App Engine. For the record, I was trying to use the Spring framework with JPA for persistence and Spring MVC for the frontend. I want to share the challenges I faced and how I handled them to get things working.
Sometimes I had to write custom classes to get things working, I combined all those classes in a tiny open source project called app-engine-workarounds. The project can be found at http://code.google.com/p/app-engine-workarounds/. Below I will sometimes refer to classes in this project.
Spring and the Java Mail Sender
When you’re using Spring and want to send an email from within your application, you will use the JavaMailSenderImpl which is packaged with Spring. But when running an application the Google App Engine, you can’t use this class out-of-the-box. The reason is that Google has its own email implementation and does not use SMTP servers for instance. This is why you have to interact differently with the javax.mail.* framework. Luckily you can easily extend the JavaMailSenderImpl to make adjustments. The app-engine-workaroundss library actually contains an adjusted JavaMailSender which is called the GaeJavaMailSender. This class is a drop-in replacement for the original JavaMailSenderImpl.
Handling file uploads in Spring MVC
Handling file uploads in Spring MVC requires an implementation of the MultipartResolver. The only implementation available in Spring MVC 3.0 is the CommonsMultipartResolver which uses commons-fileupload to do its job. Unfortunately the way Spring uses commons-fileupload, is not supported by the Google App Engine because it uses the file system, which Google App Engine does not provide. To make this work, you will have to utilize the streaming API part of commons-fileupload framework, which does not need the filesystem. I created my own custom implementation of the MultipartResolver that actually uses this streaming API of commons-fileupload. I put this implementation in the app-engine-workarounds library too.
Spring and JPA with transactions
You can use JPA with Spring almost like you’re used to, except that the EntityManager factory bean is configured differently. In the section “Other workarounds” on http://code.google.com/p/app-engine-workarounds/ I put a description of how to configure JPA in Spring for the Google App Engine.
Using JPA with the Google App Engine has its limitations. I only tried the JPA implementation and I soon found out that a lot of JPA features are not (yet) supported. Most of these features are related to relationships between entities. I used a relatively simply data model and already encountered the following issues:
- Multiple ManyToOne relations to the same entity is not supported
- OneToMany relation can only be used with entities that use the GAE “Key” class as the unique identifier
- Can’t operate on multiple entities within the same transaction
- In a query, you can’t use “OR” filtering referring to two different properties of an entity
Parsing inbound emails
Google App Engine offers the very useful feature of receiving emails in your application. This way users can just send an email to some address and your application processes it. When an email is received Google App Engine does a post on an URL in your application you configured. The HTTP body of the POST request contains the exact mime message as it was received by Google. To parse this mime message you can use the MimeMessage class provided by the JDK.
Unfortunately this class is not easy to use and sometimes not that straightforward at all. Usually all you want is to extract the sender, subject, body (html or plain text version) and attachments from the mime message. I created a few classes that help you to easily parse that information from a mime message received by your application. And guess what? I put these classes in the app-engine-workarounds project too! Example of how to parse an incoming email message using this class:
Session session = Session.getDefaultInstance(new Properties(), null); MimeMessage mimeMessage = new MimeMessage(session, request.getInputStream()); EmailMessage email = new EmailMessage(mimeMessage); // Now you can use the EmailMessage instance to easily extract information String subject = email.getSubject(); String plainTextBody = email.getPlainTextBody(); String htmlBody = email.getHtmlBody(); Address fromAddress = email.getFromAddress(); List<Attachment> attachments = email.getAttachments(); // ... etcetera
Cronjob to keep your application “hot”
When you deploy your application it doesn’t always keep running. After like 5 minutes of inactivity, the application shuts down. Now when a user tries to access a URL, the application starts up again. So the first user that tries to open a page after a period of inactivity has to wait 30 seconds before he gets a response. Google does this to save CPU power of the servers in their “cloud”.
Especially during development, this is very annoying because it slows you down trying to test your application. What you can do is configure a cronjob with the expression “every 1 minutes” which calls the URL “/ping” (for example). When this is in place, your application always stays “hot”. In other words, it never shuts down and will always quickly respond to requests. I’m not sure if this violates any usage policy of Google, but I’m sure it’s not that bad when you only use this during development, when it’s the most annoying.
Google services as Spring beans
Google exposes a few services for you to use, but you can only get a reference to them using a static factory method. In a Spring application this is not a nice thing to do, especially because this is hard to unit test. Instead, you can configure Google services as Spring beans like this:
<bean class="com.google.appengine.api.images.ImagesServiceFactory" factory-method="getImagesService"/> <bean class="com.google.appengine.api.users.UserServiceFactory" factory-method="getUserService"/> ...
Then you can wire one into the class that needs that service and you’re done!
When you use JPA, any date field you’re trying to persist will get saved using the “GMT” timezone. So whenever you want to display dates you have to keep in mind to apply your own timezone to them. When you for example use the
<context-param> <param-name>javax.servlet.jsp.jstl.fmt.timeZone</param-name> <param-value>GMT+1:00</param-value> </context-param>
On one hand Google App Engine provides a rich set of helpful features and services to help you build better applications. On the other hand you do need to compromise by working around certain issues because the Google App Engine doesn’t entirely behave as a regular application server. Also the JPA implementation in Google App Engine is very limited. But, with the workarounds in place (which I described above) you should be able to get rid of most of the frustrations you will encounter. This way you can start developing your own application like you’re used to, with the tools you’re used to but now using all the cool features the app engine offers!
Unfortunately, some frameworks won’t work at all on the Google App Engine, not even with a workaround. To quickly find out whether a certain framework will work on the app engine, take a look at this page http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine. As long as you’re not using any frameworks on the “black list” you will be fine ^^
If anyone else has workarounds or other helpful classes for the Google App Engine, let me know by posting a comment below. I will include them to this blog post and/or to the app-engine-workarounds project.