.NET integration with WebSphere Queues – Another Update

The IBM Message Service Client for .NET has been Updated

Part of an ongoing series on JMS and .NET interop

Another update on IBM SupportPac IA9H, the IBM Message Service Client for .NET, aka "XMS .NET".

First, it's supported! Woohoo! IA9H has graduated into a "category 3" SupportPac, which means if you use it with a licensed WebSphere queue product, IBM will support it. Good stuff. This is the same path the original MQ.NET library followed - it means IBM is seeing enough customer interest that they want to deliver something REAL, as opposed to sample code.

Second, it works with .NET v2.0 now. The assembly itself is built with .NET v1.1, but it will work with .NET 2.0.

Phil Willoughby at IBM also says there are some perf improvements.

If you use Websphere messaging products and need to connect .NET apps with Java/JMS apps through those messaging products, XMS .NET is worth checking out.


[Update, 23 August 2006, 949am Pacific:  I checked the readme and had some questions, which Saket Rungta at IBM (a colleague of Willoughby I take it) graciously answered via email this morning.   first, the readme says: 

In testing, we have found that XMS .NET applications sending messages through WebSphere Application Server Messaging Engines typically need to use a larger JVM heap than the default. Please see the Application Server documentation for details on changing heap configuration. 

The obvious question is, whats up with that?  Saket:

The additional heap requirement for WAS is independent of the clients, in other words, applies equally to .NET clients, Java clients and C/C++ clients. The root cause for this is perhaps a conservative choice for default heap size from our messaging perspective, but is likely to be appropriate default heap size for the common scenarios.

Ok, so if you use XMS.NET (or any XMS library, I guess, or in fact any JMS client) with the embedded messaging engine in WebSphere App Server or WebSphere Process Server, you will need to bump up the heap size.  Clear enough.

Next question: the readme says that XA transactions are not supported with XMS.NET.  I know that XMS.NET depends on the MQ Classes for .NET, which does support XA transactions.  So, again, what's up with this?   Saket:

We are evaluating customer requirements/need for this and may offer this functionality some time in the future, subject to resource availability, management approval and strategy recommendations.

Good clear answers.  That's all for now... ]

Comments (2)

  1. Kris says:

    Along the same lines – it would be nice to see MSMQ support for Java – not via third party addons or COM wrappers for Java.

  2. cheeso says:

    Kris, the closest thing I know of, so far, is this:


    Unlike the MQ Classes for .NET, and XMS.NET, both of which are fully supported by IBM, the Java/MSMQ library mentioned in the post above is not supported by Microsoft.  It is example code only.  Microsoft continually receives requests and requirements from customers, and a supported Java API for MSMQ is certainly one of the things we have heard about. On the other hand, the demand so far has been small enough that this capability is falling "below the bar" when we make the decision to build it or not.

Skip to main content