te hacemos llegar este boletín, porque entendemos que Informar es Colaborar. Si no puedes visualizarlo correctamente, está disponible en la página web correspondiente.

Editorial

A día de hoy todavía nos toca dar muchas explicaciones a nuestros clientes sobre para qué y cuándo tiene sentido utilizar un diseño lógico de nuestros desarrollos basado en WorkFlow. La teoría está clara: cuando la solución está orientada a procesos en los que intervienen varias actividades, probablemente en un periodo largo de tiempo, con varios subsistemas y/o personas intervinientes y diversas decisiones en función de las variables y valores de contexto... entonces, un diseño basado en flujos de trabajo es lo adecuado. Y lo es porque cambios en las reglas de negocio, en las personas y subsistemas intervinientes, en los caminos y las decisiones que los toman, etc. van a ser mejor soportados, interpretados y mantenidos por sistemas basados en workflows.

La práctica pone el umbral de la decisión un poco más complicado ¿cuantos cambios van a ocurrir o cuantas variantes del proceso van a convivir para que el coste de trascender a unos cuantos if-then y unas cuantas decisiones basadas en el modelo clásico compense el sobrecoste de aplicar una capa de abstracción más al diseño del sistema?.

A Microsoft le ha costado mucho proporcionar un sistema que verdaderamente ofrezca toda la potencia del diseño de aplicaciones a medida basadas en workflow. Ahora está disponible la Workflow Fundation en su .Net framework 3.0 en adelante y es muy interesante. Hasta ahora, Microsoft ofrecía un ESB (Enterprise Service Bus) verdaderamente potente y a la vez complejo (basado en Biztalk) que resolvía todo el modelado para soluciones B2B y EAI. Sin embargo, todavía en muchos casos, la resistencia a incrementar la complejidad y en otras, el desconocimiento de los posibles beneficios, hace que este tipo de soluciones no penetren con toda la intensidad con la que deberían en el espectro de los desarrollos a medida (aunque sí como productos específicos BPM separados).

En este boletín traemos algunos apuntes para que podáis profundizar en el tema.

¿En qué escenarios es útil WF?

Sin duda, cuando hablamos de las capacidades de Windows Workflow Foundation (WF), una de las preguntas que nos surge es cuáles son sus escenarios de aplicación más interesantes. Pues bien, Paul Andrew (Product Manager de Microsoft y uno de los padres de WF) nos comenta en su blog algunos de estos escenarios:

• Construir un servidor para Business Process Management (BPM), siendo el motor de ejecución el núcleo de tal servidor como mecanismo de ejecución, control y seguimiento de los workflows que implementemos.

• Implementar lógica de negocio que requiere características long running, las ventajas que aporta WF en este caso vienen dadas por el hecho de que por defecto está preparado para persistir información y estados de ejecución (desde una perspectiva High Level), lo que reduce mucho tiempo de desarrollo al tener gran parte del trabajo realizado.

• Situaciones que impliquen cambios dinámicos de reglas de negocio, esto facilita la creación de workflows estándar que podemos utilizar en múltiples entornos, y en el que los cambios necesarios los incluimos en las reglas de negocio asociadas a los workflows para soportar así cada caso específico.

• Hacer visualizables los procesos de negocio de una organización, a través de los servicios de runtime de WF que nos permite hacer, entre otros, un seguimiento del estado de ejecución de nuestro workflow (tracking service), generación automática de logs, y por supuesto, el hecho de que podamos modelar el workflow de manera visual en base a arrastrar una serie de piezas o actividades que interconectamos de acuerdo a las directrices de los procesos de negocio a modelar.

Arquitectura de WF

Un workflow está compuesto por una serie de componentes, llamados actividades, que se enlazan de manera adecuada (y en función de estilo de creación del workflow, secuencial o máquina de estados) para constituir un modelo ejecutable de un cierto proceso de negocio. Como vemos en el diagrama de la arquitectura de WF, tenemos 5 elementos fundamentales: Un diseñador visual de para crear nuestros worflows en base a arrastrar actividades sobre una superficie por diseño. Por defecto el entorno natural para la creación de workflows es Visual Studio 2005 que actúa como hoster del diseñador visual de WF. Para tener disponible este diseñador, necesitamos las extensiones de WF para VS 2005. Como ya nos comentó Unai, el diseñador de WF se puede “sacar” del entorno de WF y hostearlo en otros entornos. Dos ejemplos de esto los tenemos con NetfxLive (un diseñador de workflows embebido en una aplicación web) o la aplicación WFPad.

