The Messaging Way : MSMQ & JMS

By Daniel Rubio
[Posted by Jack Vaughan]
Messaging is a popular technique for applications requiring asynchronous communication, and its same architecture which introduces an additional broker between client and server, also lends itself to support interoperability between Java and .NET applications, via a messaging provider.

A messaging provider adheres pretty strictly to the definition of middleware, its role is to sit between client and server hosts to support additional software services, one of which can be bridging platform disparities. Messaging providers come in many flavors and are produced by many vendors, strictly speaking in Java and .NET terms, in the Java camp there are a series of products designed around JMS(Java Messaging Service), while in the Microsoft-centric product line there is MSMQ.

Choosing between a messaging provider can be an elaborate process, but generally speaking all of them support a plethora of client/server platforms to bridge communication disparities, ranging from Java, .NET to others like C++ and C. In all cases, any messaging platform requires a concerted effort to install, configure and use, so with that said, we will concentrate our efforts on a what I have personally experienced to be the easiest to set up : MSMQ. This is not to say MSMQ is superior to other messaging platforms, but simply more ubiquitous than others, given its already included in Windows 2000, Windows XP, Windows Server 2003 and Windows Vista, contrary to many other products which require more elaborate steps to install.

In any of the aforementioned operating systems, first ensure you have MSMQ enabled going to the control panel and selecting the Add or Remove Programs icon, followed by Add/Remove Components, in the emerging window you will see a list, make sure Message Queuing is selected. You now have MSMQ ready for action on your system.

The next step is to create a queue, in messaging speak this is where the communications token — message — you wish to transfer between a Java and or .NET application is stored. The actual message can be varied in nature, it can have distinct formats — text, XML, binary — or have different behaviors — guaranteed delivery, transactional properties — in this particular case, I wont delve in the finer details of incorporating any elaborate messaging behaviors, but rather focus on storing a vanilla type message in MSMQ through either Java or .NET.

In .NET the process is very straightforward, since two of the many .NET classes are designed for just this purpose, one is named System.Messaging.MessageQueue and the other System.Messaging.Message. The following snippet shows the sequence:

Listing 1.1 Creating MSMQ queue and sending message from .NET

// Check if queue exists, if not create
if(MessageQueue.Exists(@”.\Private$\InteropQueue”))
      // Creates an instance MessageQueue, which points to existing InteropQueue
      mq = new System.Messaging.MessageQueue(@”.\Private$\InteropQueue”);
else
      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);

// Create a message to send, with text and label
System.Messaging.Message msg = new System.Messaging.Message();
// InteropMsg variable contains payload, assign to body
msg.Body = InteropMsg.Text;
msg.Label = “InteropMsgJavaNET”;
// Send it to the queue.
mq.Send(msg);
[End Listing 1.1]

In Java, the process is a little more elaborate since it requires connecting to MSMQ via a supporting library/mechanism, among them : COM, C++ or C. This means that your Java class would need to communicate through either one of these technologies to get through to MSMQ, since MSMQ does not support native Java or JMS calls.

So what you are left with when trying to create MSMQ queues from Java is using a separate API. Currently, there are a series of commercial offerings — sometimes referred to as bridges — to ease Java communication to COM(and hence MSMQ), but since this would take us down the avenue of proprietary API’s and product selection I won’t discuss it here.

An alternate route for those looking for non-commercial — read free — communication from Java to MSMQ would be using JNI(Java Native Interface), which is Java’s way of tapping C++ or C libraries, but we will leave JNI’s interoperability details for a later entry. An excellent write-up on this process by Dino Chiesa is found on his All About Interop blog.

Returning to the task at hand, once a message sits in an MSMQ queue, it can easily be consumed by either a Java or .NET client using a similar sequence to the one used for creating it. In .NET you once again use MessageQueue class for this purpose:

Listing 1.2 Consuming message from MSMQ queue in .NET

      // Creates a new queue called InteropQueue
      mq = MessageQueue.Create(@”.\Private$\InteropQueue”);
try
{
      // Call receive on queue
      msg = mq.Receive(new TimeSpan(0, 0, 5)); // 5 is wait time in seconds
      // Assign to variable
      msgInterop = msg.Body.ToString();
}
catch
{
      msgInterop = “No Message”;
}
[End Listing 1.2]In Java, the message consuming code would again entail using a communications bridge to COM or some other form JNI library to tap MSMQ’s C or C++ interfaces.

There you have it, a quick run-through on using messaging to achieve interoperability between Java and .NET applications. In the next entry, we will take a look at another non-web service alternative to achieving application interoperability: CORBA.

Daniel Rubio is a software consultant with over 10 years of experience in enterprise software development, having recently founded Mashup Soft, a startup specializing in the use Web services for Mashups. He is a technology enthusiast in all areas related to software platforms and maintains a blog on these topics at webforefront.com.

 

Related MQ/MSMQ messaging link
Dino Chiesa blog

 

3 Responses to “The Messaging Way : MSMQ & JMS”

  1. Marcel Says:

    This article is more a tutorial about MSMQ but less an
    article about interoperability.

    Having a robust JNI access is not so trivial, features like
    reconnect polling, client side queuing etc need to be addressed.

    Using real inter operable MOMs like xmlBlaster (http://www.xmlBlaster.org) support many OS and programming languages (C,C++,C#,Java,PHP,Python,Javascript etc) out of the box (having said that as an xmlBlaster developer :-).

    Integrating mobile phones with Symbian OS or Windows Mobile/Smartphone devices with highest streaming-compressed communication to server side HPUX/Linux/Windows boxes and back end servers transparently over fancy protocols like SSH encrypted or CORBA or email or http tunnels are real use cases to solve with MOMs.

    regards
    Marcel

  2. rogerv Says:

    With a JMS implementation, such as Tibco EMS, one has a far superior interoperability story than what was related here for MSMQ.

    My production systems comprise C/C++ clients, .NET clients, WinCE .NET Compact Framework clients, and of course Java clients. We bridge to Oracle AQ and IBM MQSeries.

    My own developers build systems that are .NET on the client-side and Java in the middle-tier, but another product group at my company that uses .NET exclusively for all end-points, still went with Tibco EMS instead of MSMQ.

    A lot has to do with the superiority of JMS spec, but Tibco EMS proved to be a very excellent implementation relative to MSMQ. Tibco knows messaging much more deeply than Microsoft does.

  3. Old -timer Says:

    The assertion that MSMQ is ubiquitous is simply nonsense. It only runs on Windows OS flavours. JMS implementations on the other hand run on any OS for which there’s a Java Virtual Machine. Noter however that no two JMS implementations have to be able to interoperate. That’s just missing from the spec. Also more ubiquitous is IBM’s WebSphere MQ. It runs on something over 40 different operating systems, including all the Windows ones, most Linux, many Unix and several mainframes.


Leave a Reply