Skip to main content
IBM Redbooks

WebSphere MQ Telemetry

Web Doc

Note: This is publication is now archived. For reference only.

thumbnail 

Published on 09 August 2012, updated 23 August 2012

  1. View in HTML
  2. .PDF (0.8 MB)

Other language versions

Share this page:
 
 

IBM Form #: TIPS0876

Authors: Martin Keen

    menu icon

    Abstract

    IBM® WebSphere® MQ Telemetry is a feature of IBM WebSphere MQ that extends the universal messaging backbone with the MQ Telemetry Transport (MQTT) protocol to a wide range of remote sensors, actuators and telemetry devices. MQTT is a messaging protocol that is lightweight enough to be supported by the smallest devices, yet robust enough to ensure that important messages get to their destinations every time. With the MQTT protocol, such devices as smart energy meters, cars, trains, satellite receivers, and personal healthcare devices can communicate with each other and with other systems or applications.

    Contents

    IBM® WebSphere® MQ Telemetry is a feature of IBM WebSphere MQ that extends the universal messaging backbone with the MQ Telemetry Transport (MQTT) protocol to a wide range of remote sensors, actuators, and telemetry devices (Figure 1). The MQTT messaging protocol is lightweight enough to be supported by the smallest devices, yet robust enough to ensure that important messages get to their destinations every time. With the MQTT protocol, smart energy meters and other devices, such as for cars, trains, satellite receivers, and personal healthcare, can communicate with each other and with other systems or applications.

    This solution guide provides an overview of the MQTT support that is provided by WebSphere MQ Telemetry. It provides information about the architecture of an MQTT solution and includes scenarios for use.


    Figure 1. WebSphere MQ Telemetry helps connect remote sensors, actuators, and telemetry devices


    Did you know?

    With the rise of various smart devices, the internet will evolve to an Internet of Things - billions of interconnected smart devices measuring, moving, and acting upon, sometimes independently, all the bits of data that make up daily life. The world is already increasingly instrumented, with examples ranging from tiny sensors and RFID tags in stand-alone products, through smartphones and location-aware GPS devices to notebook PCs and embedded systems. 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 respond as necessary to make life better. This is where MQTT can help.


    Business value

    IBM WebSphere MQ has long served as a reliable, universal messaging backbone enabling any-to-any connectivity. It runs on wide variety of platforms, has a number of language bindings, and a stable, backward-compatible API. It has become the accepted method of gluing disparate applications together.

    The piece that has been missing until recently is the ability to reliably connect the edges, the frontiers of the data network. Systems already exist that understand what actions to take based on the status of the remote device. 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 the following components are just some examples of those that can communicate with each other and with other systems or applications:

    • Smart energy meters
    • Industrial control systems
    • Satellite receivers
    • Healthcare monitoring devices
    • Sensors on everything from planes to trains to automobiles

    Usage of the MQTT protocol extends WebSphere MQ 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, some devices are battery-powered, which puts additional restrictions on their use for telemetry messaging.

    The MQTT protocol includes 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


    Solution overview

    With WebSphere MQ Telemetry, instrumented devices that are located anywhere in the world can connect to each other. And with WebSphere MQ, they can connect to enterprise applications and web services. The use of MQTT extends WebSphere MQ to remote devices and enables massive scalability. A WebSphere MQ server can handle up to 100,000 concurrent MQTT connections.

    WebSphere MQ Telemetry includes the following key components:
    • The MQ Telemetry service that runs on the WebSphere MQ server
    • MQ Telemetry clients that are distributed to remote devices and applications

    MQ Telemetry uses the MQTT protocol to send and receive messages between devices or applications and the WebSphere MQ queue manager. From the WebSphere MQ queue manager, the messages can be exchanged with other messaging applications. Such applications include similar telemetry applications, Message Queue Interface (MQI), Java Message Service (JMS), or enterprise messaging applications.

    MQTT uses a publish/subscribe messaging pattern that enables a loose coupling between the information provider, called the publisher, and consumers of the information, called subscribers. This coupling is achieved by introducing a message broker between the publisher and the subscribers (Figure 2).


    Figure 2. Two examples of publish/subscribe combinations

    Compared to the traditional point-to-point pattern, the advantage of the publish/subscribe model is that the publishing device or application does not need to know anything about the subscribing one, and vice versa. The publisher sends the message with an identifier that denotes its topic or subject area. The broker then distributes the message to all applications or devices that subscribe to that topic. In this way, the publish/subscribe pattern turns traditional point-to-point messaging into a multicast of content-based communications.


    Solution architecture

    The popularity of MQTT-based messaging stems from the simple way it allows information to be published or subscribed to, without needing to know who or what is sending or receiving the information. This simplicity allows each message to be small in size, reducing demands on the network and on the remote monitoring devices from which many MQTT messages emanate.

    The WebSphere MQ Telemetry daemon for devices is an advanced MQTT V3 client that can act as a concentrator to connect telemetry channels to a queue manager, shown in Figure 3.


    Figure 3. Typical system architecture with the WebSphere MQ Telemetry daemon for devices

    This connection makes it possible to minimize the number of concurrent channel connections on a WebSphere MQ queue manager. The daemon also can be used to store and forward messages from other MQTT clients. It connects to WebSphere MQ similar to an MQTT client but can also have other MQTT clients connected to it. You can even connect it to other telemetry daemons to create a complex network of remote devices.

    A WebSphere MQ application can send a message to an MQTT V3 client by using one of the following methods:
    • Publish the message to a topic (the publish/subscribe model)
    • Send the message to the client directly (the point-to-point model)

    Regardless of the method that is used, the message is placed by the queue manager onto a queue. Then the message is sent to the client by the WebSphere MQ telemetry service, as shown in Figure 4.


    Figure 4. Publishers and subscribers connecting to queue managers within a cluster


    Scenarios of use

    The MQTT messaging protocol is for devices in constrained environments, such as embedded systems with limited processing ability and memory or systems that are connected to unreliable networks. It provides the robust messaging features that are needed to communicate with remote systems and devices and use just a small portion of network bandwidth.

    Healthcare care study

    A medical organization wanted to create an at-home, cardiac pacemaker monitoring solution. The solution needed to address the following aspects of patient care:
    • Monitoring cardiac patients after they leave the hospital
    • Improving the efficiency of later checkups
    • Meeting new industry data-capture standards

    The company worked with IBM to create a solution in which an MQTT client is embedded in a home monitoring appliance that collects diagnostic data whenever the patient is close to a base unit. The base unit sends the diagnostic data over the Internet to the central messaging server. There, it is handed off to an application that analyzes the readings and alerts the medical staff if the patient shows signs of having difficulty (Figure 5).


    Figure 5. Home pacemaker monitoring solution with MQTT

    With this solution, the organization can provide a higher level of post-hospital patient care and early diagnosis of follow-up issues. It also saves money for the organization and its patients, because less travel is needed by either party and because patients who are doing well might be allowed to come in for checkups less often.

    Energy and utilities

    A utility company was faced with both rising costs to produce electricity and increasing demand for power from its customer base, which was unable, generally, to pay ever-increasing rates. Rather than passing on production costs that its customers are unlikely to pay, the company first sought a solution to reduce overall demand for electricity. This solution entailed placing smart meters in customers’ homes to remotely control the use of certain power-consuming devices. However, the solution needed to minimize use of the available data network, for which the company paid according to the volume of data transmitted.

    The next solution involved creating a virtual power plant (VPP) that sits between the company’s generating sources and its customers. In-home smart meters collect usage data for the appliances that are used in the home. Then, home gateway monitors, which have an advanced MQTT client, publish the usage data to the VPP at regular intervals over the local mobile telephone network.

    As illustrated in Figure 6, the VPP monitors energy consumption in real time, predicts upcoming consumption needs, and when necessary, lowers overall demand by taking control of electricity-using devices in customers homes. When instructions are sent to electricity-using devices in a home, the commands are pushed to the home gateway box by using MQTT.


    Figure 6. The virtual power plan that uses MQTT


    Integration

    Many IBM products have applications and devices that communicate by using the MQTT protocol:
    • WebSphere Message Broker

      • Support for the MQTT protocol is included in WebSphere MQ with telemetry channels. Messages from MQTT clients are made available by using JMS topic destinations or are routed to standard WebSphere MQ message queues. Communication that uses the MQTT protocol is accomplished by using the MQInput, Publication, JMSInput, and JMSOutput nodes of WebSphere Message Broker.
    • WebSphere Application Server


      • The WebSphere MQ JMS Resource Adapter is used for the interaction between WebSphere Application Server and WebSphere MQ. This resource adapter allows JMS applications and message-driven beans that are running in the application server to access the resources of a WebSphere MQ queue manager. The resource adapter supports both point-to-point and publish/subscribe messaging.
    • WebSphere Operational Decision Management

      • MQTT-based messaging systems can be integrated with WebSphere Operational Decision Management, a business events processing engine. This combination can turn simple status updates from remote devices into alarms that focus immediate attention on what is being monitored. WebSphere Operational Decision Management can be used to define and apply business rules to incoming events. Therefore, it is an ideal partner with MQTT messaging, which enables communication with devices at the farthest reaches of a network.
    • Intelligent Operations Center

      • You can integrate devices or applications that use the MQTT protocol with the IBM Intelligent Operations Center. The IBM Intelligent Operations Center is an event management system that can help monitor operations and predict and respond to changing situations. When MQTT devices are introduced, they connect to the internal event management engine, through which events and other updates are processed.
    • IBM Lotus® Expeditor integrator

      • Lotus Expeditor integrator uses the included IBM micro broker as the MQTT messaging provider and an IBM micro broker bridge. The IBM micro broker and broker bridge are used for transparent connectivity to other JMS-compliant messaging back ends, such as IBM WebSphere MQ.


    Supported platforms

    WebSphere MQ helps to integrate virtually anything, with support for more than 80 platform configurations. For the latest information about supported platforms, see the System Requirements for WebSphere MQ at:

    http://ibm.com/software/integration/wmq/requirements/


    Ordering information

    This product is only available through IBM Passport Advantage®. It is not available for shrink wrap.

    License function title: WebSphere MQ
    Product group: IBM MQSeries®
    Product category: MQSeries

    The following table shows the ordering information.

    Table 1. Ordering part numbers and feature codes
    Program namePID numberCharge unit description
    WebSphere MQ5724-H72Per Processor Value Unit (PVU) for Linux on System z
    WebSphere MQ5724-H72Per PVU
    WebSphere MQ5724-H72PROCESSOR-Day


    Related information

    For more information, see the following documents:

     

    Others who read this also read

    Special Notices

    The material included in this document is in DRAFT form and is provided 'as is' without warranty of any kind. IBM is not responsible for the accuracy or completeness of the material, and may update the document at any time. The final, published document may not include any, or all, of the material included herein. Client assumes all risks associated with Client's use of this document.