如何通过WebSphere MQ Telemetry使用MQTT协议

Posted 2023-03-24

参考技术A 　　在 MQTT 客户端连接时设置，设定在自己连接中断后，自动往 Will 主题上发送的通知消息。
　　在 Worklight Studio 中新建 Worklight Project，在工程名中填入 WebSocketMQTT，然后选择 Hybrid Application，点击下一步，在应用名中填入 WebSocketMQTTApp，点击完成。
图 3. WorkLight 工程
　　在工程上单击右键，选择新建 Worklight Environment。Project 选择刚生成的 WebSocketMQTT，Application 选择刚生成的 WebSocketMQTTApp，然后在 Mobile 中选择"iPad"选项框。最后点击完成。
图 4. 新建 Worklight Environment

　　然后在工程中就生成的为 iPad 开发的模板。
　　图 5. iPad 开发模板
　　将 MQTT 的基于 WebSocket 的 Client API 拷贝到 iPad 下的 js 文件夹。
图 6. 拷贝 MQTT Client 的 JS 库文件
　　从本文附件中导入并替代展现页面 WebSocketMQTTApp.html 到 common 文件夹。
图 7. 替换原有展现页面

　　然后在 application：WebSocketMQTTApp 上右键，选择 Run As -> Build All and Deploy
　　在 iPad 模板图标上右键，选择 Run As -> Xcode project。
图 8. 打开 Xcode Project
　　在 Xcode 里，在 Build 成功后，选择配置过的 ios 设备安装。

IBM WebSphere MQ请求/回复方案

我目前正在开发一个项目，我需要与IBM系统进行交互，该系统通过WebSphere MQ与外部世界进行通信。我需要使用队列以“请求 - 响应”方式查询系统，我将通过队列管理器执行此操作。

但是，我无法理解这在实际工作中是如何运作的。

假设我有相同应用程序的多个实例，它们将消息放入请求队列。离开应用程序时，消息会获得CorrelationId和MessageId，并在每条消息上设置ReplyToQueue属性，以确保队列管理器知道将响应放在哪个队列上。

但是，队列管理器如何操作响应队列？关于响应的时间安排无法保证，那么正确的响应如何返回到发出相应请求的应用程序实例？

我一直认为消息队列是一个FIFO队列，必须逐个拾取消息。但是，这意味着实例A可以选择针对例如B的响应。显然，这不是它的工作原理。

然后，当我查看API（com.ibm.mq.MQQueue）时，我看到要选择一条消息，我有机会提供请求消息的CorrelationId和MessageId。这是否意味着当我向队列管理器查询消息（具有这些ID的集合）时，队列管理器会遍历队列中的消息并返回匹配的消息？另一方面，这意味着我们不是在谈论FIFO队列？

答案

通常的做法是使用CorrelationId来关联请求和响应消息。它以这种方式工作：

1）假设有两个队列，一个REQQ - 请求队列，其中放置消息，要求另一个应用程序，服务应用程序，接收和处理以及服务应用程序向其发送回复的RESPQ。

2）请求者应用程序（让我们将其称为REQAPP）将请求消息（REQMSG）放入请求队列（REQQ）。在发送消息之前，REQAPP将消息的ReplyToQ属性设置为RESPQ。发送请求消息时，JMS提供程序使用唯一的MessageId更新已发送的消息。请求者应用程序缓存此唯一的MessageId供以后使用。

3）在世界的另一端，服务应用程序从REQQ检索REQMSG，从该消息中读取MessageId和ReplyToQ属性，处理请求并准备适当的响应消息RESPMSG。然后，它将RESPMSG的CorrelationId属性设置为从REQMSG读取的MessageId，并将回复放入ReplyToQ。

4）请求者应用程序在阅读回复时，使用缓存MessageId并设置如下选择标准来读取回复消息

GET MESSAGE FROM RESPQ WHERE RESPMSG.CORRELATIONID==REQMSG.MESSAGEID

此选择标准可确保检索到正确的响应消息。这里的关键是服务应用程序必须将响应消息上的CorrelationId设置为请求消息的MessageId。

尽管Queue是FIFO类型，但MQ实现在优先级基础上提供消息传递，其中首先传递具有高优先级的消息或者首先传递队列顶部的消息。也可以使用选择标准检索消息，如上例所述。

希望这有帮助

另一答案

Shashi的答案在许多情况下都很明显，实际上是在多个相对低容量的请求应用程序之间分配响应的主要方法。

大批量服务的更好选择将涉及多个RESPQ。您可以通过使用临时动态队列来接收RESPMsgs为REQApp的每个实例提供单独的RESPQ - REQApp的每个实例都将使用MQOPEN函数创建TDQ，并在它发出的每条消息的ReplyToQ属性中指定RESPQ名称。

使用此设置，您不必担心排序和相关ID，因为消息将按照服务应用程序处理它们的相同顺序返回到各个RespQ。

值得注意的是，TDQ只是暂时的。当OPENing应用程序关闭队列时 - 通过MQCLOSE或终止 - TDQ中的任何消息都将丢失且无法恢复。如果这是一个问题 - 无论如何都必须处理所有响应 - 那么您希望一次性分配一系列永久动态队列（也使用MQOPEN），每个REQApp实例一个，REQApp的每个实例都必须每次都重新连接到同一个队列。

我希望这也有帮助。