Rapid Cloud Development with Spring Roo – Part 1: Google App Engine (GAE)

Spring Roo is a tool to offer rapid application development on the Java platform. I already explained when to use it: http://www.kai-waehner.de/blog/2011/04/05/when-to-use-spring-roo. Spring Roo supports two solutions for Cloud Computing at the moment: Google App Engine (GAE) and VMware Cloud Foundry. Both provide the Platform as a Service (PaaS) concept. This article will discuss the GAE support of Spring Roo. Cloud Foundry will be analyzed in part 2 of this article series.

A very good introductory article, which describes the combination of Spring Roo and GAE, already exists here: http://java.dzone.com/articles/creating-application-using. In a nutshell, there is not much to do to deploy your (CRUD-) application in the GAE cloud. You have to choose another database provider, enter your GAE application id in a configuration file and deploy the application using one single Maven command (mvn gae:deploy). That is the difference to „traditional“ Roo applications. Thus, no rocket science! Nevertheless, there are several restrictions for developing GAE applications, for instance you cannot use @OneToMany annotations to specify relations due to NoSQL concepts. Deployment will fail respectively the application will not work as expected if you do not follow the rules.

So, after reading the previous paragragh, the conlusion is the following: Spring Roo supports deploying its applications to the GAE cloud. Thus, everything is fine? No, not at all!

Yes, you can deploy your CRUD application to the GAE cloud (if you do not use relations), but GAE is much more. You can or rather should use Task Queues to segment your long-running work, the BigTable datastore and blobstore to store your data, use the URL fetch service to communicate to other applications using HTTP(S), and several other GAE services such as XMPP, Memcache, Mail, and so on. The number of available services further increases with new GAE releases.

These GAE services exist for some reasons: You should be able to create a cloud application which scales automatically without any manual server configuration and such stuff. That is the reason why you have to use NoSQL database concepts and Fetch URL instead of a SQL database, Threads, socket programming, and the other techniques which you used in the past when not developing an application for the cloud. Google developers are NOT too dumb to support SQL databases, but it is not the appropriate technology for highly scaling cloud applications. A nice article about „SQL versus NoSQL“ can be found here: http://java.dzone.com/news/sql-vs-nosql-cloud-which

Spring Roo has no special GAE command. You use the persistence command to create support for BigTable, and you use a Maven goal to deploy the GAE application. Besides, there are no GAE commands although you would need them to create your Task Queues, BigTable datastore access (including relations), URL fetches, and so on. You have to code everything by yourself, as you have to do without Spring Roo. Thus, there is no real support for GAE, yet – contrary to Cloud Foundry (as we will see in part 2 of this article series). Of course, VMware wants to push its own PaaS solution, I understand that. Nevertheless, Spring Roo should also offer good support for other solutions as it does for web frameworks (in the meantime, there is offical support for Spring MVC and GWT, besides plugins for Vaadin, Flex and JSF are available respectively in work).

Be aware that GAE is the only stable and production-ready PaaS solution in the Java environment at the moment. Other offerings such as Cloud Foundry or Red Hat OpenShift are still in BETA status. Also be aware that there exist reasons why Google is not offering SQL database support yet. They will probably add this feature in the future, because public criticism is huge. Nevertheless, NoSQL databases will be required in many use cases where you want to deploy your application in the cloud. Thus, I hope that Spring Roo will offer better GAE support in future versions.