|Featured Blog Entries|
BarryG57 270002K7B2 Visits (2759)
How using a web app eases application deployment
If you have experience of developing and deploying traditional messaging apps on (for example) WebSphere® MQ, you might be familiar with the following deployment process:
Why you might want to use messaging directly from the browser in your web apps
How the pieces fit together
These are the flows:
The web app contains application logic, and the URL of the MQTT server. When opened in a browser, the app connects to the MQTT server, creates the subscriptions it needs, then waits to receive event-driven alerts and act on them.
The web app connects using MQTT as the transport protocol, running over WebSockets. Most modern browsers can make WebSockets connections. By using WebSockets, the web app can pass messages through firewalls that accept HTTP and the WebSocket protocol, and can send packets of data (known as
When a message sent by the web app arrives in the MQTT server, the server-side app just sees it as a message. It does not know the message has come from a browser.
Administering and controlling an MQTT server
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:
Note: Because it is designed for high throughput environments, IBM MessageSight expects you to do this.
For example, if you are using WebSphere MQ Telemetry, you use the WebSphere MQ Explorer New Telemetry Channel wizard to complete the following steps:
The sample web app and client library are stored in the MQIN
To stop the queue manager serving the web app executable files, or modify where the queue manager looks for the executable files, you configure the webcontentpath property and add it to the mqxr.properties file. See MQXR properties.