How to build a fully functional app. hosted on Google App engine

How to build
a fully functional app.
hosted on
Google App engine
in 1 hour!
Sound's amazing is it not?, to build an application hosted on Google App engine
cloud framwork from scratch within an hour. But with MDA techniques that's
exactly possible and will be described in this document. There are some caveat's
– I assume that a Google App code has been registered.
– I also assume that Eclipse is setup with the Google App engine plugin.
– For this demo I also have a (simple) UML model prepared, because
designing the domain model(s) and corresponding services is outside of this
Ok let's start.
Preparing the Eclipse projects.
For this demo the following three projects will be created:
– A project that contains the backend code, that will actualy run on Appengine.
– A (resource) project that contains the UML model and diagram, that will be
used to generate most of the source code.
– A projects with the frontend code. Currently the Flca has cartridges for:
Flex : Actionscript3 is generated.
: A GUI Ajax based framework
GWT : This is under way.
In addition, the original Taylor has a cartridge for Jboss/Seam.
In this demo I will use the ZK framework.
To setup these projects I use a simple tool, that copies a source directory to a
another location, and performs some search / replace actions. Is uses an ini file,
that looks like this:
source.dir = home/robin/temp/GglAppEng
target.dir = /home/robin/temp/MyDemoApp
gglappeng = mydemo
GglAppEng = MyDemoApp
flca = myname
app-id = mygoogleappid
As part of the Flca MDA framework, several template projects have been prepared
that can be used as a starting point. These template projects are almost empty
except for some (base) class java files, that are used by the generator. Doing so,
it is possible to generate source files that is not specific to a particulal application,
but can specialized via the java classes from above.
So I run this tools three times, to copy the template projects:
– GglAppEng (template project for Google App engine backend)
– TemplateModel (template for UML model plus diagram)
– ZkFrontend (template for ZK frontend)
I can import these three new projects in my Eclipse workspace.
Preparing the UML model
As said before, for this demo I already have a UML model/diagram prepared, that
looks like this:
This UML model is my reference model to test a (new) cartridge. It contains all
the possible elements:
– Simple class that will be persisted (an Entity)
– Simple class that will NOT be persisted (a Dto)
– Class with One-to-many relation(s)
– Class with Many-to-one relation(s)
– Class with Many-to-Many relation(s) (Join table)
– All kind of datatypes
– Interface with and without parameters and or return type.
– Different annotations (via Stereotypes)
The Flca/Taylor generator allows to generate to either generate:
– All classes and interface for all generators in a particular cartridge
– Just on one class or interface for just one particular generator.
– A combination of these two above.
After running the generator using the first option (all classes with all generators,
from backend cartridge) I get the following output, after approx 30 seconds:
generated 93 files with 8293 lines
0 errors and 0 warnings encountered
*** End Generate ******************
As you can see that's an impressive amount of source code, for such a simple
UML model.
For each Dto the following is generated:
– The Dto itself
– A corresponding mock object.
For each entity (a class that will be persisted), the following is generated:
– The Entity itsef, using standard JPA annotations.
– A mock object
– A validator class
– Dao interface, with the following methods: save, retrieve, findAll, remove.
– Dao implementation
– Junit test, to test the Dao from above
For each interface the following code is generated:
– The interface
– The implementation
– A corresponding so called RPC class, this can be used by for example Flex
ZK or GWT, to call the implementation from above, using Guice.
– A corresponding Rest wrapper, based on Jersey to call the implementation
from above.
– Junit test.
I have put many effort into the generators to generate high quality code, just the
way you would it yourself, with logging documentation and no warnings.
After refreshing the Eclipse workspace, you may find the generated files from
above in diiffererent source code locations depending on the nature of the file,
– src-generated
– src-gen-work
– str-test-gen
– src-test-work
All files in the generated subdir, should normally not be editted yourself. These
are the dto's, entities and interfaces.
The files in the work subdirs, normally do require some work after generating, like
for example the service implementation.
After the generating process, the project will normally containg a few errors that
must be fixed before, for example, junit tests can be run. Most of the errors are
generated deliberately by the generator, to cleary indicate that this requires user
attention. In junit tests for example you may encounter generated code like:
SearchCriteriaDto searchCriteriaDto = TODO;
After all the errors are fixed, all junit tests should run successfully.
Unfortunately, this kind of generator, based on a UML model, is not a two-way
process. That means that if you alter a class, like for example adding a new
property, this wil not be reflected in the UML model. Hence it is always a one-way
process: from model → source code. The generators however do support code
merging, so changes made in a generated class, will be kept after the code is
generated again.
Generating the frontend.
The same process described above can be repeated to generated the frontend
code, in this case based on ZK. This cartridge is relatively small compared with
the cartridge to generate Flex code because from the ZK backend we can
immediately access the classes generated above.
This is the result after running the entire ZK frontend cartridge:
generated 29 files with 2835 lines
0 errors and 0 warnings encountered
*** End Generate ******************
The following classes are being generated:
– The markup file (the View) in the form of a zul file
– The controller code behind java class
– And the plumbing code to access the service Rpc class described earlier.
The Flex cartrige is more elaborate, bacause apart from generating similar modelview-controller files, it also generates the actionscript3 equivalents of the java
entities dto and services. Hence a lot more code is being generated:
generated 72 files with 6280 lines
0 errors and 0 warnings encountered
*** End Generate ******************
The generated gui code is particular handy for admin like crud applications. But
even although such use cases are only a very small portion of a typical
application, the generated model-view-controller can be good starting point in
many different use-cases.
Deploy and run the application.
The Flca/Taylor code generator only deals with generating source code files, and
does not impose any restrictions to the application. Once the code is generated
and the generated implementation files are fixed, it is business as usual as if all
code was hand written. So there is not special on first deploying the
Webapplication to the local machine and then to deploy to the Google cloud with
the Eclipse plugin