Over a million developers have joined DZone.

CapeDwarf - Google App Engine on Java EE

DZone's Guide to

CapeDwarf - Google App Engine on Java EE

· Cloud Zone ·
Free Resource

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.

I have many hobbyhorses. Coming all the way from the early Java EE specifications and having done the "cloud" excursion with Java EE 7, I was curious to see what the newly announced CapeDwarf project has in stock to bring Google's Platform as a Service offering "Google App Engine" on premise.

The Story so Far
I did play around with App Engine. It was the first true PaaS offering for me back in the day. And I liked it. What I dislike is that you have to check if GAE is playing nicely with your flavor of Java. At the end of June, Google and Red Hat announced an official partnership for working on the GAE TCK, which sooner or later should bring the App Engine to Wildfly.

Installing and Configuring your Environment
Let's start right away. Get CapeDwarf and play around with it. In the core, there is Wildfly or JBoss AS 7. CapeDwarf is only an extension module and needs to be build in. There are basically two ways of getting it: Grep the latest build from the downloads page, which would be the Beta 5 (released  2013-07-10) or build it on your own. I tried the last way first. It is supported by a very brief readme on the GitHub project page, but I wouldn't recommend doing this. It takes roughly 30 minutes (pure build time) because you also have to build the AS 7.2.0.Final yourself. If you get the zip distribution all you have to do is to unzip it and start the CapeDwarf-enabled server via:

$JBOSS_HOME/bin/standalone.bat/.sh -c standalone-capedwarf.xml

This looks like an AS 7 startup at first glance because it is taking much longer due to the JGroups startup. At least on my machine.

After that you have to add an admin user and log-in to the server console at http://localhost:9090/. Then you check if the extension is there by visiting the "Extensions" tab. Now you're all set.

Using the Guestbook Example Application
All that's left to do now is to fire up your IDE of choice (NetBeans in my case) and get a nice little demo project up and running. Lets stick to the guestbook example, which is also part of the official gae-sdk. You should have Maven and Java 7 at hand already. The guestbook example is available as an official archetype and you can simply have it by using the following mvn command:
mvn archetype:generate -B
-DarchetypeArtifactId=guestbook-archetype -DarchetypeVersion=1.7.7
-DgroupId=net.eisele.demo -DartifactId=guestbook -Dversion=1.0 -Dpackage=net.eisele.demo
Everything you need in terms of dependencies is in central so you don't even have to configure another repository! Open the generated project right away and start to tweak some things. First, you need to change the appengine.target.version in the pom.xml to 1.8.3. Next, you need to add the relevant datastore indexes. As I understand it, GAE does this on its own. CapeDwarf, which relies on a couple of existing Red Hat technologies, needs to be instructed to fire up the indexes. Add the  datastore-indexes.xml to your src/main/webapp/WEB-INF/ folder with the following content:
<?xml version="1.0" encoding="utf-8"?>
<datastore-indexes autoGenerate="true">
    <datastore-index kind="Greeting" ancestor="true" source="manual">
        <property name="date" direction="asc"/>
If you add the  <finalName>ROOT</finalName> attribute to the <build> section of the pom, you're ready to go. Deploy the app via the management console or put it into the $JBOSS_HOME/standalone/deployments folder. There you go. Navigate to http://localhost:8080/ and watch the magic happen.

You could post greetings or even log in with an email address and leave personalized comments. You can do everything without changing a single line of code. You could even deploy the same piece of code to the App Engine. Further on, if you navigate to http://localhost:8080/_ah/admin/ you get a nice little admin console which gives you access to the underlying datastore.

Even Datanucleus plays nicely within this setup, and you could make the examples run by changing the  javax.jdo.PersistenceManagerFactoryClass in the jdoconfig.xml to  org.datanucleus.api.jdo.JDOPersistenceManagerFactory. If you get the dependency versions right ( jdo-api:3.0.1, datanucleus-core:3.1.5) and you use the right maven datanucleus plugin, things should look like this:
You're good to go with that. Give it a try. It is really easy.

Things to Improve on for Now
The implementation is limited at the moment. It seems as if the project team focuses on the official GAE-TCK. A majority of the APIs are completed, and only nine out of 26 services aren't supported according to the CapeDwarf homepage. Given that, I would have expected to see a little bit more documentation. For now, this basically comes down to the official Google documentation. If you run into something special you're on your own. If you have questions regarding the TCK, a newly formed Google Group covers them. Good news: The Project Lead  Aleš Justin is responsive and helpful just like all of the Red Hat Java guys so far. If you are looking for examples, there is a broad test coverage suite based on Arquillian in the CapeDwarf project. This is a good place to start for now.

Google App Engine an Alternative to Java EE 8?
What is the bottom line? I would call the GAE infrastructure mature. Being launched in April 2008 and released to public late 2011 it had a solid five years to handle customer needs. Looking at the definitions from the cloud topic in early versions of the Java EE 7 specs and comparing them with what GAE has already achieved is saddening. While EE has a very decent technical cut along application layers, GAE at least partly breaks this up in a service-oriented way. While you see stuff like security spread nearly all over the place in SE/EE (JAAS, JASPIC, individual specs) GAE simply provides a Users API for User Management and an AppIdentity API for integration with other systems. Beside this, it also provides APIs and abstractions for features that Java EE simply doesn't offer ready-made. I'm thinking about a Multitenancy API or something like the Capabilities API. If someone wanted to start lightweight on Google's PaaS in the past and tried to have a later migration to Java EE-based on-premise hardware in mind, he had to think carefully about mapping technologies and buying into Google specific services. As of today, CapeDwarf already changed the rules significantly and lowered the vendor lock-in risk.

If you look at the specification side, it has it's drawbacks. Google is in charge. Exclusively. For now I don't see any advisory-board or comparable thing in place. So if Google decides to pull back (e.g. Reader disaster), many people would be stuck. The open TCK on the other hand at least makes the specification available, free of charge, to everybody (ASL2.0). And this is what basically made CapeDwarf and AppScale possible. For now, this isn't the better Java EE, at least for me. But given the fact that we are again looking into a cloudy future with Java EE 8, this could be a blueprint for new specifications, which need to get done.  It could also be a nice guideline for something I would call "topic centric APIs". Taking care of the business needs and not just the technology problems. This is going to be an interesting movement in the next few years, and I am curious to see if some other vendors jump on that train sooner or later. It is sad to see that Google pulled themselves out of the JCP and the active development inside the standards body.

Further Links and Readings
The Blog of the project lead  http://in.relation.to/Bloggers/Ales
CapeDwarf on Github  https://github.com/capedwarf/
CapeDwarf Downloads  http://www.jboss.org/capedwarf/downloads
The App Engine TCK  https://github.com/GoogleCloudPlatform/appengine-tck

How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}