Google App Engine & Java Hosting - Oh My!
Over the last few years, I've been watching the various cloud computing initiatives with great interest - at the most basic level, I love the idea of being able to abstract the hardware purchase and spool up new virtual instances (or even just pay by the CPU cycle).
There are a number of interesting packages out there that offer cloud computing - for your reference, here are a couple I'm tracking:
Flipping through the documentation for these different sites, one thing that you'll notice is there are no consistent standards for what is and what is not allowed, how the apps should be packaged, etc. Some assume a complete virtual machine, with your own app server, others assume a WAR, others customize the deployment even more (perhaps with their own added descriptors). Most interestingly, all support different chunks and extensions of the JDK.
Even if you don't like picking and choosing interfaces, the simple fact is that there are no good standards for Java-based web application hosting. All of the specs for Java pretty much assume that you are running your own web server on your own private host - which means that everyone pursing Java in the cloud basically has to make it up as they go along. It's not meaningful or appropriate to require a hosting provider to provide support for every last bit of cruft in the JDK (e.g. CORBA), but there also is no good mechanism for sorting out how this works. It's also considered good practice to not allow web apps to do things like System.exit(). The examples go on and on - and this is part of the reason why it's hard to find inexpensive entry-level Java hosting (certainly as compared to ubiquitous cheap PHP hosting).
So, in no particular order, here are a two basic questions that should be informing the debate:
- How should a cloud service vendor indicate and choose what is supported by their platform?
- How should developers expect to package their Java application for the cloud?
A long time ago, the notion that you could reasonably expect to drop a WAR file into an app server and have it work was a pretty big deal. It was never perfect, but it did give you something to shoot for (and as a side note, that plus persistence via Hibernate always did work a lot better than EJB 1.x-2.x). That positive, simple vision is what drove Java.
I don't know precisely what combination of specifications, standards, and marketing is needed (Cloud Application Resource files, Java Cloud Edition, Certified Cloud Platforms... oh my!), but that's a more constructive conversation - and one more likely to produce results - than arguing over interpretations of specs never designed to support cloud computing.
I would certainly hate to have to point to any other competitive offerings as a possible source of the angst over interpretations of "pure" Java...