Dela via

JMS Interop, revisited

  • Artikel

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 www.mqseries.net 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

  • Anonymous
    April 20, 2005
    The comment has been removed
  • Anonymous
    April 21, 2005
    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.
  • Anonymous
    May 30, 2005
    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.
  • Anonymous
    August 03, 2005
    IBM's .NET Managed client for JMS
    Today I received a comment on a prior entry of this blog. It is noteworthy...
  • Anonymous
    April 27, 2007
    IBM's .NET Managed client for JMS Today I received a comment on a prior entry of this blog. It is noteworthy