Alternativas de implementação de webservices assíncronos

Oi pessoal,

Bom, antes de tudo, não sei se esta mensagem deveria estar aqui, ou na parte de Ferramentas, ou até em Java EE, sei lá.
Enfim, temos um contexto aqui onde temos um Oracle Service Bus chamando um web service.

Por requisito, pela quantidade de requisições feitas a este serviço, e principalmente pelas atividades desencadeadas por ele, este serviço deverá ser um serviço assíncrono.

Podemos partir para dois modelos (jax-rpc e jax-ws) de implementação, porém qualquer um dos nos trás impossibilidades. Ambos por uma questão "ferramental". Segue os dois fatos.

Com jax-ws, temos a facilidade de que a especificação nos provê "de fábrica" chamadas assíncronas, via callback ou via pooling, porém isto fica sob responsabilidade de ser ativado durante a geração do consumer deste serviço, via aquela querida e conhecida tag enableAsyncMapping no nosso arquivo de binding. Porém como nesta situação o real consumer do serviço seria o próprio Service Bus (uma vez que ele está ali para expor o serviço no barramento) e também porque jax-ws é uma especificação <ironia-mode>nova</ironia-mode>, ele quando vai consumir um WSDL não nos dá a opção de usar os métodos assíncronos da geração, ou seja, consumir serviços Jax-WS de maneira assíncrona (seja por callback ou pooling) com Oracle Service Bus fica fora das alternativas.

Com jax-rpc, temos uma boa vantagem em cima disso tudo, pois podemos usar neste caso soap em cima de jms para que desse para fazer request-response assíncrono. Pronto, bem tranquilo, com a anotação @WlJmsTransport consigo expor um mesmo serviço que é Http agora também em Jms, basta passar a fila e a connectionFactory que será usada para request e o response virá no reply-to. Porém o Weblogic quando expõe serviços via JMS, tem um outro problema que é na implementação do MDB que fica pendurado na fila para ativar o serviço, ele (por mais insano que possa ser) é um cara singleton que permite a execução de um fluxo por vez. Ou seja, aquele velho cliente que faz N chamadas simultâneas a um processo pesado fica enfileirado e faz um por um....

Problema né? Bom, alguém já passou por algo semelhante, ou tem alguma sugestão de uma implementação assíncrona de WS sem sair do contexto do produto Weblogic?

Valeu,

[]s,

Vc´s estão usando Oracle 10G, ou a Suite antiga da BEA?

DaviPiala wrote:Vc´s estão usando Oracle 10G, ou a Suite antiga da BEA?

Já a nova, 10gr3. Mas ambas as falhas, tanto para jax-ws quanto para jax-rpc já vem de antes, nas releases da bea.

[]s,

Você já pensou em usar o BPEL pra resolver isso?

DaviPiala wrote:Você já pensou em usar o BPEL pra resolver isso?

BPEL seria no mínimo interessante, uma vez que até nos fóruns da oracle o pessoal recomenda o transporte nativo do bpel no bus para chamar processos assíncronos implementados desta maneira. Porém temos que dar uma resposta a esta questão, a implementação do cliente é WS, e ele precisa da alta disponibilidade. Passar para BPEL agora por requisitos acaba não sendo uma possibilidade. Minha intenção é realmente tentar achar um workaround para isso.

Valeu!

[]s,

Bom,

Respondendo a questão de jax-ws, de fato o Oracle Service BUS não suporta chamada assíncronas para ele.
Acabei de ser respondido no fórum da Oracle sobre isto: http://forums.oracle.com/forums/thread.jspa?threadID=904971.

Resta agora apelar para alguma maneira menos tradicional de se colocar com jax-rpc.

[]s,

This message was edited 1 time. Last update was at 26/05/2009 10:31:11

Eu sei de uma solução sombria, só que é tão horrivel que nem vou comentar.

O serviço está exposto com foco em reusabilidade? Ele irá ter diversos clientes?

DaviPiala wrote:Eu sei de uma solução sombria, só que é tão horrivel que nem vou comentar.

Solução sombria? Nem comente aqui por favor....
Mas talvez você queira comentar ela por e-mail

DaviPiala wrote:Eu sei de uma solução sombria, só que é tão horrivel que nem vou comentar.

O serviço está exposto com foco em reusabilidade? Ele irá ter diversos clientes?

Sim. E com mais de um endpoint disponível.
Tanto em HTTP quanto em JMS, @HttpTransport e @WlJmsTransport...

Qual a idéia?

[]s,

JavaChild Membro desde: 03/08/2005 15:06:13 Mensagens: 147 Offline

Davi,

Posta a solução sombria, por favor.

Inté!

Resolvido.

Infelizmente não da melhor maneira.
Para usar Jax-Ws, o Oracle Service BUS não dá suporte para chamada de web-services assíncronos, então, a opção fica descartada.
Para usar Jax-Rpc, com SOAP/JMS existe um BUG no Weblogic que retira as mensagens de forma serializada, ou seja, uma por vez, fazendo com que não seja possível ter paralelismo na operação, então opção também descartada.

Tivemos que implementar o transporte JMS do Oracle Service Bus ao Weblogic e colocar MDBs na ponta para efetuar as operações. A resposta foi feita usando JMS Request Response com o pattern Message Id.

Obrigado,

[]s,

Talvez a solução sombria seja o que utilizamos em nosso projeto aqui. Implementamos um pool de Threads no servidor e as threads podem ser executadas simultaneamente resolvendo o problema do assíncrono.
É claro que vocês vão me xingar e dizer que estou abrindo threads "na mão" no servidor de aplicações, e isso é inconcebível na cartilha do JEE. No entanto, a solução usando filas não funcionou legal para nós, elém de ter ficado difícil de implementar e uma característica do Weblogic nos obrigava a usar um driver XA em razão das transações com o banco se tornarem distribuídas, com certeza um impacto muito grande na camada de persistência que já está desenvolvida.
Bom , o sistema já está rodando há algum tempo em produção com as threads e funciona muito bem.

OBS: neste projeto não podíamos usar o BPEL em razão de ter sido desenvolvido apenas com o servidor de aplicações e o banco de dados pago.

This message was edited 1 time. Last update was at 04/06/2009 18:15:20

Pessoal foi mal até esqueci de dar a solução,
Eu andava meio ferrado na semana passada.

O POG que eu iria propor é criar dois serviços um serviço com a carga de atividades e outro só pra callback e com duas threads, a thread com o fluxo do programa que fazia a chamada ao serviço, enquanto isso continuamente chamava esse serviço de callback pra verificar se o estado aplicado pelo primeiro serviço já havia sido concretizado.

Por isso perguntei se o serviço seria continuamente usado.

Agora falando sério quando vc's tiverem problemas com os produtos da oracle me mande um email.

davi.piala@hotmail.com

Eu posso verificar com o pessoal do PTS e Pre-Sales.

Notícias, artigos e o maior fórum brasileiro sobre Java