我有一个正在研究的软件会在远程系统上产生短暂的进程来运行一些代码(主要是SerialPort IO),这些代码可能会或可能不会与产生应用程序进行交互(但应该假设它将),然后将在命令终止。
产生这样的远程进程的最佳方法是什么(PSExec?WMI?System.Diagnostics.Process也许?)生成进程后如何告诉它订阅它的主机? SO社群对基于通信/消息的基于通信流程的框架的建议是什么? WCF非常适合这项任务吗? Remoting会更容易吗?我有什么选择?
答案 0 :(得分:1)
我不认为System.Diagnostics.Process允许在远程系统上启动进程。所以WMI或像psexec这样的东西可能是你唯一的选择。
关于订阅/交互选项,是的,WCF是可行的方法。避免Remoting:它没有为一般情况提供任何好处,不再被增强,并且由于各种原因而被弃用以支持WCF(由于版本控制和状态考虑,基本上分布式对象变得困难;消息通常是更容易设置,理解和维护。如果我没记错的话,远程处理也没有安全性。为了进行此设置,当父进程生成远程进程时,它可以将URL作为命令行参数传递。父级在该URL上托管WCF服务。现在,如果生成的进程需要回传/订阅父进程,它只是连接到它给出的URL。如果父进程需要启动通信,则使WCF服务双工,或让生成的进程托管自己的WCF服务,并通过父服务告诉父进程。