Windows WorkFlow Foundation – Part II

Runtime Hosting

Todos los workflows dependen del Windows Workflow Foundation Runtime Engine. Este motor ejecuta cada workflow y maneja su estado a lo largo de su tiempo de vida. El Windows Workflow Foundation Runtime es una librería; por lo tanto, debe ser ejecutado en algún proceso host. En vez de proveer un host requerido, Windows Workflow Foundation le permite al runtime (y a cualquier workflow que ejecute) ser alojado en cualquier proceso Windows, desde una simple aplicación de consola de Windows o una aplicación de formulario, hasta un servidor complejo diseñado teniendo en cuenta el ambiente de workflow.

Windows Workflow Foundation cuenta con un conjunto de servicios que le permiten al runtime ejecutarse dentro de ASP.NET, aunque los vendedores independientes de software y los usuarios finales son libres de crear sus propias aplicaciones contenedoras de workflows para aplicaciones existentes.

Los diferentes hosts tendrán distintas características. Por ejemplo, un workflow que se ejecuta en un escritorio en una simple aplicación de Windows Forms, será menos escalable y menos confiable que un workflow hosteado en Windows SharePoint Services (WSS) o BizTalk Server.

A pesar de que cada host usa el mismo Runtime Engine, cada uno debe proveer un conjunto de servicios runtime. Estos servicios brindan soporte para persistir el estado de un workflow, rastrear su ejecución, usar transacciones, etc.  

Windows Workflow Foundation provee una implementación predeterminada para todos estos servicios que pueden ser usados por cualquier host. Para darse una idea de cómo trabaja el runtime de Windows Workflow Foundation con los servicios proporcionados por el host, se debe pensar en los aspectos fundamentales de un workflow.

Un workflow puede ser de larga duración, ya que podría ejecutarse durante horas, días o semanas, y el runtime de Windows Workflow Foundation podría apagarse durante un workflow, y persistentemente almacenaría su estado si hubiera estado inactivo por un período de tiempo.

La decisión de descargar el workflow se puede lanzar porque éste se encuentra bloqueado esperando un evento externo; esta decisión es tomada típicamente por el runtime. Para escribir estados del workflow en el disco, el runtime depende del servicio de persistencia proporcionado por su proceso host.

El host basado en ASP.NET que contiene Windows Workflow Foundation depende de Microsoft SQL Server para la persistencia. Otro host podría preferir persistir workflows usando otra tecnología, como, por ejemplo, una base de datos propietaria utilizada por una aplicación de un vendedor de software independiente.

Cualesquiera que sean los servicios que proporciona el host, las bases de hosting del Windows Workflow Foundation Runtime son muy simples. Una vez que una instancia es creada, puede ser inicializada llamando a su método StartRuntime. El proceso host es una parte importante del ambiente en el que se ejecuta un workflow, ya que el runtime puede ser contenido en un rango de procesos de Windows. Asimismo, los workflows de Windows Workflow Foundation pueden ser usados en una variedad de escenarios.

Workflow Runtime Events

Los eventos workflow son procesados por el Workflow Runtime a través de los delegados de manejo de eventos. Estos eventos son generados/levantados por el Workflow Runtime y no por el Workflow Instance. Asimismo, tampoco son modelados como parte de la definición de workflow.

El Workflow Runtime levanta eventos en tiempo de ejecución para instancias workflow.

Los eventos mandados por el Workflow Runtime contienen un objeto de tipo WorkflowId, que corresponde al workflow que generó el evento.

Provee un mecanismo para mantener el paso del ciclo de vida de las instancias de workflow:

WorkflowCreated, WorkflowCompleted, etc

Provee un mecanismo para seguir todas las instancias de workflow, ya que los workflows pueden ser:

Ø  Creados

Ø  Abortados

Ø  Terminados

Ø  Etc.

La clase WorkflowRuntime expone la funcionalidad requerida por una aplicación host, y servicios para configurar y controlar el runtime.

public class WorkflowRuntime : IServiceProvider, IDisposable

El namespace System.Workflow.Runtime contiene clases e interfaces que se pueden usar para controlar el runtime de workflow y la ejecución de una instancia workflow.

