The MQTT messaging client for JavaScript and web apps

If you have experience of developing and deploying traditional messaging apps on (for example) IBM® WebSphere® MQ, you might be familiar with the following deployment process:

1. The system administrator installs or embeds the client library.
2. The system administrator arranges for the messaging app to be distributed to the end users and installed on their local systems.
3. When the code changes, the system administrator repeats the previous steps (so change management is complex).

If you code your messaging app as a web app, this is the deployment process:

1. The system administrator serves the web app and the client library at a URL.
2. The end user's browser pulls in the web app and client library together.
3. When the code changes, the updated version is picked up when the browser is refreshed (so change management is simple).

If you have experience of programming apps in JavaScript, you might be interested to know the benefits provided by messaging systems such as IBM WebSphere MQ:

• If you send and receive messages through a messaging system, that system is responsible for ensuring that the messages are delivered.
• Because the messaging system looks after delivery, your web app can "fire and forget". This greatly simplifies the programming logic. If messages are delivered for you, your code need not check they got there. Your app no longer needs to handle receipt acknowledgement, or save undelivered messages and retry them later.
• Messaging systems provide event-driven messaging. Your client app no longer needs to send a request then continuously poll for a response. Instead, the messaging server sends a message to your client app when an interesting event occurs. This also means that your client app is alerted as soon as the event happens, rather than waiting until the next time the app polls the server.
• Event-driven messaging also massively reduces the load on the device hosting your client app, the network traffic between the browser and the messaging server, and the load on the messaging server. This matters increasingly, as more and more systems are running on mobile devices, and connecting across wireless networks.

These are the flows:

1. Each instance of the browser refreshes its connection to the URL on which the web app is available, and an up-to-date version of the web app and client library is loaded onto the browser.
2. The web app connects to a queue manager, using MQTT over the WebSocket protocol, and subscribes to a topic of interest.
3. The queue manager uses the same connection to send messages that match the subscription back to the web app.

The MQTT server handles the server-side complexity of the messaging. It ensures delivery of the messages it receives from the web app, and it hosts the publish and subscribe application that responds to the web app. For any MQTT server, you need to complete the following steps:

• Create a server.
• Pick a port.
• Define a new MQTT channel.
• Configure your client web app to connect to the chosen port across the new MQTT channel.

You also need to serve the web app executable JavaScript to the browser. If you are using IBM WebSphere MQ Telemetry, by default the MQTT server does this for you, using the same MQTT channel that the web app uses to connect to the MQTT server. If you are trying out MQTT, this can help you get up and running quickly. For production use, particularly in high throughput environments, you might prefer to serve the web app executable JavaScript on a separate channel, using a dedicated application server such as WebSphere Application Server.

For example, if you are using IBM WebSphere MQ Telemetry, you use the IBM WebSphere MQ Explorer New Telemetry Channel wizard to complete the following steps:

1. Create a server.
2. Pick a port (1883 by default).
3. Define a new MQTT channel.
4. Configure your client web app to connect to the chosen port across the new MQTT channel.

The web app executable JavaScript is (optionally) also served through the queue manager on the same channel. To do this, the queue manager must support both MQTT and HTTP. If you already have a queue manager that is configured for MQTT, you can use the MQSC command line tool to alter the protocol in the channel definition to support both MQTT and HTTP. See ALTER CHANNEL.

The web app and the MQTT messaging client for JavaScript client library are stored on disk in a structure that is defined by your application server or queue manager. If you are using IBM WebSphere MQ Telemetry, the web app and the client library are stored in the following directory structure:

MQINSTALL
  |
  mqxr
  |  |
  |  SDK
  |    |
  |    WebContent
  |       sample web app (the Web Messaging Utility sample HTML pages)
  |       |
  |       WebSocket
  |          IBM client library (the messaging client JavaScript classes)
  |
  qmgrs
     |
     qmgr_name
        |
        mqxr
           |
           WebContent
              |
              your_client_app (your own JavaScript pages)

The sample web app and client library are stored in the MQINSTALL/mqxr/SDK/WebContent directory. Material in this directory is served by all queue managers. If you do not want your users to see and use all this material, you should create your own version of the app. To make this app, or your own replacement app, available on specific queue managers, you put the app in the MQINSTALL/qmgrs/qmgr_name/mqxr/WebContent directory. To select the app and associated JavaScript classes to serve at a URL, the queue manager looks first in its own WebContent directory, then in the global WebContent directory. In the previous example directory tree, the queue manager serves your_client_app and the global copy of the JavaScript classes.