我即将编写一个负责与外部硬件通信的“服务器”应用程序。应用程序应处理来自客户端的请求。客户端向服务器发送消息，如果服务器忙于处理硬件，则新消息应存储在稍后处理的队列中。
客户端也应该能够取消请求（如果它在服务器的队列中）。当服务器应用程序完成硬件后，它应该能够将结果发送回请求该作业的客户端。
服务器和客户端应用程序可能在也可能不在同一台 PC 上。 所有开发均在 .NET (C#) 2005 中完成。
那么，我的问题是：解决这个沟通问题的最佳方法是什么？
MSMQ？肥皂？ WCF？远程？其他？
【问题讨论】：
标签： c# client-server interprocess
假设您可以使用 .NET 3.0 或更高版本，那么您可能希望 WCF 作为通信通道 - 接口是一致的，但它允许您使用适当的传输机制，具体取决于客户端和服务器相对于每个的位置其他 - 因此您可以选择使用 SOAP 或 MSMQ 或二进制格式或其他适当的格式（如果需要，可以自己滚动）。它还涵盖了双向通信的需求。
在服务器上排队消息可能应该被视为一个单独的问题 - 特别是考虑到需要删除排队的消息。
【讨论】：
如果客户端和服务器进程在同一台机器上，我认为命名管道将为您提供最快的原始字节传输率。 如果进程跨不同机器，则需要使用基于套接字的方法。
据报道，远程处理非常慢。根据您计划在其上部署解决方案的目标操作系统，您可以有 WCF 等选项。但是，您在决定时可能需要考虑这些协议的开销。
【讨论】：
远程处理
如果所有开发都是在 .NET 2005 中完成的，那么 Remoting 是最好的方法。 http://en.wikipedia.org/wiki/.NET_Remoting
【讨论】：
MSMQ 会有一定的意义，尽管有安全和部署方面的考虑。您可以查看服务总线（例如 NServiceBus 或 MassTransit），还有可以提供帮助的 SQL Server Service Broker（也可以被服务总线用作传输）。
WCF 是另一回事，但它确实是跨网络传输，因此您可能仍希望 WCF 调用将消息放入服务器队列。
我不建议进行远程处理，因为很难保持关注点分离，而且在不知不觉中，您正在开发一个非常健谈的界面而没有意识到这一点。相对而言，远程调用成本很高，因此您应该尽量保持消息的粗粒度。 WCF 将是我的建议。尤其是因为您可以将其设置为使用 HTTP 传输并避免大量部署和安全问题。
【讨论】：
.NET Framework 提供了多种与不同应用程序域中的对象进行通信的方法，每种方法的设计都考虑到了特定级别的专业知识和灵活性。例如，Internet 的发展使 XML Web services 成为一种有吸引力的通信方法，因为 XML Web services 建立在 HTTP 协议和使用 XML 的 SOAP 格式的通用基础设施之上。这些是公共标准，可以立即与当前的 Web 基础架构一起使用，而无需担心额外的代理或防火墙问题。
并不是所有的应用程序都应该使用某种形式的 XML Web 服务来构建，但是，这仅仅是因为与通过 HTTP 连接使用 SOAP 序列化相关的性能问题。
Choosing Communication Options in .NET 帮助您决定您的应用程序需要哪种形式的对象间通信。
【讨论】：