El namespace System.Workflow.Runtime contiene la clase WorkflowRuntime, que usted puede usar para configurar, controlar y suscribir a eventos para el runtime de workflow asociado con su dominio de aplicación. La clase WorkflowInstance provee un proxy para cada instancia workflow y le deja controlar la ejecución de un workflow. Además de estas clases, varias clases que tienen que ver con las colas de eventos workflow y con excepciones lanzadas por el runtime de workflow son contenidas en este namespace

CorrelationProperty: representa el nombre de la propiedad y el valor usado en un conjunto de correlación que maneje el tiempo de vida de la transacción entre un mensaje y un workflow.

CorrelationToken: maneja las suscripciones de la CorrelationProperty a las actividades del dueño. Esta clase no puede ser heredada.

Runtime Services

Windows Workflow Foundation provee distintos servicios que se pueden usar para manejar hilos de instancias workflow, trabajos batch a través de transacciones, persistencia de instancias workflow a un medio de almacenamiento para ser recuperadas más tarde, y el rastreo de ejecuciones de instancias workflow.

El runtime de workflow usa muchos servicios cuando una instancia de workflow se ejecuta. Estos componentes del servicio son “enchufables”, lo que les permite a las aplicaciones proveer servicios de maneras que son únicas a su ambiente de ejecución.

Windows Workflow Foundation provee implementaciones predeterminadas de los servicios del runtime que cumplen las necesidades de varios tipos de aplicaciones. Por ejemplo, estos componentes determinan el modelo de programación que es usado para correr instancias workflow, cómo se comunican el workflow y la aplicación host, cómo monitorear y rastrear su workflow, y demás.

Windows Workflow Scheduling Services

Los servicios Windows Workflow Scheduling controlan el modo en que las instancias workflow son programadas por el runtime de workflow, ya sean manejadas de una manera asincrónica a través del DefaultWorkflowSchedulerService, o manual, de manera sincrónica, a través del ManualWorkflowSchedulerService.

wwf_SchedulingServices

DefaultWorkflowSchedulerService es usado por el runtime de workflow por default. Crea y maneja los hilos que ejecutan las instancias workflow de una manera asincrónica en el runtime del workflow. Los workflows que están esperando para ejecutarse son almacenados en la cola interna del DefaultWorkflowSchedulerService. Cuando el DefaultWorkflowSchedulerService quiere empezar un workflow, un hilo es adquirido del thread pool del framework de .NET y es usado para correr el workflow. La propiedad MaxSimultaneousWorkflows determina qué cantidad de hilos simultáneos permitirá el servicio scheduler en un tiempo. Si el límite es cuatro, por ejemplo, el DefaultWorkflowSchedulerService adquirirá hasta cuatro hilos del thread pool del framework de .NET para ejecutar los workflows. Si cuatro workflows se están ejecutando actualmente, ítems adicionales de trabajo (workflows) son colocados en la cola y eventualmente ejecutados a medida que los hilos se van habilitando.

ManualWorkflowSchedulerService controla el número de hilos que aparecen en un proceso ASP.NET reutilizando el hilo que hizo la petición ASP.NET Web para correr la instancia workflow. Esto asegura que en cualquier momento, el número de hilos activos en el runtime de workflow iguale el número de peticiones Web activas en el proceso activo de ASP.NET.

ManualWorkflowSchedulerService no ejecuta automáticamente una instancia workflow que esté en la cola. El host debe invocar al RunWorkflow para ejecutar un workflow específico.

El ManualWorkflowSchedulerService provee un servicio de threading que le permite a la aplicación host que crea una instancia workflow donar el thread en el cual la instancia workflow es ejecutada. Usando este servicio de threading, las aplicaciones host pueden correr una instancia workflow en un simple thread (eso es, en modo sincrónico).

Windows Workflow CommitWorkBatch Services

