how can I send messages to/from a Websphere Message Broker from an embedded C client (no JVM)?

Question

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, cheers

Answer 1

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.

Answer 2

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.