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."

Re:Why?

[Howie]

Haven't you read? There's a downturn. You have to try and save a few bucks on consultants where you can.

Need more info

[adlam.bor]

(my favourite but will generate fear and loathing from our VB coders)

Dumb, obvious questions to follow.

How are the VB coders involved? Can you modularize it so that they don't even need to worry about what's going on with the development you're describing (just get their projects to use an ActiveX/COM reference that you create using VC++)? Will the threading need to be done in their VB applications?

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.

Wrong question

[aminorex]

The powers that be are obviously idiots,
so the question you should be asking instead
is something like "what is the best recruiter
board"? I like dice.com. Whenever it becomes
obvious that management has chosen the downward
spiral, I just hop over to an enterprise that
might have a better future. Since my experience
and qualifications have compounded, I generally
get a better compensation package each time.

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.)

Roll your own.

[taveren]

Your best bet, from what I can see, is to write your own app in C++ with a listener on the queue. Have it invoke whatever other apps your working with. Your right in assuming that the triggers won't handle the load on NT, if they manage to work at all. Not saying they don't, they just have issues at the most inappropriate times.

Step #1

[duffbeer703]

Resign so your company can replace you with someone competent.

Use VB instead

[signifying nothing]

If you're a VB shop, then why not use VB to read the messages and call the COM objects?

There's no need to do any fancy thread-pooling - just write a single-threaded VB app, and get MQSeries to trigger more instances at various queue depths. There's some performance degradation if you're using transactions (and you should) but this should work acceptably.

You're right that triggering a process for each message is wasteful.

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.

Jewels..

[schon]

the jewel in the crown, a COM application on NT

Hate to tell the emperor that he has no clothes, but that jewel is actually just a piece of polished glass.

Moderators without a sense of humor: I hit the karma cap awhile ago - do your worst :o)

Give this guy a break.

[Dark Fire]

This guy actually posts a perfectly legitimate question and he gets "ragged on" for doing so. I see about 3 *possibly* helpful posts and the rest are just putting the guy down and saying he is incompetent. Could those people please shutup? Only answer if you can help him. Otherwise you are just a moron who knows less than he does and wastes a lot of posts with non-sense. Be more professional and just answer the guys post if you have something beneficial to helping him with a solution instead of posting crap. The guy asked a question and he admits he could use some help making the best possible and most informed decision. That makes him by no means an idiot. I am reminded of a saying my 7th grade teacher had posted on his fall back in junior high school, "He that asks a question is a fool for 5 minutes. He who does not is a fool for a lifetime."

Some many consultants fit the latter in that they think they know it all and won't ask anyone for help. Funny how sayings stick with you for so long in life.

So help the guy, or don't say anything at all.

My $.02.

You are on the right path. Here's a head start

[CoderDevo]

I think using MQSeries is a very appropriate infrastructure for web apps. MQ is very responsive and highly reliable. If this web app is important to your companies business, then get management to pay for one of your Admins to get certified on MQSeries administration.

Use the MQSeries Server (not Client) for NT and 2000. You will want the queue manager and queue to exist on the server where you COM app resides. The MQSeries Interface (MQI) is small and easy to use.

Personally, I would write a C or C++ application that that you will be able to tweak for performance. Don't use MQ Triggers if you expect many messages to come in.

Instead, if you want your program to wait until a message arrives on a queue, specify the MQGMO_WAIT option in the Options field of the MQGMO structure. Use the WaitInterval field of the MQGMO structure to specify the maximum time (in milliseconds) that you want an MQGET call to wait for a message to arrive on a queue.

If the message does not arrive within this time, the MQGET call completes with the MQRC_NO_MSG_AVAILABLE reason code.

Hope this helps.