Java in the cloud: Google, Aptana, and Stax
Google App Engine, Aptana Cloud, and Stax for EC2 make it easy to spin up and scale a simple Java Servlet Container, but are still a far cry from the full Java EEFollow @infoworld
But this may be because the creators have a slightly different goal than the creators of the original J2EE. They're not trying to create a wonderful cloud of objects that float from machine to machine, nibbling on a few cycles here, chomping on a large block of memory there. They're really just tackling the headaches of deploying a server, a process that can be maddening in many IT shops. They want to make it easy for a project to turn into a public Web site and then grow adequately if thousands or millions decide they want to tune in. The goal is to make all of this happen as automatically as possible without all of the headaches of approving purchase orders, reserving rack space, waiting for deliveries, and other time-consuming problems.
Some of the simplicity must also be because this is all very new. I wouldn't be surprised if the companies begin integrating all of the more sophisticated layers in their next generation. They're starting with Tomcat for now, and it shouldn't be too hard to catch up with Java EE.
[ See previous Test Center cloud reviews: Cloud versus cloud: A guided tour of Amazon, Google, AppNexus, and GoGrid | Inside Amazon Web Services | Windows Azure Services Platform gives wings to .Net ]
There is a great deal of variety in the approaches and the levels of abstraction. Google's App Engine caters to a thinner, more widely parallel set of applications that can scale automatically. Aptana's tool, on the other hand, is a nice IDE that integrates deployment and purchasing into Eclipse. Stax offers something that lies roughly in between both tools.
Google App Engine
Google's shining new Java wing to the App Engine should be very familiar to anyone who's spent time with the first generation based on Python because many parts of the architecture are unchanged. You write a thin layer of logic that juggles the requests and then you rely upon the back end to synchronize everything. The Java applications use the same database, image processing engine, and mailer in pretty much the same way as their Python-based cousins.
While the new Java tool will be very familiar to Python programmers who used the original engine, many of the ideas will be a bit strange and new to Java programmers. The database is not MySQL, Oracle, or even the embedded database included with the JVM, Derby. It's a proprietary data store with a small subset of SQL called GQL. You can't use JDBC (Java Database Connectivity) to link up with it; you need to use Google's own proprietary layer.
This is just the beginning of the changes. You can't just open up a socket and suck down a Web page; you have to use the URL fetching code. If you want to keep a cache of commonly used information, you should store your objects with the Memcache implementation that Google offers. Google's code will keep everything consistent so that the Memcache on all machines will offer the same thing when the synchronization is finished.