El servicio de Scheduler de Workflow Foundation

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

Depuracion avanzada en dispositivos moviles(II)

En la anterior entrega vimos los primeros pasos para empezar a trabajar con Mdbg para nuestras aplicaciones para dispositivos móviles, de hecho llegamos al punto de conectar Mdbg contra unos dispositivo en la última parte. En esta ocasión veremos también algo de teoría, si se que todos deseamos siempre empezar trasteando…pero lo primero es lo primero. A continuación os pongo una tabla con los comandos más habituales en Mdbg:




  • ap(process


    • Permite cambiar a otro proceso manejado, Mdbg permite simultanear la depuración entre varios procesos .NET


  • a(ttach)


    • Permite adjuntarse a un proceso para empezar una depuración, un comando relacionado con este es proc que permite enumerar los procesos


  • k(ill)


    • Permite matar un determinado proceso


  • r(un)


    • Permite iniciar un determinado proceso pasándole como argumento el path del mismo


  • x


    • Muestra la lista de módulos o las funciones dentro de un módulo


  • s(tep)


    • Salto en una función


  • sh(ow)


    • Muestra el código fuente para la posición actual


  • p(rint)


    • Muestra el valor de las variables locales y de depuración


  • when


    • Permite la ejecución de un comando dependiendo de un determinado evento de depuración


  • b(reakpoint)


    • Crea un breakpoint o permite visualizar los breakpoints


  • g(o)



    • Resume de la ejecución

Bueno, para empezar a jugar creo que ya llega ¿verdad? Si quereis obtener o saber más comandos pues help o ‘?’


P.D: En las siguientes entregas empezaremos con la parte práctica….


Saludos


Unai Zorrilla Castro

Depuración avanzada en dispositivos móviles (I)

La verdad es que yo no soy muy amigo de realizar artículos o post en varias partes, quizás la principal razón es la falta de tiempo para poder hacerlo, pero en esta ocasión, como el tema creo que lo merece, he decidido ir haciendo un pequeño resumen sobre la depuración de aplicaciones para dispositivos móviles usando Mdbg.


Requerimientos


Empezaremos por el principio, y eso suele ser siempre especificar los requerimientos:



  • Visual Studio 2005

  • El SDK de PocketPC para Windows Mobile 5.0, esto realmente no es necesario, pero como los ejemplos se realizarán usando esta plataforma pues….

  • El SP1 o SP2 de .NET Compact Framework, a poder ser SP2

  • Si usas Windows Vista para desarrollar obligatoriamente necesitas SP2 y Device Emulator 2.0


  • Active Sync 4.2 o Mobile Device Center si usas Windows Vista

Instalación de los componentes necesarios


Ahora que ya tenemos todos los requisitos ¿verdad? Vamos a empezar por instalar en el emulador los componentes necesarios.


Incluye dentro del directorio Windows del emulador los siguientes elementos. NOTA: Esto realmente solo lo harás una vez y posteriormente guardarás el estado del mismo.


Netcfrtl.dll y NetcfLaunch.exe que podrás encontrar en la ruta de abajo si tienes instalado el SP1


C:Program FilesMicrosoft Visual Studio 8SmartDevicesSDKCompactFramework2.0v2.0WindowsCEwce500armv4i


Si lo que has instalado es el SP2 entonces lo tendrás dentro de la siguiente ruta:


C:Program FilesMicrosoft.NETSDKCompactFrameworkv2.0WindowsCEwce500armv4i


Inciando Mdbg y preparándonos



  • Crea un nuevo proyecto para dispositivos móviles, uno sencillo por ahora, simplemente vamos a ver como conectar Mdbg.

  • Desplegamos el proyecto en un emulador, no hace falta la ejecución

  • Con el Emulador abierto abre Device Emulator Manager y haz ‘Cradle’ del mismo

  • Abre la ventana de comandos de visual studio 2005

  • Cambia el directorio hasta el directorio con el código fuente de la aplicación y sitúate dentro del directorio bin/debug


  • Ejecuta mdbg en la consola

                                      



Cargando las extensiones de Compact Framework a Mdbg



  • Para depurar aplicaciones Compact Framework con Mdbg es necesario cargar la extensiones, para ello ejecutamos el comando load de la siguiente forma

Load “C:Program FilesMicrosoft.NETSDKCompactFrameworkv2.0binMdbgNetCf”



  • Si usas el SP1 la ruta es C:Program FilesMicrosoft Visual Studio 8SmartDevicesSDKCompactFramework2.0v2.0bin

 


                                   


Conectando Mdbg y el dispositivo móvil


Ya casi hemos llegado al final de esta primera entrega, este último punto consiste en conectar una aplicación en el emulador con Mdbg.



  • Ejecutamos la aplicación netcflaunch.exe que tenemos en el path Windows de nuestro dispositivo móvil

  • Ejecutamos device dentro de la consola de Mdbg, obtendremos los dispositivos a los que tenemos acceso

  • Ahora ejecutamos en la consola device [ID] siendo ID el número de dispositivo al que queramos acceder

                                


 


Bueno, en estos momentos ya sabemos como iniciar Mdbg, en las siguientes entregas veremos los comandos y los métodos de depuración más tradicionales. Espero que os resulte interesante…


 


Saludos


Unai Zorrilla Castro


 

Por fin… Cradle Cradle!!

Hace poco Bruno informaba en su blog del lanzamiento de Device Emulator 2.0, hablaba de las novedades que este traía.. que no son pocas y a muchos de nosotros nos pueden salvar más de una, os recomiendo ver las nuevas ‘features’. Una de las cosas importantes que creo que merece la pena mencionar es que es ‘medio obligado’ instalar esto en Windows Vista para solucionar algunos de los problemas que teníamos con el desarrollo de aplicaciones para dispositivos móviles en Windows Vista. De hecho una de las cosas que más me gusta es que por fin podemos hacer ‘CRADLE’ del emulador con Windows Mobile Device Center!! Y eso para los que solemos depurar las aplicaciones en el emulador usando Mdbg es esencial…


P.D: Bueno, se nota que por desgracia no he podido ir al Summit de Micro y me he quedado currando o sea que antes de que nadie diga nada pues… J J


Saludos


Unai Zorrilla Castro

Compact Framework v2 SP2

Me cachis…. Es que los chicos de Redmon no paran eh!!! Que no nos dejan poner los pies en el suelo y sacan algo más para que jueguemos!! En esta ocasión el SP2 de Compact Framework 2.0 el cual viene a paliar unos pequeños problemillas que podéis observar en la página de descarga y agregar una serie de pequeñas funcionalidades a la aplicación de monitorización del rendimiento. Una de estas funcionalidades añadidas es la de poder pillar snapshots de la memoria con el fin de buscar ‘Memory Leaks’… ¡! Si has oído bien, memory leaks en .NET ¡! Os dejo un enlace del monstruo de Steven Pratchner’s que seguro que hará las delicias de más de uno.


Saludos


Unai Zorrilla Castro

Las métricas de código en Orcas (I)



  • Ciclomatyc Complexity



    • Permite ver una medida de la complejidad del código escrita basándose en el número de destinos posibles. En un lenguaje más llano podríamos decir que mide el número de condiciones que tenemos puestas en un determinado método. Podéis obtener una definición mucho más formal en la Wikipedia.


      • Posible tabla de valores






















Valor de CC


Evaluación


1-10


Un programa simple, sin mucho riesgo


11-20


Medianamente complejo


21-50


Un programa complejo


+50


Programa inestable


Si queréis probar como se modifica el valor de CC, poner un método con un Switch y muchas condiciones dentro del mismo o bien, muchos expresiones If etc etc…




  • Lines Of Code


    • Como su propio nombre indica mide el número de líneas de código que tenemos en un determinado método, esto lógicamente afecta mucho a la mantenibilidad del mismo como uno puede suponer, de hecho hasta hay un antipatrón que pude aplicarse al caso. No confundir esta métrica con SLOC ( Source Lines of Code) horrible métrica que estima el esfuerzo de un proyecto en líneas de código.

    • Existe un cierto baremo establecido en 50 líneas de código, a partir de este número se puede decir que un método es poco mantenible y debemos refactorizarlo, personalmente yo barajo un número algo inferior


  • Deph Of Inherintance


    • Permite obtener una medida a partir del grafo de herencia de una clase, se define como la máxima longitud que hay desde un nodo cualquiera hasta la raíz, es decir la clase base.


    • Cuantos más profunda encontremos una clase en el grafo mayor es el número de métodos heredados, sobreescritos y por lo tanto es más complejo determinar el comportamiento de la misma.

Depurar tareas propias de MSBuild

Como seguramente todos sabéis unos de los puntos de extensibilidad más importante que provee MSBuild, realmente este es el punto de extensibilidad propiamente dicho, es la creación de tareas propias para incluir dentro de los Targets del Project File. ¿ Os habéis preguntado cómo se pueden depurar estas tareas que creáis? Seguramente muchos para salir del paso pensarán que una buena forma es como anteriormente depurábamos aplicaciones, logeando los pasos de las tareas para ver cómo está funcionando. No sé si la forma que voy a explicar a continuación es la mejor o no pero desde luego a mi no me parece mala ya que nos permite depurar las tareas directamente en Visual Studio como cualquier otro programa o librería.


Pasos para depurar nuestras tareas para MSBuild:


1º Abrir el proyecto de librería en el que se define la tarea customizada de MSBuild


2º Abrir las propiedades del proyecto, botón derecho sobre el proyecto en el explorador de soluciones y clic en propiedades


3º Cambiar en la pestaña de Debug la opción de StartProject por Start External Project


4º Establecer el path completo hacia MSBuild en la caja de texto de Start External Project


5º En Command line arguments establecer el path completo hacia un archivo Project File que incluya la tarea personalizada


6º Ahora ya puedes poner un break point en la clase de definición de la tarea y depurar tranquilamente


Saludos


Unai Zorrilla Castro