I previously posted about issues with JMS-to-.NET interop.
I just saw this, 2 weeks ago IBM posted a beta of something they call the IBM Message Service Client for C/C++. This thing was previously known as XMS, apparently.
A couple of months ago, I had a post on the issue of JMS interfering with interop between Java and .NET. Though I did not state it explicitly then, the issue affects Java + anything; it's not related only to Java + .NET. [It's also (probably) a general JMS thing, not specific to IBM or MQSeries. It's just that MQSeries is the best known queuing system with a JMS access library. ]. This Message Service Client package from IBM apparently addresses this very issue.
Now, using the IBM's Message Service Client to connect to MQ from a C or C++ app, you can read messages that were written by a JMS app, and you can write messages that will be received from a JMS app. Interop blooms again.
Essentially what I suppose IBM did was embed the JMS "value add" into a C/C++ library.
The library is in beta. Yesterday, IBM announced the v6.0 of MQSeries, and they said the Message Service Client will be part of that new version of MQ. Nice!
The next obvious question is, what about .NET? We all know that .NET can call into C/C++ DLLs via p/invoke, so likely it will be possible for a VB or C# app (or pick your fave language) will be able to speak JMS. But .NET developers would like a simpler approach - a truly managed library. IBM hasn't said why the IBM Message Service Client thing is limited to C/C++. Probably it is being driven by customer demand and noise.
So, 2 things for you all:
I may explore putting together a managed layer for the Message Service Client, if I have time. Let me know if that's something that would interest you.