SERVICE 和 Web/桌面应用程序之间的通信
在服务和桌面应用程序或网页之间进行通信的推荐方式是什么？
我希望该服务能够完成所有工作，但可以通过以下方式进行管理/管理/报告 网络或桌面。 （它将用 C# 和 .Net 4.0 编写）
它是命名管道吗？插座？世界CF？休息 ？肥皂 ？其他 ？什么是最佳实践？
任何信息将不胜感激。
该服务需要有效地实时，因此任何通信都需要异步。
谢谢 Andrew
更新 1 - 该服务作为服务实时监控网络流量。客户端可以是本地的，也可以是远程的（使用 ASP.NET/MVC 甚至 silverlight）。客户端不需要实时数据，但应该能够查询设置、统计、日志等。
Whats the recommended way to communicate between a service and a desktop app or webpage ?
I want the service to do all the work, but admin/management/reporting to be possible via
web or desktop. (It will be written in C# with .Net 4.0)
Is it named pipes ? sockets ? wcf ? rest ? soap ? other ? What is best practice ?
Any info would be greatly appreciated.
The service needs to be effectively real time so any comms need to be async.
Thanks
Andrew
UPDATE 1 - The service monitors network traffic REALTIME as a service. The client could be local or could be remote (using ASP.NET/MVC or even silverlight). The client doesn't need realtime data, but should be abe to query SETTINGS, Statistics, Logs, etc..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果代码的两端都受到控制，那么除非有任何特定要求，否则我会选择 WCF，因为“它非常简单”。
请参阅选择 (WCF) 传输：
轻松从 HTTP 到 TCP 再到命名管道（哦啦啦！）：
当然，如果违反了相同机器的要求，则可以根据网络配置等使用 HTTP/TCP 来代替 - 与代码有何不同？配置设置:)
快乐编码。
If both ends of the code are controlled then, barring any specific requirements, I'd opt for WCF because "it's so darn simple".
See Choosing a (WCF) Transport: it's
easy to go from HTTP to TCP to Named Pipes (ooo la la!):
Of course, if the same machine requirement is violated, then HTTP/TCP can be used instead depending upon network configuration, etc -- difference to code? A configuration setting :)
Happy coding.
问题以 WCF、HTTP 或 TCP 形式提出。 WCF 是一个极其灵活的通信基础。您可以编写一次代码并装饰您的数据类，并通过 HTTP JSON/POX、TCP、二进制、HTTP 上的二进制、自定义序列化等之间的配置和代码进行动态切换...您选择哪种传输机制的问题是基于路由/防火墙限制、客户端等...就我个人而言，我喜欢像 HTTP 和 JSON/XML 这样的可诊断传输，因为它们具有通用性、可路由性和可诊断性（查看 fiddler2）。
从您的描述来看，问题的棘手部分似乎是服务执行的实时网络流量监控。客户端和该服务之间的通道似乎是问题中更简单的部分。
另外，从描述来看，客户端不需要是实时的，只需查询统计数据、设置和日志。因为客户端可以是本地的，也可以是远程的（远程意味着可能在内网之外？在外部路由）。
因此，我会将实时网络统计信息收集过程与查询部分分离，这使得它像您提到的那样异步。此时，该服务只是向客户端打开一个通道来查询简单的统计信息、设置和日志...选择最可路由和可诊断的通道，例如 HTP、REST JSON|XML。如果出现问题，请保持 WCF 服务器代码完整并更改 WCF 绑定配置。
这个问题有点开放式且含糊不清，但希望能有所帮助。
The question is asked as WCF or HTTP or TCP. WCF is an extremely flexible communications foundation. You can write your code once and decorate your data classes and on the fly switch via configuration and code between HTTP JSON/POX, TCP, Binary, Binary over HTTP, custom serialization etc... The question as to which transport mechanism you choose is based on routing/firewall limitations, clients etc... Personally, I like diagnosable transports like HTTP and JSON/XML just because how universal, routable, and diagnosable they are (checkout fiddler2).
From your description, it seems like the tough part of the problem is REALTIME network traffic monitoring which the service performs. The channel between the client and that service seems like the simpler part of the problem.
Also from the description, the client doesn't need to be REAL TIME and is simply querying statistics, settings and logs. Because the client can be local or remote (remote implying possibly outside the intranet? routing externally).
Because of that, I would decouple the REALTIME network statistics gathering process from the querying portion which makes it async as you mentioned. At that point, the service is simply opening a channel to the clients to query simple stats, settings and logs ... choose the most routable and diagnosable channel like HTP, REST JSON|XML. If that's a problem, keep your WCF server code intact and change the WCF bindings configuration.
The question is a bit open ended and ambiguous but hopefully that helps a bit.