In today’s Internet of Things, landscape allowing devices to communicate efficiently and effectively is key and as a part of allowing IoT Devices to do so, a message broker system is needed.
What’s a Message Broker?
The purpose of a broker is to take incoming messages from applications or IoT Devices and perform some action on them.
A message broker is an architectural pattern for message validation, transformation, and routing. It mediates communication amongst applications, minimizing the mutual awareness that applications should have of each other in order to be able to exchange messages, effectively implementing decoupling. The purpose of a broker is to take incoming messages from applications or IoT Devices and perform some action on them or move them to a message broker subscriber.
Some messaging functions do not require an intermediary message broker. For example, end-point objects can take the roles of publisher and subscriber, as in the observer design pattern. Message brokers are used to decoupling end-points and/or meet specific non-functional requirements and/or facilitate reuse of intermediary functions. For example, a message broker may be used to manage a workload queue or message queue for multiple receivers, providing reliable storage, guaranteed message delivery and perhaps transaction management.
Welcome to MQTT
MQTT… is bandwidth-efficient and uses little battery power
MQTT was developed by Andy Stanford-Clark (IBM) and Arlen Nipper in 1999 for the monitoring of an oil pipeline through the desert. The goals were to have a protocol, which is bandwidth-efficient and uses little battery power because the devices were connected via satellite link and this was extremely expensive at that time.
The protocol uses a publish/subscribe (pub/sub) architecture in contrast to HTTP with its request/response paradigm. Publish/Subscribe is event-driven and enables messages to be pushed to clients. The central communication point is the MQTT broker, it is in charge of dispatching all messages between the senders and the rightful receivers. Each client that publishes a message to the broker, includes a topic into the message. The topic is the routing information for the broker. Each client that wants to receive messages subscribes to a certain topic and the broker delivers all messages with the matching topic to the client. Therefore the clients don’t have to know each other, they only communicate over the topic. This architecture enables highly scalable solutions without dependencies between the data producers and the data consumers.
The difference to HTTP is that a client doesn’t have to pull the information it needs, but the broker pushes the information to the client
The difference to HTTP is that a client doesn’t have to pull the information it needs, but the broker pushes the information to the client, in the case, there is something new. Therefore each MQTT client has a permanently open TCP connection to the broker. If this connection is interrupted by any circumstances, the MQTT broker can buffer all messages and send them to the client when it is back online.
A topic is a simple string that can have more hierarchy levels, which are separated by a slash.
As mentioned before the main concept in MQTT is to dispatch messages to topics. A topic is a simple string that can have more hierarchy levels, which are separated by a slash. A sample topic for sending temperature/humidity data of a warehouse could be location6/north-west/temphumid. On one hand the client can subscribe to the exact topic or on the other hand use a wildcard. The subscription tolocation6/+/temphumid would result in all message sent to the previously mention topic location6/north-west/temphumid as well as any topic with an arbitrary value in the place of the warehouse, for example, location6/south-east/temphumid. The plus sign is a single level wild card and only allows arbitrary values for one hierarchy. If you need to subscribe to more than one level, for example to the entire subtree, there is also a multilevel wildcard (#). It allows subscribing to all underlying hierarchy levels. For example, location6/# is subscribing to all topics beginning with location6.
The right platform
When choosing the correct IoT platform it’s important to now consider what message broker is brokering the messages between your devices and applications.
Companies are often concerned that their employees lack IoT skills and knowledge, along with senior managers lacking knowledge of, and a commitment to, the required technologies to succeed with an IoT strategy. The Internet of Things is new and often a very nebulous idea. In fact, 70% of companies often look to outside consultants or IoT companies for help or try to learn from early movers in similar markets.
When companies look to secure outside help they tend to be more successful and reach the market faster. Consultants have often seen the pitfalls and can help identify issues early because of the experience they already had with launching IoT based projects.
Let Echolo help you with you next or ongoing IoT project today!
Echolo IoT Platform
Our custom designed IoT platform uses the latest technologies to make your next IoT project highly efficient. Contact us to see if the Echolo IoT can help you get your project to market faster.
