Computing in the cloud... it’s all the buzz these days as seen by ec2, google, rackspace, microsoft and many more. There are lots of cool benefits of using the cloud, increase speed of deployment, quickly create real demos for potential clients, handle load increases dynamically, self healing systems, and lots of business like reasons too.

My cloud ambitions are seemingly straight forward:
1) Make our apps run seamlessly in the cloud.
2) Make our apps run just as seamlessly without a cloud.
3) Speed up deployment time (self healing and load handling)
4) Have fun learning and leveraging the new technology

One of the first roadblocks for cloud computing is how to best enable a mix of scheduled, durable, and instant messaging among the application servers. There are a ton of open source and free solutions, but as is usually the case they all are missing something. I instantly ruled out any service that could not be embedded, deploying a web app takes enough time to push out and support, I don’t really want to support more then one. 

We implemented 2 solutions

Quartz Scheduler - This was a pretty good drop in framework that allows us to create load balanced threaded task execution that can be persisted in the database. We only needed to make two changes to the standard framework. First we created our own JDBC backed JobStore that hooks into our c3p0 database pool. We also (and this wasn’t really necessary and still unproven) made our own ThreadPool that is just a wrapped Java SDK Executor Cached ThreadPool. 

Apache Tribes - Our application was already using the JBoss backed JGroups framework for peer to peer messaging over UDP. We had thought about simply modifying our JGroups configuration to use TCP (necessary for the cloud and simple server configuration) but the amount of configuration and seemingly deep overhead provided by JGroups was more then we needed. We already are using Tomcat 6 as an application server so moving over to tribes was easy enough. Tribes provides pretty nice implementations for inter-app communication and membership. The default tribes system uses nio TCP for communications and UDP for membership. Our one smallish deviation from the more normal use is we don’t currently use the provided session replication. We have an internally managed tomcat channel that we use for our application messaging needs. One change we plan on making soon is to replace the UDP messenger with some sort of “smart” system to allow for instance cluster growth.