MSMQ would work, but you could also use web services since they also
support asynchronous calls.

--
Bryan Phillips
MCSD, MCDBA, MCSE
Blog:  http://bphillips76.spaces.live.com

Hi Serge,

I've had to solve a similar problem to what you have, and I also used
something along the lines of a dispatcher service in conjunction with
remoting and MSMQ messaging.

The requirements I had were that each responding component (or assembly in
your case) had to be 'hostable' on a separate server, and in addition if
required, each could be hosted in a server cluster (fronted by a load
balancer). One other requirement I had (may not apply to you) was that the
functionality had to be extensible (in addition to being distributed) after
the deployment phase.

To solve this, I created two interfaces IClientPlugIn and IServerPlugIn,
whose implementing assemblies/classes were hosted in designated folders at
the client and server computers respectively. Each plug-in pair (client &
server) had a matching task id (using attributes to decorate the plug-in
classes).  Also, each IClientPlugIn was a subclass of a generic class that
provided methods for remoting.

To 'trigger' execution on the server, a special "initiator" console exe
located on the client would be passed a task id at the command line - this
task id was then used to locate an IClientPlugIn assembly/class (using
reflection to match the task id), which in turn utilised its base class
remoting functionality to connect to the server, and stream an XML document
containing any required parameters over to the server. Note that each client
plug-in had an accompanying configuration file (named the same as the
assembly, but with ".config" appended) that included the address of the
target server that hosted the component, as well as parameters wrapped/passed
via the XML document.

At the server, a message dispatcher service would receive the remoting call,
unwrap the XML received into an MSMQ message, and place this on an MSMQ
queue. As an aside, to place the received params inside the MSMQ message, I
constructed a XmlMessageFormatter passing in new Type[] { typeof(string) },
and assigned that to the message's "Formatter" property.

A second service running on the server, which was blocked on the messaging
queue, would pick the message off the queue, retrieve the target task id and
adorning parameters, and again using reflection, match the corresponding task
id on the appropriate IServerPlugIn assembly/class and then execute the
appropriate action as required.

One advantage with this approach was that to start off with, all components
were hosted on the same server, however as loads increased, the components
began to be spread across different physical servers (each with a dispatcher
service installed) without the need for code changes, just configuration file
edits.  We are not there yet, however in the near future, it will be fairly
straightforward task to utilise a load-balancer and have the same component
hosted on multiple physical servers).  In addition, use of the plug-in
pattern meant that after deployment,it was simple to extend system
functionality by creating new IClientPlugIn/IServerPlugIn pair assemblies and
xcopying these into appropriate folders on the client and server, to be
triggered as normal via the console initiator exe.

A few points to note:
- in our set up, client's were not allowed to have MSMQ installed, hence use
of remoting from client to server - this had the obvious drawback that
servers had to be up-and-running to service remoting requests. Without this
restriction, clients will likely have used messaging (instead of remoting) to
the dispatcher service, which would have meant that message requests would
have been placed on server queues for later processing even if the server
components were down.

- our set up did not require asynchronous execution of receieved messages,
so you'd have to do some extra work/thinking there

- use of this solution was in a closed environment so for remoting etc, it
was acceptable to use tcp transport & normal messaging etc (which is not
secure). Clearly, you'll need to re-think parts of this solution if high
security is especially an issue.

Here's to hoping that this helps you somehow :-)

Kind regards,
Patrick