2012-06-18 18 views
9

Estoy construyendo un servicio WCF que expondrá varias operaciones, se ejecutará en IIS porque necesita puntos finales HTTPS. La mayoría de las operaciones funcionarán en segundos o menos; sin embargo, una o dos de estas operaciones tomarán entre 5-90 minutos.¿Cuál es la forma correcta de manejar operaciones de servicio de larga ejecución con WCF hospedado en IIS?

El principal consumidor de este servicio será una aplicación ASP.NET MVC; ¿Cuál es la forma correcta de manejar esto?

¿Debo aumentar el tiempo de espera y hacer algunas llamadas ajax? ¿Debería agregar una tabla a mi base de datos y hacer que las operaciones de larga ejecución actualicen esta base de datos y hacer que la interfaz web sondee esta tabla cada minuto? No estoy seguro de qué (si es que existe) la mejor práctica generalmente aceptada para esto.

+0

Si las operaciones de larga duración no transfieren datos, entonces quizás deba dividir esto en un procesador asíncrono. Por lo tanto, el cliente solicitará que se inicie el trabajo, luego revisará a intervalos regulares para obtener la respuesta o un mensaje que diga volver más tarde. – Noah

+1

@Noah, las operaciones de larga ejecución no devuelven demasiados datos, hasta que están completos, donde devuelven un mensaje de aproximadamente 50kb. – Nate

+0

Definitivamente no debe mantener una conexión HTTP abierta por tanto tiempo si no transfiere datos, por lo que probablemente sea mejor dividirla. @Jim proporciona un buen ejemplo. – Noah

Respuesta

1

escribí algo similar para mi proyecto de alto nivel, básicamente un marco de planificación de tareas.

  1. Elegí ir por el camino de almacenar el "estado" del "trabajo" en la base de datos.
  2. Escribí un administrador de servicio de Windows que implementó un cliente WCF (proxy)
  3. Escribí un Servicio WCF que implementó mi "host de trabajador".

El servicio del administrador leería la cola de la base de datos y distribuirá el trabajo a todos mis "hosts de trabajadores". La razón por la que tuve el servicio de Windows para realizar esta tarea en lugar de simplemente hacer que la UI hablara directamente con el host del trabajador, era porque daba un nivel extra de control sobre todo el proceso.

No me gustó la idea de tener "desenchufado el cable de red" de mi host de trabajador y nunca volver a obtener una actualización de estado de este trabajo específico. Entonces, el servicio de Windows me da la capacidad de monitorear constantemente el progreso del host trabajador WCF, y si alguna vez ocurre un error de conexión (o algo inesperado), puedo actualizar el estado al error. Por lo tanto, no hay trabajos huérfanos.

+0

¿Hay algún motivo por el que haya generado su propio administrador en lugar de utilizar MSMQ? – Nate

+0

No particularmente. Nunca he usado MSMQ, y como dije, este era solo un proyecto para la escuela/COOP. Estoy seguro de que hay muchas maneras de mejorar el diseño, pero fue lo suficientemente simple para lo que necesitaba. El objetivo principal de la aplicación era obtener un control sobre WCF, y aunque MSMQ hubiera sido útil, no era el foco. – Jim

+0

En su diseño, ¿cada uno de sus "hosts de trabajadores" consulta al gerente que busca trabajo? ¿O el gerente llama a cada trabajo cuando lo necesita? – Nate

0

Tome un vistazo a este

WCF Long Running Operations Podría haber otras opciones, pero que casi son los mismos. También puede llegar a algunas notificaciones push (supongo que no se devuelven datos) como uno int el siguiente enlace

WCF Push

Cuestiones relacionadas