Na especificação BPEL
correlação é uma funcionalidade importante que precisa ser entendida por aqueles que ou irão projetar processos complexos ou irão desenvolver aplicações que utilizarão tais processos. Isso porque a correlação de mensagens em
BPEL (
Business Processo Execution Language) é uma das funcionalidades que permitem a elaboração de cenários complexos onde diferentes "parceiros" (
partners - consumidores ou provedores de serviços) estão envolvidos na execução de uma
instância de processo.
O que é uma instância de processo?
Apenas para que fique claro o que é uma instância de um processo, vamos fazer uma breve analogia à linguagem Java. Quando escrevemos uma classe em um arquivo ".java" estamos codificando a sua definição ou declaração. Ao compilar e executar essa classe em uma máquina virtual Java teremos um objeto dessa classe, ou seja, uma instância da classe. (Logicamente que, dependendo da situação, podemos ter em execução mais de uma instância dessa classe). Sendo assim, podemos fazer a seguinte analogia:
- Em tempo de projeto ou codificação:
- Uma classe Java equivale à definição de um processo;
- Em tempo de execução:
- A Java Virtual Machine (JVM) equivale a um motor (engine) BPEL;
- Um objeto Java em uma JVM equivale a uma instância do processo em um engine BPEL.
Entendendo o problema de correlação.
Antes de começar a falar de
BPEL (
Business Processo Execution Language) e sobre
correlação vamos começar entendendo o contexto em que utilizamos a palavra
correlação. Segundo o dicionário
Michaelis:
correlatar
cor.re.la.tar
(co+relatar) vtd 1 Estabelecer relação mútua. vpr 2 Entrar ou estar em correlação com.
Quando falamos em correlação no contexto de processos e de BPEL, estamos nos referindo a como relacionar diferentes instâncias de um processo aos seus devidos usuários, ou ainda, como correlacionar diferentes mensagens que são recebidas em momentos distintos e eventualmente por fontes distintas.
Vamos a um exemplo prático utilizando o seguinte processo fictício:
Esse processo possui 2 tarefas (ou atividades) que no caso foram chamadas de "1o processamento" e "2o processamento". A dinâmica do processo ocorre da seguinte forma:
- Toda vez que uma "Mensagem tipo X" chega ao engine BPEL uma nova instância do processo é criada;
- A tarefa "1o processamento" é acionada de forma a consumir a mensagem;
- Como a tarefa "2o processamento" depende da chegada da "Mensagem tipo Y", o engine BPEL coloca instância do processo em pausa para aguardá-la
- Quando a "Mensagem tipo Y" chega, a instância do processo sai do estado de pausa e a tarefa "2o processamento" é executada;
- O processo termina e a instância é finalizada pelo engine BPEL.
Agora observe a figura abaixo onde há mais de uma instância do processo em pausa, cada uma aguardando a chegada da sua segunda mensagem. A qual instância de processo o engine BPEL deverá enviar a próxima "
Mensagem tipo Y" que chegar?
O que o engine BPEL precisa descobrir é qual instância de processo foi criada pela "
Mensagem tipo X" que possui
correlação com a "
Mensagem tipo Y" que está chegando. Vamos ver como a especificação BPEL trata esse problema?
Como a correlação pode ser implementada?
Quem está acostumado a trabalhar com linguagens de programação web deve estar pensando que isso pode ser facilmente implementado usando sessões (sessions). Mas e se eu dissesse que a especificação BPEL não resolve essa questão utilizando sessões?
O que acontece é que um das principais observações feitas
pelo grupo especificou o BPEL é que a maioria das mensagens trocadas entre
partners e processos já carregam os dados requeridos para identificar unicamente a instância de um processo, ou seja, dados que tornam possível a correlação de mensagens enviadas em momentos diferente. Por esse motivo a especificação BPEL recomenda que a correlação seja implementada usando dados funcionais da mensagem, ou seja, dados existentes no conteúdo da mensagem. Voltando ao nosso exemplo, poderíamos considerar que a "
Mensagem tipo X" seria um pedido de reserva de espaço para um anúncio em um jornal, enquanto que a "
Mensagem tipo Y" equivaleria à confirmação da reserva. Nesse caso, as duas mensagens poderiam ser correlacionadas simplesmente por uma ID do anunciante ou por algum outra chave, seja ela simples ou composta, que permitisse identificar unicamente cada pedido.
O grande benefício que a maiorida dos engines BPEL proporcionam é o suporte oferecido por eles para a recuperação da correta instância de processo a partir da correlação de mensagens.
Quer mais detalhes sobre correlação? Sugiro como leitura a parte da
especificação BPEL que trata a questão de
correlação de mensagens. Em seguida vale conhecer melhor como as ferramentas que você tem disponível implementam essa parte da especificação.
Em um próximo post mostrarei como implementar a correlação de mensagens em um processo BPEL na ferramenta GlassFish ESB.
Até lá !
