MQSeries to COM - What's Best?

King Of Chat asks: "We have a project underway which involves Suns, A/S400s, 390s and the jewel in the crown, a COM application on NT. Given all these different platforms, the powers that be have decided the MQSeries is to be the middleware. The problem is the NT server app which some executive decided was going to be a strategic purchase. The NT app is all COM components so the question is: how do we get MQSeries to talk to them?"

"Options as we see it are:

• Use an off-the-shelf MQSeries/MSMQ bridge. Problem here is that this is a high(ish) volume web app so extra latency == bad.
• Write a bit of C++ which picks the messages out the queue and then services them from a thread pool (my favourite but will generate fear and loathing from our VB coders).
• Use the triggering to start apps to service the messages. I don't see this working under heavy load due to limits in NT.
• Anything else?

Has anyone out there any experience in trying to do such a thing? I don't like the look of it much as the NT app looks like the weakest link."

Comments

Why make things so complex?

[barzok]

The MQSeries Client installs components that can be invoked directly from anything that supports COM - ASP, other COM objects, etc.

Web Methods

[rogerl]

There is a company out there called web methods that made a decent product that would run on all of those systems. The product is active works. We used it on NT, 2000, 390, and Solaris.

MSMQ problems

[yamla]

At my last job, we tried using MSMQ for a high-volume application and had to rewrite the thing from scratch. MSMQ was just too slow. We only needed it to support about 100 messages a second but it would actually only support 1 to 3 per second in our particular setup. I'll point out that we were using a fairly complicated server setup (replication, etc. etc.) and I'm not all that familiar, but we ended up writing a simple TCP/IP client/server application because MSMQ simply wasn't fast enough. And yes, we did call Microsoft for help.