> MSMQ is intended to be used by COM objects, so it all works together
pretty
> well. The only real problem is that it was designed with a C++ mentality,
so
> it tends to be more complicated than it really needs to be.
>
> The basic model is that you set up message queues in different machines,
and
> each COM object 'subscribes' to one or more queues. Then and program on
the
> network can send messages to any message queue, using the MSMQ COM
> interface. When a message arrives in a queue MSMQ generates an event that
> signals any 'subscribed' COM objects that there is a message waiting.
>
> You can do some really neat things with the system, like sending messages
> when the network is down (they just pile up until the connection comes
back,
> at which point they all get sent), or interfacing with other message queue
> systems. However, you have to write your own code to handle dead letters
> (i.e. method calls that can't be processed) and serializing data (a
message
> body can be text, almost any primitive data type, a byte array, or a
> persistent ActiveX object, but it can't be a variant or an array of
anything
> except bytes, so you end up having to do some work if you're object have
> complex parameters).
>
> The best book I've seen on using this kind of setup is:
>
http://www.amazon.com/exec/obidos/ASIN/1861001460/qid%3D957502926/102-931255
> 7-4150418
>
> I give it about a 5 on a scale of 1-10, but then I rarely rate anything
> above a 7.
>
> Billy Brown
> bbrown@transcient.com
> http://www.transcient.com
>
Thanks thanks thanks thanks thanks!
My problem is that I'm trying to make a call from a client to a server,
where the server is not trusted to actually process the call in a reliable
way; in particular, where the call may never return. So, I want to make an
asynchronous call - then the server can balls up, but the client can
continue.
I hacked together a pretend asynchronous call between com objects, using an
intermediate out-of-process object. The client calls the intermediate
object, and the intermediate object sets a timer (1 msec) and returns the
call (so the client can get on with it's life). Meanwhile, the timer goes
off in the intermediate object, which then calls the server as the client
has requested. If the server hangs, then the intermediate object does too,
but the client is clear of the damage.
Gross, isn't it? I think these message queues might be a better solution...
Emlyn
This archive was generated by hypermail 2b29 : Thu Jul 27 2000 - 14:10:30 MDT