This is a guest post by Robert Miller. If you want to guest post on this blog, check out our guest author guidelines.
On April 7th, Google announced an early look at Google App Engine for Java and I received access to it shortly thereafter. I was able to complete their example application and deploy it to Google servers with very little struggle. I found the Google App Engine for Java to be very entrepreneurial because it offers a simple development and deployment process along with really cheap, scalable hosting. The following are notes and a case study of my experience in developing a new microblogging service using Google App Engine for Java.
Ease of Development with the Eclipse Plugin
Google App Engine for Java includes an Eclipse plugin that makes it easy to develop and deploy a Java web application onto Google’s servers. The Eclipse plugin creates a web application project that includes all of the necessary JAR and configuration files. Further, the Eclipse plugin provides the ability to test your application on your local machine because it can start a local database and web server that emulates Google App Engine’s production environment. What’s more, the Eclipse plugin provides one-click deployment to Google App Engine’s servers. There is an online administrative tool that works in concert with the plugin to provide version management for database changes.
Really Cheap, Scalable Hosting
Last fall, I stated that one of Java’s biggest long-term problems was that there was not any really cheap, scalable hosting solutions and that Google App Engine should add Java to their list of support languages. I believe that Google App Engine can spark a resurgence in entrepreneurs choosing Java over Ruby now that Google has added Java support. Google App Engine for Java is free to use until an application exceeds the following daily usage: 46 hours of CPU time per day (i.e., processing time not idle time), 10 gigabytes of data transferred in and out, 1 gigabyte of stored data (i.e., data accumulates over time), and 2,000 e-mails. It should be noted that the free daily quotas are scheduled to be reduced: CPU time down to 6.5 hours and the data transferred down to 1 gigabyte.
Hosting environment – Google App Engine for Java meets or exceeds all of my expectations for a Java web application hosting environment because it decreases time to market, requires little or no start up costs, and supports long-term scalability and growth. Time to market benefits are derived from actions that do not need to be taken: deployment script configuration, database clustering, and web server clustering. Further, time to market is supported by built-in unit testing and easy to follow code conventions. The start up costs for licensing and hosting are zero so the only cost is time spent programming. What’s more, long-term scalability and growth can be achieved headache-free (in theory) because App Engine for Java takes responsibility for providing additional resources (i.e., servers and database storage) as they are needed.
Support for Java
Shaking off the rust – Developing and launching a new service using Google App Engine for Java meant shaking off my Java programming rust because I had not programmed Java in almost three years. The transition back into Java was helped by my attendance of JavaOne in 2006 because a lot of what I learned then is now being used in Google App Engine for Java (e.g., JDO, annotations). In addition, I have recently done some programming in Ruby on Rails so my programming acumen has not diminished entirely. In shaking off the rust, I found the Google App Engine documentation sufficient for basic tasks and that the Google App Engine Developer group was required for complex tasks.
Web application support – Google App Engine for Java supports standard Java web application development and deployment including Servlets, Filters, JSPs, and JSTL. I was unable to get JSTL working but I am assuming that it was a personal problem. Some people have pointed out that Google App Engine for Java does not support the full Java specification and the frameworks built on top of it including JDBC, JSF, Struts 2, RMI, and JAX-RPC. This can be a serious problem for porting existing applications over to App Engine for Java but should not be a big deal for new applications that can suffice with basic Servlet and JSP programming. Further, the compatibility issues are well documented so it should be easy to architect an application that can successfully run on App Engine for Java. For me, it is worth trading the full set of Java features for an easy to manage, scalable hosting environment.
Other Notes -
- Google App Engine allows each developer account to create up to 10 applications. If you plan to use Google Accounts to authenticate users then choose your application name carefully because I could not edit my application name (for display on the user login page) after I created my app.
- By default, an application is deployed with a domain of something.appspot.com. A free Google Apps account is required to associate your custom domain to your application.
- Google App Engine for Java administration site includes the ability to run queries, delete data, manages versions of your application, and view usage/billing statistics.
- You can give other developers access to your Google App Engine for Java administration site.
Case Study – New Microblogging Service
I created a new microblogging service http://m.TwoKnobbyTires.com that was programmed for and deployed on Google App Engine for Java. m.TwoKnobbyTires.com’s functionality is part microblog (e.g., Twitter) and part discussion forum. The simplistic look and feel is modeled after Craigslist and designed to be usable from all mobile devices. Unfortunately, Google Accounts for authentication does not work on all mobile devices. The service facilitates real-time niche discussions including:
- An outdoor forum for outdoor enthusiasts to discuss hiking, biking, hunting, fishing, etc.
- A pro sports forum for fans to debate their city’s NBA, MLB, NFL, and NHL teams
- A college sports forum for fans to debate college football and basketball
The App Engine features utilized include Google Accounts for authentication, App Engine’s email service, and the default JDO implementation. Java features and frameworks put to use include Servlets/JSPs, Servlet Filters, JUnit 3, log4j, and Apache’s commons-lang. Fitnesse was used to automate HTML tests for web pages and XML tests for RSS feeds. FeedBurner was employed for generating a daily digest email of forum updates.
JDO Struggles – The only significant hangups I experienced centered around Google App Engine’s implementation of JDO and, specifically, my adjustment to Google’s non-relational database. Developing with Google App Engine for Java was the first time I had used JDO and my limited experience probably accounts for most of my struggles. However, many of the App Engine bugs and group discussions are with regard to JDO issues so I am not the only one struggling with it. Inserting, updating, and querying data was effortless once I got my JDO issues straightened out. The following are tasks that I found challenging and that took much longer than originally anticipated:
- Defining one-to-many relationships
- Writing queries that do not use the following query functions since they are not allowed: “LIKE” clause, “IN” clause, and “NOT NULL” clause
- The need to use && instead of AND in queries
- Setting multiple query parameters
- Using the
PersistenceManagerin a chain of Servlets and JSPs
Recommendations – Transitioning from other Java programming environments to Google App Engine for Java should be effortless but there are some quirks that require adjustment. The following recommendations address some of the quirks:
- Google Accounts for Authentication – If you use Google Accounts for authentication then encapsulate Google’s User object inside a persistent object such that a minimal amount of code depends on it. This is important because Google’s User object is subject to change and currently does not provide a primary key.
- One-to-Many Relationships – Use written queries to load one-to-many relationships if you are struggling to define one-to-many relationships with JDO annotations. The App Engine Data Store has limitations that do not allow it to support the full JDO specification.
- Servlet Filters – In lieu of a framework like Struts 2 or Spring, use Servlet Filters to implement features that span several pages including user authentication and database connection management. For example, in a single HTTP request you can “get” a persistent manager multiple times but cannot close a persistent manager more than once so I recommend creating a Servlet Filter that initiates a connection but is the only place where a connection is closed.
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { if (filterConfig == null){ return;} PersistenceManager pm = PMF.get().getPersistenceManager(); try{ chain.doFilter(request, response); } finally { pm.close(); } } - Version management – Version management is limited to 100 versions for each application so only change your application’s version number when making a database change (i.e., adding and removing columns or tables).
- Localize Data – Store lookup data as static arrays (or collections) to minimize database queries since Google charges for database storage space and CPU processing time.
- Auto Generate Query Indexes – Write automated tests against your development server that trigger every possible query your application needs to run in production because App Engine for Java can auto generate the datastore index file that is required to configure your production database. Manually writing the datastore index file is cumbersome and error prone.
- Development Server – Stop your development server from Eclipse’s debug mode (this took me a while to figure out).
Note: If you like this article, make sure you check out 3 Tips For Getting Started with Google App Engine for Java.
Robert Miller is a technology entrepreneur specializing in e-commerce and online services that integrate with social networks and mobile devices. He blogs at PardonTheInformation and you can also subscribe to his feed.
Please Tweet, Bookmark, or Share This Free Content Using These Services:
Add New Comment
Subscribe to comments
Email
Reader
Listen or subscribe via podcast
By default, an application is deployed with a domain of something.appspot.com. A free Google Apps account is required to associate your custom domain to your application.”\
Last time I checked pay was required for this feature.
Reply
Twitter/Share/BookmarkFlorin, I did not have to pay for a standard edition Google Apps account (i.e., to associate my domain) because my company does not have that many employees and, thus, does not require the Google Apps “premier edition”. There may be other reasons that force you to buy a premier account but I can’t remember what they are.
Reply
Twitter/Share/BookmarkHow do you pre-load sample data? What do you do if you want to do a production change of data? I am curious. Good article, thanks. I would like to read more when you have it.
Reply
Twitter/Share/BookmarkMatt, good questions. I haven’t spent much time on it but have yet to figure out how to pre-load sample data. In development, I load data by manually testing my service from a browser. I use Fitnesse to automate tests but it would also work for loading data too (via automated form submissions).
The Google App Engine administration web site includes a “Data Viewer” that allows you to query and delete your production data but does not allow you to insert or update data. A “database migration” tool similar to what Ruby on Rails provides would be ideal.
Reply
Twitter/Share/BookmarkFYI, JPA is also available for persistence along JDO in Google App Engine. Since I’m not a JDO guru (just like you) I prefered using JPA. Although much less documented, it works, at least for common cases.
I’ve written a fairly long article on my own experience with Google App Engine. You can see it here: http://blog.frankel.ch/tech/dev/java/jee/google-appengine-limitations.
Best of luck.
Reply
Twitter/Share/BookmarkInteresting article. It’s also worth pointing out that the latest version of Grails now runs on Google AppEngine (see http://www.springsource.org/node/1471 ). This should further encourage the choice of Java (with Grails) over Ruby/Rails.
Reply
Twitter/Share/BookmarkCouple of quick points:
Be careful when creating your apps, as you can only have up to 10, and you cannot delete an app.
You can use Google App Engine with a Google Apps account to link your app to your own domain. This also allows you to restrict access to the app to authenticated users within your own domain (http://code.google.com/appengine/articles/auth.html).
Reply
Twitter/Share/BookmarkThanks for the suggestions. I programmed with Ruby on Rails for 2 years and really enjoyed it but have yet to try Grails. With Grails on GAE, it sounds like now is the time to start.
Reply
Twitter/Share/Bookmark