Alternate Comet Ruby On Rails

I happened to have a talk about the previous post to Raja. The implementation had its own problems and changes.

Firstly : The Service Layer of the app, the part which communicates with the queue, must be separated from the controller. We don't want the controller to have a heavy load. The service layer will not know the part of the application that communicates with it and the controller will not know who its contacts. This ensures that even if the service layer has implementation changes, it will not affect the controller thus making it entirely a different entity. I guess this kind of distinction will only come with age and experience. The Facade Pattern is the base.

Secondly: The application is better off with cache implementations. Mainly because the queues are designed to serve a purpose. Communication between apps. The Cache will also be maintained by a service layer and the access via the controller will either be fetched from the cache or if expired from the database. To have a uniformity between the kind of platforms accessing the application (say Adobe AIR and the browser accessing the Mongrel server), we could have an identifying parameter parameter passed along with the url which tells the controller the type of client and the resultant format of output (say XML/ JSON/RHTML).

I feel I have lifted myself a step now !! Thanks Raja .

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 !!