IBM MessageSight and MQTT
The integration of the IBM MessageSight appliance with the MQTT protocol provides reliable, secure messaging features that can be scaled to over one million concurrent remote client connections. The IBM MessageSight appliance can extend the reach of an existing enterprise messaging network.
This chapter describes how the MQTT protocol is used by the IBM MessageSight appliance, and includes a simple startup configuration. MQTT is ideal for mobile applications because of its small size, minimized data packets, and efficient distribution of information to one or many subscribers.
For the examples shown in this chapter and throughout this IBM Redbooks publication (unless otherwise noted), the WebSphere MQ software is installed and configured on a Linux 64-bit system.
This chapter provides information about the following topics:
•MQTT protocol
•Features of IBM MessageSight
•Getting started
•Configuration and administration
2.1 MQTT protocol
MQTT is an extremely simple and lightweight messaging protocol. The publish/subscribe architecture is designed to make it easy to build loosely-coupled HTML5, native, and hybrid mobile applications. MQTT is 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.
MQTT minimizes network bandwidth and device resource requirements when attempting to ensure reliability and delivery. This approach makes the MQTT protocol particularly well-suited for your business applications to interact with remote devices, such as mobile phones.
The MQTT protocol enables you to extend connectivity beyond your enterprise boundaries to smart devices. The protocol is efficient on battery, processor, and network bandwidth in mobile scenarios.
The MQTT protocol includes the following highlights:
•Open and no-charge for easy adoption. MQTT is open to make it easy to adopt and adapt for the wide variety of devices, platforms, and operating systems that are used at the edge of a network.
•A publish/subscribe messaging model that facilitates one-to-many distribution.
•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 use low.
•Multiple service levels allow flexibility in handling different types of messages. Developers can designate that messages will be delivered at most one time, 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 just the CONNECT, PUBLISH, SUBSCRIBE, and DISCONNECT commands.
•Built-in support for loss of contact between client and server. The server is informed when a client connection breaks abnormally, enabling the message to be resent, or preserved for later delivery.
MQTT was co-invented by IBM and Eurotech. It was designed specifically for sending data over networks where connectivity is intermittent or bandwidth is at a premium. The protocol is simple, making it extremely efficient for reliable publish/subscribe messaging. MQTT enables devices to open a connection, keep it open using little power, and receive events or commands using a small two-byte header.
The MQTT protocol is built upon several fundamental concepts, all aimed at assuring message delivery and keeping the messages themselves as lightweight as possible. The following list includes a few features of the MQTT protocol:
•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. Each message is published to a specific named topic. Clients who want to receive messages can make subscriptions against the topics that interest them.
•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 at hand, or you can use wildcard designators, such as a number sign (#) to receive messages for a variety of related topics.
For example, topic strings might include scores/football and scores/cricket, where a subscriber uses the score number to receive scores of all sports.
•Quality of service (QoS) levels
MQTT defines three QoS levels for message delivery:
 – QoS 0: At most once
 – QoS 1: At least once
 – QoS 2: exactly once
Each level designates 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 use more network bandwidth.
•Retained messages
Retained  messages is an MQTT feature where the server keeps the messages and delivers them to future subscribing clients. A retained message enables a client to connect and receive the retained message as soon as it creates the subscription, without waiting for a new publication.
•Clean sessions and durable connections
There are two types of MQTT clients:
 – Those which the server remembers when they disconnect
 – Those which the server does not remember
When an MQTT client connects to the server, the client indicates which type of client to use by setting the clean session flag. If the clean session flag is set to true, all of the client’s subscriptions are removed when the client 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.
•Will messages
When a client connects to a server, it can inform the server that it has a will message that is published to a specific topic or topics in the event of an unexpected disconnection. A will message is particularly useful in settings where system managers must know immediately when a remote sensor has lost contact with the network
2.1.1 Eclipse Paho project
The Eclipse Paho project is aimed at developing open source, scalable, and standard messaging protocols. The scope of the project includes client software for use on remote devices, along with corresponding server support. It is focused on new, existing, and emerging applications for machine-to-machine (m2m) and Internet of Things (IoT).
The Eclipse Paho project is part of a broader m2m initiative at the Eclipse Foundation, to provide open source tools and protocols to simplify development using MQTT.
The Eclipse Paho project includes these major goals:
•Bidirectional messaging
•Determinable delivery of messages
•Loose coupling
•Constrained-platform usability
The Eclipse tools facilitate designing and developing connectivity solutions between devices and applications, thereby enabling and encouraging more innovative integration with remote devices through the MQTT protocol.
You can find more information about the Eclipse Paho project at the following website:
2.1.2 OASIS
The Organization for the Advancement of Structured Information Standards (OASIS) Technical Committee for the standardization of MQTT was established for organizations from around the world to collaborate and develop a standardized version of the MQTT protocol. IBM and Eurotech, the original authors of the MQTT protocol, have brought MQTT into the OASIS open standards process.
OASIS plans to expand the range of enterprise solutions by facilitating integration with business applications and increasing connectivity to different types of networks and remote devices.
The OASIS MQTT technical committee is producing a standard compatible with MQTT V3.1, together with requirements for enhancements, documented usage examples, leading practices, and guidance for the use of MQTT topics with commonly available registry and discovery mechanisms.
The standard supports the following functions:
•Bidirectional messaging to uniformly handle both signals and commands,
•Deterministic message delivery
•Simple QoS levels
•Always/sometimes-connected scenarios
•Loose coupling
•Scalability to support large numbers of devices
Candidates for enhancements include the following functions:
•Message priority and expiry
•Message payload typing
•Request/reply
•Subscription expiry
For more information about the MQTT technical committee, see the following website:
2.2 Features of IBM MessageSight
IBM MessageSight delivers massive scale communication to extend your existing enterprise to include interactions from remote clients, such as mobile phones, sensors, machines, and other applications. The IBM MessageSight appliance delivers performance and scalability, enabling organizations to meet the demands of an always-connected world, and users who want an interactive experience. These are a few of the features that IBM MessageSight delivers:
•Ease of deployment
Device can be up and running in 30 minutes. The User Interface helps guide administrators through the first steps.
•Developer friendly
Simple yet powerful programming interfaces make application development easy. A simple paradigm of connect, subscribe, and publish promotes loosely coupled and scalable applications.
•Easy integration
IBM MessageSight supports Java Message Service (JMS), WebSockets, and the MQTT protocol. It has built-in connectivity with WebSphere MQ (making it possible to connect to multiple back-end queue managers). It can be directly connected to IBM Integration Bus using JMS nodes.
•Secure
Messaging policies allow you to filter for specific access. Options are available to add Secure Sockets Layer/Transport Layer Security (SSL/TLS), including Federal Information Processing Standard (FIPS) 140-2.
•Reliable
Two devices can be connected to provide high availability without shared resources. Various options for QoS, including assured delivery.
•Optimized for wireless clients
Efficient MQTT messaging protocol that is faster, and requires less bandwidth and less battery than traditional HTTP. Event-oriented paradigm provides for a better customer experience. The developer-friendly application programming interfaces (APIs) and libraries can be used for a variety of mobile platforms. IBM MessageSight and MQTT integrate easily with IBM Worklight.
•Massive scale
One appliance can handle one million concurrent connections. This enables massive fan-out streaming of data, processing 13 million non-persistent messages per second. When assured delivery matters, the device can process 400 thousand persistent messages per second.
The IBM MessageSight appliance is designed to sit at the edge of the enterprise, and it can extend an existing messaging infrastructure or be used stand-alone. It handles the load and concentrates the data to the back-end applications (Figure 2-1).
Figure 2-1 IBM MessageSight sits at the edge of the Enterprise to allow interactions with remote devices
The IBM MessageSight appliance supports client applications using protocols. At the time of publishing, IBM provides the following clients for those protocols:
•MQTT over TCP/IP:
 – MQTT C client
 – MQTT client for Android
 – MQTT client for Java
 – MQTT client for iOS
•MQTT over WebSockets:
 – MQTT client for JavaScript
•JMS:
 – IBM MessageSight JMS client
IBM MessageSight V1.1, released at the end of November, 2013, provides several enhancements to the appliance. These enhancements include:
•Updates to the appliance browser-based GUI, including a dashboard that provides an at-a-glance view of system status.
•A JMS resource adapter, which facilitates direct connection between WebSphere Application Server and the appliance using message-driven beans.
•Shared subscriptions in which the stream of messages for a single subscription can be shared among multiple consumers. This can be considered a type of message load sharing among consumers.
•Shared subscriptions are available for WebSphere Application Server consumers and conventional JMS clients.
•Appliance security policies can access information contained inside client certificates, and can be used for authentication and authorization.
•Appliance security can be configured to use National Institute of Standards and Technology (NIST) SP 800-131A security recommendations.
•A new feature for mobile applications using MQTT called disconnected client notification provides a mechanism whereby the IBM MessageSight appliance can use a gateway service to send a notification to platform-specific notification mechanisms, such as Apple Push Notification service (APNs) or Google Cloud Messaging (GCM).
Through the use of this feature, a disconnected mobile application can be notified that there are messages for it at the IBM MessageSight server.
Due to the timing of the release, the author team was not able to take advantage of any of the new features for use in the sample scenarios in this book.
2.3 Getting started
To set up your IBM MessageSight appliance, follow these steps:
1. After the appliance is installed in the rack, you must connect an Ethernet cable between the management port (labeled mgt0) and the network that will be used by the administrator.
2. Connect a second Ethernet cable between the port labeled eth0 and the network to be used by the messaging clients. Figure 2-2 on page 23 shows the locations of the mgt0 and eth0 ports, which are located on the back of the IBM MessageSight appliance.
Figure 2-2 Port locations on IBM MessageSight appliance
3. Connect the VGA cable of the monitor to the VGA port, and connect the USB cable of the keyboard to one of the available USB ports on the appliance. You are then ready to turn on the appliance. It might take a few minutes for the startup to complete.
4. Log in with the default user ID (admin) and default password (admin).
5. In the initial setup wizard prompts, select which interface to configure. The default interface is mgt0.
a. Choose whether to use Dynamic Host Configuration Protocol (DHCP). You must enter yes or no (abbreviations are not accepted).
b. If you are not using DHCP, enter the IP address and gateway.
c. After you press Enter to accept, the URL to connect through the web user interface (web UI) is displayed on the panel.
 
Tip: If you realize that you made a mistake, type the following text at a command line and make the necessary corrections:
edit ethernet-interface mgt0
6. After configuring the ports, you must accept the license. The IBM MessageSight appliance provides the web UI, which is intended for most administration and monitoring of the appliance. You can use the web UI to accept the license:
a. To accept the license, access the web UI through a browser using the URL (https://<IPAddress>:9087) that was displayed when you configured the management and ethernet ports.
b. If you do not know the web UI address and port, use the following commands to find the web UI address and port:
imaserver get WebUIHost
imaserver get WebUIPort
c. The default login ID and password for the IBM MessageSight administrator are admin and admin.
d. View the Software licensing and click I Agree.
7. You are then presented with the web UI First Steps tab. You can change the default password for the admin and configure the range for Ethernet client connections.
8. To save the configuration, click Save and Close.
2.4 Configuration and administration
The IBM MessageSight web UI is intended for most administration and monitoring of the appliance. Most of the functions available in the web UI are accessible with a command-line interface (CLI) as well.
2.4.1 Command-line interface
The IBM MessageSight appliance provides an extensive CLI, which includes a few utilities and diagnostic tools not available through the web UI.
You can access the IBM MessageSight CLI locally using a keyboard, video, and mouse (KVM) console, or over the network. If you are physically in the room with the IBM MessageSight appliance, you can access its CLI if you know an administrator name and password.
From the KVM console, log in with the administrator name and password. The default name and password are both admin. You can use the IBM MessageSight KVM console to display the machine type and serial number, as shown in Example 2-1 on page 25.
Example 2-1 Displaying the machine type and the serial number
Console>show version
Installation date: May 10, 2013 2:24:35 PM
Platform version: 5.0.0.10
Platform build ID: build99-20130510-1044
Platform build date: 2013-05-10 17:27:55+00:00
Machine type/model: 6188SM1
Serial number: KLM0199
Firmware type: Production
To determine the IP address of the Ethernet interface, you can use the status ethernet-interface command on the IBM MessageSight appliance CLI. For example, for the Ethernet interface mgt0, enter the following command:
status ethernet-interface mgt0
To access the IBM MessageSight CLI over the network, record some information when at the KVM console.
Use the status netif command (Example 2-2) to find the IP address of the mgt0 interface. This is the management IP address that you can use to access the IBM MessageSight CLI over the network.
Example 2-2 Finding the IP address of the mgt0 interface
Console> status netif mgt0
mgt0 OpState:[Up]
generic MTU:1500 carrier:true flags:UP BROADCAST RUNNING MULTICAST
index:5
inet addr:192.168.1.2 flags:PERMANENT mask:255.255.255.0
scope:GLOBAL
Also record the Secure Shell (SSH) key fingerprint of the IBM MessageSight appliance so that you can verify it when you first access the system over the network:
Console> sshkey fingerprint
To access the CLI over the network, use SSH to connect to the appliance as the administrator. On Windows, there are several SSH clients that you can use, such as PuTTY. Linux, OS X, and UNIX users can use the ssh command to access the management IP address as the administrative user:
sh> ssh Admin_User@IP_Address
The first time you access a system, you might be prompted to accept the SSH key fingerprint for the server. If you recorded the SSH key fingerprint at the IBM MessageSight KVM console, you can validate it now, or you can choose to proceed.
If the IBM MessageSight appliance was given a node name, you can display it to make sure you are accessing the correct system:
Console> nodename get
nodename is Doncaster
The IBM MessageSight CLI enables you to run any of the commands listed in the Command Reference section of the IBM MessageSight Information Center. See Example 2-3 for an example.
Example 2-3 Command example
Console> status imaserver
Status = Stopped
Console> imaserver start
Start IBM MessageSight server.
The IBM MessageSight is running in production mode.
Console> exit
Use the exit command when you are done with the IBM MessageSight CLI.
To display the firmware version using the CLI, run the show imaserver command. The firmware version is included (in this case, 1.0) along with some build date and time information:
Console> show imaserver
IBM MessageSight version is 1.0 20130510-1400 2013-05-10 19:12
The IBM MessageSight appliance includes a powerful command that gathers detailed information about your appliance configuration, log files, and other important diagnostic information.
The platform must-gather command is for troubleshooting, and gathers information needed by the IBM MessageSight support team if you need to open a problem management record (PMR). Sending output from the platform must-gather command when you open a PMR helps the IBM MessageSight support team understand your problem more quickly.
To collect this output, complete the following steps:
1. Access the IBM MessageSight CLI.
2. Run the platform must-gather command to create a .tgz file containing diagnostic information. If you have a PMR open with IBM, include that number in the file name:
Console> platform must-gather PMR-12345,67R,890-May10.tgz
3. Run the file list command. You see the file that you created, and a separate collect-pd.txt file, as shown in Example 2-4.
Example 2-4 Listing file
Console> file list
collect-pd.txt 676421 bytes created May 10, 2013 11:04:42 PM
PMR-12345,67R,890-May10.tgz 33598707 bytes created May 10, 2013 11:04:56 PM
You can then send those files to IBM as part of a PMR problem ticket if you need assistance with troubleshooting.
2.4.2 The web UI
You can access the web UI of an IBM MessageSight appliance with the IP address, port, and administrator name and password. The default web UI IP address is the one assigned to the mgt0 interface, and the default port is 9087. However, you can change both values.
If you do not know the web UI address and port used by your system, you can obtain it at the CLI, as shown in Example 2-5.
Example 2-5 Obtaining the web UI address
> imaserver get WebUIHost
WebUIHost = 192.168.1.2
> imaserver get WebUIPort
WebUIPort = 9087
Using one of the supported web browsers listed in the IBM MessageSight Information Center, connect to the web UI using the IP address and port in the following format:
https://<IPAddress>:9087
When you access the web UI through a browser, you are presented with a Login window to enter your User ID and password, as shown in Figure 2-3.
Figure 2-3 Login window for the IBM MessageSight web UI
After you have successfully logged in to the IBM MessageSight appliance through the web UI, you can complete the Common configuration and customization tasks from the Home tab.
The web UI provides a user menu in the upper right corner (Figure 2-4). The icon for the menu is your user name. From the user menu, you can change your password or logout.
Figure 2-4 The web UI
There are three types of users that can be configured on the IBM MessageSight appliance:
•System administrator
•Messaging administrator
•Appliance users
System administrators are the only users who have access to the IBM MessageSight appliance. The system administrator can access IBM MessageSight using the web UI or the CLI.
The IBM MessageSight administration user interfaces (Figure 2-5) support role-based user actions. The system administrator role has access to every
task on the appliance. Alternatively, the messaging administrator only has access to view or alter messaging-related tasks. For example, a messaging administrator can configure an endpoint, but is not able to configure the SSL/TLS certificates.
Figure 2-5 Use the web UI to configure users and groups for the IBM MessageSight appliance
Complete these steps to configure IBM MessageSight appliance users:
1. From the home page, under Create users and groups, select Appliance Users.
2. The default admin ID already exists, and you can edit that if you want by highlighting and clicking the pencil (edit) icon.
3. To create a new ID, select the plus sign (+). When the Add User pop-up box appears, you provide the User ID and Password and select the type of user, as shown in Figure 2-6.
Figure 2-6 Adding a user with the web UI
2.4.3 Displaying the firmware version in the web UI
The IBM MessageSight firmware version is visible on the Home tab of the
web UI. Log in to the IBM MessageSight web UI and scroll down to display the firmware version.
 
Restriction: If the firmware is not visible, you can log in to the web UI as a messaging administrator or appliance user, but not the administrator ID that has full system administrator permission.
Figure 2-7 shows the firmware version displayed in the web UI Home tab.
Figure 2-7 Firmware Version displayed in the web UI Home Tab
The firmware version is also displayed when you select the Appliance tab and click the System Control option (Figure 2-8).
Figure 2-8 Firmware version displayed in the web UI Appliance tab
2.4.4 Configuring message hubs
A message hub is an organizational object that groups endpoints, connection policies, and messaging policies that are associated with a specific goal. For example, you can create a message hub per application to organize the endpoints and policies that each application uses.
You can configure messaging hubs either by using the IBM MessageSight appliance web UI, or by using the commands shown in Example 2-6 from the CLI.
Example 2-6 Commands to configure messaging hubs
imaserver create
imaserver update
imaserver show
imaserver list
imaserver delete
You create message hubs, and the message hub components, in the following order:
1. Message hubs
2. Connection policies
3. Messaging policies
4. Endpoints
When you create a message hub, the name you specify must not have leading or trailing spaces, and cannot contain control characters, commas, double quotation marks, back slashes, or equals signs. The first character must not be a number or any of the following special characters:
! # $ % & ’ ( ) * + - . / : ; < > ? @
To create a message hub using the web UI, follow these steps:
1. Choose Message hubs from the drop-down box of the Messaging tab.
2. Click the green plus (+) sign to open a pop-up box where you enter the name and description, as shown in Figure 2-9.
Figure 2-9 Example of Message Hub configuration
3. After the message hub is named and saved, you highlight the name of the message hub in the list and click the pencil icon to edit it. You must provide the Connection policy, messaging policy, and endpoint. Each message hub must have at least one endpoint.
Connection policies
A connection policy is used to authorize a client to connect to an endpoint. The connection policy can restrict which clients can connect to the endpoint. You must apply at least one connection policy to an endpoint so that a client can connect to that endpoint. When you create a connection policy, you can use the following filter attributes to restrict who is allowed to connect:
•Client IP address
•Client ID
•User ID
•Group Name
•Protocol
•Certificate common name
For example, an endpoint that is bound to an external-facing ethernet might be configured so that any IP address can connect. However, an endpoint that is bound to an internal-facing ethernet might be configured with a different connection policy, for which only certain IP addresses can connect.
A connection policy can be applied to more than one endpoint. For example, you can use a single connection policy to allow all clients from a particular IP address range to connect. You can then restrict the access of different clients to particular queues and topic strings by using a messaging policy.
To configure a connection policy using the web UI, you highlight the name of the message hub in the list and click the pencil icon to edit it. You then see tabs for Connection Policy, Messaging Policy, and Endpoint. On the Connection Policy tab, select the green plus (+) sign to create a new Connection Policy.
In the example shown in Figure 2-10, a sample connection policy is created that supports both JMS and MQTT connections. The IP address is not limited, but the Group ID parameter is populated to only allow IDs in the UserGroup to connect.
Figure 2-10 Example of a connection policy
Messaging policies
A messaging policy is used to control the topics or queue for which a client can send and receive messages. When you create a messaging policy, you must specify the following components:
•Name
•Destination Type (topics or queues)
•Destination
•Max Messages (only valid for topics)
•Authority
You must specify at least one of the following filters:
•Client IP address
•Client ID
•User ID
•Group Name
•Certificate Common Name
•Protocol
To configure a messaging policy using the web UI, you highlight the name of the message hub in the list and click the pencil icon to edit it. You then see tabs for Connection Policy, Messaging Policy, and Endpoint. On the Messaging Policy tab, select the green plus (+) sign to create a new messaging policy.
 
Tip: When specifying the Destination, you can use an asterisk (*) to specify all topic strings or queues. You can also use variable substitution in the topic string or queue to ensure that only specific user IDs or client IDs can access a topic. The variable for the user ID is ${UserID}. The variable for the client ID is ${ClientID}.
For example, if a topic string in a messaging policy is ExampleTopic/TopicA/${ClientID}, a client with an ID of client_a can access topic ExampleTopic/TopicA/client_a. A client with an ID of client_b cannot access topic ExampleTopic/TopicA/client_a, but can access ExampleTopic/TopicA/client_b.
In the example shown in Figure 2-11 on page 37, a sample Messaging Policy is created to allow applications with an ID in the group UserGroup to browse, put, or get messages from the TEST.QL queue.
Figure 2-11 Example of a Messaging Policy
Endpoints
An endpoint enables a client to connect to the IBM MessageSight appliance. Each endpoint must have at least one connection policy, and at least one messaging policy.
When you create an endpoint, you can specify the following attributes:
•Name
•Enabled
•IP address
•Port
•Protocol
•Max Message Size
•Security Profile
•Connection Policies
•Messaging Policies
 
Important: When you configure an endpoint by using the CLI, you must also specify the Message Hub and Security components.
To configure an endpoint using the web UI, you highlight the name of the message hub in the list and click the pencil icon to edit it. You then see tabs for Connection Policy, Messaging Policy, and Endpoint. On the Endpoint tab, select the green (+) sign to create a new Endpoint, as shown in Figure 2-12.
Figure 2-12 Example of Endpoint configuration by the web UI
 
Restriction: If an endpoint is configured with an IP address that does not match any of the IP addresses in the configured Ethernet-interfaces, the web UI adds that IP address to the list and selects it. That IP address will not show up in the list for any other endpoint, because it is not associated with an Ethernet-interface.
 
..................Content has been hidden....................

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