Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Transcripción

1 Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11

2 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow open source. En este documento se presentan los puntos más importantes considerados en la presentación de JBoss jbpm realizada por su fundador el 23 de junio de Qué es lo que le falta a Java? Luego de todo el problema para hacer que Java sea rápido, vamos a introducir estados de espera, esta es la principal dificultad que vamos a tratar. Lo que se quiere mostrar en la presentación es que no se necesita magia para realizar todo ese trabajo. Figura 1 Como puede verse en la figura 1, se tienen diferentes dominios, el dominio de workflow con sus requerimientos específicos, el dominio de BPM con sus requerimientos específicos, y finalmente los requerimientos de orquestación. Hay soluciones en cada dominio. Algo que se ha descubierto es que en muchos de estos dominios, no solo estos 3 porque en realidad hay mas, todas las soluciones son parecidas pero son muy diferentes, no tienen un modelo en común. Esto es lo que se presentará a continuación, el hecho de que se pudo encontrar un modelo en común que por un lado es bastante chico y simple de entender y por el otro lado puede ser extendido en cada uno de los dominios funcionales mencionados anteriormente. Workflow, BPM y Java Página 2 de 11

3 Figura 2 Se tiene un sistema A y un sistema B y se quiere suspender la ejecución del sistema A mientras espera por la ejecución de ciertas instrucciones de B. Hay que ver cuales son las limitaciones de Java para este tipo de tareas. Es posible hacerlo pero lleva mucho costo, esto muestra el problema que vamos a tratar. Una forma de resolver esto es la siguiente: sendmessagetosystemb(); Response response = waitforresponsefromb(): El problema es que esto no es persistente porque si el thread de Java esta esperando el waitforresponsefromb y se apaga el servidor, el problema es que se pierde el thread y no se sabe donde se está en el proceso. Por lo tanto, este código java no es posible utilizarlo porque no es persistente. La solución tradicional a este problema es separar el código en requests separados y guardar algún estado en la base de datos. Otra cosa importante es la representación gráfica porque podemos pensar en soluciones para persistir los threads, soluciones orientadas al área técnica, pero el problema es que no hay una representación grafica y esto es importante. Por lo tanto las principales limitaciones de Java son que no es persistente y que no es posible definir una representación grafica. Ahora vamos a hablar de la representación gráfica y de por que es importante. Entre los analistas del negocio y los técnicos desarrolladores debería haber un lenguaje en común con el que puedan comunicarse. Los analistas no están aptos para escribir software porque eso requiere saber muchos detalles técnicos. Estos dibujan una representación grafica de los procesos del negocio con los que están trabajando, pero estas imágenes contienen estados de espera y esta es una de las limitaciones de java por lo que es difícil transformar esos estados de espera en software. Lo que vamos a intentar hacer es crear una solución técnica a los estados de espera y esto creara un lenguaje en común entre los analistas del negocio y los técnicos desarrolladores. Workflow, BPM y Java Página 3 de 11

