Comet Ruby On Rails

The stuff that we do in the company is quite cool. It lets me, personally, to go through many technologies and implement many ideas. Concepts in theory is not great unless you start to implement those. A new thing that we are trying to accomplish is the functionality that a Comet Server gives, an HTTP push. This must be implemented in Ruby On Rails. Now the point here is that as HTTP is a connectionless protocol, we cannot pass stuff from the server to the client (unless the client requests). To have this functionality, we must either do a polling technique, where in the client constantly accesses the server for information or a live connection (may be a flash connection). Now another techniques which goes against this HTTP connectionless concept is the one that Comet deals with. A long lasting HTTP connection, either streaming or long.

Juggernaut is a Ruby On Rails plug-in which has this kind of functionality. It uses a flash open socket connection to get this server side push. Now this is great but the main problem that I felt is the firewall problem. Most of the firewalls do allows connections from other ports to go through them. Juggernaut also say that we could connect through the 443 port (http ssl) and that would solve the firewall issue. For a general need this is great.

My requirement was a little specific and I needed more stuff to get this stuff working. That was when I got to see the Active Messaging plug-in that Ruby On Rails had. A plug-in which could take in data from an Event Driven Architecture based product (say Queue / Messaging) and consume results in a Provider/ Subscriber model. The application also needed a lot of database optimization ( it will have to survive a lot of select statements). So an intermediated queue is perfect.

This is what it might look like.






















The only problem that I am facing is that by default the Active MQ is supposed to be a first Come First Serve queue. Now this does not serve my purpose as there might be many clients subscribing to the out queue. What I need is durable subscribers and that problem has been addressed in their thread.

This is a great way of accessing data (messages) as it is inherently the publisher/subscriber pattern (which I need) and the interoperability between different application could also be possible (a flex app accessing not HTTP information ?). Load balancing could also be done on queues !!