El propósito de los servicios CommitWorkBatch es permitir una lógica personalizada a pesar de la comisión de batches de trabajo (también conocida como puntos persistentes). Cuando un trabajo batch es cumplido, el runtime llama al servicio CommitWorkBatch y pasa un delegado para que llame a hacer el cumplimiento del batch de trabajo. Igualmente, el runtime debe hacer el finalizado, pero permitiéndole a un servicio insertarse a sí mismo dentro de un proceso, lo que permite una personalización alrededor del proceso de finalización.

Existen dos tipos de CommitWorkBatch Services:

Ø  DefaultWorkflowCommitWorkBatch Service

Ø  SharedConnectionWorkflowBatch Service

DefaultWorkflowCommitWorkBatch Service

La razón principal de este tipo de servicios es permitir una lógica de manejo de errores personalizada. Si el servicio DefaultWorkflowCommitWorkBatchService posee la transacción, porque creó una, cuando Current retorna null (Nothing en Visual Basic), puede llamar al delegado más de una vez, creando una nueva transacción para cada llamada. El ejemplo más común de esto es manejar problemas de red intermitentes o cluster failovers de SQL. Si la llamada al CommitWorkBatchCallback tira una excepción, WorkflowCommitWorkBatchService puede atrapar esta excepción, empezar una nueva transacción, y llamar al delegado nuevamente. Esto da un nivel de resistencia a la ejecución de instancias workflow que de otra manera causaría que los workflows se terminaran.

SharedConnectionWorkflowCommitWorkBatch Service

Cuando el motor del runtime es iniciado, la clase WorkflowRuntime crea un objeto DefaultWorkflowCommitWorkBatch Service si ningún otro servicio WorkflowCommitWorkBatch fue agregado. Se puede usar este servicio en el workflow para soportar batches de trabajo que son necesarios para la integridad de datos.

También se puede decidir utilizar el servicio SharedConnectionWorkflowCommitWorkBatchService. Este servicio es usado para transacciones de bases de datos que utilizan una conexión compartida entre objetos diferentes.

static void Main(string[] args)

{

    string connectionString = " Initial Catalog=WorkflowDataStore;Data          Source=localhost;Integrated Security=SSPI;";

    WorkflowRuntime workflowRuntime = new WorkflowRuntime();

    workflowRuntime.AddService(new SharedConnectionWorkflowCommitWorkBatchService(connectionString));

    workflowRuntime.StartRuntime();

   // … workflowRuntime.StopRuntime();

}

Para utilizar el servicio SharedConnectionWorkflowCommitWorkBatchService en vez del servicio DefaultWorkflowCommitWorkBatchService en la instancia WorkflowRuntime, se puede usar el método AddService, como se muestra en el ejemplo. El parámetro para el constructor SharedConnectionWorkflowCommitWorkBatchService es el string de conexión a la base de datos.

<?xml version="1.0" encoding="utf-8" ?>

<configuration>

  <configSections>

    <section name="WorkflowServiceContainer" type="System.Workflow.Runtime.Configuration.WorkflowRuntimeSection, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>      

  </configSections>

  <WorkflowServiceContainer Name="Container Name" UnloadOnIdle="true">

    <CommonParameters>

      <add name="ConnectionString" value="Initial Catalog=WorkFlowStore;Data Source=localhost;Integrated Security=SSPI;" />

    </CommonParameters>

    <Services>

      <add type="System.Workflow.Runtime.Hosting.DefaultWorkflowSchedulerService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <add type="System.Workflow.Runtime.Hosting.SharedConnectionWorkflowTransactionService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

      <add type="System.Workflow.Runtime.Tracking.SqlTrackingService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

      <add type="System.Workflow.Runtime.Hosting.SqlWorkflowPersistenceService, System.Workflow.Runtime, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>

    </Services>

  </WorkflowServiceContainer>

  <system.diagnostics> </system.diagnostics>

</configuration>

También se puede usar el archivo de configuración de la aplicación para crear el objeto SharedConnectionWorkflowCommitWorkBatchService. Cuando se hace eso, hay que agregar la información del string de conexión a la sección CommonParameters del archivo app.config. El ejemplo muestra un archivo de configuración de la aplicación que usa el servicio SharedConnectionWorkflowCommitWorkBatchService.

Jonnathan De La Barra Hot

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Development. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s