3

我即将编写一个负责与外部硬件通信的“服务器”应用程序。应用程序应处理来自客户端的请求。客户端向服务器发送消息，如果服务器忙于处理硬件，则新消息应存储在稍后处理的队列中。

客户端也应该能够取消请求（如果它在服务器的队列中）。当服务器应用程序完成硬件后，它应该能够将结果发送回请求该作业的客户端。

服务器和客户端应用程序可能在也可能不在同一台 PC 上。所有开发均在 .NET (C#) 2005 中完成。

所以，我的问题是：解决这个沟通问题的最佳方法是什么？

MSMQ？肥皂？WCF？远程？其他？

4

5 回答 5

2

假设您可以使用 .NET 3.0 或更高版本，那么您可能希望 WCF 作为通信通道 - 接口是一致的，但它允许您使用适当的传输机制，具体取决于客户端和服务器彼此相关的位置 - 所以您可以根据需要选择使用 SOAP 或 MSMQ 或二进制格式或其他格式（如果需要，您可以自行选择）。它还涵盖了双向通信的需要。

在服务器上排队消息可能应该被视为一个单独的问题 - 特别是考虑到需要删除排队的消息。

于 2009-05-07T08:06:58.393 回答
1

如果客户端和服务器进程在同一台机器上，我认为命名管道将为您提供最快的原始字节传输率。如果进程跨不同的机器，则需要使用基于套接字的方法。

据报道，远程处理非常慢。根据您计划在其上部署解决方案的目标操作系统，您可以选择 WCF et.all 但是这些协议的开销是您在决定时可能需要查看的内容。

于 2009-05-07T08:02:41.820 回答
0

MSMQ 会有些道理，尽管有安全和部署方面的考虑。您可以查看服务总线（例如 NServiceBus 或 MassTransit），还有可以提供帮助的 SQL Server Service Broker（也可以被服务总线用作传输）。

WCF 将是另一件事，但它确实是跨网络传输，因此您可能仍希望 WCF 调用将消息放入服务器队列。

我不推荐远程处理，因为很难保持关注点的分离，而且在你意识到之前你正在开发一个非常健谈的界面而没有意识到它。远程调用相对而言代价高昂，因此您应该尽量保持消息的粗粒度。WCF 将是我的建议。尤其是因为您可以将其设置为使用 HTTP 传输并避免大量部署和安全问题。

于 2009-05-07T07:59:42.297 回答
0

远程处理

如果所有开发都是在 .NET 2005 中完成的，那么 Remoting 是最好的方法。 http://en.wikipedia.org/wiki/.NET_Remoting

于 2009-05-07T07:59:45.430 回答
0

.NET Framework 提供了多种与不同应用程序域中的对象进行通信的方法，每种方法的设计都考虑到了特定级别的专业知识和灵活性。例如，Internet 的发展使 XML Web services 成为一种有吸引力的通信方法，因为 XML Web services 建立在 HTTP 协议和使用 XML 的 SOAP 格式的通用基础设施之上。这些是公共标准，可以立即与当前的 Web 基础设施一起使用，而不必担心额外的代理或防火墙问题。

然而，并不是所有的应用程序都应该使用某种形式的 XML Web 服务来构建，哪怕只是因为与通过 HTTP 连接使用 SOAP 序列化相关的性能问题。

在 .NET 中选择通信选项可帮助您决定您的应用程序需要哪种形式的对象间通信。

于 2009-05-07T08:01:18.313 回答