Messaging has been the fundamental communication mechanism which has been succeeded all over the world. Either it is human to human, machine to human or machine to machine, messaging has been the single common method of communication. There are 2 fundamental mechanisms we used to exchange messages between 2(or more)parties.
- Synchronous messaging
- Asynchronous messaging
Synchronous messaging is used when the message sender expects a response to the message within a specified time period and waiting for that response to carry out his next task. Basically he “blocks” until he receives the response.
Asynchronous messaging means that sender does not expect an immediate response and does not “blocks” waiting for the response. There can be a response or not, but the sender will carry out his remaining tasks.
Out of the above mentioned technologies, Asynchronous messaging has been the widely used mechanism when it comes to machine to machine communication where 2 computer programs talk to each other. With the hype of the micro services architecture, it is quite evident that we need an asynchronous messaging model to build our services.
This has been a fundamental problem in software engineering and different people and organizations have come up with different approaches. I will be describing about 3 of the most successful asynchronous messaging technologies which are widely used in the enterprise IT systems.
Java Messaging Service (JMS)
JMS has been one of most successful asynchronous messaging technology available. With the growth of the Java adoption of large enterprise applications, JMS has been the first choice for enterprise systems. It defines the API for building the messaging systems.
- Standard messaging API for JAVA platform
- Interoperability is only within Java and JVM languages like Scala, Groovy
- Does not worry about the wire level protocol
- Supports 2 messaging models with queues and topics
- Supports transactions
- Defines the message format (headers, properties and body)
Advanced Message Queueing Protocol (AMQP)
JMS was awesome and people were happy about it. Microsoft came up with NMS (.Net Messaging Service) to support their platform and programming languages and it was working fine. But then comes the problem of interoperability. How 2 programs written in 2 different programming languages can communicate with each other over asynchronous messaging. Here comes the requirement to define a common standard for asynchronous messaging. There was no standard wire level protocol with JMS or NMS. Those will run on any wire level protocol but the API was bound with the programming language. AMQP addressed this issue and come up with a standard wire level protocol and many other features to support the interoperability and rich messaging needs for the modern applications.
Here are the main features of AMQP:
- Platform independent wire level messaging protocol
- Consumer driven messaging
- Interoperable across multiple languages and platforms
- It is the wire level protocol
- Have 5 exchange types direct, fanout, topic, headers, system
- Buffer oriented
- Can achieve high performance
- Supports long lived messaging
- Supports classic message queues, round-robin, store and forward
- Supports transactions (across message queues)
- Supports distributed transactions (XA, X/Open, MS DTC)
- Uses SASL and TLS for security
- Supports proxy security servers
- Meta-data allows to control the message flow
- LVQ not supported
- Client and server are equal
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 3rd technology? It is specifically for small guys. Devices with less computing power cannot deal with all the complexities of AMQP rather they want a simplified but interoperable way to communicate. This was the fundamental requirement for MQTT, but today, MQTT is one of the main components of Internet Of Things (IOT) eco system.
Here are the main features of MQTT:
- Stream oriented, low memory consumption
- Designed to be used for small dumb devices sending small messages over low bw networks
- No long lived store and forward support
- Does not allow fragmented messages (hard to send large messages)
- Supports publish-subscribe for topics
- No transactional support (only basic acknowledgements)
- Messaging is effectively ephemeral (short lived)
- Simple username, password based security without enough entropy
- No connection security supported
- Message is opaque
- Topic is global (one global namespace)
- Ability to support Last Value Queue (LVQ)
- Client and server are asymetric
- Not possible to extend