IIS->COM+->Service communication via MSMQ?
Next week I'm going to build a model to try this out, but I'm not quite sure how best to allow ASP pages running in IIS to communicate with a Windows Service running on the same or different machine.
Here is the scenario that I'm envisioning:
I have an NT Service that can accept commands via TCP or MSMQ (I haven't built it yet, but I can use either).
ASP creates a COM+ object and gives it a session key. Then it calls a method on the object that validates the call, sends a command to the NT Service, receives a response from the NT Service, and gives the result back to ASP which sends it down to the client.
Here is my question: When the COM+ object wants to talk to the NT Service, would it be better to use MSMQ or a TCP connection?
I would like to use MSMQ, but does it add more overhead than simply connect/send/receive/disconnect with TCP?
Also, do I have to block the thread in my COM+ object myself while waiting for a response MSMQ message, or can calls be made synchronously?
I've been experimenting/reading books on COM+MSMQ (got myself an oreilly Safari membership), but if anyone could help me out, that'd be great. Thanks.
Wayne
Saturday, February 28, 2004
Also, is it safe to use mult-threading techniques in a COM+ object like using a timer to re-enter into the object and respond to a method call asynchronously?
I realize this may be totally stupid, as I'm just learning about this stuff but I figure I'd ask before I try it out.
Wayne
Saturday, February 28, 2004
MSMQ is a great product. The model we use is generally to queue off an MSMQ message that could be completed at some later time (between 3 seconds and 5 hours, depending on the task)...
After queueing the work request, the IIS application communicates with the service entirely through database state. The application knows the task is done because it logged a bit of information before queueing the request, which is then updated by the service.
We've been using MSMQ heavily for the past 4 years. Hundreds of thousands of requests per day. It's been a rock.
Rick Watson
Monday, March 1, 2004
On the other hand, if you want to block until you get a response, I'm not sure what using MSMQ would buy you over using TCP.
Christopher Wells
Monday, March 1, 2004
We have been using MSMQ for running some long processes which have to be started and monitored from ASP pages. Once you get it running it works fine, but there wasn't a single instance when we get a new server (clients setup their own wi2k boxes, we just install our stuff on top) and we could get MSMQ running w/o any problem. There are always some myseterious errors in the event log (my favourite are like 'assert failed in line 54 of msmq???.c') and it takes quite a lot of googling to figure it out. I'll get rid of MSMQ ASAP.
Alexander Chalucov (www.alexlechuck.com)
Monday, March 1, 2004
Recent Topics
Fog Creek Home
|