I have what seems to be a fairly common inter-process communication requirement – a parent process spawns some child processes, and the parent process and child processes need to be able to perform two-way communication with each other (the child process needs to keep the parent process up-to-date with its state and the parent process needs to be able to check that the child process is still alive – note that the child processes don’t need to communicate with each other).
I’ve been looking into doing this using WCF, but I’m new to using WCF for this sort of IPC – as far as I can tell in order to get this two-way communication I’d need both the parent process and the child process to expose WCF services, which seems like a bit of a faff.
On the other hand .Net Remoting makes this sort of communication almost seamless, but everyone seems to be of the opinion that Remoting is old-hat and I should use WCF instead.
So I’m struggling to choose the approach I should take:
– My goal is to make the communication as uncomplicated as possible.
– Security isn’t really an issue.
Which should I choose?
Both technologies should be suitable for what you want to do. The main design difference between the two APIs is:
WCF appears to be more complex because it exposes the complexity rather than hiding it. Since your stated goal is to remove code complexity, you might as well go for Remoting.
Having said that, WCF will allow you to evolve your implementation later on, e.g. change protocols, add security, etc. Only if you are absolutely sure you will never need to do this should you drop WCF.
I prefer the WCF approach for everything, but that’s a very subjective preference.