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 :-)
1: I've recently replaced the transport's ZeroMQ C++ library with a pure Java implementation of ZeroMQ.
Nice solution! DCOM is awful. Having used both ZeroMQ and MSMQ, I much prefer the ZMQ but I suppose if you have an existing installation of MSMQ it makes sense to stick with it.
ReplyDelete