Qual è il modo migliore per comunicare tra un servizio WCF e thread separati?

Question

La formulazione della questione non significa necessariamente fare giustizia problema ...

• Ho un interfaccia utente client seduto su una scatola locale con e un servizio di sfondo finestre di sostenerla mentre svolge funzioni di sfondo .
• L'interfaccia utente del client è solo il livello di presentazione e il servizio Windows fa tutto il duro intervento ... quindi è necessario che ci sia comunicazione tra loro due. Dopo aver passato un po 'di tempo su google e aver letto le migliori pratiche, ho deciso di creare il livello di servizio utilizzando WCF e named pipe.
• L'interfaccia utente client è il client WCF e il servizio Windows funge da host WCF (che ospita solo localmente) per supportare il client.

Quindi questo funziona bene, come dovrebbe. L'interfaccia utente del client può passare dati all'host WCF. Ma la mia domanda è, come faccio a rendere utili quei dati? Ho un paio di motori in esecuzione sul servizio Windows/host WCF ma l'host WCF è completamente inconsapevole dell'esistenza di eventuali motori in background. Ho bisogno che le richieste di comunicazione del cliente siano in grado di interagire con quei motori.

Qualcuno ha un'idea di un buon modello di progettazione o di una metodologia su come affrontare la comunicazione facilitata tra un host WCF e thread in esecuzione?

Answer 1

Penso che la soluzione migliore sia disporre di alcune proprietà o metodi statici che possono essere utilizzati per scambiare i dati tra i thread/processi del servizio e il servizio WCF.

In alternativa, il modo in cui ci avviciniamo a questo è attraverso l'uso di un database in cui il servizio client o wcf accoda le richieste per il servizio a rispondere e il servizio, quando è disponibile, aggiorna il database con le risposte a quelle richieste. Il client esegue quindi il polling del database (tramite WCF) su base regolare per recuperare i risultati di eventuali richieste in sospeso.

Ad esempio, se il client ha bisogno di un report generato, viene attivata una richiesta tramite WCF e WCF crea una richiesta di generazione di report nel database.

Il servizio responsabile della generazione di report esegue regolarmente il polling di questa tabella e, quando trova una nuova voce, esegue il filing di un nuovo thread/processo che genera il report.

Quando il report è completato (con esito positivo o negativo), il servizio aggiorna la tabella del database con il risultato.

Nel frattempo, il client richiede regolarmente il servizio WCF se uno dei report inviati è già stato completato. Il servizio WCF a sua volta esegue il polling della tabella per tutte le richieste che sono state completate, ma che non sono ancora state consegnate al cliente, raccoglie le informazioni da loro e le restituisce al client.

Questo meccanismo ci permette di fare un paio di cose:

1) Siamo in grado di scalare il numero di servizi di elaborazione queste richieste su più macchine fisiche/virtuali con l'aumentare del carico di lavoro.

2) Un determinato servizio può supportare numerosi client.

3) Tramite l'interfaccia WCF, possiamo estendere questo supporto a qualsiasi piattaforma client che scegliamo di supportare (web, win, tablet, telefono, ecc.).

dimenticato di dire:

Solo perché scegliere di utilizzare un database non significa che si deve al fine di attuare questo modello. È possibile implementare facilmente la stessa funzionalità creando una raccolta di richieste statiche che il servizio WCF e il servizio di lavoro accedono più o meno allo stesso modo in cui utilizziamo il database.

Sarà sufficiente fare molta attenzione a ottenere e rilasciare correttamente i blocchi sulle proprietà statiche per evitare conflitti o deadlock tra thread.