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