Apples and Oranges UK, Monday, 17th January 2011
This is the fifth of six articles in the series Apples and Oranges comparing stormmq and Amazon SQS.
Amazon SQS and stormmq both support message properties. These are meta data that can be attached to your message (a bit like headers are attached to email) that help an application process a message. A classic example is a message id. However, both systems differ vastly in the range of properties offered, their granularity and understanding by the server.
In it we cover how message properties are used:‐
Intelligently by the Server
With stormmq, you can choose whether to use message ids or not; with Amazon SQS, you have to, and, more importantly, you’re constrained by the ones generated for you. This means you can’t set your own message ids with meaningful data. Every architect has an opinion about whether identifiers should be meaningful or just a random or incremented number, but message ids with meaning are often very useful. For example, it lets a receiver differentiate between different message creators, or use a missing number (in an increasing sequence) to warn an application that data has been lost somewhere (perhaps by an intermediary node transforming XML). The latter is a common approach in very large systems, where data is sent asynchronously by messaging and any ‘holes’ are filled in by the receiver making a synchronous request for it. It’s a consequence of thinking ‘things break and accidents happen’.
Both systems use data about the message to automatically delete messages. With stormmq, it’s optional, and can be chosen per message – perhaps 5 minutes for a stale stock price, perhaps never at all for an important invoice. With Amazon SQS, it’s 4 days or so. And it can’t be changed. For some audit requirements, or EU data protection directives, that might just not be good enough.
With stormmq, there are more properties the server understands, such as:‐
- whether your data is important and should be securely persisted, or;
- whether it is transient and (if we ever crashed) tolerable to lose. Such options control how fast data flows from producer to consumer – a choice you can make.
- is your message more important than others on the queue (priority queueing)
- precise message expiry
- deliver now or don’t bother (ie is someone connected to consume it)
With stormmq, whilst we provide several ‘precanned’ message properties that cater for common messaging needs (thereby allowing your clients to get on with things and not reinvent the wheel), we allow you to attach any additional metadata you need, typed as numbers, strings and the like, as you need it. With the AMQP API, that message data is available to parse separately from the content. With Amazon SQS, you can only add message properties if you define your own content schema, and embed headers in it. Consequently every message receive would require parsing of the data – not a fast option if you’re XML! With stormmq, your client can look at the dictionary of properties and make a decision to parse or not. Allowing you to read detailed metadata from the headers allows you process more messages, more quickly.
Amazon SQS and stormmq both let you set the MIME ContentType of your message so you know what it is. However, only stormmq lets you send plain text, binary, XML or any other format; we simply don’t care, because we never look at your message data. It’s opaque to us. With Amazon SQS, you’re constrained to a subset of Unicode – the W3C XML specification character set.
Enterprise message queue requirements are diverse. Amazon SQS is an excellent product, but it is not feature rich, if you need an enterprise message queue you need to look at AMQP, and perhaps 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 messaging idioms.
Superficially, stormmq seems to be like Amazon’s SQS, but they have very different models for acknowledgments and transactions.