4 Los analistas no crean software, estos crean un modelo inicial de los requerimientos con su representación grafica, luego los desarrolladores agregan algunos detalles técnicos. Los analistas solo miran la vista proyectada lo que significa que solo miran la parte gráfica del proceso y no los detalles que se esconden detrás. 3. Enfoque tradicional Hoy en día el mercado de workflow y sistemas BPM está muy fragmentado y no se pueden encontrar sistemas con fundamentos en común por lo que es difícil mirarlos y compararlos. Todos estos sistemas de workflow y BPM definen un conjunto de construcciones de workflow, estos son todos los elementos que se pueden dibujar en la representación gráfica, hay un conjunto fijo de construcciones. Todas estas construcciones están hardcodeadas o fuertemente ligadas al comportamiento en tiempo de ejecución o a una implementación. Cuando se dibuja algo en la pantalla se especifica el comportamiento en tiempo de ejecución o implementación. El conjunto de construcciones para definir el workflow, tipos de nodos, etc. es lo que comúnmente se llama el lenguaje del proceso. La runtime engine esta completamente escondida en el enfoque tradicional, todos estos tipos de nodos son ejecutados en el ambiente de desarrollo y no se tiene acceso a ellos, están como escondidos bajo las cortinas de la runtime engine. Este enfoque tradicional también tiene problemas tradicionales. Los sistemas tienden a ser monolíticos por lo que hace difícil integrarlos con el software java. Otro problema es que el lenguaje de proceso nunca es lo suficientemente poderoso. Existe cierta investigación sobre soluciones y especificaciones todas basadas en un conjunto fijo de tipos de nodos y se muestra que el lenguaje de proceso de ninguna de estas propuestas es lo suficientemente poderoso para construir un modelo. Otro problema es que no hay libertad para modelar, en un sistema tradicional se dibuja en la pantalla e inmediatamente se conecta a una implementación. La idea de los analistas es dibujar los nodos vacíos y posponer los detalles técnicos de la implementación para después, esto en el enfoque tradicional no es posible y se transforma en programación visual. 4. Programación orientada a grafos. Se comienza el modelo definiendo un grafo dirigido compuesto por nodos y transiciones. Workflow, BPM y Java Página 4 de 11

5 Figura 3 Podemos modelar esto de la siguiente forma: Figura 4 El siguiente paso es definir un modelo de ejecución. Un token es una ruta de ejecución en un sistema en particular. Cuando se ejecuta codigo Java, un token corresponde a un thread pero la diferencia es que cuando un sistema A envía un mensaje a un sistema B y está esperando entonces el token sigue ahí, el token sigue representando esta ejecución porque desde el sistema B se espera un mensaje en la misma ejecución en la cual luego se quieren hacer mas cálculos. Un token es la base para un modelo de ejecución de un grafo. Figura 5 En la figura anterior se puede ver el grafo que especifica el proceso del negocio y se puede ver un árbol de tokens. Un token representa una parte de la ejecución, pero un proceso del negocio puede tener muchas partes de ejecución concurrentes y para modelar eso tenemos una relación padre-hijo entre los tokens. Tenemos un token principal creado al inicio de la ejecución y luego hay un fork por lo que tenemos dos tokens los cuales son hijos del token principal y pueden progresar independientemente. Estos tokens pueden ser representados al igual que antes en cualquier formato. Workflow, BPM y Java Página 5 de 11

6 A continuación se muestra la relación entre los tokens y la relación entre un token y un nodo del grafo. Figura 6 El siguiente paso definiendo el modelo de ejecución es definir las señales. Una señal es el disparador que reanuda el proceso de ejecución. El sistema A esta ejecutando codigo java, envía un mensaje al sistema B y el token va a apuntar a un nodo en el grafo el cual es un estado de espera y luego se necesita un mecanismo para reanudar la ejecución de este token, esto es la señal. Ahora vamos a ver de qué se trata todo esto de las señales y creación de una instancia de proceso, a continuación se pueden ver dos fragmentos de código: ProcessInstance pi = new ProcessInstance(pd); Token token = pi.getroottoken(); token.signal(); //put process instance and token //in the persistent store web app MDB //fetch the token from //the persistent store Token token =...; token.signal(); La primer parte podría estar dentro de una aplicación web y la otra dentro de un MDB (Message Driven Bean). En la primer parte, se crea una nueva instancia de proceso para determinada definición de proceso. Luego, se toma el token principal de la instancia de proceso y se le da una señal porque luego de creada la instancia de proceso el token raíz apunta al estado inicial del proceso. Esta señal va a hacer que el token que apunta al primer estado deje ese estado a través de una transición y el proceso se va a ejecutar hasta que entre en algún estado de espera. Entonces la ejecución del proceso está en algún estado apuntando a algún nodo del proceso grabado en Workflow, BPM y Java Página 6 de 11

