Why is a clean room JMS product a better performer than IBM MQ and MSMQ for publish/subscribe?

Why is a clean room JMS product a better performer than IBM MQ and MSMQ for publish/subscribe?

From your article on the differences between IBM MQ, MSMQ and JMS can you give me more detail on the following statement you made? Why is a clean room JMS product a better performer than IBM MQ and MSMQ for publish/subscribe?

    Requires Free Membership to View

    When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSOA.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSOA.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

Internally, IBM MQ and MSMQ only implement the message queueing model, but not the publish/subscribe model. Hence, in IBM MQ, the JMS pub/sub model is realized atop of message queues, by creating one queue per subscriber, for example. This works but will not necessarily lead to good performance or scalability, as the middleware is not aware of pub/sub communication and thus does not provide any optimizations for that.

A clean-room JMS server typically provides a "native" implementation of the pub/sub domain, without simply layering it atop point-to-point queue. Some clean room JMS products even utilize IP multicast to broadcast JMS messages over local area networks. This further increases the scalability.

This was first published in April 2002