.NET integration with WebSphere Queues

  • Article

.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