Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Java in the cloud: Google, Aptana, and Stax

Peter Wayner | April 22, 2009
Just as the megastars in Hollywood seem to find each other and fall in love, it was only inevitable that two of the greatest buzzwords ever hatched -- "Java" and "cloud" -- would meet and begin to breed.

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.

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.

There are also a number of restrictions on the classes you can use. Google's version of the JVM isn't fully stocked. You won't be able to spin off a thread to handle processing and you can't write to the disk -- ever. You have to use Google's data store if you want to save the data.

All of these changes have some advantages. Google's data store is stripped down and optimized for working with many machines at once. The Memcache service saves calls to the data store -- something to be wary about because the meter is clicking whenever your servlet is churning. The image processing tool handles some of the work with native code, another advantage.

 

Previous Page  1  2  3  4  5  6  7  8  9  Next Page 

Sign up for MIS Asia eNewsletters.