Slashdot Mirror
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?
Haven't you read? There's a downturn. You have to try and save a few bucks on consultants where you can.
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
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?
The MQSeries Client installs components that can be invoked directly from anything that supports COM - ASP, other COM objects, etc.
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 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.
-I like my women like I like my tea: green-
So you should only work for people who make decisions you like? Good luck!
Apart from the obvious problems with memory leaks and some bugginess, why not use VB instead of C++? Sounds like you already have some VB coders there. I've written a few apps that move messages between the mobile phone network (SMS) and two MQSeries message queues, and I've found using VB with MQSeries is a cinch, provided you look at their examples.
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.
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.
Place witty comment here.
Resign so your company can replace you with someone competent.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.
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.
Oceania has always been at war with Eastasia.
the jewel in the crown, a COM application on NT
:o)
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
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.
I just wanted to practise my new sig:)
Quidquid cognoscitur, aliquo actu cognoscitur
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.
Why not use MQSeries Cluster with three-four queue managers and let MQ do the load balancing??
Then you can have trigger first on every queue, make sure you got a usefull value on the Queue manager 'Trigger Interval'.
Make sure you have looked at IBM, there are a lot of apps, maybee a trigger-monitor for you.
I guess a C++ app will work with an interface that encapsulate ClassId and COM com stuff.
/MF