7 persistencia. Luego MDB puede traer el token de la persistencia y reanudar la ejecución del mismo con la señal. El algoritmo de ejecución es básicamente una variante de la cadena de responsabilidades. Veamos que pasa internamente cuando un proceso se está ejecutando. Figura 7 Dada una instancia de proceso en un estado dado, hay un token apuntando a un nodo en el grafo. En ese momento, se puede enviar una señal al token y eso va a tener un efecto que va a hacer que se ejecute el método leave(token,transition) del nodo, donde el token se pasa a si mismo como parámetro y se ejecuta la operación take de la transición que también se pasa como parámetro. El método take de la transición se va a fijar en el nodo destino y va a ejecutar el método excecute de dicho nodo pasándole el mismo token como parámetro. Puede verse que el token es pasado desde un nodo hasta el otro nodo por medio de la transición. En el método excecute del nodo destino, dos cosas pueden pasar, primero que nada, cada nodo puede implementar un comportamiento especifico y esa es la primer responsabilidad que tiene el método excecute, denominada responsabilidad funcional. Además, el método excecute también es responsable de la propagación de la ejecución del proceso, esto significa que podría invocar un método leave para hacer una transición o podría no hacer nada en caso de que tenga que quedarse esperando. Otra opción sería crear nuevos tokens concurrentes y lanzarlos a través de transiciones diferentes. Para cada tipo de nodo se puede tener una subclase de la clase Nodo y se sobrecarga el método excecute para reflejar los diferentes comportamientos que pueden tener los nodos. Este algoritmo esta alineado con transacciones y sincronización. Por cada pedido que llega al servidor, se tiene una transacción y típicamente todos los cálculos que se hacen pertenecen a una transacción. En cualquier momento se puede agregar comunicación asíncrona, cuando esto se hace es más fácil combinar todo esto. Los analistas del negocio dibujan el grafo y los técnicos desarrolladores pueden agregar detalles técnicos como ser transacciones y sincronización o comportamiento. Workflow, BPM y Java Página 7 de 11

8 Una característica importante es que no hay reinvención, esto significa que pueden hacerse subclases de Nodo e implementar el método excecute. En el código dentro de un Nodo se puede utilizar cualquier API de Java, por ejemplo JMS para comunicación asíncrona. Tenemos que ser capaces de definir más detalles técnicos y esto se hace agregando acciones. Antes de definir lo que son las acciones es necesario definir que son los eventos. Los eventos también se pueden especificar en el grafo, por ejemplo, tomar una transición, entrar a un nodo, dejar un nodo. Figura 8 Los eventos se consideran instantáneos, son disparados y eso es todo, se ejecutan, sin espera. Algo importante sobre las acciones es que están escondidas de la representación visual del proceso y esto es bueno para que los desarrolladores puedan agregar detalles técnicos sin tener que modificar el grafo dibujado por los analistas. Cualquier cosa se puede modelar como un nodo si es interesante para los analistas, pero si no lo es se puede modelar luego como una acción. En la figura 8 pueden verse los eventos como cuadrados y las acciones como rectángulos rojos incluidos en estos. En cada evento se tienen una lista de acciones. Al inicio se tiene un token el cual apunta al primer nodo del grafo, luego se envía una señal y el token comienza a viajar por la transición hacia el siguiente nodo y cuando esto pasa las acciones que se encuentran en el evento de la transición son ejecutadas una por una, luego el token se mueve hacia el evento de entrada al siguiente nodo y se ejecutan las acciones del evento y luego el token se posiciona en el nodo. Ahora vamos a ver la programación orientada a grafos desde otra perspectiva. La programación orientada a grafos provee razones para estructurar el software mediante un grafo. Esto es importante porque existen muchas técnicas para desarrollar software que son solo técnicas para estructurar. La primer técnica creada hace mucho tiempo atrás fue la de programación abstracta la cual permite crear mucha abstracción en el código separando los métodos de las definiciones de Workflow, BPM y Java Página 8 de 11

