如何从嵌入式 C 客户端(无 JVM)向 Websphere Message Broker 发送消息或从 Websphere Message Broker 发送消息?

发布于 2024-08-21 08:55:15 字数 366 浏览 11 评论 0原文

对于从没有 JVM 的嵌入式无头 C/C++ Linux 客户端向 IBM 消息代理发送消息和从 IBM 消息代理发送消息,我有哪些选择?

理想情况下我们想要 大文件传输(客户端每天一次 2GB) 加密(SSL) 可靠(“保证”交付/ QoS2,也许 QoS1 会做)

有问题的客户端当前只有 exe 和一些 bash 脚本,我一直在使用 MQTTv3 和 RSMB,但为此我必须将大文件切碎(然后回到家重新集合)如果有交通工具可以为我做这件事,我不想参与其中?

我研究过 MQTTv5(但我们的客户端没有 JVM); JMS(无 JVM)和 XMS?看起来它又给了我一个 C API,但随后需要在客户端上安装 JVM(或者我错了?)

任何线索或提示将不胜感激。

What are my options for pubsubing (or point to point but pubsub is better) messages to and from an IBM message broker from an embedded headless C/C++ linux client that doesn't have a JVM?

Ideally we want
large file transfer (2GB once per day off of the client)
encryption (SSL)
reliable ('assured' delivery / QoS2, maybe QoS1 would do)

The client in question currently only has exes and some bash scripts, I've been playing with MQTTv3 and RSMB, but for that I'd have to chomp the large files up (and reassemble back home) and I don't want to get into that if there's a transport that will do this for me?

I've looked at MQTTv5 (but our client's got no JVM); JMS (no JVM) and XMS? which again looks like it gives me a C API but then needs the JVM to be installed on the client (or am I wrong?)

Any clues or hints would be appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

晨与橙与城 2024-08-28 08:55:15

为什么不直接使用 WMQ C/C++ API? WMQ 客户端安装可作为 SupportPac MQC7:WebSphere MQ V7.0 客户端 下载。完成后,只需 使用 C API照常编译。这是所有本机 WMQ 基础产品功能。

请注意,带有 WMQ v7 客户端的 WMQ V7 QMgr 提供了与 JMS、WMQ Broker 等更好的互操作性,因为所有消息属性现在都是消息属性,并且 WMQ v7 QMgrs 原生支持 pub/sub 。此外,v6 已于 2011 年 9 月终止生命周期,因此请尽可能多地对 v7 组件进行新开发,以避免以后迁移。

Why not just use the WMQ C/C++ API? The WMQ Client install is downloadable as SupportPac MQC7: WebSphere MQ V7.0 Clients. Once you have that, just use the C API and compile as usual. This is all native WMQ base product functionality.

Note that the WMQ V7 QMgr with the WMQ v7 client provides much better interop with JMS, WMQ Broker and so forth, because all message attributes are now message properties and pub/sub is natively supported in WMQ v7 QMgrs. Also, v6 is end-of-life as of Sept 2011 so do as much new development on v7 components as possible to avoid migration later.

羁绊已千年 2024-08-28 08:55:15

您是在谈论单次/几次大额转账,还是只是大量小额转账?这比哪种原始连接更能说明您的解决方案的需求。

如果它是单个/几个大对象,那么我会考虑将其分成两阶段方法,以便您可以更轻松地管理入站带宽和内部处理...

  1. 使用本机(或其他)应用程序推送数据在 Linux 中使用 SCP 或 HTTPS 或同等协议将数据推送到指定的投放点,基本上只是发布数据。

  2. 有一个可以向前处理数据的 MB 流。

如果有很多小调用,为什么不能通过 HTTP[S] 节点作为 MB 数据流的头部来完成呢?使用 HTTP POST 在本机应用程序中包装和推送数据应该不会那么困难,并且应该有大量预先存在的“艺术”可以为您提供帮助。

Are you talking about single/few large transfers, or just plenty of smaller transfers? This speaks to needs of your solution even more than what kind of raw connectivity.

If it's single/few large objects then I'd think about breaking it up into a two phase approach so that you can manage inbound bandwidth and internal processing more easily...

  1. push the data with a native (or whatever) app in Linux to a designated drop-off using SCP or HTTPS or the equivalent, basically just posting the data.

  2. have a MB flow that can process the data onwards.

If it's lots of small calls, why can't you do it via an HTTP[S] node as the head of your MB data flow? Wrapping up and pushing data in a native app with an HTTP POST should not be that difficult and there should be plenty of pre-existing "art" to give you a leg up.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文