Messaging has been used successfully all over the world as a basic communication mechanism. Messaging has always been the only commonly used method of communication, whether it is human-to-human, machine-to-human, or machine-to-machine. There are two basic mechanisms for exchanging messages between two parties (or more).
- Synchronous messaging
- Asynchronous messaging
Synchronous messaging is used in this situation when the message sender expects to receive a response within a certain time frame before proceeding to the next task. Basically it’s “blocked” until he receives a response.
Asynchronous messaging means that the sender doesn’t require an immediate response and doesn’t block the entire process. Responses are optional, the sender always does the rest.
The techniques mentioned above make extensive use of asynchronous message passing when programs on two computers communicate with each other. With the rise of microservices architecture, it became clear that we needed to build services using an asynchronous messaging model.
This has always been a fundamental question in software engineering, and different people and organizations have come up with different approaches. I will introduce three of the most successful asynchronous messaging techniques widely used in enterprise IT systems.
Java Messaging Service (JMS)
JMS is one of the most successful asynchronous messaging technologies. With the use of Java in many large enterprise applications, JMS has become the first choice for enterprise systems. It defines the API for building messaging systems.
The following are the main features of JMS:
- Standard messaging API for the Java platform
- Interoperability in Java or JVM languages like Scala, Groovy
- No need to worry about the underlying protocol
- There are two messaging models: queues and topics
- Support transactions
- Ability to define message format (message headers, attributes and content)
Advanced Message Queueing Protocol (AMQP)
JMS is great and people are very happy to use it. Microsoft developed NMS (.NET Messaging Service) to support their platform and programming language and it works just fine. But ran into interoperability issues. How do two programs in two different programming languages communicate with each other through their asynchronous message passing mechanisms. At this point it is necessary to define a common standard for asynchronous messaging. Neither JMS nor NMS has a standard underlying protocol. They can run on any underlying protocol, but the API is bound to the programming language. AMQP solves this problem by using a standard set of underlying protocols and adding many other features to support interoperability and enrich the messaging needs of modern applications.
The following are the main features of AMQP:
- Platform-independent underlying messaging protocol
- Consumer Driven Messaging
- Interoperability Across Languages and Platforms
- It’s the underlying protocol
- There are 5 exchange types direct, fanout, topic, headers, system
- cache oriented
- High performance possible
- Supports long-cycle messaging
- Supports classic message queues, round robin, store and forward
- Transaction support (across message queues)
- Support for distributed transactions (XA, X/OPEN, MS DTC)
- Secure with SASL and TLS
- Support proxy security server
- Metadata can control message flow
- LVQ is not supported
- Client and server peering
- Scalable
Message Queueing Telemetry Transport (MQTT)
Now we have JMS for Java-based enterprise applications and AMQP for all other application needs. Why do we need a third technology? It is specially designed for small devices. Devices with low computational performance cannot accommodate complex operations on AMQP, they need a simple and interoperable way to communicate. This is a fundamental requirement of MQTT, which today is one of the main ingredients in the Internet of Things (IoT) ecosystem.
The following are the main features of MQTT:
- Stream-oriented, low memory footprint
- Designed for sending short messages over low bandwidth between small silent devices
- Long-term store and forward is not supported
- Fragmented messages are not allowed (hard to send long messages)
- Support topic publish-subscribe
- Transactions are not supported (only basic acknowledgments)
- Messages are actually ephemeral (short cycle)
- Simple username and password, based on security without sufficient information entropy
- Secure connections are not supported
- message opaque
- Topic is global (a global namespace)
- Support for Last Value Queue (LVQ)
- Client and server asymmetry
- cannot be extended