Como todos los desarrolladores de software sabemos, crear programas es una actividad gratificante y que impone una enorme cantidad de retos. Desde el principio de los tiempos, los programadores siempre andamos buscando y creando herramientas, librerías, marcos de trabajo, etc. que nos simplifiquen la solución de las tareas y nos faciliten el desarrollo de las aplicaciones y servicios que nuestros clientes y jefes necesitan.

La mayoría de las complejidades de una aplicación no se ven a simple vista en el software que habitualmente creamos. Me refiero a cosas como la ejecución en paralelo, la sincronización de procesos, las llamadas a procedimientos remotos, etc. Detalles que tendríamos que ir resolviendo en cada desarrollo específico si no contásemos con herramientas como a las que me refería anteriormente.

Workflow Foundation provee al desarrollador de una caja de herramientas que permite abstraernos de muchos de esos detalles y centrarnos en los aspectos importantes del negocio de la mano que nos da de comer: mejorar procesos y herramientas para aumentar la productividad y reducir costes; permitiendo que el desarrollador sea más productivo, que las aplicaciones sean más sencillas de modificar y más fácilmente actualizables.

Si queréis saber más sobre los conceptos que se esconden detrás de Workflow Foundation, os recomiendo que le echéis un vistazo a "The Workflow Way"

Nuevas características

Para esta nueva versión de .NET Framework, se han introducidos grandes cambios en la versión correspondiente de Workflow Foundation, que llamaremos WF4, con respecto a las versiones incluidas en .NET 3.0 y 3.5 (a las que nos referiremos por WF3). El equipo ha revisado el núcleo del modelo de programación, el runtime y las herramientas, y ha reestructurado cada uno de ellos para mejorar el rendimiento y la productividad, así como para añadir algunas de las propuestas más importantes recibidas a través del feedback de los usuarios actuales.

La gran mayoría de los cambios que encontrarán los desarrolladores en WF4 con respecto a WF3 han sido necesarios para mejorar la experiencia de utilización de Workflow Foundation y hacer de él cada vez más una pieza fundamental en el desarrollo de aplicaciones .NET. Es importante destacar que todos esos cambios se han realizado manteniendo la compatibilidad hacia atrás. Los nuevos componentes del framework están localizados en un nuevo ensamblado llamado System. Activities.dll, mientras que los componentes compatibles con versiones anteriores se encuentran en System.Workflow.dll, de manera que podemos migrar sin tocar nada de código las aplicaciones que ya tengamos desarrolladas con WF3.

Diseñadores
El diseñador de workflows es la parte más visible de Workflow Foundation, y para el equipo de Visual Studio 2010 los objetivos principales en este sentido han sido la usabilidad y el rendimiento. Los diseñadores de actividades están basados en Windows Presentation Foundation (WPF), aprovechando todas las capacidades que éste aporta. A partir de ahora, podremos definir en XAML nuestras actividades, para luego verlas e interactuar con ellas. Una novedad muy interesante es la posibilidad de alojar (host) el diseñador en nuestras aplicaciones, de forma que nuestros los usuarios puedan interactuar con los flujos de trabajo de una manera mucho más fácil y natural.

Flujo de datos
En WF3, el flujo de datos dentro de un workflow era algo oscuro. WF4 nos ofrece un modelo de flujo de datos mucho más claro y conciso en el uso de parámetros y variables. Estos conceptos, que son familiares a los desarrolladores, simplifican tanto la definición del almacén de datos como su viaje a través de flujos y actividades. Este nuevo modelo, a la vez, hace más obvias las entradas y salidas esperadas de una actividad, y mejora el rendimiento del runtime en la medida en que los datos son administrados con más eficiencia.

Diagramas de flujo
En WF4 aparece una nueva actividad de control de flujo llamada Flow- Chart, de manera que los desarrolladores puedan definir un workflow usando el modelo de diagramas de flujo, algo mucho más similar y cercano a los conceptos que muchos analistas y desarrolladores manejan habitualmente cuando crean soluciones o diseñan procesos de negocio, por lo que tenía sentido proveer de una actividad que hiciese más sencillo modelar este concepto. Este nuevo control permite trabajar con operaciones como volver a pasos anteriores, dividir la lógica en base a una condición, etc.

Modelo de programación
En WF4, se renueva el modelo de programación de Workflow Foundation para hacerlo más simple y más robusto. La clase base en este modelo de programación es WorkflowElement, que sirve para representar tanto workflows como actividades. Además, ya no necesitamos crear un Workflow- Runtime para invocar a un workflow; tan solo necesitamos crear una instancia del flujo y ejecutarla, lo que simplifica la creación de tests unitarios y elimina la necesidad de crear un entorno apropiado cada vez que queremos instanciar un flujo.

Integración con WCF
Las ventajas que ofrece Workflow Foundation se aplican tanto a crear servicios y consumirlos como a coordinarlos. Para WF4, se ha hecho un gran esfuerzo en la integración de WCF y WF, y el resultado de ello se traducirá en nuevas actividades de mensajería, coordinación de mensajes y un soporte para alojar servicios mejorados, junto a una forma de definir declarativamente esos servicios.

