Todos los servidores utilizan la misma base de datos y una compartición de archivos común. La compartición de archivo se utiliza para los registros y algunos otros directorios, específicamente: logs, var/email, var/plugins y var/repository. Cada servidor también mantiene de forma independiente cierta información de configuración, como puertos y hosts. La base de datos se utiliza para la información de configuración, datos de tiempo de ejecución, etc.
Dado que los servidores comparten la base de datos, todos los servidores se ejecutan en el mismo intervalo.
Algunas propiedades de configuración permanecen en el servidor, como la información de conexión JMS y de base de datos. La configuración de base de datos se gestiona durante la instalación del producto; no se necesita configuración adicional posterior a la instalación.
Los flujos de trabajo constan de actividades. Las actividades se pueden ejecutar de forma secuencial, en paralelo unas con otras, o una combinación de las dos. Un flujo de trabajo típico consta de varias actividades secuenciales, como:
En comunicaciones basadas en JMS, los agentes se pueden configurar de varias formas:
Todos los servidores realizan sondeos de forma constante en busca de flujos de trabajo pendientes, por lo que cualquier servidor podría iniciar el flujo de trabajo. El servidor que adquiera este flujo de trabajo ejecuta las tareas siguientes:
Después de que finalice el trabajo, el agente envía un mensaje de respuesta sobre JMS. El mensaje se escribirá en la base de datos (por medio de uno de los servidores) y se iniciará la siguiente actividad (por medio de uno de los servidores). El servidor que ha iniciado la actividad B, ejecuta los mismos pasos descritos anteriormente.
En el flujo de trabajo simple que se describe aquí, es posible que el mismo servidor gestione todas las actividades o que lo hagan servidores distintos (o alguna combinación). Por supuesto, esto se aplicaría también si el flujo de trabajo constase de tres actividades paralelas.
Un único registro en la base de datos mantiene un flujo de trabajo de aplicación (sólo una hebra puede gestionar un flujo de trabajo al mismo tiempo).
Durante el proceso de la aplicación, los errores del mandato se marcan en el flujo de trabajo. La gestión de errores es responsabilidad del autor de la aplicación. La retrotracción de componentes puede gestionarse con pasos o con el mandato de retrotracción. La retrotracción, según se usa aquí, implica reinstalar una versión anterior del componente.
Si el servidor se cuelga mientras un agente está ejecutando un mandato, la maya JMS asigna el flujo de trabajo a otro servidor.
Si un agente se cuelga o, en otro caso, desaparece mientras se está ejecutando un mandato (recuerde que los pasos erróneos no hacen que fallen los agentes propiamente dichos), el servidor supone que el mandato todavía se está ejecutando; no existe ningún tiempo de espera automático. Normalmente, no es posible ni es factible asignar un intervalo de tiempo de espera.