在SERVICE和Web /桌面应用程序之间进行通信

Question

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..

Answer 1

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!):

A named pipe is an object in the Windows operating system kernel, such as a section of shared memory that processes can use for communication [read: very fast ]. A named pipe has a name, and can be used for one-way or duplex communication between processes on a single machine .

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.

Answer 2

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.