.NET integration with WebSphere Queues - An Update
- 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
- 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 href="http://blogs.msdn.com/dotnetinterop/archive/2004/12/06/275958.aspx">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
- 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
Does this help?