Welcome to Comunidad .NET de Cd. Juárez Sign in | Join | Help

May 2006 - Posts

Aprendiendo a ser un buen anfitrión para workflow

Si le echaron un vistazo al mapa, se habrán dado cuenta de los 3 conceptos principales que hay que entender: host, actividades y workflow.

En esta entrada, hablaré un poco sobre el primero: ¿qué se necesita para que mi aplicación pueda utilizar Windows Workflow Foundation?

Muy sencillo: la aplicación debe tener la capacidad de ser el anfitrión (host) para el ambiente de ejecución de los workflows.

Ahora, en la vida real, ser un buen anfitrión pudiera requerir de mucho dinero o amigos--después de todo, hay que tener chelas en la casa para cuando caen los compas, y tener listos los teléfonos de las amigas teiboleras en caso de una fiesta de emergencia, ya saben... digo... ejem... ¿En qué estaba? Ah si, hablando de una aplicación de .NET en realidad solo necesitas hacer 2 cosas:
  1. Crear el ambiente de ejecución de workflow (runtime engine)
  2. Instanciar y arrancar el workflow

// asumiendo que se tienen referencias a los 
// siguientes assemblies:
// 
// System.Workflow.Activities,
// System.Workflow.ComponentModel y
// System.Workflow.Runtime
 
using System.Workflow.Runtime;
using System.Workflow.Runtime.Hosting;
 
namespace WorkflowApplication
{
  class MyProgram
  {
    static void Main(string[] args)
    {
      // crear el ambiente de ejecución de para 
      // los workflows (runtime)
      WorkflowRuntime runtime = new WorkflowRuntime();
 
      // TODO:
      // agregar servicios y/o suscribirse a 
      // eventos del runtime antes de arrancar 
      // la ejecución del workflow
 
      // instanciar e iniciar la ejecución del workflow.
      // en este caso, "MyWorflow" es el nombre 
      // de la clase que representa mi workflow
      WorkflowInstance instance =
        runtime.CreateWorkflow(typeof(MyWorkflow));
      instance.Start();
 
      // no olvidar destruir el runtime cuando 
      // ya no se necesite!
    }
  }
}

Y eso es todo. Esto implica que cualquier "ejecutable" de .NET puede ser un anfitrión--desde una vulgar aplicación de consola, como en el ejemplo, hasta una aplicación de Windows Forms o incluso ASP.NET. El runtime correrá dentro del proceso de tu ejecutable. El runtime sigue el patrón sigleton, por lo que solo se permite una instancia del runtime por aplicación.

Ahora, hay algo que sí hay que cuidar desde un inicio: el threading. Sobretodo en ASP.NET, es importante, ya que el runtime tomará "prestado" el thread de ejecución de la aplicación. De eso platicamos luego, en otra entrada...

Por default, los workflows son iniciados de manera asíncrona por el runtime, así que tendrás que tomar medidas para asegurar que la aplicación host no termine antes de que tu workflow. Esto se hace con algunas de las clases de System.Threading, como en el siguiente ejemplo:

using System.Threading;
using System.Workflow.Runtime;
using System.Workflow.Runtime.Hosting;
 
namespace WorkflowApplication
{
  class Program
  {
    static void Main(string[] args)
    {
      // crear el runtime
      using (WorkflowRuntime runtime = new WorkflowRuntime())
      {
        AutoResetEvent waitHandle = new AutoResetEvent(false);
 
        // estos son eventos del runtime a los cuales nos podemos 
        // "suscribir". en este caso se utilizan para señalar 
        // cuando el workflow terminó de ejecutarse
        runtime.WorkflowCompleted +=
          delegate(object sender, WorkflowCompletedEventArgs e)
          {
            waitHandle.Set();
          };
 
        runtime.WorkflowTerminated +=
          delegate(object sender, WorkflowTerminatedEventArgs e)
          {
            Console.WriteLine(e.Exception.Message);
            waitHandle.Set();
          };
 
        // instanciar y arrancar el workflow
        WorkflowInstance instance =
          runtime.CreateWorkflow(typeof(MyWorkflow));
        instance.Start();
 
        // el thread se queda esperando hasta que reciba una señal
        // debido a algún Set()
        waitHandle.WaitOne();
      }
    }
  }
}