Con las manos en la masa…

Plantillas de flujos y el diseñador
WF4 incorpora muchas actividades, y Visual Studio 2010 incluye dos plantillas para definir workflows: secuencial (sequential) y de diagrama de flujo (flowchart). Aunque cualquier objeto WorkflowElement puede ser ejecutado como un workflow, estas dos plantillas nos ofrecen los patrones de diseño más comunes a la hora de definir la lógica de negocio. En la figura 1 vemos un ejemplo de flujo de trabajo secuencial que define lo que ocurre cuando se recibe un pedido: se guarda y se notifica a otros servicios.

Por su parte, los flujos de tipo flowchart se han introducido en WF4 a petición de un montón de desarrolladores que desean trabajar en base a paradigmas más parecidos a aquellos con los que suelen razonar. Por ejemplo, imaginemos un escenario en el que entran en juego parámetros de un usuario en nuestra aplicación. Como respuesta a los datos introducidos, nuestro sistema debería continuar con el proceso o volver a un paso anterior para que el usuario vuelva a introducirlos. En un flujo secuencial, esto se modelaría mediante algo parecido a la figura 2, donde la actividad DoWhile se usa para continuar procesando hasta que se cumpla una cierta condición.

La figura 2 es muy correcta; pero como desarrolladores o analistas, esta figura no nos dice gran cosa. Sin embargo, el diagrama de flujo que se muestra en la figura 3, que hace exactamente lo mismo, es mucho más parecido a lo que estábamos pensando cuando lo definimos.

Actividades de flowchart
Cuando diseñemos flujos de tipo flowchart, podremos usar muchas más actividades para controlar el flujo de ejecución de nuestros workflows. Estas actividades nos aportan pasos simples, o puntos de decisión basados en una condición o un switch. El poder real de los diagramas de flujo reside en la posibilidad de conectar estos tipos de nodos para conformar los flujos deseados.

• Flowchart. Es un contenedor de pasos del workflow. Cada paso puede ser una actividad o cualquiera de los siguientes elementos de esta lista, que para ser ejecutados deberán estar conectados dentro del flowchart.
• FlowDecision. Es un bifurcador lógico basado en una condición.
• FlowSwitch. Permite varias ramas de ejecución basadas en una expresión.
• FlowStep. Representa un paso en el flujo de ejecución, con la posibilidad de estar conectado a otros pasos.

Es importante darse cuenta de que, mientras que hay actividades específicas para este modelo de flowchart, podemos usar otras actividades en el workflow. Una actividad de tipo flowchart se puede añadir a otra actividad para que aporte la semántica de ejecución y diseño de un diagrama de flujo. Es decir, podemos tener una secuencia con muchas actividades y un flowchart justo en el medio.

La actividad Interop
Para aquellos que tenemos workflows y actividades ya definidos en WF3, la actividad Interop puede sernos muy útil para reusar lo que ya tenemos hecho. Esta actividad nos permite incorporar a un modelo de WF4 las actividades que ya tengamos definidas bajo un modelo WF3, mapeando las propiedades que tengamos como parámetros en el modelo de WF4. Al ser estas propiedades parámetros, podremos utilizar expresiones para definir valores. En la figura 4 se muestra la configuración de una actividad Interop que llama a una actividad de WF3. Los parámetros son definidos a través de referencias a variables definidas en el workflow.

Actividades de "mensajería"
Uno de los puntos más importantes en WF4 es la mejora en la integración de WF y WCF. Desde el punto de vista de los workflows, esto se traduce en tener actividades que modelen diferentes operaciones de "mensajería", tales como enviar o recibir mensajes. Actualmente hay varias actividades para ello, cada una con una funcionalidad y sentido algo diferentes:

• Send/Receive. Actividades de un solo sentido para enviar o recibir mensajes. Estas actividades se componen de interacciones petición/respuesta.
• ReceiveAndSendReply. Modela una operación que recibe un mensaje y devuelve una respuesta.
• SendAndReceiveReply. Invoca a un servicio y recibe la respuesta.
• SendParameters/ReceiveParameters. Invoca o implementa una operación de servicio usando varios parámetros.

Para hacer una llamada a un método de un servicio desde un workflow, seguiremos los pasos normales de añadir una referencia al servicio a nuestro proyecto de Workflow Foundation. Visual Studio creará una actividad personalizada para cada método que se encuentre en el contrato del servicio. Podéis pensar en esto como algo similar a un proxy WCF para WF. Por ejemplo, si disponemos de un servicio que busca reservas de hoteles con el contrato que se muestra en el listado 1, al añadir una referencia a él nos aparecerá una actividad personalizada como la de la figura 5.

[ServiceContract] public interface ISearchHotels { [OperationContract] List<HotelSearchResult> SearchHotels( HotelSearchRequest requestDetails); }

Conclusiones

Todo lo anterior y mucho más nos espera a partir del próximo abril; un sinfín de mejoras en cuanto a rendimiento, productividad y facilidades a la hora de definir la lógica de negocio. Si quiere tener una visión más detallada de las características que hemos presentado aquí, así como de algunas otras que se nos han quedado en el tintero, visite Workflow Foundation 4 Beta 1.