Apples and Oranges UK, Friday, 14th January 2011
This is the fourth of six articles in the series Apples and Oranges comparing stormmq and Amazon SQS.
There are several common idioms, including:‐
- 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.
About the AuthorGot a question but don’t want to comment? Email me.
Other posts you might likeGuess-timated
Every messaging systems offers a different approach and trade offs for security, authentication and permissions.
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different message properties.
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different models for acknowledgments and transactions.