Ramblings of an integration guy

Are you getting the message? IBM MQ - it's a beast but it's also the beast that's best at what it does - getting messages from A to B and not losing them. If you don't believe me then speak to the world's banks and see what they use. But, nothing is perfect and IBM MQ is old. It shows its age in some obvious ways - the security model is treacherous. I would also say that having, how many is it now...? 5 different ways to achieve HA (https://developer.ibm.com/articles/mq-ha-dr-options/), shows just how complex a beast it can be. Never mind the number of switches and options you have when setting up the queues and clients.  But... I still love it. It's what I specialise in and I still think it's a product that does what it says on the can - not lose your messages. However, wait for it.... it's biggest problem is.... I never know where my messages are at any give point in time. Trapping messages in MQ is hard so trusting that your message has been and gone ...

Often customers will say 'I want reliable messaging'. At this point I ask lots of questions – the main one being 'what happens if you lose that message'. Only then can I actually start to ascertain what *they* mean by 'reliable' In this blog I'd like to cover the messaging terms 'persistence', reliability', 'transactionality' and 'acknowledgements'. These are all terms used when talking about messaging. Unfortunately, it's the ease with which each term can interchange with the other that is the problem. Aligned to all these terms are the more specification like: at-most-once, at-least-once and once-and-once only.