MQSeries to COM - What's Best? 24
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?
Re:Why? (Score:1)
Need more info (Score:1, Insightful)
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? (Score:4, Informative)
Web Methods (Score:2, Informative)
Wrong question (Score:1)
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 (Score:2)
your project is doomed (Score:4, Insightful)
Re:your project is doomed (Score:2)
Re:your project is doomed (Score:2)
Re:your project is doomed (Score:2)
Re:your project is doomed (Score:2)
(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. (Score:1, Insightful)
Step #1 (Score:1, Flamebait)
Use VB instead (Score:1)
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 (Score:3, Informative)
Jewels.. (Score:1)
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
Give this guy a break. (Score:1)
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 (Score:1)
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.