Un mapa a Windows Workflow Foundation

Ayer me tocó hablar de Windows Workflow Foundation en la reunión de la Comunidad .NET de Juárez, y alguien me hizo la pregunta: “si quiero comenzar a jugar con Windows Workflow Foundation, ¿por dónde comienzo?”

Mi respuesta fue: sepalaching… digo, ejem… pues por el principio.

Lo que recomiendo es lo siguiente:
  1. Conocer los conceptos fundamentales de Workflow Foundation
  2. Bajar e instalar los componentes (beta) en algún ambiente de prueba donde puedan jugar.
  3. Jugar un rato con ellos

Conceptos fundamentales de Windows Workflow Foundation

Para ahorrarme las más de 1000 palabras, aquí les va una imagen (den clic para ampliar):


Un buen punto de inicio, creo que es la ayuda que viene cuando instalan los componentes. También está disponible en línea aquí.

Otro sitio útil es windowsworkflow.net.

Incluso hay un libro anaranjado por ahí que sacaron con el Beta 1 de WinFX/WF, pero le eché una ojeada en el Barnes&Noble local y sinceramente no me ayudó. Aparte que entre Beta y Beta, las cosas pueden cambiar bastante. Pero, si ustedes tienen $30 dlls que les sobren, pues puede ayudarles.


Bajar e instalar los componentes


Actualmente tienen 2 opciones: El Beta 2 de los componentes o el Beta 2.2

Si únicamente quieren desarrollar con Workflow Foundation, recomiendo usen la versión Beta 2.2, para ello solo necesitan los Componentes Runtime y Extensiones de Worflow Foundation Beta 2.2 para Visual Studio 2005. Esta es una descarga como de unos 70Mb solamente.

Ahora, que si quieren desarrollar con otras cosas de WinFX aparte de Workflow (como Windows Communication Foundation, Windows Presentation Foundation u Office 12 Beta 1 Technical Refresh), entonces necesitarán forzosamente conseguir los componentes de la Beta 2:

Runtime de WinFX, February CTP (para correr ejecutar sus componentes)
+ WindowsSDK correspondiente (para desarrollar)
+ Extensiones de Windows Workflow Beta2 para Visual Studio 2005 (para diseñar/desarrollar workflows)

Esta descarga es de arriba de 1Gb (!)

Ahora, recuerden que estos componentes están en Beta, lo cual—como ya deben saber—significa que no se recomienda instalarlos en una máquina en la que dependan, o un ambiente de producción. Lo que hice yo fue poner una Virtual PC con Visual Studio 2005 y ahí le ataqué los componentes.


Jugar un rato con Workflow Foundation

Soy de los que cree que toda la teoría del mundo no sirve de nada sin la práctica y viceversa—hay que usar los 2 hemisferios cerebrales.

Así que mientras pienso en algunos ejemplos qué poner en línea, pueden comenzar a practicar con los Hands-On Labs para Windows Workflow Foundation Beta 2, que contienen 10 “laboratorios” o prácticas. Estos labs contienen instrucciones paso a paso para que hagan sus primeros pininos con WF.

Enjoy.

Seleccionando herramientas para workflow

Si ya vieron la importancia del workflow, quizá se estén preguntando “¿Qué herramientas hay disponibles? ¿Por dónde debo comenzar?”

A ver si le puedo dar un llegue a estas preguntas.

El concepto de workflow en los sistemas ciertamente no es nuevo, de hecho probablemente se remonta a la era de las herramientas CASE. A través de los años me tocó personalmente manejar algunas herramientas en esta área—que ciertamente no eran las únicas:

