Hearing the words Mule and Microsoft’s MSMQ in the same sentence sends a shiver down my spine. I remember once, Mule guru John D’Emic and me had spent a considerable amount of time and patience getting Mule and MSMQ to talk to each other through DCOM. The major factor that contributed to this unpleasant experience was our ignorance of the numerous security measures imposed by Windows to restrict DCOM access. The morale of this story is unless you have a veteran Windows administrator at your disposal, avoid the DCOM route.
So which choices do we have other than DCOM? JNI sounds promising but you are then sacrificing Mule’s platform independence. Here’s an idea: introduce a messaging bridge between Mule and MSMQ. The bridge can be implemented in any language that facilitates interaction with MSMQ. C# is an attractive option.
We still have to consider which middleware to use for exchanging messages between the bridge and Mule. There are many alternatives and among them is ZeroMQ. I think ZeroMQ is a good candidate for several reasons:
- It supports asynchronous communication
- You’re not adding another component to your architecture
- It’s well documented in addition to having a low learning curve
- A ZeroMQ transport [1] and binding are available for Mule and C# respectively
- It will more than likely satisfy your message throughput requirements
The above code should be self-explanatory but I’ve put comments for your convenience.
Here’s the Mule 3 app dispatching messages to the bridge:
On receiving an HTTP request, Mule leverages the ZeroMQ transport to send asynchronously the request’s payload to the bridge.
In all likelihood, the illustrated bridge code for Mule-MSMQ interoperability won’t serve all your needs. I can think about a dozen features that a developer would want such as destination queues resolved at run-time, an agreed format for message content, and etc. But hey, at least it’s a start :-)