WS-BPEL e os cabeçalhos HTTP de resposta


Nos últimos dias realizamos alguns testes com o GlassFish ESB expondo processos BPEL através de WebServices SOAP de diferentes maneiras. Tais testes foram feitos com dois diferentes padrões de troca de mensagens (MEP – Message Exchange Patterns): Request Only (Também conhecido como InOnly) e Resquest-Response.

Para quem não sabe, o GlassFish ESB possui um componente JBI chamado BPEL Service Engine que é implementação do padrão WS-BPEL. Relembre o que é o padrão JBI.

O motivo de ter feito esses testes é porque no caso dos serviços assíncronos eu estava pensando que, para o cliente saber se a requisição foi aceita pelo provedor do serviço bastaria verificar se cabeçalho HTTP de resposta era o 200 OK. Acontece que não é bem assim que a coisa funciona. Segue abaixo as constatações…

Serviços Resquest Only (São os serviços que estou considerando como sendo Assíncronos)

  • O GlassFish ESB, mais especificamente o BPEL SEsempre (eu disse SEMPRE) retorna o status HTTP/1.1 202 Accepted
    • Esse código indica que “…a requisição do cliente não pode ou não será tratada em tempo real, sendo processada mais tarde. A requisição parece válida, mas pode causar problemas quando for processada. Essa é uma resposta adequada quando uma requisição ativar uma ação assíncrona.“. Fonte:http://goo.gl/QEYZ
    • Nesse caso, o provedor do serviço não envia nenhum conteúdo no corpo da mensagem de resposta, ou seja, existe uma resposta mas ela é vazia no sentido que só existe o cabeçalho HTTP de resposta. Isso acontece dessa forma mesmo se o dentro da implementação do serviço (no nosso caso dentro de um BPEL) for gerada uma exception!!! Nesse caso temos que ter muita atenção ao tratamento de erros dentro do BPEL para não deixar a requisição “se perder”. Por exemplo, eu forcei a geração de uma exception dentro do processo e, mesmo usando um Throw ou fazendo uma conta de 1/0, o serviço respondeu HTTP/1.1 202 Accepted. Sendo assim o Framework de tratamento de erro que estamos construindo e o seu correto uso tornam-se fundamentais.

Serviços Request-Response

  • O GlassFish ESB… 
    • Retorna o status HTTP/1.1 200 OK quando…
      • A requisição foi processada sem problemas. Esse código indica que bem, esse tudo mundo sabe, né?!? A diferença para o código 202 Accepted é que nesse caso o serviço enviou um conteúdo no corpo da mensagem. O consumidor do serviço poderá decidir, por exemplo, se precisa realizar alguma outra ação.
    • Retorna o status HTTP/1.1 500 Internal Server Error quando…
      • Dentro do BPEL capturarmos alguma exception, fizermos o devido tratamento e respondermos para o cliente uma mensagem do tipo Fault no corpo da mensagem. Sendo assim, o provedor do serviço também envia algum conteúdo no corpo da mensagem.

O interessante disso tudo foi constatar a fidelidade do GlassFish ESB em relação aos cabeçalhos HTTP de resposta.

Acredito que essas informações possam nos ajudar a desenvolver serviços no GlassFish ESB de forma mais segura (no sentido de saber mais sobre o comportamento da ferramenta) e também implementar consumidores de serviços ainda mais refinados.

Abraços a todos e até o próximo post!

Correlação de Mensagens utilizando BPEL


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:

  1. Toda vez que uma “Mensagem tipo X” chega ao engine BPEL uma nova instância do processo é criada;
  2. A tarefa “1o processamento” é acionada de forma a consumir a mensagem;
  3. 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
  4. Quando a “Mensagem tipo Y” chega, a instância do processo sai do estado de pausa e a tarefa “2o processamento” é executada;
  5. 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á !