Lo primero, vamos a iniciar el proyecto…

Elegimos Process Project y procedemos a darle un nombre

Nos pide configurar el JBoss jBPM Runtime… asi que buscamos el directorio donde nos hayamos instalado

el jBPM, sigo a partir del tutorial donde explico la instalacion del jBPM 3.3.0GA.

El nombre se lo poneis vosotros… que sea un nombre característico, porque ireis actualizando las librerias con nuevas versiones que si no vais con un poco de cuidado se lia bastante la cosa.

A continuación elegis el Core jBPM al que le habeis dado nombre en el paso anterior y seleccionais el cuadro para que te genere el simple process definition, action handler y JUnit test. Generalmente es más fácil empezar con esto aunque para el ejemplo básico voy a crear el proyecto totalmente vacio.

Le dais a finalizar y ya teneis la estructura necesaria para empezar.

He encontrado también un video bastante majo para empezar, aunque es de una versión más antigua, os puede ayudar bastante. Aprovecha toda la estructura visual de eclipse… se configura todo por menus y tal… el mio será totalmente por código.

Demo jBPM

Si que bueno.. comentaré algunas cosillas para que podais trastear con el WF.

Como ya dije, está dentro del .NET Framework 3.0, así que si programais con el Visual Studio 2005, os tendreis que actualizar un poco. Si teneis el 2008, pues creo que ya te viene con el 3.5 por defecto, asi que podreis trabajar sin problemas.

Os podeis bajar el nuevo framework (ahora van por el 3.5) en la página de microsoft : netfx3.com

Lo que si haré proximamente será explicar como se hace el hosting WF en nuestras aplicaciones y construiré un “Workflow Runtime Factory”

Un Workflow define acciones, ya estén hechas por seres humanos como por sistemas informáticos, y transiciones entre estas para definir el flujo que un proceso sigue.

Un Workflow puede ser visto como un autómata finito en el que los nodos representan las acciones y las arcos representan las transiciones. Sin embargo, los Workflows son capaces de representar patrones cuya complejidad no es representable en autómatas finitos.

Patrones tales como paralelización y sincronización de procesos no son directamente representables en este tipo de marcos teóricos. Los Workflows, tradicionalmente, vienen siendo utilizados para el modelado de procesos de negocios y a su coordinación. Sin embargo, nuevas aplicaciones pueden aprovecharse de estas técnicas; como por ejemplo, sistemas formales de guiado del cuidado del paciente, como pueden ser las vías clínicas, o sistemas de guiado del tráfico vehicular en las grandes ciudades.

Un Workflow no sólo está pensado para representar flujos de procesos, sino que también es posible interpretarlos para permitir el guiado automático de los procesos para que tanto personal humano como los sistemas informáticos, estén coordinados en la ejecución de los flujos de los procesos. Se conoce como Sistema de Gestión de Workflow (o Motor de Workflow) a los sistemas ideados para interpretar y automatizar Workflows. La automatización de un Workflow consiste en la interpretación de un Workflow para ejecutar sus acciones de forma ordenada tal y como vienen especificadas en este. La mayoría de los modelos comerciales de representación de procesos de negocio que se encuentran en el mercado cuentan con herramientas de ejecución de estos Workflows que permiten cierta interoperabilidad para facilitar la integración de los modelos de Workflow con los sistemas ya existentes.

Especificar un Workflow es equivalente a implementar un programa en un alto nivel, utilizando para ello librerías y lenguajes de especificación complejos que permiten no solo la automatización del proceso, sino también la posibilidad de saber en que punto del proceso estamos, e incluso cambiar el flujo de ejecución de una instancia del Workflow dinamicamente.

Actualmente existen multitud de sistemas de interpretación de Workflows disponibles tanto comerciales como de código libre. Normalmente los motores de Workflow van ligados a los lenguajes de representación, aunque existen excepciones como BPEL que es un estandar de representación sin motor oficial asociado. Comercialmente el estándar BPEL o BPEL4WS es el que actualmente está teniendo más auge debido a que está indicado para la ejecución de orquestación de Web Services para la creación de aplicaciones B2B (Bussiness to Business). Por otro lado, comercialmente existen marcos de programación para la creación e interpretación de Workflows como la Windows Workflow Foundations desarrollado por Microsoft y el jBPM desarrollado por Sun. Sin embargo, la expresividad de estos modelos se ve limitada, ya que estos modelos no cumplen muchos de los patrones de Van der Aalst, que son una importante herramienta de validación de lenguajes de especificación de Workflows.

Además, todos estos modelos suelen resultar muy pesados y requieren potentes ordenadores para funcionar. Como proyecto Open Source, YAWL es un lenguaje definido y diseñado específicamente para cumplir los patrones de Workflow de Aalst basado en Redes de Petri. Sin Embargo, uno de los problemas de implementación de YAWL son algunas limitaciones que ha sido necesario realizar en el modelo de interpretación para la implementación de Workflows.

Según los autores de YAWL ha sido necesario limitar la implementación del lenguaje en algunos aspectos, ya que la ejecución de Redes de Petri de alto nivel es complicada debido su complejidad. Además, a pesar de ser un modelo altamente expresivo, su mayor desventaja es que su definición gráfica está basada en Redes de Petri que tienen menos legibilidad, por lo que este modelo está teniendo un uso muy minoritario. Por otro lado, otra de las desventajas de los sistemas actuales de ejecución de Workflows es que no generan logs suficientemente potentes para ser utilizados por el Workflow Mining basado en Actividades, por lo que limitan la posibilidad de inferencia de Workflows utilizando estas técnicas inductivas.

]]> http://www.workflowsworld.com/2008/05/introduccion/feed/ 0