Apples and Oranges: Messaging Idioms

Superficially, stormmq seems to be like Amazon’s SQS, but they have very different messaging idioms.

This is the fourth of six articles in the series comparing stormmq and Amazon SQS.

Superficially, stormmq seems to be like Amazon’s SQS, but they have very different messaging idioms.

A messaging idiom is a typical way of sending data using queues.

There are several common idioms, including:‐

  • Point‐to‐Point
  • Store‐and‐Forward
  • Fire‐and‐Forget
  • Fanout
  • Publish‐Subscribe (Pub‐Sub)
  • Priority Queues

Amazon SQS and stormmq both support basic ‘point‐to‐point‘ messaging with ‘Store‐and‐Forward‘ and ‘Fire‐and‐Forget‘. This is where a message is created and posted to a queue by a producer, and a consumer then reads it off latter on. Messages are read in the order they’re received. For many applications, such as one system talking to another (eg transferring an end‐of‐day balance sheet) this is ideal. However, the disadvantage is that the producer has to know something about the consumer – namely, where he looks for his messages.

stormmq supports more complex idioms using routing. Sometimes, a producer wants all potential consumers to get his message. He doesn’t know who they are. Indeed, the list might change. An example might be broadcasting an alert, or sending heartbeats to servers. Fanout messaging is used for this. One message is sent to everyone interested, on multiple queues, in one go. This can be done with Amazon SQS, but would additional knowledge in the client (eg a database). The whole point of fanout is the client is dumb, and doesn’t need to know – it makes maintenance much easier, as producer and consumer are separated.

A more involved idiom still is publish‐subscribe, often just called “pub‐sub“. For this, a producer is sending messages, but not every consumer wants every messages. It’s like fanout but with picky users. A classic example might be a system sending out change requests or currency prices. For example, a manager might want to see all change requests, but a development team just gets those relevant to their project. Or some financial traders are betting on currency rates. Some want to know about dollar‐sterling, others euro‐sterling and others both. And there interests change over time. Doing this with Amazon SQS is fiendishly hard, and rather error prone. It’d need database lookups, application logic and a complex queue setup – especially if different queue permissions were needed. On the other hand, it’s pretty simple with stormmq.

Last, but no means least, is priority queuing. A priority queue is one which sorts messages by their urgency. When a message is requested by a consumer, the most urgent is given – this might not be the one that is oldest. These sorts of queues are used for call dispatch systems or ambulance HQs – typically, ‘end‐user’ systems. stormmq has simple priority queues. However, systems using them often have more complex logic for deciding priority (eg urgents first, but occasionally, an important if it’s over 10 mins) and so care needs to be taken in deciding the right queuing approach and solution. With such systems, uptime, reliability and data protection often matter more – something stormmq is ideal for.

In terms of enterprise functionality, Amazon SQS does not compare to stormmq.

  Raphael ‘Raph’ Cohn

Raphael ‘Raph’ Cohn
Chief Architect
+44 (0) 7590 675 756

I’ve designed, developed and burnt the midnight oil on the graveyard support shift from large systems for banks to troubleshooting telcos to pricing electricity in Singapore. The one thing that was always missing was ‘ready to use’ Message Queuing. Message Queues you could set up and tear down yourself without bureaucracy or crazy costs. Message queues that worked with anything. Then it dawned. Message Queuing should be a cloud based service.