• Una librería de actividades base, que son un conjunto de actividades que por defecto nos da WF para crear nuestros workflows. Algunos ejemplos de actividades son: IfElse, While, Policy, Delay, etc. Además de estas, ya tenemos actividades especificas para crear workflows en el entorno de WSSv3: SendEmail, OnTaskChange, OnWorkflowActivated, etc (estas actividades las tenéis a partir de la dll Microsoft.SharePoint.WorkflowActions.dll que hay que añadir como referencia en nuestro proyecto de workflow para Sharepoint y en en la toolbox de VS 2005), interactuar con servicios de WCF, y otros muchos ejemplos en el sitio oficial de WF .

• El runtime engine de WF, que es el responsable de la ejecución, control y gestión de las distintas instancias de workflows que tengamos creadas. Los componentes fundamentales son el motor de ejecución, los core services para el motor de ejecución (que se encargan de controlar la ejecución de los workflows), y el motor de reglas que permite utilizar reglas de negocio en nuestros workflows.

• Los servicios de runtime, que son piezas “enchufables” que permiten extender las capacidades del motor de ejecución de WF habilitando la posibilidad de persistir el estado de ejecución y los datos de un workflow, realizar un seguimiento (tracking) de las instancias del workflow en ejecución, comunicarlo con el exterior (aplicaciones locales y remotas), etc.

• Proceso de host, que se encarga de hospedar tanto el runtime engine como los runtime services, es decir, es el que en la práctica se encarga de instanciar y arrancar el motor de ejecución de WF, así como de instanciar los servicios de runtime necesarios. En este link podéis ver un estupendo resumen de todo lo que se puede hacer en el proceso de host de WF. Finalmente comentaros que la naturaleza del proceso de Host de WF es realmente variada, desde un servicio Windows o una aplicación de consola, pasando por un formulario Windows (justo el caso que veremos en este post) o una página ASP.NET, hasta entornos más complicados como WSSv3 o la BTS 2006 R2.

Más información sobre las características software del framework 3.0 WF

Caso de éxito en Kiwibank

Banco líder en Nueva Zelandia gestiona su rápido crecimiento mediante el uso de un moderno modelo de programación (WF del .Net framewwork 3.0)   Más información sobre el caso de éxito.

Referencias

Apuntes interesantes: Información sobre el Motor, Información sobre las Instancias y Tipos de Workflow

Introducing Microsoft Windows Workflow Foundation: An Early Look
Muy completo y extenso (ingles) 

Cutting Edge, Un viaje por las actividades del flujo de trabajo de Windows 
Muy bueno para empezar (en castellano)

Simplify Development With The Declarative Model Of Windows Workflow Foundation 
Muy completo, también para empezar pero en ingles

Windows Workflow Foundation - Ejemplo simple
 
Windows Workflow Foundation - Samples 
Ejemplos y otra información (en ingles)

Microsoft .NET Framework 3.0 Community (NetFx3)
La "home" de la comunidad (ingles)

Curso de Workflow Foundation 
Curso completo de Carlos Segura

Blog interesante con muchos recursos

Ejemplo sobre un HelpDesk (inglés)
http://msdn.microsoft.com/msdnmag/issues/06/03/CuttingEdge/
http://msdn.microsoft.com/msdnmag/issues/06/04/cuttingedge/default.aspx (segunda parte con ASP.net)

Este e-mail se envía por correo electrónico de la mano de ENCAMINA, S.L [CIF:96988837] con la intención de informarle de de aspectos relacionados con las TIC. Si no desea recibir este boletín puede darse de baja a través de un mensaje a info@encamina.com, llamando al 902 196 893 o por fax al 96 269 80 63

(c) 2007 ENCAMINA, S.L. T. 902 196 893 | 96 269 80 64 | F. 96 269 80 63 | Avda. 9 de Octubre, nº 76, 3º y 4º | 46520 Puerto Sagunto, Valencia