Questions from Customers

We often get asked about questions from customers about the technologies behind stormmq.

You might also want to check  Frequently Asked Questions

We often get asked about questions from customers about the technologies behind stormmq.

We’ve tried to answer some of the common ones.

We decided to design stormmq around the emerging AMQP 1‧0 standard because it’s extremely reliable, flexible and it can be used for many messaging scenarios. It scales from simple processes interacting on one machine all the way up to huge, high‐bandwidth set ups of different vendors systems talking across the internet.

No! The value of using open protocols like AMQP is that it means you can move! Open protocols have strict rules for the behavior of the messaging provider (stormmq) and client (your software components). This gives everybody advantages over what’s gone before. You are not locked into one supplier for the server or client – in just the same way that SMTP, HTTP, FTP, etc. have created interoperable systems.

The vendors behind AMQP are completely committed to interoperability… so much so that we have organised four ‘connect‐a‐thons’ between the various AMQP implementers so that we can ensure that this happens.

Certainly not, unlike JMS, which merely defines an API, AMQP is a wire‐level protocol. A wire‐level protocol is a description of the format of the data that is sent across the network as a stream of octets. Consequently any tool that can create and interpret messages that conform to this data format can interoperate with any other compliant tool irrespective of the implementation language.

The differences between XMPP and AMQP are not obvious at first. XMPP is often mistaken as a message queue, especially because of the ability to send “offline chats” and various “targeted message” abilities. Importantly, AMQP supports all of this, and so much more, such as real database‐like transactions and deep security, without some of the really annoying stuff such as roster management.

XMPP was designed as a one‐on‐one communication protocol. You can add extensions to allow things like “broadcasting” but this not supported by default. AMQP supports one‐on‐one and one‐to‐many communication through its clever message/exchange system.

In most cases I would be very reluctant to replace your existing solution if you’re already happy as it’s unlikely to give you a return on your investment. An upgrade would only seem necessary if you have one of the following needs:–

  • You need to interoperate with other systems
  • You need to talk to systems written in more than one programming language (eg you’re using JMS or MSMQ)
  • The current solution is expensive (in terms of licence fees, consultancy or time investment to maintain)
  • You want to outsource administration, maintenance and support to reduce costs
  • You can’t scale out easily
  • The performance isn’t good enough.

If the answer to any of these questions is yes then you should investigate the a move to stormmq.


  Raphael ‘Raph’ Cohn

Raphael ‘Raph’ Cohn
Title
Chief Architect
Co‑Founder
Company
stormmq
Phone
+44 (0) 7590 675 756
Email
raphael.cohn@stormmq.com

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.