Este post pretende continuar con una serie de post escritos en anteriores ocasiones en las que se hablaba de diversos servicios de Windows Workflow Foundation, tales como el Servicio de Persistencia o el motor de reglas de Workflow Foundation. Sin duda una de las cosas más interesantes de la API de Windows Workflow Foundation es la puesta en práctica de una arquitectura basada en servicios o proveedores lo que nos permite variar el comportamiento de un Workflow o del Runtime cambiado los servicios. En esta ocasión me gustaría hablar del servicio de Scheduler de Workflow Foundation, este servicio es uno de los servicios principales de Workflow Foundation y se encarga básicamente de la creación de los hilos que se encargan de ejecutar las instancias de los Workflows además del registro de los timers y los eventos. Por defecto WF trae ‘out-of-box’ dos servicios de Scheduler, el DefaultWorkflowService y ManualWorkflowService aunque siempre podremos realizar nuestra propia implementación del servicio heredando de la clase base WorkflowSchedulerService. DefaultWorkflowSchedulerService es el servicio de scheduler por defecto que tendremos dentro del Runtime de WF y funciona mediante la asignación de hilos físicos ( ojo, más adelante explicaremos que son los WorkflowThreads) de un pool al Runtime para que este ejecute instancias de Workflow, siempre y cuando tengamos hilos disponibles, el workflow puede tomar la decisión de persistir una instancia de Workflow si comprueba que existe una carga de trabajo muy elevada. Esta implementación de servicio es la más usual en la mayoría de los ámbitos de uso de WF, sin embargo, existen ciertas situaciones en las que este servicio no es el adecuado, una de estas situaciones por ejemplo es un entorno Web, en la que las páginas ejecutan o interactúan con instancias de Workflow Foundation, como seguramente sabe cada Request de una página aspx se ejecuta en un determinado hilo y dejar que el servicio de scheduler por defecto cree un nuevo hilo podría resultar en una gran merma de rendimiento. Para resolver estas casuísticas desde el equipo de Windows Workflow Foundation se desarrollo el servicio ManualWorkflowService el cual utiliza el mismo hilo de ejecución del runtime de workflow para ejecutar las instancias de Workflow con el consiguiente aprovechamiento de recursos para entornos como el anteriormente mencionado.
Muchas de las personas con las que hablo y que ya tienen cierto conocimiento de Windows Workflow Foundation hablan siempre de la Actividad PararellActivity y siempre comentan la ejecución paralela de las actividades contenidas dentro de las ‘ramas’ de la misma, lo cual es incorrecto y técnicamente no se podría conseguir puesto que Workflow no permite la concurrencia a la hora de ‘desencolar’ actividades de la cola de la instancia de Workflow para ejecutar actividades, digamos que únicamente un hilo físico puede en un determinado instante retirar una actividad a ejecutar de la cola de actividades y que además ningún otro hilo podrá retirar otra actividad hasta que la actividad anterior no se encuentre en el estado ‘Closed’. ¿Entonces, que significa una actividad como PararellActivity? Aquí es donde entra lo que comentamos anteriormente sobre los WF Threads, los WF Threads son hilos ‘virtuales’, sin representación física, que simulan un pararelismo, que no es real puesto que ambas ramas son ejecutadas por un mismo hilo. Lo que si puede realmente pasar es que varios hilos ejecuten la misma instancia de un determinado Workflow, nunca concurrentemente claro, piense por ejemplo en un workflow con un actividad Timer y el servicio de persistencia incluído dentro del Runtime, una vez transcurrido el tiempo especificado en el Timer el servicio de persistencia recuperará del ‘Store’ asignado la instancia de Workflow para ejecutar la misma, en estos momentos el hilo anteriormente podría haberse asignado a otra instancia y por lo tanto a la instancia recuperada del servicio de persistencia se le asignaría otro hilo diferente.
A continuación os enseño una serie de pantallazos de una herramienta que desarrollé para intentar explicar gráficamente el comportamiento del servicio de Scheduler en los eventos de desarrollo y formaciones que doy sobre Windows Workflow Foundation, la herramienta en cuestión permite seleccionar una librería y ejecutar con los distintos servicios de persistencia cada uno de los tipos de workflows que estén contenidas dentro de la misma.
Instancia de Workflow secuencial con dos Code Activities y DefaultWorkflowSchedulerService
Workflow secuencial con dos Code Activities y el ManualWorkflowSchedulerService
Instancia de Workflow secuencial con una actividad Pararell y dos Code Activities en cada una de las ramas y DefaultWorkflowSchedulerService
Instancia de Workflow secuencial con una actividad Pararell y dos Code Activities en cada una de las ramas y ManualWorkflowSchedulerService
Saludos
Unai Zorrilla Castro