建議在服務與桌面應用程序或網頁之間進行通信的方式是什麼？服務與網絡/桌面應用程序之間的通信
我希望服務能做所有的工作，但管理員/管理/報告可以通過網頁或桌面 。 （它將用C＃和.Net 4.0編寫）
它是否命名爲管道？套接字？ wcf？休息？肥皂 ？其他？什麼是最佳做法？
任何信息將不勝感激。
該服務需要有效實時，所以任何通信都需要異步。
感謝 安德魯
更新1 - 服務監控網絡傳輸REALTIME作爲一項服務。客戶端可以是本地的，也可以是遠程的（使用ASP.NET/MVC或甚至Silverlight）。客戶端不需要實時數據，但應該是abe來查詢設置，統計信息，日誌等。
如果代碼的兩端都被控制，那麼除了任何特定的要求，我會選擇WCF，因爲「這太簡單了」。
見Choosing a (WCF) Transport：這是 容易從HTTP去TCP來命名管道（000啦啦！）：
命名管道是在Windows操作系統內核對象，如進程可用於通信的共享內存部分 [閱讀：非常快速]。命名管道具有名稱，可用於單臺機器上的進程之間的單向或雙工通信。
當然，如果相同的機器要求被違反，則HTTP/TCP可以代替這取決於網絡配置中使用，等等 - 差代碼？配置設置:)
快樂編碼。
謝謝......剛剛更新了問題......還是推薦WCF？ – user296191
我會堅持下去：聽起來服務 - 客戶端通信會受到個別請求的影響（可能是週期性的，但是具有相對較大的有效負載），但不一定是數據流本身。當然，請記住WCF是一個「以微軟爲中心的解決方案」，它可能相關也可能不相關。 – 2011-09-24 02:20:33
該問題被問爲WCF或HTTP或TCP。 WCF是一個非常靈活的通信基礎。您可以編寫一次代碼，並通過HTTP JSON/POX，TCP，二進制，HTTP上的二進制文件，自定義序列化等配置和代碼來修飾數據類和動態切換...您選擇的傳輸機制是什麼基於路由/防火牆的限制，客戶端等......就我個人而言，我喜歡HTTP和JSON/XML這樣的可診斷傳輸，只是因爲它們具有通用性，可路由性和可診斷性（checkout fiddler2）。
從您的描述來看，問題的難處似乎是服務執行的REALTIME網絡流量監控。客戶和該服務之間的渠道似乎是問題中較爲簡單的部分。
另外從描述中，客戶端不需要是實時的，只是查詢統計信息，設置和日誌。因爲客戶端可以是本地或遠程的（遠程意味着可能在外部網絡之外？路由外部）。
因此，我會解耦REALTIME網絡統計信息收集過程從查詢部分，使其異步如您所述。在這一點上，服務只是打開一個渠道，客戶端查詢簡單的統計信息，設置和日誌...選擇最可路由和可診斷的渠道，如HTP，REST JSON | XML。如果這是個問題，請保持WCF服務器代碼不變並更改WCF綁定配置。
這個問題有點開放式和模棱兩可，但希望能有所幫助。
這太含糊了。取決於很多事情：你的客戶和服務器相互之間的關係，數據量，持久性/可靠性要求等。 – Joe
剛剛更新了問題......這是否足夠詳細？ – user296191