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.

The Right Answer

[fm6]

So you should only work for people who make decisions you like? Good luck!

your project is doomed

[markj02]

If people decide a-priori that the answer to your middleware problems is "package X" without actually having answered the kinds of questions you are asking, you have a serious management problem at your company. Unless your company is big enough that it will stay around out of sheer inertia, these kinds of problem can be fatal--maybe working on your resume is more important at this point.

Re:your project is doomed

[gorilla]

Sounds to me like the right decision has been made. MQ supports Sun's, AS/400's and 390's, as well as NT. COM only supports NT. There are lots of solutions for COM/MQ interchange, so the problem is definatly solvable.

Re:your project is doomed

[markj02]

You speak like a true manager. At issue isn't whether MQSeries supports all the platforms in question (lots of software does that), at issue is whether it satisfies the latency and performance requirements and whether its platform support on NT is suitable for the environment where it's being deployed. You can't answer those questions without having the technical people on the project look at it in detail (although the range of features that MQSeries supports already suggests that it is not the optimal choice for this application).

Re:your project is doomed

[gorilla]

I am a technical person. MQ's latency is quite low, and perfectly suitable for developing websites. I can say this mainly because I have websites which are based upon MQ.

Re:your project is doomed

[markj02]

Well, how nice for you. But the question is not whether MQSeries ultimately turns out to be the right tool for the job, but whether KingOfChat's managers made their decision based on sufficient information.

(Besides, not all websites are the same. I have built websites in PHP, but that doesn't mean that PHP is the right tool for all websites.)

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.