views:

122

answers:

1

I've got a piece of software i'm working on that spawns short lived processes on remote systems to run some code (mostly SerialPort IO) that may or may not interact with the spawning application (but it should be assumed it will), and will then terminate on command.

What is the best way to spawn a remote process like this (PSExec? WMI? System.Diagnostics.Process perhaps?) After the processes is spawned how can i tell it to subscribe to it's host? What would the SO community reccommend for a basic event/message based framework for the communication process? Is WCF well suited to the task? would Remoting be easier? What are my options here?

+1  A: 

I don't think System.Diagnostics.Process allows launching a process on a remote system. So WMI or shelling to something like psexec may be your only options here.

Regarding subscription/interaction options, yes, WCF is the way to go. Avoid Remoting: it offers no benefits for the general case, is no longer being enhanced, and is deprecated in favour of WCF for a variety of reasons (basically distributed objects become a pain in the neck due to versioning and state considerations; messaging is usually easier to set up, understand and maintain. Also remoting had no security if I remember rightly). For setting this up, when the parent process spawns the remote process, it could pass a URL as a command line argument. The parent hosts a WCF service on that URL. Now if the spawned process needs to communicate back to / subscribe to the parent process, it just connects to the URL it was given. If the parent needs to initiate communication, then make the WCF service duplex, or have the spawned process host its own WCF service, and tell the parent the URL via the parent's service.

itowlson
I'd really like to get in touch with you to discuss this in more detail if you wouldn't mind, would you be willing to email me at [email protected] ? I'll try not to use up too much of your time.
Firoso