9 operaciones, esto en realidad es una forma de estructurar para hacer que el código sea mas mantenible y más fácil de desarrollar. Lo mismo con la programación orientada a objetos la cual fue el siguiente paso, y lo mismo con programación orientada a aspectos la cual fue el siguiente paso y también es una forma de estructurar el software. Volviendo ahora al algoritmo de ejecución visto antes, básicamente esto también es una forma de estructurar el software y en este caso es estructurarlo alrededor de un grafo. Sabemos que el costo de realizar un proyecto de software está exponencialmente relacionado al tamaño del proyecto por lo que si podemos bajar la complejidad va a haber un impacto en el costo. 5. Conclusiones Una simple API y la cadena de responsabilidades reemplazan los sistemas monolíticos. No se necesita más un sistema monolítico, es mucho más fácil integrar esto con código Java existente. Herencia de Nodo. Podemos crear nuevos tipos de nodos creando subclases de la clase Nodo y sobrecargando el método excecute. Agregado de acciones invisibles. Le da libertad al modelado, los analistas pueden modelar lo que quieren y no es necesario que modifiquen el grafo para agregar alguna cuestión técnica que no les preocupa. Los analistas pueden concentrarse en las cosas que son importantes para ellos sabiendo que los técnicos son los que van a hacer que sea ejecutable agregando detalles técnicos. Ciclo del proceso de desarrollo, o proceso de desarrollo iterativo donde los analistas del negocio crean un modelo inicial, los técnicos refinan el modelo, éste vuelve a los analistas y se crea un círculo. Reemplaza la programación visual la cual existe en las soluciones tradicionales. A continuación se muestra una estructura de bloques donde puede verse cual es la posición de la programación orientada a grafos relacionada a Java y el área funcional. Workflow, BPM y Java Página 9 de 11

10 Figura 9 Esto esta relacionado a la figura 1 donde pueden verse los 3 dominios. Posicionamos la programación orientada a grafos inmediatamente arriba de Java. En este modelo se pueden agregar características para el manejo de tareas (task management features) directamente relacionadas al workflow y agregar una interfaz de usuario arriba de las tareas de manejo mencionadas. En otro dominio funcional se pueden agregar características para la invocación asíncrona, se pueden agregan diferentes mecanismo de transporte como los web services. Lo que se hace es extender la programación orientada a grafos para agregar características de orquestación. Lo mismo para BPM, también se puede extender la programación orientada a grafos construyendo bloques arriba de ella. jbpm está construido utilizando este paradigma por lo que si se lo quiere extender utilizando algún área funcional esto se puede hacer construyendo bloques arriba como se mencionó anteriormente. 6. Resumen Java tiene un soporte limitado para estados de espera. La programación orientada a grafos extiende Java con la habilidad de suspender y reanudar ejecuciones. La programación orientada a grafos sigue el paradigma de bloques. Se pueden agregar más componentes funcionales arriba de la programación orientada a grafos en cualquier dirección, en el dominio de workflow, BPM u orquestación. JBoss jbpm es un proyecto que implementa esta tecnología, puede ser utilizado en cualquier ambiente Java ya que proporciona un API. Workflow, BPM y Java Página 10 de 11

11 Se puede comenzar muy simple agregando esta librería Java al classpath, escribiendo una simple aplicación web pero es importante saber que si se necesita después se puede escalar a un nivel empresarial. La idea de la programación orientada a grafos es brindar la comodidad de que un grupo de analistas estudien un problema y busquen la solución mediante la generación de un grafo que modele el proceso de la realidad planteada, y a partir de este grafo los programadores implementen las acciones a realizar en cada nodo del grafo, así como también en las transiciones y en las distintas acciones que pueden ocurrir. Esto implica que la definición del grafo generado por los analistas es estática, pero permite que si en un momento dado el problema cambia, los analistas modifican el grafo para representar estos cambios y a su vez los programadores tienen que modificar la implementación necesaria para que los cambios en el grafo tengan efecto. 7. Referencias - integration Pagina de cursos on-line donde se encuentra la presentación de Tom Baeyens. Pagina principal de jbpm. Pagina principal de Jboss. Foros de jbpm. Workflow, BPM y Java Página 11 de 11