Introducción
Con WWF, puede crear flujos de trabajo basados en Processor Flow e implementarlos en cualquier tipo de aplicación .NET. Además, este artículo analiza algunos problemas únicos que enfrentan los desarrolladores de ASP.NET: problemas que pueden resolverse mediante el uso de flujos de trabajo, como el mantenimiento del estado y la navegación de páginas.
En septiembre de 2005, Microsoft presentó Windows Workflow Foundation (WWF, Windows Workflow Foundation) en su conferencia bianual de desarrolladores profesionales. Como uno de los pilares de la API de WinFX, WWF proporciona a los desarrolladores un marco común para desarrollar aplicaciones centradas en el flujo de trabajo y basadas en procesos.
Actualmente, algunas organizaciones están intentando automatizar procesos comerciales completos; su respuesta estándar es formar un equipo de desarrolladores para desarrollar el código correspondiente. Aunque este enfoque funciona bien para estas organizaciones, existen algunos problemas inherentes. Para comprender este tema en profundidad, es necesario comprender las características básicas de un flujo de trabajo.
Un flujo de trabajo es esencialmente un método para archivar las actividades involucradas en completar una unidad de trabajo. Normalmente, durante el procesamiento, el trabajo "fluye" a través de una o más actividades. Estas actividades pueden ser realizadas por máquinas o humanos, y pueden ser tan simples como definir el orden de las páginas en una aplicación de Internet, o tan complejas como administrar un documento o producto que debe ser visto, modificado y aprobado por cualquier número de personas. complejo.
Debido a que muchos flujos de trabajo deben permitir la participación humana, su finalización puede tardar mucho tiempo, desde unas pocas horas hasta meses o más. Por ejemplo, es posible que las personas involucradas en el proceso no estén disponibles, no sean locales o estén ocupadas con otras tareas; por lo tanto, el flujo de trabajo debe poder persistir durante todos los períodos de inactividad; Además, los procesos implementados de forma independiente a través de la codificación pueden ser difíciles de entender para las personas sin conocimientos técnicos y difíciles de cambiar para los desarrolladores. Este y otros factores son exactamente el objetivo de los marcos de flujo de trabajo genéricos como Windows WF, cuyo objetivo es facilitar la creación, el cambio y la gestión de flujos de trabajo, ya sea proporcionándoles una interfaz visual o definiendo un conjunto común de API.
Puede colocar flujos de trabajo de WWF en cualquier tipo de aplicación .NET, incluidos Windows Forms, aplicaciones de consola, servicios de Windows y aplicaciones web ASP.NET. Cada tipo requiere consideraciones especializadas. Aunque algunos ejemplos existentes son suficientes para ilustrar cómo alojar flujos de trabajo en Windows Forms y aplicaciones de consola, este artículo se centrará en los problemas que enfrentan los desarrolladores de ASP.NET que desean integrar flujos de trabajo en sus propias aplicaciones.
Nota del autor: el código proporcionado en este artículo se creó utilizando Windows WF Beta 1 y Visual Studio 2005 Beta 2. Puede encontrar información sobre la instalación de Windows WF en www.windowsworkflow.net . Aunque este artículo analiza algunos de los conceptos básicos de Windows WF, hay otros recursos disponibles en esta área. Supongo que el lector sabe al menos un poco sobre Windows WF. El propósito de este artículo es analizar Windows WF y ASP.NET en profundidad, en lugar de discutir Windows WF desde un nivel alto.
1. Patrones WF y MVC de Windows
Al desarrollar una aplicación ASP.NET, una forma común de utilizar WWF es implementar un enfoque modelo-vista-controlador (MVC). En esencia, el objetivo de MVC es separar la capa de presentación, la lógica de la aplicación y la lógica del flujo de la aplicación.
Comprender esto será muy beneficioso al desarrollar una aplicación ASP.NET; considere un lugar de flujo de trabajo de tickets de la mesa de ayuda. Supongamos que un usuario empresarial inicia este flujo de trabajo completando un formulario web ASP.NET y haciendo clic en el botón Enviar. A continuación, el servidor notifica a un empleado mediante una aplicación de Windows Forms y al servicio de asistencia técnica que "hay un nuevo ticket disponible". El empleado de la mesa de ayuda trabajará en el problema y finalmente cerrará el ticket. Si utiliza Windows WF para desarrollar este escenario de flujo de trabajo, toda la lógica y el flujo de procesamiento pueden estar contenidos en el propio flujo de trabajo y la aplicación ASP.NET no necesitará comprender esta lógica en absoluto.
Este tipo de lugar proporciona evidencia sólida: separar la descripción de la lógica es algo bueno. Debido a que este proceso de manejar las solicitudes de la mesa de ayuda es tan mundano, si usa código C# o VB.NET para implementar esta lógica en varias aplicaciones .NET diferentes, correrá el riesgo de duplicar la codificación o algo peor: usar códigos completamente diferentes. a diferentes implementaciones del mismo proceso de negocio. Pero si utiliza WWF para implementar este proceso, los desarrolladores de aplicaciones que requieran este proceso sólo necesitarán modificar los pasos en un lugar (el flujo de trabajo en sí) sin tener que preocuparse por cambiar la lógica de la aplicación. La duplicación de código y dónde implementar este proceso se pueden facilitar mediante el uso de Windows WF.
Al implementar una arquitectura MVC en ASP.NET utilizando Windows WF, los desarrolladores deben intentar crear flujos de trabajo que sean independientes de la aplicación, mientras el flujo de trabajo aún esté alojado dentro de la aplicación. Esto ayudará a mantener la lógica independiente de la descripción y a mantener un alto grado de independencia entre la secuencia de pasos de trabajo y el flujo de páginas en la aplicación web.
Un nuevo desarrollador de WWF podría intentar desarrollar un flujo de trabajo con un número fijo de actividades en un orden determinado y luego desarrollar un conjunto de formularios web ASP.NET que fluyan de un formulario a otro en el mismo orden. Desafortunadamente, aunque esto parezca lógico, en realidad es muy improductivo porque tendrá que implementar la lógica del flujo de trabajo nuevamente. La página web X no necesita saber si necesita ir a la página Y o a la página Z para implementar este paso del flujo de trabajo correctamente. En cambio, el flujo de trabajo (modelo) debería indicarle a ASP.NET (el controlador) qué hacer a continuación; ASP.NET debería decidir qué página mostrar; De esta manera, cada página apenas necesita comprender todo el proceso; solo necesita saber cómo completar una actividad diferente y dejar que el flujo de trabajo se encargue de cómo fluye la página de un lugar a otro. Esta separación ofrece a los desarrolladores una gran flexibilidad a la hora de gestionar el flujo de páginas. Por ejemplo, si decide cambiar el orden en que se muestran las páginas, puede hacerlo fácilmente desde el flujo de trabajo sin cambiar una sola línea de código en la aplicación ASP.NET.
2. Un ejemplo de MVC de flujo de trabajo simple
Para ilustrar esta idea, le mostraré una aplicación y un flujo de trabajo ASP.NET simples. Este flujo de trabajo demasiado simplificado describe un proceso que recopila información privada de una aplicación externa y luego la muestra. Los pasos son los siguientes:
1. Invocar un método: esto significa solicitar el nombre de una persona; este flujo de trabajo utiliza la actividad InvokeMethod (consulte la Figura 1).
2. Espere hasta que se active un evento; esto significa recibir un nombre en este paso, el flujo de trabajo utiliza la actividad EventSink;
3. Obtenga una dirección de correo electrónico del anfitrión mediante una llamada similar.
4. Esperar un evento significa recibir una dirección.
5. Después de recibir el nombre y el correo electrónico, el flujo de trabajo inicia una actividad InvokeMethod para enviar la información personal a la aplicación que llama. En una situación del mundo real, este último paso no es muy importante. Lo más probable es que llame a un servicio web para enviar los datos a otro sistema o colocarlos en una base de datos.
Figura 1. Flujo de trabajo de muestra: este flujo de trabajo describe el proceso implícito en una aplicación ASP.NET de muestra.
Para implementar este flujo de trabajo en ASP.NET, necesita una página para recopilar nombres de personas, una página para recopilar direcciones de correo electrónico y una página para mostrar datos personales. Recuerde, el formulario de inicio de sesión de datos no debe tener idea de lo que sucedió antes o después. Lo mismo ocurre con las páginas de visualización. Sin embargo, la aplicación ASP.NET debe saber qué página mostrar al usuario; este es el propósito de introducir controladores. Este ejemplo utiliza un controlador HTTP para implementar la solución. Este controlador personalizado, llamado WorkflowController, es responsable de las siguientes tareas:
· Obtener una referencia al momento en que se ejecuta el flujo de trabajo.
· Obtener una referencia a una instancia de flujo de trabajo existente o iniciar una nueva instancia de flujo de trabajo (esto depende de si se ha iniciado una instancia de flujo de trabajo).
·Establecer comunicación entre el controlador y el flujo de trabajo.
·Manejar eventos de este flujo de trabajo.
·Dígale a ASP.NET qué página debe mostrarse, dependiendo de qué capa del flujo de trabajo se esté ejecutando actualmente.
Como ha visto, este controlador personalizado esencialmente maneja todo el trabajo relacionado con WWF y el control de páginas, manteniendo las páginas ASP.NET individuales "en silencio" sobre las acciones que suceden en segundo plano. Lo único de lo que debe preocuparse un formulario web es de realizar la tarea específica en cuestión y pasar los datos necesarios al controlador.
De forma predeterminada, WWF funciona en un modelo asincrónico. Esto significa que cuando el host de una aplicación inicia una instancia de flujo de trabajo, el control se devuelve inmediatamente al host mientras el flujo de trabajo continúa ejecutándose en otro subproceso. Esto puede resultar útil en una aplicación de Windows Forms, donde es muy deseable una capacidad de respuesta continua de la interfaz de usuario. Al utilizar este modelo asincrónico, el flujo de trabajo se puede ejecutar en segundo plano mientras el usuario puede continuar operando la aplicación. Sin embargo, en una aplicación web, es posible que no se espere este tipo de comportamiento, ya que normalmente el control solo se devolverá al usuario después de que el servidor haya completado una unidad de trabajo. Esta es exactamente la encarnación de la escalabilidad de Windows WF. En Windows WF, los desarrolladores pueden usar o crear "servicios de tiempo de ejecución" para monitorear e incluso modificar el tiempo de ejecución del flujo de trabajo. Los ejemplos incluyen:
· Servicio de persistencia: almacena el estado del flujo de trabajo entre los tiempos de ejecución y de inactividad
· Servicio de seguimiento: envía información sobre la ejecución del flujo de trabajo a algunos medios
· Servicio de transacciones: ayuda a mantener la integridad de los datos durante la ejecución del flujo de trabajo
Además, los servicios de subprocesamiento permiten a los desarrolladores controlar cómo funcionan las instancias del flujo de trabajo son ejecutados. Como se analizó anteriormente, el tiempo de ejecución del flujo de trabajo ejecutará de forma predeterminada la instancia de forma asincrónica en un subproceso independiente del host. Pero como lo más probable es que esto no sea lo que espera ASP.NET, deberá cambiar el servicio de subprocesos de flujo de trabajo predeterminado. Afortunadamente, Microsoft ha proporcionado una solución para esto: ASPNetThreadingService. Para implementar este cambio, puede agregar ASPNetThreadingService al servicio de ejecución del flujo de trabajo mediante codificación manual o completar esta tarea en el archivo web.config. La aplicación de ejemplo de este artículo utiliza el modo de configuración. En la sección de servicios/tiempo de ejecución del flujo de trabajo de web.config (consulte el Listado 1), agregue una línea similar a la siguiente:
<add type=
"System.Workflow.Runtime.Hosting.ASPNetThreadingService,
System.Workflow.Runtime, Versión=3.0.00000.0,
Cultura=neutral, PublicKeyToken=31bf3856ad364e35"/>
3. Implementar la lógica del controlador
A continuación, debe implementar la lógica del controlador con un procesador HTTP. Para construir este controlador, todo lo que necesita hacer es crear una clase llamada controlador WorkflowController, que implementa la interfaz del controlador IHttp. Hasta ahora, no ha visto nada especial sobre Windows WF: esta es una característica específica de ASP.NET (siga leyendo).
En esta clase de procesador WorkflowController, el método de interfaz del procesador IHttp denominado ProcessRequest maneja una solicitud web desde la aplicación ASP.NET. Aquí, debe obtener una referencia a una instancia de tiempo de ejecución de flujo de trabajo estático, crear controladores de eventos para el flujo de trabajo e iniciar la ejecución del flujo de trabajo. Antes de iniciar una instancia de flujo de trabajo, debe verificar si el valor de la cadena de consulta de la solicitud contiene un GUID que represente un ID de instancia de flujo de trabajo. Si este ID está presente, sabrá que ya hay una instancia en ejecución, por lo que puede obtener una referencia a esa instancia y continuar con la ejecución. Si este ID no existe, debe crear una nueva instancia e iniciar el proceso de ejecución llamando al método Iniciar flujo de trabajo en el tiempo de ejecución del flujo de trabajo.
Una vez iniciada una instancia, los controladores de eventos administran la comunicación dentro y fuera del flujo de trabajo. Dado que el propósito de este artículo no es discutir los servicios de comunicación local, no discutiré este tema en detalle aquí, pero analizaré sus técnicas de implementación de alto nivel y discutiré nuevamente cómo funciona esto en una aplicación ASP.NET. Para facilitar el procesamiento de la comunicación, necesitará varias interfaces .NET, que se utilizan para describir información dentro y fuera del flujo de trabajo y del host. Los encontrará en el código fuente del proyecto WorkflowClassLibrary adjunto a este artículo. También encontrará clases que implementan estas interfaces y la funcionalidad correspondiente necesaria para implementar el mecanismo de flujo de trabajo.
Echemos otro vistazo breve al archivo web.config. Tenga en cuenta que, cerca del elemento ASPNetThreadingService analizado anteriormente, utilizamos tres elementos para describir la clase de servicio de comunicación:
<add type="Workflow.RuntimeServices.GetNameService,
Workflow.Library, Versión=1.0.0.0, Cultura=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜agregar tipo="Workflow.RuntimeServices.GetEmailService,
Workflow.Library, Versión=1.0.0.0, Cultura=neutral,
PublicKeyToken=c4620ae819b5257e"/>
＜agregar tipo="Workflow.RuntimeServices.SendDataService,
Workflow.Library, Versión=1.0.0.0, Cultura=neutral,
PublicKeyToken=c4620ae819b5257e"/>
También hay un elemento aquí que indica a la biblioteca de tiempo de ejecución del flujo de trabajo que utilice SqlStatePersistenceService. Este servicio adicional almacena la persistencia de un estado de flujo de trabajo en una base de datos del servidor SQL entre solicitudes de página. Debe crear esta base de datos manualmente en Por adelantado, pero Microsoft proporciona un script SQL para hacer esto. Lo encontrará en la carpeta C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Windows Workflow FoundationSQL. Al igual que los servicios modelo, puede agregar estos servicios mediante programación. , pero también puede implementarlo en la configuración, lo que reducirá en gran medida la cantidad de código a escribir y brindará flexibilidad, incluso después de que se produzca el código. Hay una línea en la configuración que agrega un HttpModule, que admite el tiempo de ejecución de Windows WF. biblioteca en ASP.NET; también hay una línea que configura el controlador del controlador Http discutido anteriormente. Como puede ver en esta configuración, hay muchas cosas en ella.
Como conclusión, Windows WF proporciona una configuración extremadamente fácil de usar. Marco extensible para que los desarrolladores desarrollen aplicaciones basadas en flujos de trabajo. Se ha convertido y seguirá siendo una aplicación importante. A menos que sea una empresa de servicios tecnológicos o un ISV, el software debe proporcionar procesos operativos y comerciales. , los desarrolladores pueden hacer que el proceso de desarrollo sea fácil y flexible.
