MQTT and MQ Design Considerations

Question

I have no specific request; just need some design guidelines.

I came across this article on Node.js, MQTT and Web sites . I think we can achieve a similar goal using Node / Java + ActiveMQ + Websockets. My request is how to choose MQ and MQTT? Can I safely use an “open” server, such as mosquitto, in a mid-sized project compared to ActiveMQ?

This article had some insight, and it seems to me that I should use MQ and MQTT, since MQTT can help if I get light weight customers in the future.

Thanks!

Answer 1

Adding to what Shashi said, they have different possibilities and use cases.

MQTT defines a standard wired protocol for pub / sub and, as Shashi noted, is designed for very light environments. Thus, it has a very minimal wire format, several basic qualities of service and a basic set of functions.

Traditional message queuing systems, on the other hand, are usually proprietary (although AMQP seeks to change this), cover both point-to-point and pub / sub, offer many quality of service and tend to have a heavier wire format, although this exists to support advanced feature sets, such as addressing response, protocol translation, etc.

A good example of MQTT would be where you have endpoints in phones, tablets, and set-top boxes. They have minimal power, memory and system resources. As a rule, the connections from them either remain MQTT, and they talk to each other, or they connect to enterprise-class MQ, where they can interact with internal applications. For example, an MQTT-based chat client can talk directly to another through an MQTT broker. Alternatively, an MQTT-based content delivery system could connect to a corporate messaging network that hosted ads and other content to be delivered to applications running on phones and tablets. The internal base of the enterprise will manage all the statistics of the delivery of advertising and the views on which the accounts are based, and the MQTT foot allows you to download content with minimal battery or power consumption on the end device.

Thus, MQTT is used for embedded systems and end-user devices in which problems with power, bandwidth and network stability. This is often combined with traditional MQ messaging, although I have never seen MQTT used as an exclusive transport for traditional messaging applications. Presumably, this is due to the fact that MQTT does not have some more robust features, such as message correlation, reply to addressing, and point-to-point addressing, which have been the basis for messaging for 20 years.

Answer 2

The MQTT protocol is suitable for small devices, such as sensors, mobile phones, etc., which have a small amount of memory. These devices are usually located on a fragile network and usually have low processing power.

These devices connect to the organization’s internal network through the MQTT protocol to send and receive messages. For example, a temperature sensor in an oil pipeline would collect the temperature of the oil flowing through the pipe and send it to the control center. In response, a command message can be sent via MQTT to another device to reduce / stop the flow of oil through this pipe.

WebSphere MQ has the ability to send / receive messages to MQTT devices. Therefore, if you plan to implement a messaging solution that includes devices and sensors, you can consider MQ and MQTT.

NTN

Answer 3

As already discussed, MQTT defines an application posting protocol (that is, how information is organized and then serialized, before it is transmitted), Mosquitto, or something else that the MKTT broker does, is just an implementation of the hub and conversation integration template , like brokers based on JMS and AMQP, the difference is in the wired protocol at the transport level: AMQP defines a standardized protocol for transport wires, instead JMS brokers, such as ActiveMQ, define their own proprietary format, namely: OpenWire . Of course, non-standard implementations such as Mosquitto implement a proprietary wiring protocol (this affects compatibility, but may be the best choice in terms of performance).

Back to the question. Brokers such as Mosquitto can be used in real-world scenarios according to your needs in terms of scalability and reliability: typically clustering is necessary to ensure i. Availability, ii. Reliability and iii. Scalability. Brokers thought that PAN (Private Area Netorks), as a rule, did not provide OTB (Out of the Box) such functions - ActiveMQ provides this.

In conclusion, it depends on your requirements in order to choose the best solution for you.