Archive for the ‘web messaging’ Category

Introducing RabbitMQ-Web-Stomp

Monday, May 14th, 2012

For quite a while here, at RabbitMQ headquarters, we were struggling to find a good way to expose messaging in a web browser. In the past we tried many things ranging from the old-and-famous JsonRPC plugin (which basically exposes AMQP via AJAX), to Rabbit-Socks (an attempt to create a generic protocol hub), to the management plugin (which can be used for basic things like sending and receiving messages from the browser).

Over time we've learned that the messaging on the web is very different to what we're used to. None of our attempts really addressed that, and it is likely that messaging on the web will not be a fully solved problem for some time yet.

That said, there is a simple thing RabbitMQ users keep on asking about, and although not perfect, it's far from the worst way do messaging in the browser: exposing STOMP through Websockets.


How to compose apps using WebSockets

Thursday, February 23rd, 2012

Or: How to properly do multiplexing on WebSockets or on SockJS

As you may know, WebSockets are a cool new HTML5 technology which allows you to asynchronously send and receive messages. Our compatibility layer - SockJS - emulates it and will work even on old browsers or behind proxies.

WebSockets conceptually are very simple. The API is basically: connect, send and receive. But what if your web-app has many modules and every one wants to be able to send and receive data?


AtomizeJS: Distributed Software Transactional Memory

Tuesday, February 21st, 2012

AtomizeJS is a JavaScript library for writing distributed programs, that run in the browser, without having to write any application specific logic on the server.

Here at RabbitMQ HQ we spend quite a lot of time arguing. Occasionally, it's about important things, like what messaging really means, and the range of different APIs that can be used to achieve messaging. RabbitMQ and AMQP present a very explicit interface to messaging: you very much have verbs send and receive and you need to think about what your messaging patterns are. There's a lot (of often quite clever stuff) going on under the bonnet but nevertheless, the interface is quite low-level and explicit, which gives a good degree of flexibility. Sometimes though, that style of API is not the most natural fit for the problem you're trying to solve - do you really reach an impasse and think "What I need here is an AMQP-message broker", or do you, from pre-existing knowledge, realise that you could choose to use an AMQP-message broker to solve your current problem?

AtomizeJS exists at the opposite end of the spectrum. There is lots of messaging involved, but you almost never get to see any of it. Instead, you write transactions in JavaScript that modify objects, and those objects are shared between all clients that are connected to the same AtomizeJS server. The API that you're given lets you do slightly more powerful things than you're used to from database transactions, in particular, retry allows you to abort a transaction but then restart it automatically once someone else has changed one of the variables you read. This means you have the observer-pattern, and from that you can then build any explicit messaging patterns you want. In most cases, I doubt you'll be building APIs that say send or receive, instead you'll be building richer data-structures - work queues, shared dictionaries etc. The question to pose then is: is it easier to build these things based on top of a transaction-like API such as offered by AtomizeJS, or on top of an explicit messaging API such as offered by RabbitMQ and AMQP brokers. There is no one solution and horses-for-courses etc, but please leave your thoughts below.

The gain that AtomizeJS provides is not so much in the use of STM from the browser, but the use of STM against a distributed object. This allows you to trivially share state between browsers, modify it safely in intuitive terms, and thus build your applications with little or no application-specific server-side code. Currently, it's a little clunky to use with browsers that don't support bleeding-edge JavaScript features (though I've provided some tooling to try and mitigate this), and everything does work with the latest versions of Chrome, Firefox, IE, Safari, and Opera. Please have a go and let us know what you think!

SockJS 0.2 released!

Tuesday, January 24th, 2012

SockJS version 0.2 has been released:

You can test it in the usual playground:


Ponies, Dragons and Socks

Thursday, November 3rd, 2011

We were wondering how to present SockJS and its possibilities to a wider audience. Having a working demo is worth much more than explaining dry theory, but what can you present if you are just a boring technologist, with no design skills whatsoever?

With questions like that it's always good to open a history book and review previous generation of computer geeks with no artistic skills. What were they doing? On consoles with green letters they were playing geeky computer games, MUDs (Multi User Dungeons) were especially popular.

Hey, we can do that!


Keeping It Realtime Conference (Portland, OR)

Wednesday, October 19th, 2011

There's a lot of hot stuff happening in the web technology lately. JavaScript seems to be bearing the torch, both browser-side and server-side.

At the RabbitMQ HQ we're interested in developments in the wide world of messaging, and we're particularly excited about the JavaScript angle on messaging - namely WebSockets and related technologies.


PubSubHuddle “Realtime Web” talk

Monday, September 26th, 2011

I was asked to do a short presentation during the PubSubHuddle meetup. The talk was about current development of WebSockets, its issues and building web applications using them.



SockJS – WebSocket emulation

Tuesday, September 13th, 2011

WebSocket technology is catching up, but it will take a while before all browsers support it.

In the meantime there are loads of projects that aim to substitute for WebSockets and enable 'realtime' capabilities for web apps. But all attempts solve only a part of the general problem, and there isn't any single solution that works, is scalable and doesn't require special deployment tricks.


SockJS – web messaging ain’t easy

Monday, August 22nd, 2011

The idea of 'realtime web' or messaging using web browsers has been around for quite some time. First it was called 'long-polling', then 'Comet', the latest incarnation is named 'WebSockets'.

Without doubt it's going in a good direction, WebSockets is a neat technology.

But during the fight for realtime capabilities we've lost focus on what is really important – how to actually use messaging. In the web context everything is request-response driven and marrying a typical web stack to asynchronous messaging isn't easy.