Overview of Message Queuing Telemetry Transport (MQTT)
This chapter introduces the Message Queuing Telemetry Transport (MQTT) protocol and how it can be used to connect various types of smart devices and applications that are measuring, monitoring, and, in certain cases, controlling the world today. This chapter also introduces IBM MessageSight. MessageSight is an appliance-based messaging server that is designed to handle large numbers of connected clients and devices and process high volumes of messages with consistent latency.
This chapter includes the following topics:
1.1 Building a Smarter Planet world
The concept of connecting our superabundance of devices to the Internet, known as the Internet of Things1 (IoT), is a critical foundation on which the IBM Smarter Planet® vision will be realized. In addition, supporting the IoT are new, more advanced approaches to telemetry that make it possible to connect all kinds of devices, wherever they might be, to each other, to the Internet, and to the business enterprise.
One of these advancements is the MQTT messaging protocol (http://www.mqtt.org). This protocol is so lightweight that it can be supported by some of the smallest measuring and monitoring devices, and it can transmit data over far-reaching, sometimes intermittent networks. MQTT is a publish/subscribe messaging transport protocol that is optimized to connect physical world devices and events with enterprise servers and other consumers. MQTT is designed to overcome the challenges of connecting the rapidly expanding physical world of sensors, actuators, phones, and tablets, with established software processing technologies.
Before getting into the details of MQTT, let’s take a brief look at the evolving world that developers who are using MQTT are working to connect.
1.1.1 The Internet of Things (IoT)
Anyone who has used a web browser and a search engine or social media site knows the power of the Internet to connect people to information or to other people. Yet, with the rise of various smart devices, the Internet will evolve to become the IoT (Figure 1-1), in which billions of interconnected smart devices are measuring, moving, and acting upon, sometimes independently, all the bits of data that make up daily life.
Figure 1-1 The Internet of Things (IoT)
To imagine what the IoT might bring about in the next 10 or 20 years, think about the remarkable things we already can do remotely:
•A connected car can predict parts failure and schedule maintenance. Driving habits can be captured and used for calculating insurance.
•A doctor can examine a patient in a distant city and see real-time health status information, such as blood pressure, heart rate, and so on.
•An energy company can monitor windmills in the middle of the ocean and remotely diagnose and cut off the problematic units.
•A homeowner can view his home on a web page, complete with the status of interior devices, such as the security alarm, heating system, and more.
The IoT will go beyond connecting people to information and to other people. Devices are interacting with devices, creating what might eventually become a global central nervous system (Figure 1-2).
Figure 1-2 Examples of the IoT global central nervous system
1.1.2 Smarter Planet concept
The IBM Smarter Planet concept is built on a set of pillars called the Three I’s, as listed here and illustrated in Figure 1-3 on page 4:
•Instrumented: Information is captured wherever it exists, such as through the use of remote sensors.
•Interconnected: Information is moved from the collection point to wherever it can be usefully consumed.
•Intelligent: Information is processed, analyzed, and acted upon to derive maximum value and knowledge.
Figure 1-3 The three pillars of the Smarter Planet concept
The world is already increasingly instrumented, with examples ranging from tiny sensors and radio-frequency identification (RFID) tags in stand-alone products, through smartphones and location-aware global positioning system (GPS) devices to notebook PCs and embedded systems. These devices typically have enough computing power to gather and transmit data, and certain devices have enough to respond to requests to modify their behavior.
These devices also are nearly all connected to some extent. Most have, or will have, an Internet address with which they can communicate directly across local networks or indirectly by way of the cloud. So, the concept of the IoT has already begun to emerge.
The next steps, then, are gathering all of the data that is collected by these small, medium, or even large devices, routing that data to where it is best interpreted, and using the world’s vast computational resources to understand what is happening, and to respond as necessary to improve the quality of life.
1.1.3 Telemetry and the Internet
Telemetry technology allows things to be measured or monitored from a distance. In addition, today, improvements in telemetry technology make it possible to interconnect measuring and monitoring devices at different locations, and to reduce the cost of building applications that can run on these smart devices to make them even more useful.
People, businesses, and governments are increasingly turning to smart devices and telemetry to interact more intelligently with the world. A man shopping for groceries wants to know what is currently in his pantry at home. A woman heading to Austin, Texas, wants to know whether flights into that city are currently delayed by weather. A motorist driving across town wants to know whether the main highway is still blocked by the car crash that was reported on the news. A doctor with a patient due to arrive in the office at 3 p.m. wants to know, in the morning, whether the patient’s blood pressure is stable enough to make the trip safely.
Information to help with each of these decisions can be made available from a variety of smart meters and devices.
The challenge is in getting the information from the devices to the people and applications that want to use the information, and to do so in time for the information to be used effectively. Ideally, this will have the added ability for the users and applications to reply to the devices with new instructions or requests. If the devices are widely distributed geographically, or if they have limited storage or computational abilities, the challenges increase considerably, as do costs.
Fortunately, these challenges are being overcome through the use of improved telemetry technologies and communication protocols that are making it possible to send and receive this information reliably over the Internet, even if the network is unsteady or the monitoring device has little processing power.
MQTT provides telemetry technology to meet the information challenges of today’s Internet users.
1.2 MQTT
MQTT is an extremely simple and lightweight messaging protocol. Its publish/subscribe architecture is designed to be open and easy to implement, with up to thousands of remote clients capable of being supported by a single server. These characteristics make MQTT ideal for use in constrained environments where network bandwidth is low or where there is high latency, and with remote devices that might have limited processing capabilities and memory.
1.2.1 Benefits of the MQTT protocol
The MQTT protocol offers the following benefits:
•Extends connectivity beyond enterprise boundaries to smart devices
•Offers connectivity options that are optimized for sensors and remote devices
•Delivers relevant data to any intelligent, decision-making asset that can use it
•Enables massive scalability of deployment and management of solutions
MQTT minimizes network bandwidth and device resource requirements and also attempts to ensure reliability and delivery. This approach makes the MQTT protocol particularly well-suited for connecting machine-to-machine (M2M), which is a critical aspect of the emerging concept of the IoT.
The MQTT protocol includes the following highlights:
•Open and royalty-free for easy adoption.
MQTT is open and standardized by the OASIS Technical Committee2, and MQTT connects to MessageSight, inside an enterprise network. This makes it easy to adopt and adapt for the wide variety of devices, platforms, and operating systems inside an enterprise network. This is depicted graphically in Figure 3-1 on page 46.
•A publish/subscribe messaging model that facilitates one-to-many distribution.
The sending application or device does not need to know the specifics of the receiver, even its IP address.
•Ideal for constrained networks (low bandwidth, high latency, data limits, and fragile connections).
MQTT message headers are kept as small as possible. The fixed header is just two bytes, and its on-demand, push-style message distribution keeps network utilization low.
•Multiple service levels allow flexibility in handling different types of messages.
Developers can designate that messages will be delivered at most once, at least once, or exactly once.
•Designed specifically for remote devices with little memory or processing power.
Minimal headers, a small client footprint, and limited reliance on libraries make MQTT ideal for constrained devices.
•Easy to use and implement with a simple set of command messages.
Many applications of MQTT can be accomplished using only CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT control packets.
•Built-in support for loss of contact between client and server.
The server is informed when a client connection breaks abnormally, allowing the message to be re-sent or preserved for later delivery.
1.2.2 Basic concepts of the MQTT protocol
The MQTT protocol is built upon several basic concepts, all aimed at ensuring message delivery and keeping the messages as lightweight as possible.
Publish/subscribe
The MQTT protocol is based on the principle of publishing messages and subscribing to topics, which is typically referred to as a publish/subscribe model. In this model, clients can subscribe to topics that pertain to them and therefore receive messages that are published about those topics. Alternatively, clients can publish messages to topics, therefore making them available to all subscribers to those topics.
Topics and subscriptions
Messages in MQTT are published to topics, which can be thought of as subject areas. Clients, in turn, sign up to receive particular messages by subscribing to a topic. Subscriptions can be explicit, which limits the messages that are received to the specific topic, or they can use multi-level wildcard designators (#) or a single-level wildcard designator (+) to receive messages for a variety of related topics.
Quality of service (QoS) levels
MQTT defines three quality of service (QoS) levels for message delivery, with each level designating a higher level of effort by the server to ensure that the message gets delivered. Higher QoS levels ensure more reliable message delivery but might consume more network bandwidth or subject the message to delays due to issues, such as latency.
Retained messages
With MQTT, the server keeps the message even after sending it to all current subscribers. If a new subscription is submitted for the same topic, any retained messages are then sent to the new subscribing client.
Clean sessions and durable connections
When an MQTT client connects to the server, it sets the clean session flag. If the flag is set to true, all of the client’s subscriptions are removed when it disconnects from the server. If the flag is set to false, the connection is treated as durable, and the client’s subscriptions remain in effect after any disconnection. In this event, subsequent messages that arrive carrying a high QoS designation are stored for delivery after the connection is reestablished. Using the clean session flag is optional.
The client will (or message)
When a client connects to a server, it can inform the server that it has a will, or a message, that will be published to a specific topic or topics in the event of an unexpected disconnection. A will is particularly useful in alarm or security settings where system managers must know immediately when a remote sensor has lost contact with the network.
1.2.3 The OASIS MQTT Technical Committee
The purpose of the MQTT Technical Committee is to define an open publish/subscribe protocol for telemetry messaging that is designed to be open, simple, lightweight, and suited for use in constrained networks and multi-platform environments. The Technical Committee will accomplish this purpose through the refinement of an input specification.
Background and opportunity
Many industries are seeing a trend and a demand for solutions that capture physical world events for use by enterprise and web applications. There is a need to capture and integrate data that is captured from sensors, actuators, and other types of devices with a wide range of application middleware and web programming models. These devices can be in an enterprise, or in stores, cars, mobile phones, and more, to capture events and transmit them to back-end applications.
Needs and requirements
A simple, lightweight, and easy to implement messaging protocol is required to connect applications on embedded and mobile devices with servers used in web, enterprise, and other applications, where a lightweight messaging protocol is a necessity. The protocol needs to cope with the network, hardware, and challenges with other resources, yet still provide the QoS required by the application.
Experience with messaging and events across many industry domains has identified key requirements for such a messaging protocol:
•The protocol needs to provide bidirectional messaging support to uniformly handle both signals and commands. Additionally, the protocol is required to deliver messages to and from constrained devices that are connected over networks that have limited bandwidth. Basic QoS levels are needed to reflect trade-offs among bandwidth, availability, and delivery guarantees. A subscriber must be able to set up a QoS that works in conjunction with the available constraints.
•Connectivity cognizance to support intermittently connected networks and devices. The publish/subscribe infrastructure needs to provide message subscribers and, if necessary, a means for making a decision about likely connected, disconnected, and error states of the end devices in the network.
•Loose coupling is required to support dynamic system environments, where a heavy influx of messages and events needs to be made available to enterprise applications and other consumers in an unanticipated manner. Time, space, and synchronization decoupling is needed.
•For constrained operations, the protocol has a means of supporting platforms, technologies, and networks that are driven by diverse equations of cost, technology, and physical constraints.
•Scalability that is suitable for supporting environments in which multiple devices, applications, and sensors need to be connected to a server infrastructure.
The value of standardization
Connectivity solutions currently exist to integrate these types of systems. However, the paucity of standardized messaging protocols that are designed explicitly to address the needs and requirements listed in “Needs and requirements” on page 7 has become a hindrance in growing opportunities for the IoT. The standardization of an open protocol that conforms to these technical and market requirements can overcome the inhibitors by providing the following benefits:
•Choices: The standard protocol needs to provide implementation choices for the various devices, networks, and suppliers, with no limit of choices and adaptability over time.
•Flexible Integration: Standardization needs to enable integration between the plethora of constrained devices and enterprise applications. This integration will assist in the widespread adoption of the protocol.
•Time to Market: The protocol needs to be open and one that scales well from critical, embedded systems up to high volume enterprise transaction processing, and one that is data, platform, and language independent. This will shorten the time to market and support new levels of integration.
•Skills: A standard, based on protocol and programming models, will stimulate skilled developers and encourage the adoption and use of the protocol.
For more details about the OASIS MQTT Technical Committee, visit this website:
1.2.4 The Eclipse Paho project
The Eclipse Paho project3, sponsored by iot.eclipse.org4, was developed to provide scalable, open source implementations of open and standard messaging protocols that support the requirements of M2M integration with web and enterprise middleware and applications. This includes client implementations for use on embedded platforms, with corresponding server support as determined by the community.
One of the major objectives of the Eclipse Paho project is to provide an effective level of decoupling between the device and applications. The project initially started with MQTT publish/subscribe client implementations for use on embedded platforms, but in the future, it will bring corresponding server support as determined by the community.
For M2M devices and client developers to integrate, develop, and test messaging components end-to-end, the Eclipse Paho project provides the framework to support the testing and development of end-to-end device connectivity with a server. The MQTT application described in this chapter uses the Java client implementation from the Eclipse Paho project.
The Eclipse Paho 1.0 release provides client libraries, utilities, and test material for the MQTT and MQTT-SN messaging protocols. MQTT and MQTT-SN are designed for existing, new, and emerging solutions for M2M and IoT. The Eclipse Paho project includes client libraries in Java, C/C++, Python, and JavaScript for desktop, embedded, and mobile devices.
For more details about the Eclipse Paho project, see this website:
Information is also available about the MQTT V3.1 Java and C clients, which IBM contributed, and which you can download from the following web pages:
1.2.5 Comparison of MQTT and HTTP
Although comparison is often made between MQTT and other common protocols, the most useful comparison is with the hypertext transfer protocol (HTTP) for the following reasons:
•HTTP is the most widely used and available protocol. Almost all computing devices with a TCP/IP stack have it. In addition, because HTTP and MQTT are both based on TCP/IP, developers need to choose between them.
•The HTTP protocol uses a request-and-response model, which is currently the most common message exchange protocol. MQTT uses a publish/subscribe model. Developers need to understand the relative advantages of each type of model.
Quick comparison of MQTT and HTTP
Table 1-1 provides a quick comparison to help developers choose the most suitable messaging protocol for applications.
Table 1-1 Quick comparison of MQTT and HTTP
 
MQTT
HTTP
Design orientation
Data centric
Document centric
Pattern
Publish/subscribe
Request and response
Complexity
Simple
More complex
Message size
Small, with a compact binary header that is just two bytes in size
Larger, partly because status detail is text-based
Service levels
Three QoS settings
All messages get the same level of service
Extra libraries
Libraries for C (30 KB) and Java
(100 KB)
Depends on the application (JavaScript Object Notation (JSON) or Extensible Markup Language (XML), but typically not small
Data distribution
Supports 1 to zero, 1 to 1, and 1 to n
1 to 1 only
Detailed comparison of MQTT and HTTP
The following list is a fuller explanation of the critical differences between the MQTT and HTTP protocols when used for devices:
•Design orientation:
 – MQTT is data-centric. It transfers data content as a byte array. It does not care about content.
 – HTTP is document-centric. It supports the Multipurpose Internet Mail Extensions (MIME) standard to define content type, but constrained devices usually do not need this advanced feature.
•Messaging pattern:
 – MQTT uses a publish/subscribe messaging pattern that has loose coupling. Clients do not need to be aware of the existence of other devices. They just need to care about the content to be delivered or received.
 – HTTP uses a request/response messaging model. It is a basic and powerful messaging exchange pattern, but the client needs to know the address of all devices to which it connects.
•Complexity of protocol:
 – The MQTT specification is short. It has few message types and only the CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, and DISCONNECT types are important for developers.
 – HTTP is a more complex protocol, with a specification that is more than 160 pages long. It uses many return codes and methods, such as POST, PUT, GET, DELETE, HEAD, TRACE, and CONNECT. It works well for hypermedia information systems, but constrained devices typically do not need all of its features.
•Message size:
 – MQTT is designed specifically for constrained devices. It includes only the features that are necessary to support them. The message header in MQTT is short, and the smallest packet size for a message is 2 bytes.
 – HTTP uses a text format, not a binary format, which allows for lengthy headers and messages. The text format is readable by human beings. Therefore, the HTTP protocol is easy to troubleshoot, which has contributed to its popularity. However, this format is more than is needed, or desirable, for constrained devices with limited computational resources in low-bandwidth network environments.
•QoS levels:
 – MQTT supports three QoS levels in message publication. Developers do not have to implement additional, complex features to ensure message delivery.
 – HTTP has no ability to try again or QoS features. If developers need guaranteed message delivery, they have to implement it themselves.
•Extra libraries:
 – MQTT works well on devices with limited memory, due, in part, to its small library requirement, which is only about 30 KB for the C client and 100 KB for the Java client.
 – HTTP does not require any libraries, but additional libraries of parsers for JavaScript Object Notation (JSON) or Extensible Markup Language (XML) are required if using the SOAP or Representational State Transfer (RESTful) style of web services.
•Data distribution:
 – MQTT includes a built-in distribution mechanism, supporting the 1 to 0, 1 to 1, and 1 to many distribution models.
 – HTTP is point-to-point and has no built-in distribution feature. Developers must create their own distribution mechanism or adapt common techniques, such as long-polling or by using, for example, the Comet programming model.
An actual example occurred at Facebook with their Facebook Messenger5 product. Engineers implemented the MQTT protocol instead of HTTP, because the users experienced latency problems when sending messages. Message delivery was reliable but slow with HTTP. A new mechanism was needed for maintaining a persistent connection with the messaging servers without consuming too much battery power. This is critical to users of the company’s social networking site, because so many use battery-powered mobile devices. The company’s developers solved the problem by using the MQTT protocol. By maintaining an MQTT connection and routing messages through its chat pipeline, message delivery was accomplished at speeds of just a few hundred milliseconds, rather than multiple seconds.
1.3 MessageSight
IBM provides a suite of messaging products that helps businesses to meet the demands of today’s interconnected world. By using the IBM portfolio of messaging products, you can achieve a solution that extends from back-end enterprise applications to include millions of mobile users. MessageSight is one of the latest additions to the IBM messaging family. It is an appliance-based messaging server that is optimized to address the massive scale requirements of M2M and mobile use cases. MessageSight is designed to sit at the edge of the enterprise and can extend your existing messaging infrastructure or be used stand-alone.
MessageSight joins the IBM portfolio of middleware to help bridge back-end enterprise environments to remote smart clients as the planet becomes more digitally interconnected. This allows organizations to provide an interactive experience with users and offer real-time analytics of large data volumes (Figure 1-4).
Figure 1-4 MessageSight extends your enterprise to remote wireless clients
The MessageSight appliance is built for high performance to offer persistent, transactional messaging. This hardware is 2U form factor and can connect to a 1 GbE, 10 GbE, or 40 GbE network. MessageSight includes built-in security, and permits integration with external Lightweight Directory Access Protocol (LDAP) security systems.
With MessageSight, devices can sense and respond to data coming from the edge of your enterprise. Messaging connectivity can be performed using MQTT, Java Message Service (JMS), or IBM WebSphere MQ. The ability to connect through MQTT makes the appliance ideal for use with mobile clients. Administration can be done by using the web GUI or a command-line interface (CLI). The high availability pair takes the form of a primary-standby configuration. The primary node continually replicates both the message store and the appliance configuration information to the standby node. If the primary node fails, the standby node has the latest data that is needed for applications to continue messaging services. Standby node does not accept connections from application clients or provide messaging services until a failover operation occurs.
Mobile application support is provided by MessageSight, and so, it can handle massive scaling of concurrent device connectivity and communication, offering high performance messaging. The appliance is demilitarized zone (DMZ) ready, allowing you to securely extend your existing messaging enterprise. The device can act as the gateway for business data that flows in and out of your enterprise network.
MessageSight is developer friendly, designed for easy deployment and easy integration. This book explores how MessageSight can be integrated with other IBM offerings to deliver a complete messaging solution that encompasses remote mobile clients and back-end enterprise systems.
The MessageSight appliance can be used either with the MQTT protocol for low latency publishing and subscribing (ideal for machine-to-machine (M2M)), or with the Java Message Service (JMS) to transfer messages received from remote clients to back-end applications.
Figure 1-5 on page 13 shows examples of how clients who are connected to MessageSight can interface with WebSphere MQ and other back-end applications. Here, you can see that MessageSight connects many users and devices on the Internet to services that are deployed on an intranet. The users, devices, and services interact with each other by exchanging messages through the appliance.
Figure 1-5 Typical MessageSight connectivity designs
MessageSight provides solutions to the following modern day challenges:
•A tremendous increase in the use of smartphones and tablets
The increase in the number of smartphones and tablets is creating many endpoints. Consumers expect near real-time communication between their devices and applications. Building these applications relies on a scalable, bidirectional communication infrastructure. Emerging standards, such as HTML5 web sockets, provide the basis for building rich mobile, intranet, and Internet applications. MessageSight is a highly scalable middleware messaging product that provides the full-duplex web communication that is required for rich Internet, intranet, and mobile applications.
•Device-to-device communication
The Internet is no longer just about web browsing. It is becoming a mesh of devices, such as sensors, monitors, machines, and cars, and these devices are becoming interconnected. Each device node attempts to publish data, consume data, or both in near real time. Applications attempt to consume data from these nodes, send data, or both. The IoT provides new challenges for traditional messaging infrastructures in terms of numbers of connected devices and the associated volume of messages.
Systems already exist that understand what actions to take based on the status of remote devices. However, communicating that status to the system has been a challenge, particularly if the network is constrained or if the device lacks the computational power required for traditional messaging.
With MQTT, smart energy meters, industrial control systems, satellite receivers, healthcare monitoring devices, and sensors on everything from planes to trains to automobiles can communicate with each other and with other systems or applications.
1.4 Benefits of using MQTT
Using the MQTT protocol extends enterprise messaging to tiny sensors and other remote telemetry devices that might otherwise be unable to communicate with a central system or that might be reached only through the use of expensive, dedicated networks. Network limitations can include limited bandwidth, high latency, volume restrictions, fragile connections, or prohibitive costs. Device issues can include limited memory or processing capabilities or restrictions on the use of third-party communication software. In addition, certain devices are battery-powered, which puts additional restrictions on their use for telemetry messaging.
MQTT was designed to overcome these limitations and issues and includes the following underlying principles:
•Simplicity: The protocol was made open so that it can be integrated easily into other solutions.
•Use of the publish/subscribe model: The sender and the receiver are decoupled. Therefore, publishers do not need to know who or what is subscribing to messages, and vice versa.
•Minimal maintenance: Features, such as automated message storage and retransmission, minimize the need for administration tasks.
•Limited on-the-wire footprint: The protocol keeps data that is overhead to a minimum on every message.
•Continuous session awareness: By being aware of when sessions have terminated, the protocol can take action accordingly, thanks in part to a will feature.
•Local message processing: The protocol assumes that remote devices have limited processing capabilities.
•Message persistence: Through the designation of a specific QoS, the publisher can ensure delivery of the most important messages.
•Agnostic regarding data type: The protocol does not require that the content of messages is in any particular format.
Table 1-2 lists potential scenarios where MessageSight and the MQTT protocol might be used to improve communication to and from remote devices or applications.
Table 1-2 Scenarios where MessageSight and MQTT can be used
Scenario
Key industries
Examples
Automated metering
•Chemical and petroleum
•Energy and utilities
•A homeowner uses smart metering to obtain a more accurate view of how each household appliance consumes electricity and how to make changes.
•An oil company monitors the gasoline sump levels at a gas station in real time and schedules a gasoline delivery when the sumps are nearing empty.
Distribution supply chain and logistics
•Retailers
•Distributors
•Consumer products
•Transportation
•A shipping company gains customer loyalty by providing real-time, detailed tracking information for cargo.
•A trucking company cuts costs using remote fleet monitoring, which enables more efficient use of each truck’s capacity on every run.
Industrial tracking and visibility
•Automotive
•Industrial manufacturing
•Aerospace
•Defense
•A manufacturing company automates inventory checking to improve the management of stock and to optimize production rates.
•An automobile company uses RFID tracking to obtain real-time details about the current stage of assembly of each new vehicle as it moves through the assembly line.
Health care quality and resource tracking
•Pharmaceutical
•Medical research
•Hospitals
•Nursing homes
•Waste management
•A medical clinic remotely tracks the vital signs of at-risk patients to help prevent sudden crises that might arise after a patient goes home.
•A research team monitors chemical reactions in a remote laboratory and alerts the chemist when a particular result or stage of development is achieved.
•A waste management company can be notified when the trash can is full and can be notified for pickup.
Location awareness and safety
•Chemical and petroleum
•Energy and utilities
•Homeland defense
•A gas company improves pipeline monitoring by tripling the number of remote control devices on the route from 4,000 to 12,000 devices.
•A government agency improves its early-warning system by placing remote sensors on dams and elsewhere in flood-prone regions.
Executive alerts
•Insurance
•Banking
•A bank retains more customers by monitoring all account-closing inquiries, analyzing this data, and contacting customers who might be considering closing their accounts.
•An insurance company sends claims adjusters to collect damage reports at disaster sites and collects the data in its central servers.
1.5 Where to use MQTT
In today’s world, there are many practical instances where MQTT and MessageSight implementations might offer a solution for an integrated system that allows users to interact using mobile devices. Here, we examine a few possible scenarios.
1.5.1 Connected car
MessageSight can enable customers to connect and interact with their cars. A connected car can use the MQTT protocol to send messages from the car to MessageSight and then notify the customer, as shown in Figure 1-6. For example, a connected car is one that is able to send diagnostic information to the automobile company. Also, the car can receive messages that might range from remotely locking the car to a request to send its current location.
Figure 1-6 Connected car
MQTT and MessageSight facilitate message routing, allowing the car to send diagnostic information to the automobile company. The car basically acts as a rolling sensor platform that publishes telemetric events. The MQTT protocol is used to transport data from the car sensors to the automobile company. This data can be analyzed using predictive maintenance analytics, acting as a virtual mechanic, which then sends a notification to the customer that service is needed before a component fails.
Also, the car can receive messages ranging from remotely locking the car, setting the climate controls (heat or air), or requesting that the car send its current location. Most existing connected car solutions have previously taken a mobile response time measured in tens of seconds. Tests with MessageSight using MQTT have shown the response time to be less than one second, equal to the time it takes to push a key fob.
1.5.2 Connected city
If we take the connected car scenario a step further, we can see how having the MQTT messaging features available within many cars can effectively translate into a connected city. If a car is involved in an accident that caused the airbag to deploy, it can trigger an event to be published. Publish and subscribe messaging allows different users to receive the alert that an accident has happened. It can be generic to inform other drivers of the location of the accident, or it can be specific to route only to the car owner’s family, and so on. The alert can be sent to emergency services to alert police or medics about the accident (Figure 1-7 on page 17).
Figure 1-7 Connected city
In the connected city example depicted in Figure 1-7, it is easy to see how millions of cars sending messages can create a massive amount of data to be processed. To date, capturing and analyzing this amount of data in real time was a technical challenge. Using MessageSight in conjunction with IBM InfoSphere® Streams, stream computing helps to alleviate this dilemma by allowing real-time analytics to be performed on big data.
1.5.3 Connected home
The interactive user experience can also apply to a connected home. Figure 1-8 shows a scenario in which changing a channel on the TV creates a message that is sent back to the data center. In turn, this determines how advertising might be catered specifically to the consumer currently watching TV.
Figure 1-8 Connected home
Other convenience features of the connected home are that a homeowner can adjust the thermostat or unlock a door using a mobile device. These types of features not only offer convenience; they also help to contribute to a Smarter Planet environment by being able to lower utility usage, as needed. The ability to remotely manage door locks and utilities can apply to a rental or vacation property, as well.
1.5.4 Connected consumers
Connected consumers can be provided with a unique shopping experience tailored to their location and shopping preferences. Bidirectional communication between a retailer’s back-end systems to the customer’s mobile devices allows retailers to provide notifications to consumers based on the customer’s proximity to the store (Figure 1-9).
Figure 1-9 Connected consumers
For example, if a customer is browsing a product at home on a mobile device, then enters a retail store, the retailer’s mobile application can be used to find where the product is located in the store. The retailer might even want to push a notification for a sale or discount on that or a similar product when the customer is browsing in the store.
The retailer can enable business rules to handle database calls, analytics, pricing, and so on to cater to notifications that are based on the individual consumer, even the consumer’s current geographic location. The retailer’s central office is able to monitor the millions of messages using MessageSight.
1 The Interconnecting of Everything, an IBM Redbooks Point-of-View publication:
2 OASIS: Advancing open standards for the information society; for details, visit this website:
4 IoT.eclipse.org is making the Internet of Things (IoT) development simpler: http://iot.eclipse.org/
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset