次の方法で共有

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.

Comments

  • Anonymous
    March 17, 2005
    Thanks for your thoughts Simon - that makes a lot of sense. I was aware of such bridging products that are available. The problem always lies in the fact that they are commercial products and ... not cheap, especially if you just want basic JMS interop, rather than all the other features they offer.

    The vendor of the JMS queue we currently use does not provide a .Net native option - perhaps this will become available in the future.
  • Anonymous
    March 18, 2005
    Hi Simon --

    Thanks for the mention of JNBridgePro. For more information on our JMS adapter for BizTalk server, I recommend looking at an MSDN Webcast we did on the topic:

    http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032265920&EventCategory=4

    Readers can also contact us at info@jnbridge.com for more information.
  • Anonymous
    March 18, 2005
    Chad, what implementation are you using?
  • Anonymous
    March 20, 2005
    MQ Series is by far not the same thing as JMS. MQ Series has been around as a mainframe messaging system with much more features than JMS.
  • Anonymous
    March 21, 2005
    Totally agree - I hope I didn't apply this in my post... -Simon