Núcleo

O núcleo surgiu como conseqüência natural da filosofia de particionamento de funcionalidades adotada no projeto. Foi formulado, inicialmente, como sendo a camada mais interna na arquitetura do sistema - seu papel seria prover funcionalidades básicas, tais como a criação, gerenciamento e atualização dos modelos de fluxo, através de primitivas pouco abstratas.

Logo no início do processo de modelagem, todavia, notamos ser o núcleo possuidor de uma grande vocação a biblioteca independente, já que fornece uma interface bem definida com um conjunto de primitivas genéricas, sendo completamente desacoplado do restante do sistema. Tais características permitiriam o seu uso em qualquer projeto que necessitasse de funcionalidades de workflows básicas ou simulações de fluxos (fluxos e workflows serão utilizados aqui como palavras equivalentes).

O núcleo provê, essencialmente, as seguintes funcionalidades:

• Interface para modelagem de fluxos, criação e instanciamento de templates (metaclasses);

• facilidades que permitem acompanhar o estado dos workflows instanciados: incluem formas de determinar, a qualquer instante, quais as tarefas ativas e quais os participantes nelas envolvidos;

• controle centralizado de recursos, portando interfaces de acesso aos repositórios de modelos e participantes;

• controle interno de persistência através do JDO, comportamento transacional.

Além disso, existe uma coleção de Beans de sessão (que cumprem o papel de fachadas), criados para uso exclusivo da biblioteca em ambientes gerenciados (contêiners J2EE, especificamente).

Figura 4: Núcleo e suas fachadas para uso em ambiente J2EE.

Representação Interna

Existem muitas maneiras conhecidas para representar workflows - a maior parte delas envolve grafos, a grande maioria cumpre bem o seu propósito de modelagem. O problema encontrado em muitas dessas representações está, portanto, não nas representações em si, mas no fato delas serem heterogêneas e restritas a nichos ou grupos de desenvolvimento. Isso gera uma porção de dificuldades com relação às ferramentas de análise empregadas, que diferem significativamente de uma representação para outra. Além disso, certos modelos são mais próprios a determinados tipos de análise do que outros.

Ferramentas de análise são importantes na medida que tornam possível avaliar um fluxo quanto a diversos aspectos qualitativos e quantitativos antes de colocá-lo em prática (evitando, potencialmente, prejuízos à empresa utilizando o sistema de workflows).

A escolha do nosso modelo interno de representação levou em conta, ainda, os seguintes aspectos:

• Manipulação - o modelo não pode ser críptico. Um modelo muito complexo tem sua aplicabilidade condicionada à presença de profissionais qualificados. Gostaríamos de um modelo que fosse intuitivo.

• Expressividade - não adianta o modelo ser fácil de usar e possuir boas propriedades de análise se ele não for capaz de representar a diversidade de fluxos requerida nos ambientes aos quais a aplicação é voltada. Precisamos, portanto, de um modelo expressivo.

• Propriedades de análise - além de darmos preferência a modelos com boas propriedades de análise, foi necessário também separar quais dessas propriedades eram relevantes ao nosso usuário final esperado e quais não eram.

Após estabelecidas as metas, teve início um processo de pesquisa e seleção do modelo. A representação que melhor se enquadrou nos nossos requisitos foi a das Workflow Networks, ou WF-nets.

WF-Nets

WF-nets são, essencialmente, redes de Petri acrescidas de algumas particularidades. De maneira semelhante às redes de Petri clássicas, as WF-nets possuem lugares, transições, arestas (com peso) e tokens. Além disso, todavia, nas WF-nets temos que:

As arestas que partem de transições para lugares podem ter, associadas a elas, expressões lógicas cujos átomos são propriedades. Essas propriedades assumem valores do tipo verdadeiro ou falso, que serão utilizados para avaliar a expressão associada. Durante o disparar de uma transição (onde tokens são consumidos do(s) lugar(es) de origem e produzidos no(s) lugar(es) de destino), apenas aquelas arestas cujas expressões forem verdadeiras produzem tokens. Dessa maneira podemos modelar todos os construtos de roteamento requeridos pelos diversos tipos de workflow. Além disso, as propriedades atuam como um equivalente das cores encontradas nas redes de Petri coloridas (colored Petri nets).

Figura 5: Um exemplo de uma WF-net. Lugares são círculos, transições são quadrados.

Dessa maneira, no nosso exemplo (ver figura n5) de WF-net, um token que se encontra no lugar C irá passar, mediante uma transição, para o lugar D, se e somente se a expressão (a & b) for verdadeira; isto é, se a for verdadeira (cliente aprova projeto) e b for verdadeira (gerente aprova projeto). Caso contrário, se !b ou !c forem verdadeiros (isto é, o cliente OU o gerente não aprovam o projeto), a transição irá consumir o token em C e produzir um token em D. O estado da WF-net num dado instante é representado pelo conjunto dos tokens e suas respectivas posições (em quais lugares eles se encontram).

Quanto às transições, podem ser disparadas tanto por ação do usuário (por exemplo, o usuário completa um item de trabalho como o apresentado na transição ``registra dados'') quanto pelo expirar de um timer (timeouts). Para o núcleo isso não faz diferença, todas as entidades que participam de interações com as WF-nets são representadas através de recursos (resources). Recursos podem representar usuários, grupos ou até mesmo timers e aplicações - o significado é dado pelas camadas mais externas.

Como nas redes de Petri clássicas, transições (na verdade workitems, como veremos mais adiante) só são ativadas mediantes à presença de um número suficiente de tokens nos lugares conectados a ela em leque de entrada (fan-in). Por outro lado, contrário às redes de Petri clássicas, transições não são disparadas aleatoriamente - requerem, como descrito acima, a participação de um terceiro elemento, uma resource. Uma resource deve possuir permissão para disparar uma dada transição.

Segue abaixo o diagrama de transição de estados para um item de trabalho (workitem), cujo papel é associar as transições (dadas num template) a uma dada instância de um template de fluxo de trabalho. No caso do exemplo dado acima, cada vez que um contato com um cliente for estabelecido, será posta em execução uma nova instância do template que modela esse fluxo, gerando novos workitems. O workitem é a ponte natural entre as instâncias de um template e o template.

Figura 6: Possíveis estados para um item de trabalho.

O núcleo é, portanto, o responsável por criar, manter e fornecer acesso a todas essas informações.