Understanding Google App Engine (GAE) Java API Part 1: Landscape Overview

Writing apps in your favorite language on the web is fun and rewarding for developers — and can be a good value proposition for small businesses and start ups. This is easily possible with Google App Engine (GAE), with Java as the language of development. It’s very important to know the landscape within which you can build your application using emerging GAE, and to understand the limitations of an evolving product.

Sandboxed Runtime Environment for Java

Applications in Google run on Java 6 JVM, and the SDK supports Java 5 or later. The applications run in a sandboxed environment where they are isolated for services and security. In the restricted sandbox environment, the application can execute the code, query & write to the datastore, use app engine services like mail and URLFetch, and can accept requests from users to send them back a response. However, we need to understand there are certain limitations in this sandboxed environment:

• The application can not write to the filesystem. Reading from filesystem to scope of application files is allowed.

• Opening a socket and accessing a host directly is not allowed. The user can use URL fetch service for accessing URLs.

• The application can not create new threads. The restriction also applies to JRE classes which use threads like java.util.Timer. The application can perform actions against the current thread though, like getting a dumpStack.

• Reflection is allowed for all application classes including private members. However for JRE & SDK classes, only public members can be accessed using reflection.

• The system properties that you set are only limited to the application.

• Only classes listed in the White list can be used from all Java Library classes.

Domains

Each application gets an app-id and the URL for that application is app-id.appspot.com, and you can also have subdomains like mail.app-id.appspot.com. Deployed applications can have versions and the default version serves the requests. Each version has its own URL, thus you can test your application on the server without affecting the default live version. For example version 7 of the above application can be accessed using 7.latest.app-id.appspot.com

Servlet environment

All requests received are handled by servlets as defined in your web.xml file in the web application. The Java Servlet API is used for request response handling. For backend requests, backend.xml or backend.yaml is used to invoke servlets matching the request criteria.

The app engine uses multiple web servers to handle requests to your application and scaling the number of servers is handled by platform. Requests are clustered across multiple web servers, and each web server processes one request at a time. If you want web servers to receive multiple requests, you can do so by adding the <threadsafe>true</threadsafe> element to appengine-web.xml.

The app engine passes on requests for the application to process and once a response is received, it is passed back to the client, but streaming is not supported. One important note of caution here, which if not handled has been a pain of various developers and businesses: the request handler has to finish the processing in or less than 60 seconds, else the JRE will throw com.google.apphosting.api.DeadlineExceededException and where this exception is not handled will lead to an Error 500 for the end user. The app engine is built for many small requests of a few seconds rather than longer requests. It’s the shift in paradigm with which applications need to be designed for GAE. Requests which need to run longer need to handled using alternatives such as task queues or a backend.

Development tools

The Eclipse plugin for the App Engine comes bundled with App Engine SDK and GWT SDK. The plugin provides the ability to create app engine projects, debug and one-click cloud deployment. The plugin allows you to upload application files and download log files. It also has a component for Apache Ant to automate common developement and deployment tasks. Third party plugins are also available for NetBeans and IntelliJ.

You can alternatively use the “appcfg” command line tool, which allows you to enable all tasks possible through the IDE like uploading your application files, getting logs from server and so on.

The development server that comes with the SDK enables you to test your application locally, by simulating the datastore, services, sandbox restrictions and can generate indexes based on queries that generate indexes.

With this understanding of the development and run-time environment we get a fair idea of the platform. The next part of this series is going to focus on setup and getting familiar with configurations and deployment structure. Keep watching!