Lenguaje de definición de modelos de procesos
De MorfeoWiki
Tabla de contenidos
|
Introducción.
El objetivo de este documento es proponer un modelo de proceso construído en base a la cooperación entre recursos REST. El conjunto de directrices que guían las interacciones entre los recursos está implementado mediante la combinación de flujos de trabajo o «patrones».
Un mismo recurso tomará parte a lo largo de su vida en varios procesos diferentes, en los que atenderá y realizará peticiones a otros recursos. Los patrones serán los elementos coordinadores de esas interacciones. Algunos estarán directamente asociados a un recurso particular y le añadirán las capacidades necesarias para participar en un proceso determinado. Otros patrones se apoyarán en aquellos y en los recursos para coordinar una situación determinada.
Por ejemplo, un recurso «SubmitReport» (una tarea) participa en un proceso de gestión de asignación de recursos humanos, gracias a la incorporación de los patrones «Assignment» y «TaskStatus». Por otra parte, «TaskStatus» se utiliza para el control de flujo, ya que indica cuándo ha terminado la tarea. En un momento dado, el responsable de esa tarea necesita delegar en otra persona; la gestión de esa situación la llevará a cabo una instancia del patrón «Delegation» que coordinará el proceso apoyándose en el recurso «SubmitReport» (y en sus patrones) y en otros recursos presentes, como la lista de candidatos proporcionada por el recurso «Organization».
La definición de patrón se encuentra en [1]. A continuación se define el otro elemento básico del modelo: Recurso REST.
Recurso REST.
Un «recurso» es una entidad localizable mediante una URL y que ofrece en ella un conjunto de métodos HTTP. Los datos que se intercambian mediante estos métodos estarán codificados en XML en algún vocabulario específico de la aplicación. Se supone que existe una definición en un lenguaje como WADL [5] o equivalente de los recursos.
Un recurso ofrece por lo tanto un conjunto de operaciones de aplicación. Por ejemplo, «SubmitReport» tendría un método «POST {R}/report [<report/>]» que valida los datos adjuntos y responde con el resultado.
Esta definición de recurso sin embargo no facilita la incorporación a un modelo de proceso, ya que lo más probable es que carezca del comportamiento necesario. En el ejemplo, «SubmitReport» ya incluye de alguna forma el concepto de «tarea concluída», pero no está disponible de forma explícita. Como se verá a continuación, es mediante la incorporación de un patrón al recurso que se expone el comportamiento necesario para que «SubmitReport» participe en uno o varios procesos.
Incorporación a un recurso
Dado un recurso localizable en {R}, acorde con la definición propuesta, es posible incorporar un patrón a su gestión. El problema es efectuar esa incorporación y al mismo tiempo respetar los métodos que el recurso define y que sus clientes utilizan.
Algunos de estos métodos provocan cambios en el estado del recurso que se escapan del control de los patrones asociados. Por ejemplo, un recurso ofrece el método «POST {R}/time [xs:dateTime]» para cambiar uno de sus atributos. Si se desea que éste quede bajo la gestión de un patrón, hay que evitar el acceso a ese método.
La solución que se propone aquí es colocar el recurso tras una pasarela que delegue en él los métodos invocados, pero que si se desea facilite el redefinir alguno de ellos para invocar operaciones en los patrones.
El recurso original ofrece pues una interfaz en {R} que se va a suponer definida en algún lenguaje como WADL. Al solicitar la incorporación del primer patrón al recurso, se genera de forma automática un recurso pasarela en {gw(R)} con una interfaz que incluye al menos la original.
Sus métodos se limitan a delegar en {R}, de forma que los clientes no se ven afectados. La URL {gw(R)} de la pasarela será sin embargo diferente a la del recurso y habrá que estudiar las soluciones que el protocolo HTTP proporcione para redirigir a los clientes hacia la pasarela.
Algunos de los métodos se redefinen para hacer efectiva la participación del patrón. Sea un método «POST {R}/path [param]» en el recurso original. Algunos modelos de participación serían:
- Patrón «oyente» — la pasarela recibe «POST {gw(R)} [param]» tal y como haría el recurso original y delega en {R}. A continuación comprueba la respuesta y decide si debe enviar un evento al patrón. De esta forma el patrón refleja en su flujo de trabajo el estado del recurso y ofrece, mediante el registro de acciones, la posibilidad a otros recursos de reaccionar ante los cambios de estado.
- Patrón «controlador» — al recibir la petición, la pasarela se limita a enviar un evento al patrón. Será éste el que en algún momento decida invocar o no la operación en el recurso. Esta es una forma de modificar o añadir comportamiento al recurso.
Por ejemplo, un patrón «collection» puede funcionar como oyente y permitir la inserción de acciones para el lugar «new element». Un patrón más complejo también proporciona ese lugar, pero además parte de su flujo de trabajo podría incluso decidir no invocar la inserción en el recurso.
Estos modelos suponen una relación privilegiada del patrón con su recurso. El patrón es una definición genérica, que es adaptada a la aplicación mediante la inserción de acciones. Se logra así que el patrón desempeñe un «role» propio de la situación en la que se está utilizando.
También es útil relacionar un mismo patrón con varios recursos al mismo nivel.
- Patrón «orquestador» — implementa un flujo de trabajo que invoca operaciones en varios recursos para conseguir un objetivo.
- Patrón de «control de flujo» — coordina varios recursos para que tengan una relación de control de flujo.
Diseño de la pasarela para incorporaciones.
Aunque no se plantee por ahora un diseño, hay algunas cuestiones relativas a la pasarela que habrá que comprobar en su momento:
- ¿Qué requisitos en cuanto a concurrencia debe cumplir una plataforma de ejecución de patrones? Si el procesamiento de un evento es necesariamente síncrono y éste vuelve a invocar a la pasarela, podría aparecer un «deadlock».
- La idea básica del recurso pasarela es que facilite la interacción entre el recurso y los patrones incorporados. Se reduciría a ofrecer una forma sencilla de redefinir los métodos proporcionados por el recurso. El hecho de que todo el proceso se desarrolle mediante REST/XML anima a plantear una solución basada en XQuery [3][4].
- Dado un documento WADL, se generaría la pasarela de forma automática.
- El resultado es un recurso, implementado en alguna plataforma (por ejemplo un servlet), que por defecto delega todas las invocaciones en una URL dada, la del recurso original.
- Admite la inserción de código XQuery para un método determinado, que sustituye la delegación.
- Añade operaciones a la interfaz original, para la gestión de la pasarela y de los patrones del recurso.
- El recurso pasarela puede incorporar operaciones de control, como por ejemplo inhabilitar determinados métodos cuando un patrón así lo requiera para evitar cambios en el recurso.
Roles.
Un patrón se incorpora a un tipo particular de recurso para desempeñar un papel o «role». Además del patrón genérico con sus acciones estáticas, para cumplir un role es necesario especificar los métodos de la pasarela que deben ser redefinidos y quizá insertar algunas acciones dinámicas en el patrón. Un role tendrá asociado un identificador (URI) por el que se podrá solicitar a la pasarela el patrón que lo desempeña para un recurso, si existe.
Por ejemplo, se adapta el patrón «execution status» para reflejar el estado de ejecución de una tarea que está implementada en un recurso (formulario) con dos métodos: «POST path [param]» y «GET path». El patrón dispone de un estado «suspended» que en este caso no tiene sentido; sí se aprovechan los estados «created», «executing» y «finished».
- En la pasarela, se redefine «POST path [param]» para (1) delegar en el recurso y (2) comprobar la respuesta. Si es positiva, se notifica mediante un evento al patrón, para que cambie al estado «finished», y se inhabilita el método «POST path [param]» en la pasarela.
- Además, se desea que para este tipo de recurso, el disparo de la transición «finish» invoque un método «POST» en un recurso de monitorización.
El role «http://eng01.ule.es/roles/task-status» introduce la idea de estado de ejecución en un recurso e indica el estado «created», …, «finished» de éste.
Un bloque de control de flujo podría, por ejemplo, aceptar como elemento subordinado, cualquier recurso que ofrezca ese role. El propio bloque ofrecería él mismo ese role para permitir la composición.
Flujo de control.
La inserción de acciones en los patrones es suficiente para definir un flujo de control como combinación de patrones. En el caso más simple se podría suponer la existencia de lugares «finished» y de transiciones «start» en los patrones a combinar. En las acciones se tomaría la decisión de qué hacer al llegar al término de un patrón: iniciar siempre el mismo (secuencia), comprobar el estado de algún recurso e iniciar o repetir el patrón (do-while), etc.
Aunque parece factible, es una solución con algunos puntos débiles:
- Claridad — aunque el conjunto de acciones insertado implementa un control de flujo, éste no está presente de forma clara en el resultado.
- Diseño — a la hora de diseñar un flujo de trabajo, sería interesante proporcionar elementos de construcción y facilitar su manejo: Bloques «do-while», «split/join», «sequence», etc.
- Estructuración — la información de flujo de control no aparece explicitada de forma estructurada y se dificulta así su procesamiento. Esto complica el plantear al sistema consultas en términos de las relaciones de flujo: «¿Qué recursos (tareas) vienen a continuación?».
- Gestión — por otra parte, es de esperar que las definiciones de flujo de control sean reutilizables.
Bloques de diseño.
El siguiente nivel de abstracción es entonces definir los bloques de flujo de trabajo que encapsulen la inserción de las acciones necesarias para su implementación. Es posible que en algunos casos complejos no se especifiquen todas las acciones, sino que el diseñador deba insertar alguna por sí mismo. Por ejemplo, la evaluación de la condición de salida en un «do-while» debe ser proporcionada por el diseñador en cada caso.
Estos bloques pueden implementarse mediante patrones, con flujos de trabajo más o menos complejos. Por ejemplo, una secuencia tendrá transiciones «next step», «finish», «start», etc.
Especificación de diseño.
La especificación final de un diseño puede verse desde el punto de vista de la serialización. El documento de especificación debe permitir recrear el sistema en ejecución. Algunos de los elementos pueden estar ya presentes (se da su URL en la especificación) y otros deberán ser creados y sustituídas las referencias por la nueva URL.
Este enfoque podría proponer una solución a la especificación de una instancia de un patrón. Hay que recordar que éste es genérico y en el proceso de diseño es adaptado a una situación concreta. Si el resultado es una representación de instancia válida, la creación podría ser simplemente insertar el documento en una base de datos y asociarle un nuevo caso de la red de Petri con el estado inicial que se especifique en el documento.
A la hora de hacer uso de los patrones para diseñar un flujo de control, se dispondrá de una paleta de patrones. El diseñador instanciará elementos de esa y otras paletas, establecerá enlaces entre ellos, incorporará patrones y programará algunas acciones específicas de la aplicación.
- Podría empezar, por ejemplo, con un patrón «sequence» como raíz del flujo de control.
- El primer paso de la secuencia es una tarea que está implementada mediante un recurso formulario «SubmitReport». Éste debe incorporar un patrón «task-status» para que la secuencia sepa cuándo ha terminado la tarea y debe por lo tanto ejecutar el siguiente paso.
- El segundo elemento de la secuencia es un patrón «barrier» que provoca la creación de «n» instancias independientes de un mismo flujo y que termina cuando todas ellas han concluído. El número «n» podría obtenerse en ejecución del estado de algún recurso.
- El patrón «barrier», ofrece el patrón «task-status» a la secuencia y utiliza los patrones «task-status» de cada una de las instancias de flujo creadas en ejecución para sincronizar su finalización.
- El diseñador debe ahora proporcionar a «barrier» la definición de lo que debe ejecutar. Con un procedimiento similar, construye y añade un flujo de trabajo al patrón.
- Por último, añade otro recurso formulario a la secuencia raíz.
El resultado de un diseño de combinación debe ser procesable para construir instancias en el contenedor de ejecución, lo que supone:
- Crear nuevas instancias de un recurso dado.
- Crear nuevas instancias de patrones.
- Incorporar patrones a instancias de recursos.
- Insertar acciones de forma automática para realizar el flujo de control.
En la especificación aparecerán referencias a recursos que deberán ser sustituídas por las URLs de las instancias creadas.
Coordinación.
En algunos casos será más adecuado plantear una solución en términos de cooperación entre recursos, frente a una especificación cerrada del flujo de trabajo. De hecho, ambos enfoques pueden aparecer de forma simultánea.
La cooperación se puede implementar como inserción de acciones: Un recurso «R1» está interesado en hacer algo cuando otro «SubmitReport» es asignado. «R1» deberá insertar una acción en el lugar «assigned» del patrón adecuado en «SubmitReport».
Otra forma de especificar cooperación es mediante un patrón orquestador. Son situaciones en las que existe un protocolor claro que puede plasmarse en un flujo de trabajo (dentro del patrón). Por ejemplo, la delegación de un item de trabajo puede requerir ciertos pasos y decisiones tomadas con información procedente de varios recursos que participan así en ella. El control sobre la evolución del sistema es mayor en este caso que en la simple inserción de acciones, pero no parece que se pierda demasiada flexibilidad.
Interfaz de usuario.
La estructuración de la información dentro de cada recurso anima a plantear la generación automática de interfaz de usuario. En el caso de un patrón, una transformación XSL podría generar la interfaz para presentar el estado actual del flujo de trabajo y operaciones para enviar eventos. Ya que los conjuntos de información están definidos con W3C Schema, se dispone de información suficiente para ello.
Los recursos son entidades más complejas que en principio deberán proporcionar sus propios métodos de acceso. Aparece aquí el problema de integrar la interfaz de usuario de un recurso con su correspondiente pasarela, ya que es ésta la que debe en última instancia recibir la invocación de los métodos.
Diseño.
La aplicación para el diseño contendrá la siguiente funcionalidad:
- Creación de nuevos patrones.
- Paletas de patrones y recursos, para crear nuevas instancias de ambos tipos.
- Especificación de la incorporación de un patrón a un recurso.
- Programación del recurso pasarela.
- Obtención de URLs para las nuevas instancias (que serán conocidas en ejecución) y de instancias ya presentes en el sistema.
- La combinación de patrones y recursos se basa en hacer referencias a sus URLs. Algunas de esas direcciones deberán ser resueltas en el momento de crear las nuevas instancias.
Usuario.
Un usuario estará interesado en organizar, visualizar y acceder a algunos recursos determinados. La organización puede plantearse en analogía con los gestores de ficheros y hablar así de «carpetas» que contengan otras carpetas o recursos que cumplen algún criterio. La visualización y acceso serían a través de la interfaz de usuario proporcionada por cada recurso.
Por ejemplo, podría definirse una carpeta «mis tareas» con todos los recursos en cuyo patrón «Assignment» figure el usuario como responsable y en «ofrecidas» aquellos en los que el usuario aparezca en la lista de «offered-to» del patrón.
Ejemplo — asignaciones de recursos
El siguiente ejemplo está basado en el problema de asignación de recursos humanos propuesto en [2]. El objetivo es intentar modelizar el problema basándose en la combinación de patrones y recursos.
Breve descripción del problema.
Durante la ejecución de los casos de los flujos de trabajo de una organización, aparecen items de trabajo que deben ser realizados por recursos humanos. El sistema debe gestionar esa asignación y las posibles situaciones que aparezcan relacionadas con ella, como por ejemplo la delegación de un item de trabajo a otra persona o el establecimiento de políticas propias de la organización.
Recursos.
Se va a suponer la existencia de varios tipos de recursos.
- Organization — la propia organización.
- OrgResource — un recurso humano.
- Case — un caso de un flujo de trabajo.
- WorkItem — un item de trabajo. Algunos requerirán la asignación de un recurso humano.
En ejecución se van creando nuevos recursos y estableciendo relaciones entre ellos. Por ejemplo, un caso mantendrá una lista con sus items de trabajo; en el recurso Organization se dispone de una lista de los recursos humanos.
Items de trabajo
- SubmitReport — ofrece un método POST para enviar un informe en un formato XML de la aplicación, la respuesta indica la aceptación o no del informe. El método GET devuelve el estado actual del item de trabajo.
Asignación.
Cuando un item de trabajo requiere un recurso humano, adquiere un ciclo de vida que refleja esa situación. El patrón «assignment» incorpora ese ciclo de vida al recurso WorkItem, y así será posible describir que éste se encuentra en un estado «offered-single» o «allocated», obtener la lista de recursos humanos a los que se ha ofrecido el item o a quién está asignado.
La representación de la instancia de «assignment» sería entonces:
<pattern-instance …>
<workflow>
<marking><place name="assigned"/></marking>
…
</workflow>
…
<assignment assigned-to="http://devel.ule.es/rc/developers/di013">
<offered-to>
<resource link="http://devel.ule.es/rc/developers/di012"/>
…
</offered-to>
</assignment>
</pattern-instance>
En este caso, se va a suponer que el recurso WorkItem no disponía hasta este momento de esa capacidad. Tendrá su interfaz con las operaciones pertinentes a su labor, pero no ofrece métodos asociados a su asignación a un recurso humano.
El sistema debe entonces incorporar un patrón «assignment» al nuevo recurso WorkItem e iniciar su flujo de trabajo. Las acciones insertadas en el patrón disponen de los requisitos que un recurso humano debe satisfacer para poder ser asignado a la tarea, evalúan los candidatos ofrecidos por la organización y por ejemplo, ofrecen el item a algunos de ellos.
Cuando un recurso humano decide aceptar una asignación, el patrón pasa al estado «allocated» y lo refleja en su representación, donde mantiene una referencia al recurso asignado.
Representación
En las representaciones de los recursos involucrados se dispone de información estructurada sobre la evolución del problema. Parece sencillo consultar mediante un lenguaje como XQuery el estado del sistema para obtener, por ejemplo, «qué recursos están asignados a un caso» o «cuál es el recurso con más items de trabajo asignados».
Estado de un item de trabajo.
Algunos de los protocolos de asignación pueden requerir que un item de trabajo mantenga su estado de ejecución. El patrón «task-status» incluye un flujo de trabajo con lugares como «suspended», «executing», «completed», etc. y propone un modelo de ejecución de una tarea.
De nuevo, como en el caso de «assignment», la incorporación al recurso WorkItem del patrón aumenta su estado.
El patrón puede ser accedido por otro recurso, por ejemplo para suspender la ejecución del item de trabajo. Éste es un método propio de la instancia de patrón (el envío de un evento determinado). ¿Debe ser ofrecido como una nueva operación en la interfaz del recurso pasarela?
Por otra parte, el hecho de suspender la ejecución de un item de trabajo puede tener consecuencias para el propio recurso. Por ejemplo, inhabilitar el envío del informe si esta tarea se encuentra suspendida. El patrón «task-status» podría inhabilitar determinados métodos en la pasarela al alcanzar el estado «suspended».
Ejemplos de incorporación — SubmitReport.
El recurso SubmitReport en la URL {R} no gestiona su estado de ejecución. Al incorporar el patrón «task-status» hay que especificar cuándo se pasa al estado «completed».
- Es la respuesta al método «POST {R} [report]» (envío del informe) que produzca el recurso la que indica si el item de trabajo ha concluído o no. La pasarela debe delegar el procesamiento al recurso y comprobar su respuesta para enviar el evento adecuado al patrón.
- El método «GET {R}» no es relevante para el patrón.
El responsable del informe puede solicitar la suspensión del item de trabajo. Si se añade esta operación a la interfaz de la pasarela, se ofrece un nuevo método.
- Un nuevo método «POST {R}/status/suspend [msg]» podría provocar directamente el envío del evento adecuado al patrón en «POST {P}/events/suspend [msg]».
Una forma alternativa sería añadir un método a la pasarela para realizar introspección. Se accedería así al patrón que desempeña un «role» determinado y a sus métodos.
Delegación.
Una aplicación diferente de un patrón puede ser la orquestación de una situación determinada. Por ejemplo, la delegación puede tener asociado un protocolo de actuación:
- Verificar que el item de trabajo admite delegación. Si no es así, se deniega la operación.
- Evaluar los recursos humanos candidatos. Si no hubiera, se cancela la operación.
- Ofrecer la lista de candidatos al recurso asignado al item de trabajo.
- Delegar en el indicado.
Este protocolo puede reflejarse en un patrón, con las acciones necesarias para llevarlo a cabo dentro del sistema en ejecución. En este caso, al solicitar una delegación sobre un WorkItem, debe instanciarse el patrón y establecer las relaciones con los recursos involucrados. El patrón es el orquestador del proceso.
Aquí el patrón necesita un entorno determinado para entrar en el sistema. Tiene un conjunto de requisitos expresados en términos de otros patrones con los que interactuar. Por ejemplo, una delegación debe estar asociada a un patrón «assignment» y a una colección («collection») de recursos humanos.
Composición de patrones (draft).
Una forma de componer patrones es mediante patrones de control de flujo, como «sequence» o «do-while». Aplicar esta composición a patrones orquestadores es una forma de definir flujos de trabajo más tradicional.
Por ejemplo, el patrón «reallocation» guía la reasignación de un item de trabajo ya comenzado a otro recurso humano. En algunos casos, se desea conservar el progreso realizado en el item de trabajo; si se dispusiese de un patrón orquestador que implemente un protocolo para realizar la migración del progreso del item de trabajo, se podrían combinar ambos patrones para obtener una reasignación con estado.
Políticas. (draft)
Supongamos que es necesario implementar una política de la organización: Si un item de trabajo permanece en el estado «suspended» durante más de una semana, se debe producir una reasignación. Se dispone de un patrón «re-assignment» que orquesta el proceso.
El primer paso es incorporar un patrón «timer» al item de trabajo, de forma que una acción insertada en el estado «suspended» de su patrón de estado inicie el temporizador. En el estado «timed-out», se solicita la incorporación al item de trabajo del patrón de reasignación.
Eliminación de un recurso de la organización
En el momento de eliminar un recurso humano de una organización determinada, se detecta la necesidad de realizar las siguientes tareas:
- Los items de trabajo asignados al recurso deben ser reasignados.
- Los ofrecidos deben retirar el ofrecimiento.
Nuevo patrón
Una posibilidad es implementar un patrón «reassignment» que orqueste el procedimiento de reasignación para un item de trabajo y combinar ambas actuaciones en un nuevo patrón:
- Localizar los patrones «assignment» con el recurso como responsable del item de trabajo.
- Para cada uno de ellos, crear una instancia del patrón «reassignment» e iniciar el flujo de trabajo.
- Localizar los patrones «assignment» con el recurso en la lista de «offered-to».
- Retirar el ofrecimiento: Operación de «assignment».
La combinación en un nuevo patrón es una orquestación del procedimiento de una organización determinada para gestionar la eliminación de un recurso.
Acciones
Otra implementación es la inserción de una acción en el estado «element removed» de un patrón «collection» que refleja los cambios en la lista de recursos disponibles en la organización. La acción llevaría a cabo los mismos pasos que la solución anterior.
- El procedimiento podría ser suficientemente complejo como para requerir un flujo de trabajo propio.
- Un patrón propio hace más independiente el procesamiento del patrón «collection»; la acción se limitaría a crear una instancia del patrón, iniciar el flujo de trabajo y olvidarse.
