Comunicazione tra SERVICE e applicazione web/desktop

Question

Qual è il modo consigliato di comunicare tra un servizio e un'app desktop o una pagina Web?

Desidero che il servizio svolga tutto il lavoro, ma l'amministrazione/gestione/reporting sia possibile tramite il web o desktop . (Sarà scritto in C# con .Net 4.0)

Si chiama pipe? prese? wcf? riposo ? sapone ? altro ? Qual è la migliore pratica?

Qualsiasi informazione sarebbe molto apprezzata.

Il servizio deve essere effettivamente in tempo reale, quindi tutte le comunicazioni devono essere asincrone.

Grazie Andrew

UPDATE 1 - Il traffico in tempo reale della rete monitor di servizio come un servizio. Il client potrebbe essere locale o remoto (utilizzando ASP.NET/MVC o anche silverlight). Il client non ha bisogno di dati in tempo reale, ma dovrebbe essere necessario interrogare IMPOSTAZIONI, Statistiche, Log, ecc.

Answer 1

Se entrambe le estremità del codice sono controllate, salvo eventuali requisiti specifici, opterei per WCF perché "è così dannatamente semplice".

Vedi Choosing a (WCF) Transport: è facile passare da HTTP a TCP a named pipe (ooo la la!):

Una named pipe è un oggetto nel kernel del sistema operativo Windows, come ad esempio un sezione di memoria condivisa che i processi possono utilizzare per la comunicazione [leggi: molto veloce]. Una pipe denominata ha un nome e può essere utilizzata per la comunicazione a una via o duplex tra processi su una singola macchina.

Naturalmente, se la stessa esigenza macchinaviene violata, quindi HTTP/TCP può essere usato al posto a seconda della configurazione di rete, ecc - la differenza di codice? Un'impostazione di configurazione :)

Felice codifica.

Answer 2

La domanda viene posta come WCF o HTTP o TCP. WCF è una base di comunicazione estremamente flessibile. Puoi scrivere il tuo codice una volta e decorare le tue classi di dati e passare al volo tramite configurazione e codice tra HTTP JSON/POX, TCP, Binary, Binary su HTTP, serializzazione personalizzata ecc ... La domanda su quale meccanismo di trasporto sceglierai basato su limitazioni di routing/firewall, client, ecc ... Personalmente, mi piacciono i trasporti diagnosticabili come HTTP e JSON/XML solo perché sono universali, routable e diagnosticabili (checkout fiddler2).

Dalla descrizione, sembra che la parte più difficile del problema sia il monitoraggio del traffico di rete REALTIME eseguito dal servizio. Il canale tra il client e quel servizio sembra la parte più semplice del problema.

Anche dalla descrizione, il client non deve essere in TEMPO REALE e richiede semplicemente statistiche, impostazioni e registri. Perché il client può essere locale o remoto (remoto che implica forse all'esterno dell'intranet? Routing esterno).

Per questo motivo, disaccoppierò il processo di raccolta delle statistiche di rete REALTIME dalla porzione di query che lo rende asincrono come accennato. A quel punto, il servizio sta semplicemente aprendo un canale ai client per richiedere statistiche, impostazioni e registri semplici ... scegliere il canale più instradabile e diagnosticabile come HTP, REST JSON | XML. Se questo è un problema, mantenere intatto il codice del server WCF e modificare la configurazione dei collegamenti WCF.

La domanda è un po 'aperta e ambigua, ma spero che questo aiuti un po'.