When is Microsoft going to support JMS?

Wow, if I had a dollar for every time I was asked this question...!

A high number of posts on this subject have been circulating recently.  I wanted to spend a couple of minutes to first define what JMS really is, and summarize the Interop options that exist today.  I'd like to hear other people's thoughts and experiences also...

JMS is the Java Message Service API for Java.  It is written and owned by Sun Microsystems and is currently on v1.1.  JMS is an API - not a product.  Implementations for JMS are supplied by various message queue vendors (for example, IBM have a JMS implementation for WebSphere MQ - a.k.a. MQ Series - they support the JMS API along with their own set of message queue libraries). 

When it comes to interoperability between Microsoft products and JMS I often hear one of two questions: 1) How can I access MSMQ using the JMS API? and 2) How can I use .NET to access queues exposed via JMS?

1.  How can I access MSMQ using JMS?

There are several approaches for accessing MSMQ from a JMS API.  MSMQ 3.0 supports HTTP SRMP (an older specification known as the SOAP Reliable Messaging Protocol) and I knew of a couple of developers that were looking at accessing this from Java.  SpiritSoft were also at one time looking at a JMS implementation for MSMQ.  Remember also that you can use a Java-COM bridge to access the COM interfaces that MSMQ exposes.

My recommended approach however is to look at Dino's solution for accessing the MSMQ APIs natively through JNI.  His sample shows direct access to the queue, but it is certainly possible to build a JMS provider around this (if he hasn't done so already).

2.  How can I use .NET to access queues exposed via JMS?

Creating an JMS-like API for the .NET Framework doesn't solve much - as the underlying provider implementation is still required to make it all work together.  Instead, what I'm seeing is many vendors creating .NET specific implementations for their message queues. 

Let's take IBM as an example - they now ship .NET support for WebSphere MQ 5.3 as part of CSD 05 (Service Pack 5).  After installation, you simply import a DLL in Visual Studio .NET and you can start reading and writing to queues from the Framework.  Nothing else is required.  Once you have this support, you can then also build your own message formats on top of these.  I used this approach in my MQ Series transport for WSE 2.0 (here on GotDotNet).  My book also looks at how the libraries can be used to read and write JMS ByteMessages between .NET and Java.

In addition to native .NET support from vendors, options also exist for remoting JMS functionality from the .NET Framework.  This can be achieved using a bridge (such as JNBridge Pro or Intrinsyc's J-Integra).  These products enable you to remote a JMS-based client, presenting a callable set of APIs in the .NET Framework.  JNBridge have gone the extra mile and support a shared-memory adapter model for BizTalk Server 2004 (with this you can bind existing JMS queues to ports within an orchestration).

To conclude, I think there tends to be many more options in this space than people realize.  Many organizations are using the above techniques to successfully interoperate across message queues today.