.NET integration with WebSphere Queues - An Update

Part of an ongoing series on JMS and .NET interop

Some interesting news, related to a prior post on SupportPac IA9H and the IBM Message Service client for .NET (aka XMS.NET). I heard back from some IBM XMS people, Saket and Phil.

  • The XMS client is certified with .NET v1.1, but should work also with .NET v2.0. If you experience any problems, please let them know, they would like to correct them.
  • IA9H is currently a "Category 2" SupportPac, but IBM's intent is to graduate it into Category 3, "as soon as we can complete testing to our satisfaction." This means it would be fully supported as an extension to the IBM queueing product in question.
  • The readme for this release says it runs on various versions of Windows with "Service Pack n". Saket explains 'Service Pack n' is somewhat cryptic, but our intention was to imply service pack 1,2,3,4 for Windows 2000; 1,2 for Windows XP, and 1 for Windows 2003.

This is very positive, and I am glad to see it.

What's it Good For?

Someone had asked me, what does this XMS thing get me? When would I use it? And Saket at IBM also pointed me to a newsgroup posting that asked the same thing.

Here's my take. IBM has messaging middleware, that exposes a number of different APIs. They have MQI, which is the procedural flavor. Works fast, totally flexible. then they have class libraries for .NET and Java - the MQ Classes for .NET and the MQ Classes for Java, both of which started life as SupportPacs, and both of which eventually graduated into the messaging products. IBM controls and defines all these APIs, and they get to make the flexibility-vs-usability trade-offs, and all the other decisions on implementation.

Separately, Java introduced this thing called JMS, a Java API that defines the way apps talk to messaging infrastructure. There are point-to-point and pub/sub models in the JMS API. It was designed to define a single API for any queue, in a way similar to JDBC for data (and before it ODBC, and OLEDB, and JDBC) and databases. Many vendors implemented JMS on top of their own queues.

IBM implemented the JMS spec for its messaging systems - MQSeries and etc. BUT! There is an envelope, something like SOAP, called RFH2, that IBM wraps around the raw message data when JMS is used as the API to connect to MQ. This is essentially required by the JMS spec. So, if app X enqueues a message to MQ using JMS , then the stuff on the queue is

<RFH2 Envelope> Message Data </RFH2 Envelope>

A non-Java app, including a .NET app, can connect directly to the same MQ queue, using the IBM MQ Classes for .NET, an IBM-provided .NET class library for MQSeries. But, in the non-JMS libraries, there is no support for unwrapping the RFH2 envelope. If a .NET client goes throug the MQ Classes for .NET, or a C/C++ app goes through MQI, the app cannot parse the RFH2 envelope.

The envelope is important, because it duplicates the function of some fundamental messaging concepts - like correlation ID and message ID. These are all present in MQ (and in Microsoft's messaging technology, MSMQ) but they are implemented differently, independently, at a higher-level, with the JMS layer atop MQ. So, if you try to dequeue by correlation ID from MQ, using the MQ Classes for .NET, you will not get the desired results, if the message that was enqueued, was enqueued with JMS. There are a bunch of other issues as well. I first described this problem in 2004, but it was bothering other people before then.

XMS solves this. There is a C/C++ implementation, and there is a managed library, too. Now all of those languages can read/write RFH2 headers implicitly. In practice, it means, I can dequeue a JMS message by message ID (or correlation ID, etc etc), and get what I expect.

When would you use the various options?

On the Messaging infrastructure:

  • Use MSMQ when you want to integrate various systems running on Windows, regardless of language. It's going to end up being cheaper and easier than a 3rd party queue. It's built in to Windows. It's fast. It's transactional. It works. Use it.
  • Use MQSeries or other IBM messaging infrastructure when you want to integrate with mainframes or other systems already connected to the MQ network.

Now, supposing you select IBM queueing infrastructure, which APIs should you use? For your .NET apps:

  • Use the IBM Message Service client for .NET when you want to interop with JMS-based apps on the other side. (modulo official support).
  • Use the MQ Classes for .NET when you want your .NET app to interconnect with non-JMS resources on the other end of the MQ link, including C/C++/COBOL applications.

For your Java apps:

  • Use the MQ Classes for Java when you do not care to de-couple your app from the messaging infrastructure, or when you want simplicity, or when you want easiest interop with non-Java systems, like COBOL, C/C++, or .NET.
  • Use JMS when you want to de-couple your app from the JMS provider (in this case MQSeries), or when you want to take advantage of some of the JMS features, like pub/sub, and when interop with non-Java systems can be facilitated with XMS libraries.

Does this help?

okay then,

-Dino