Lotus Notes/Domino
Mis primeros pininos con workflow, hace como 8 años, fueron con Lotus Notes. Las herramientas de Lotus funcionan bajo un modelo de “base de datos” que en realidad eran “bases de documentos”. En otras palabras ustedes modelan algo que se maneja en papel—por ejemplo una requisición de compra, o una petición para vacaciones—como una forma y se generan instancias de esa forma que se almacenan en la base. Esos “documentos” se podían enrutar via e-mail o poner en el Inbox de Fulano de Tal hasta que lo apruebe, y cuando lo hace se envían al siguiente mono involucrado en el proceso, etc. Es decir, tenía un enfoque muy humano.

Dentro de las bondades del Notes está que es muy sencillo desarrollar una aplicación de este tipo, es parte del ambiente y se puede utilizar en el Web tanto como un cliente Notes casi indistintamente. Sin embargo, no todos los flujos son humanos—p.ej. un proceso “batch” que corre cada noche para procesar algo. Además carecía de herramientas gráficas, lo cual forzaba a que todo el flujo se codificara de manera imperativa—con If/Then’s y eventos.

BizTalk
Este es un producto server de Microsoft que tiene ya un buen rato y es excelente para la integración de sistemas o para integración entre empresas. Está muy orientado a servicios y cuenta con excelentes herramientas gráficas y de transformación—ustedes definen los mensajes y los canales donde recibirlos y luego le dan un workflow (orquestación) de manera gráfica.
Sin embargo, es algo costoso y tiene una desventaja: ¿qué pasa si quiero integrar mi workflow en una aplicación que será instalada en una PC de manera independiente? Con BizTalk, no puedo tener algo así.

Skelta, k2.net, etc.
Hay algunas otras herramientas para .NET específicamente que me tocó evaluar para un proyecto. Estas, aunque muy interesantes y completas—proveían herramientas gráficas y sus propias librerías—tenían una sola desventaja con respecto a la que voy a proponer enseguida: tienen costo de licenciamiento. De ahí en más tienen varias ventajas: algunas de ellas funcionan con .NET 1.1 y son productos un poco más maduros.

Windows Workflow Foundation
Finalmente llegamos a lo que me trae emocionado últimamente. Uno de los “pilares” de WinFX es Windows Workflow Foundation—parece trabalenguas—que espero finalmente traiga el workflow a las masas de los desarrolladores.

WinFX, para los que no han estado enterados es la nueva API de Microsoft Windows, que se planea lanzar con Windows Vista, sin embargo, las Windows Framework Extensions, también se lanzarán como un producto separado que se podrá correr en Windows XP, lo cual la hace un excelente candidato para poder distribuir una aplicación con esta funcionalidad en masa.
Así que para mi Workflow Foundation, es el mejor candidato para manejar workflow porque:
  • Permite integrar worflow a prácticamente cualquier aplicación--Windows Forms, ASP.NET, Web Services, etc.
  • Provee herramientas bastante robustas para muchos tipos de workflows: humanos y de sistema, “secuenciales” y “máquina de estados”, etc.
  • Tiene capacidad de separar por completo las reglas de negocio y aplicarlas dinámicamente a un flujo que esté activo y corriendo (sin tener que suspenderlo o reiniciarlo).
  • Tiene visibilidad de manera gráfica de en qué paso va el workflow. También puedes reutilizar en tu propia aplicación, muchos de los GUIs que se utilizan a la hora de diseñar el flujo.
  • Las PCs nuevas que traigan Vista, o las que tengan XP podrán utilizarlo—si tienen instalado el .NET Framework 2.0 y el Runtime de WinFX
  • No tiene costo de licenciamiento (hasta donde sé)
  • Será el motor de workflow en la versión próxima de Microsoft Office (“12”) y de BizTalk. Y por ahí escuché también que será la base de cualquier producto “3rd party”—como Skelta y k2.net.

En la siguiente entrada les comentaré qué necesitan para comenzar a jugar…
Posted from El otro lado del Kamikaze | 0 Comments
Filed under: