JMS Interop, revisited

JMS Interop, revisited

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:

  • if you want to interop between .NET and JMS apps running on WebSphere [ emphasized text added 21 Apr 2005 1245est ], you will soon (MQ v6.0) have a much better option than before: P/Invoke into the IBM-provided JMS value-add DLL.
  • If you consider .NET and JMS interop to be a priority, make some noise!  Speak now to your IBM representatives, give them feedback on their newsgroups, or visit the forums at  and tell them you want an IBM-supported managed code library for this XMS thing. [ note added 3 Aug 2005 : IBM has announced an open beta for the IBM Message Service Client for .NET. ]

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. 

Cheers !


Comments (5)

  1. If your thinking JMS, there really is only one name you think of and thats Sonic Software. I don’t think it is a secret that they have a COM client that works with .Net and has for a while.

    I can also say that are close to releasing a .Net client! Should be interesting. Not sure if it will take advantage of Sonics market leading Fault Tolorence though, will have to wait and see.

    Check it out at


  2. cheeso says:

    Pretty cool that Sonic may soon ship a .NET client. Will that be a JMS client?

    > If you’re thinking JMS….

    My experience tells me that the API (eg, JMS) is not the object of desire. What companies want is to interconnect systems. If the company has MQ or WebSphere App Server installed, and want to connect .NET apps into that, then they don’t typically care whether it is JMS or some other API. They typically don’t need or want to add Sonic, or any other third-party JMS, to the mix to build that connection.

  3. jda says:

    Interop between JMS and .NET is great to have. What is also great to have in an interop environment is a native-code API into JMS so that one can integrate all that 3GL ‘legacy’ code with new systems being built, be they on Java, .NET, LAMP or whatever.

    SpiritSoft has a very nice ‘C’ and C++ API into their Wave product, thus allowing one to interop between legacy and ‘new’ systems. Since the software also supports XA (as it should), legacy and new may be coordinated with distributed transactions.

  4. IBM’s .NET Managed client for JMS

    Today I received a comment on a prior entry of this blog. It is noteworthy…

  5. IBM’s .NET Managed client for JMS Today I received a comment on a prior entry of this blog. It is noteworthy

Skip to main content