Formalización de modelos de recursos
De MorfeoWiki
Tabla de contenidos |
Formalización del modelo de recursos
Se pretende dotar al motor TIDStateEngine de la capacidad de gestionar recursos, aspecto crucial para construir sistemas de gestión de procesos realmente interesantes para las organizaciones. Se parte de una red de Petri que modela el ciclo de vida de una parte del proceso que requiere recursos. Cuando se define un proceso que incluye trabajos que requieren recursos, se creará un nuevo caso de esta red para cada uno de esos trabajos.
Se ha diseñado una arquitectura software para permitir la gestión de procesos que en alguna parte del mismo requieren recursos para su ejecución, en la que además del motor de workflow TIDStateEngine se dispone de los siguientes componentes:
- ResourcesManager: gestiona los recursos disponibles en la organización. Hasta ahora el modelo de recursos organizacionales se diseñaba de forma ad-hoc para cada proceso de la organización y se gestionaba desde los datos del proceso en el motor como ExternalData. Debido a que esta forma de trabajar con los recursos es muy limitada y no permitiría implementar muchos de los patrones de recursos definidos en [1] se ha diseñado un modelo organizacional más general y flexible que se gestionará a través del ResourceManager, y que permite disponer de recursos humanos y no humanos, roles, posiciones organizativas, grupos, privilegios de posiciones, capacidades de recursos, delegaciones permitidas, sustituciones entre recursos, etc. de forma totalmente independiente de los procesos. Este modelo de recursos organizacionales se almacena en una base de datos relacional y el encargado de mantenerla es el ResourceManager. Esta componente se podría envolver en una capa REST, considerando que cada recurso organizacional tendrá una URI asociada y un ciclo de vida propio. Esta conversión del componente a REST se hará si se considera necesario el acceso a dichos recursos organizacionales desde el exterior de la organización, fuera de la intranet de la misma.
- WorkItemsManager: responsable de gestionar las asignaciones de recursos a los workitems. Se trata de una componente interna muy relacionada con el motor de workflow. Gestiona la base de datos que mantiene información de workitems asignados a recursos, de workitems ofrecidos a recursos (que desde la bandeja estos pueden apropiarse de ellos), así como el historial de todos los trabajos realizados por los recursos. Sobre el se ha creado una capa REST para acceder a parte de su funcionalidad via HTTP desde Internet.
- WorkListApplication: también denominada Bandeja. Es la encargada de mostrar los items de trabajo asignados a cada recurso organizacional. Podría ser un gadget de Google o cualquier otro componente que hace uso de la capa REST que proporciona el WorkItemsManager.
Terminología
Una vez registrada la «red» en la máquina de estados, se pueden crear «tareas» para esa red y hacerlas evolucionar mediante el envío de eventos. A lo largo de esa evolución serán ejecutadas «acciones» asociadas a transiciones y estados.
Una vez registrada una «definición de proceso» en la máquina de estados, se pueden crear «casos» de ese proceso y hacerlos evolucionar mediante el envío de eventos. A lo largo de esa evolución será necesario llevar a cabo «trabajos» que pueden requerir un recurso; en ese caso se denominarán «asignaciones».
Lenguaje WDL
Es necesario ampliar el lenguaje original PNML, en principio para incluir la especificación de una asignación. Se ha optado por definir un lenguaje WDL («workflow definition language») que permita experimentar con ampliaciones del lenguaje original y que sin embargo mantenga la compatibilidad con la máquina de estados.
Los documentos WDL están codificados en XML y tienen la misma estructura que los PNML, pero con algunos elementos nuevos. Mediante transformaciones XSL se procesan las ampliaciones para generar las componentes necesarias para definir una red en la máquina de estados, tal y como se haría con el lenguaje original. Por una parte, la red de Petri inicial se modifica para obtener una nueva red de Petri que acomoda las ampliaciones, y por otra se incluye código en las clases Java correspondientes para implementar esas ampliaciones.
En la actualidad, el objetivo es la definición de asignaciones (trabajos que requieren un recurso) mediante la asociación de éstas a transiciones en la red de Petri. El ciclo de vida de una asignación se modela mediante una definición de proceso, con estados como «ofrecido a varios recursos», «en ejecución», o «terminado». En la transformación del WDL se insertan nuevos lugares y transiciones en la red de Petri para acomodar las asignaciones, de forma que al llegar a esa transición se crea un caso del proceso (sub-proceso). Ambas instancias se sincronizan mediante eventos.
En la siguiente figura se muestra la inserción de transiciones y lugares necesarios para gestionar la asignación en la transición tj.
La modificación de la red de Petri se simplifica al eliminar en WDL los identificadores numéricos de lugares, transiciones, etc. que se utilizan en PNML. Por ejemplo, dada una transición «β» es posible insertar nuevas transiciones «β.pre», «β.post» con una relación establecida dentro del propio nombre. En el proceso de transformación XSL se generan automáticamente identificadores numéricos para la máquina de estados, a partir de los nombres.
Las clases Java generadas son similares a las que se obtienen a partir de un PNML tradicional. Es necesario incluir código para la gestión de la asignación, como por ejemplo la creación del caso correspondiente. La solución adoptada es insertar una clase Java entre la clase base de acción «Action~» y la de acciones final «Action~Impl». Esta nueva clase, denominada «Action~UserImpl», es la que el usuario puede utilizar para insertar código en las acciones de la red de Petri original. En la clase final «Action~Impl» se añade el código de gestión de la asignación y se llama a los métodos de la clase de usuario cuando sea necesario.
Expresiones de asignación
A la hora de especificar una asignación en un documento WDL hay que añadir información para que el sistema de gestión de recursos sea capaz de decidir a quién se ofrece la asignación. Por ejemplo, quizá sea un requisito que el recurso posea un cierto «role» o un nivel de autorización determinado. En la definición de una asignación se dispone de un elemento para indicar expresiones que permiten seleccionar los recursos candidatos para la asignación.
Por ejemplo, la asignación «fix bugs» debe ser realizada por un recurso que tenga los roles «administrator» y «developer»:
<wdl:Assignments>
<wdl:Assignment name="fix bugs" transition="Tj">
<wdl:Resources>
<wdl:Requirements>
<ae:selection xsi:type="ae:and">
<ae:selection xsi:type="ae:roleBased" role="developer"/>
<ae:selection xsi:type="ae:roleBased" role="administrator"/>
</ae:selection>
</wdl:Requirements>
</wdl:Resources>
</wdl:Assignment>
</wdl:Assignments>
La implementación de cada uno de los tipos de expresiones de asignación debe ser capaz de generar una lista de recursos como resultado, a partir de los servicios proporcionados por la componente ResourceManager.
Propuesta de URLs para la capa REST
Se limita el acceso REST a la funcionalidad requerida por una aplicación de tipo «bandeja»:
- /resourceManagement/assignments/[id]: Asignación con identificador «id».
- POST (con datos sobre la asignación): cambio de estado de una asignación: Empezar a ejecutar, suspender o reanudar, marcar como completada. Debe incluir una referencia al recurso involucrado.
- /resourceManagement/assignments/[id]/workers: Recursos que han aceptado una asignación.
- POST (con datos sobre un recurso): acepta una asignación.
- DELETE (con datos sobre un recurso): renuncia a una asignación.
- /resourceManagement/assignments/[id]/candidates: Recursos que cumplen los requisitos para la asignación.
- /resourceManagement/roles/[id]: El «role» con identificador «id».
- /resourceManagement/roles/[id]/assignments: Asignaciones ofrecidas a ese «role».
- /resourceManagement/resources/[id]: Recurso con identificador «id».
- /resourceManagement/resources/[id]/assignments: Asignaciones para ese recurso.
Cuestiones pendientes
Algunas operaciones provocan cambios en las bandejas de otros usuarios; cómo avisar desde el servidor? No es necesario que sea instantáneo, quizá sindicación.
Referencias
- [1] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003.
