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.
This is very positive, and I am glad to see it.
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.
On the Messaging infrastructure:
Now, supposing you select IBM queueing infrastructure, which
APIs should you use? For your .NET apps:
For your Java apps:
Does this help?