Todos os servidores usam o mesmo banco de dados e um compartilhamento de arquivo comum. O compartilhamento de arquivo é usado para logs e vários outros diretórios, especificamente: logs, var/email, var/plug-ins e var/repository. Cada servidor também mantém independentemente algumas informações de configuração, como portas e hosts. O banco de dados é usado para informações de configuração, dados de tempo de execução, e assim por diante.
Como os servidores compartilham o banco de dados, todos os servidores são executados no mesmo intervalo.
Algumas propriedades de configuração permanecem no servidor, como informações de conexão do banco de dados e JMS. A configuração do banco de dados é manipulada durante a instalação do produto; nenhuma configuração adicional será necessária pós-instalação.
Fluxos de trabalho consistem em atividades. As atividades podem ser executadas sequencialmente, executadas paralelamente umas com as outras ou alguma combinação dos dois. Um fluxo de trabalho típico pode consistir em diversas atividades sequenciais, como:
Para comunicações baseadas em JMS, os agentes podem ser configurados de várias maneiras:
Todos os servidores pesquisam constantemente fluxos de trabalho pendentes, portanto, qualquer servidor poderá iniciar o fluxo de trabalho. O servidor que adquire este fluxo de trabalho executa as seguintes tarefas:
Depois de concluir o trabalho, o agente envia uma mensagem de resposta sobre JMS. A mensagem será gravada no banco de dados (por um dos servidores) e na próxima atividade iniciada (por um dos servidores). O servidor que iniciou a Atividade B executa as mesmas etapas, conforme descrito acima.
No fluxo de trabalho simples que é esboçado aqui, todas as atividades podem ser manipuladas pelo mesmo servidor ou por servidores diferentes (ou alguma combinação). Evidentemente, o mesmo seria verdadeiro se esse fluxo de trabalho consistisse em três atividades paralelas.
Um fluxo de trabalho de aplicativo é mantido por um único registro no banco de dados (apenas um encadeamento manipula um fluxo de trabalho ao mesmo tempo).
Durante o processamento de aplicativo, as falhas de comando são marcadas no fluxo de trabalho. A manipulação de erros é de responsabilidade do autor do aplicativo. O retrocesso do componente pode ser manipulado com o comando/as etapas de retrocesso. Retroceder, conforme usado aqui, significa reinstalar uma versão do componente anterior.
Se o servidor travar enquanto um agente estiver executando um comando, a malha JMS designará o fluxo de trabalho para outro servidor.
Se um agente travar ou, de alguma maneira, desaparecer ao executar um comando (lembrando que etapas com falha não causam a falha dos agentes em si), o servidor assumirá que o comando ainda está em execução; não há tempo limite automático. Normalmente, não é realista, nem factível designar um intervalo de tempo limite.