Qual è il modo corretto di gestire le operazioni di servizio a lungo termine con WCF ospitato in IIS?

Sto creando un servizio WCF che esporrà diverse operazioni, verrà eseguito in IIS perché ha bisogno di endpoint HTTPS. La maggior parte delle operazioni verrà eseguita entro pochi secondi o meno; tuttavia, una o due di queste operazioni richiederanno tra i 5-90 minuti.Qual è il modo corretto di gestire le operazioni di servizio a lungo termine con WCF ospitato in IIS?

L'utente principale di questo servizio sarà un'applicazione ASP.NET MVC; qual è il modo corretto per gestire questo?

Devo arrestare il timeout e fare alcune chiamate ajax? Dovrei aggiungere una tabella al mio database e fare in modo che le operazioni a lungo termine aggiornino questo database e l'interfaccia web effettui il poll in questa tabella ogni minuto? Non sono sicuro di cosa (se esiste) la migliore pratica generalmente accettata per questo.

fonte

2012-06-18 Nate

Se le operazioni di lunga durata non trasferiscono i dati, allora forse dovresti suddividere questo in un processore asincrono. Quindi il cliente richiede che il lavoro venga avviato, quindi controlla a intervalli regolari per ottenere la risposta o un messaggio che riporti la verifica più tardi. – Noah

@Noah, le operazioni a esecuzione prolungata non restituiscono molti dati, finché non sono completi, dove restituiscono circa un messaggio da 50kb. – Nate

Non dovresti mantenere una connessione http aperta per così tanto tempo se non trasferisci dati, quindi è probabilmente meglio suddividerla. @ Jim fornisce un esempio decente. – Noah

ho scritto qualcosa di simile per il mio progetto di alto livello, in pratica un quadro di programmazione di lavoro.

Ho scelto di percorrere il percorso di memorizzazione dello "stato" del "lavoro" nel database.
Ho scritto un servizio Windows Manager che ha implementato un client WCF (proxy)
Ho scritto un servizio WCF che ha implementato il mio "worker worker".

Il servizio di gestione leggere la coda dal database e distribuire il lavoro a tutti i miei "worker worker". Il motivo per cui il servizio di Windows ha eseguito questa attività anziché la sola interfaccia utente direttamente con l'host worker, è stato perché ha fornito un ulteriore livello di controllo sull'intero processo.

Non mi piaceva l'idea di avere "il cavo di rete scollegato" dal mio host di lavoro e di non ottenere più un aggiornamento di stato da questo specifico lavoro. Quindi, il servizio Windows mi dà la possibilità di monitorare costantemente l'avanzamento dell'host dell'operatore WCF e, se si verifica un errore di connessione (o qualcos'altro inaspettato), posso aggiornare lo stato su non riuscito. Quindi, nessun lavoro orfano.

fonte

2012-06-18 17:35:17 Jim

C'è un motivo per cui hai fatto girare il tuo manager invece di usare MSMQ? – Nate

Non particolarmente. Non ho mai usato MSMQ e, come ho detto, questo era solo un progetto per scuola/COOP. Sono sicuro che ci sono molti modi per migliorare il design, ma è stato abbastanza semplice per quello di cui avevo bisogno. Lo scopo principale dell'applicazione era quello di ottenere un handle su WCF e, sebbene MSMQ sarebbe stato utile, non era l'obiettivo. – Jim

Nella tua progettazione, ciascuno dei tuoi "worker worker" interroga il manager in cerca di lavoro? Oppure il manager chiama ogni lavoro quando è necessario? – Nate

Date un'occhiata a questo

WCF Long Running Operations Ci potrebbero essere altre opzioni, ma quasi sono la stessa cosa. Si può anche venire con alcune notifiche push (presumo non vengono restituiti dati) come uno int il seguente link

WCF Push

fonte

2012-06-18 17:32:10 Tabish

Qual è il modo corretto di gestire le operazioni di servizio a lungo termine con WCF ospitato in IIS?

risposta

Problemi correlati