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
// Creates an instance MessageQueue, which points to existing InteropQueue
mq = new System.Messaging.MessageQueue(@”.\Private$\InteropQueue”);
// 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.
[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[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.
mq = MessageQueue.Create(@”.\Private$\InteropQueue”);
// 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();
msgInterop = “No Message”;
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