Recently I scratched an itch and posted a module onto Drupal.org as a sandbox. It is perhaps slightly misnomered in “Bean Stomp” which is its development name. It is an integration of Jeff Mesnil’s Stomp over WebSockets JavaScript library which allows real time updating of a page without polling or similar overhead.
I had been thinking about doing this for a while. In the last Oxford Drupal User Group meeting, the BEAN (Block Entities Aren’t Nodes) module was mentioned. This allows a module to declare types of blocks which a user can then use as a content type. Instead of having to create various forms, it hooks into the content section. The BEAN project page has some excellent tutorials as to how to use it which I’m not going to reproduce here. I decided to use the module and put in a field for a description. Using BEAN gave me a way of creating an easy to use block which could be re-purposed if necessary and to which a content creator could add a description if required.
Back from the digression….
I have an interest in messaging and there already exists a STOMP module which provides an integration into ActiveMQ using STOMP. I haven’t fully tried it yet but I wanted to provide a way of a message system updating a screen remotely with feeds without polling a back end.
One way of doing this is to set up a page which can be called in a similar fashion to the way that autocomplete works: a remote page which wraps around the STOMP library and present the message body to the screen and the calling page works out how to display. I wrote something like this several months ago but decided that it was too scrappy to be released.
After a webinar with him, I read Charles Moulliard’s post on using Apache Camel with Web Sockets. The post not only talks about the example but also shows how to set ActiveMQ up correctly for Web Sockets. Essentially this is an update of the Stock Ticker example which ships with ActiveMQ and pushes stock information to the JavaScript and presents this to the screen.
My intention was to use a similar mechanism so that back end systems could send updates to users. For example if a system had an urgent update for users, this could be pushed out immediately without a page needing to spend a while waiting for an update. Quite simply, this is all that the module does.
On install, the admin form needs to be set up with the user name, password, host name and port and the topic or queue name. This is passed to the JavaScript with the Drupal.settings options. The block is then set up in the same way that BEAN’s are normally.
When the page is loaded, any messages are then printed out to the screen very quickly.
As a test, I set up a simple STOMP script in PHP running on the command line and then sent it off to the ActiveMQ server. The server internally routes it to the correct queue which is consumed by JavaScript. (Of course, if I connected a standard STOMP consumer to it in equal fashion then the messages would be sent in a round robin.) The JavaScript simply prints the messages out to the screen, appending it to the message class.
It is an extremely simple mechanism which satisfies my original curiosity in writing something where updates can be published.
Where I would like to go is to develop this from the simple print to screen to being a list of messages which are printed out. It also needs testing with other STOMP and Web Sockets supporting messaging system, such as RabbitMQ.
Since the script is written in JavaScript, a sensible network design should be used where the Drupal system reads from a public endpoint, as variables could be read using console.log() in Chrome.
What it shows is that message queueing can also be used to send updates out rather than purely being an arcane piece of middleware used for integration. Real time updating can be done from these useful tools rather than having to use Node.JS (and nothing against Node, I wanted to do some thing slightly different).
I am rather glad that I wrote the module and, more importantly, published it. It is simple, perhaps overly so and there is room for improvement which can always come. Perhaps this is from the fact that this module was developed from curiosity rather than a direct need.
No Comments