Which one to choose from STOMP/AMQP?

Question

i am using the node.js as client to jms topic.There are two protocols available to make the connection on Topic. Theses are Stomp and AMQP. I am read brief about them at http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol and http://en.wikipedia.org/wiki/Streaming_Text_Oriented_Messaging_Protocol. Both seems to be wire level protocol i.e data that is sent across the network as a stream of octets.I do not find any concrete reason which one should be preferred. If someone can shed light on it, it would be helpful.

Another point is both the protocol takes pride in stating them as interoprable. Does the interoperable term means that if someone want to take off specific message broker implementation say apache active MQ and instead want to plugin Websphere MQ , transition will be smooth(provided both support AMQP/STOMP or any other wire levl protocol)?

Answer 1

You may see a difference in performance (refer to this benchmark based upon many factors including message size and persistence requirements for the queue entries.

As is often the case, there are other factors to consider as well, especially if your message size/count/etc. doesn't mean there's a clear winner in terms of performance and no one protocol meets your functional requirements in a way the other does not.

This article in particular hints there may be more fragmentation in the different STOMP broker implementations. Quoting from that article

STOMP...uses a SEND semantic with a “destination” string. The broker must map onto something that it understands internally such as a topic, queue, or exchange. Consumers then SUBSCRIBE to those destinations. Since those destinations are not mandated in the specification, different brokers may support different flavours of destination. So, it’s not always straightforward to port code between brokers.

At least with AMQP (which touts interoperability as one of its most important advantages) the only issues you should have with switching providers/languages are those inherent in setting up said new providers. For example, I've read ZeroMQ is likely to take more configuration work on your part than RabbitMQ, but that's not really due to any attributes specific to AMQP.