I am developing an application that is consisted of two separate processes (.exe files). ProcessA and ProcessB need to communicate in bidirectional fashion. Two illustrate the kind of communication these two processes do I will simply my feature requests:
ProcessA is the "watchdog process" that keeps monitoring if ProcessB is up and running. Also ProcessA should provide configuration to ProcessB.
ProcessB is the main application with business logic. ProcessB should notify ProcessA if there is a critical error so that ProcessA.
I decided to implement communication between them with WCF that uses local pipes because processes are on the same machine. Since both processes need to send and receive "messages" I was wondering would it better to do that:
- via WCF duplex feature (eg. implement one service contract and then set CallbackContract property on it)
- by creating two separate WCF services - one for each process (eg. ProcessA would implement IProcessAService service contract while ProcessB would implement IProcessBService). Then ProcessA would consume IProcessBService and ProcessB would consume IProcessAService.
I am not sure which approach is better as I'd like to avoid too much complex logic that synchronizes how these processes communicate. Any guide or best practice tips on this scenario would be very welcome.
