Galera quem tiver experiência e puder me indicar alguma tecnologia.
Preciso realizar requisições assíncronas, determinado momento receberei uma requisição numa classe java, e partir daí realizar assincronamente. Não será usado ajax, pois será um sistema de integração e não terá uma camada view, esses processos serão disparados por outro sistema, por isso tem que ser em java puro.
Não tenho conhecimento, mas pelo que pesquisei achei falando sobre JMS, EJB 3 no JEE 6 tem suporte a requisição assíncrona…
Não entendi direito se vc quer fazer ou receber as requisições.
Enfim, se vc pretente processar requisições de forma assincrona, além das tecnologias que vc mencionou, vc pode adicionar a lista Servlets ou ainda WebServices, dependendo do escopo e do número de requisiçoes que vc for receber, seria até mais simples do que partir para o Ejb, pois a primeira grande pergunta é quem esta efetuando a chamada? Qual o seu tipo (Tecnologia) de cliente?
Agora se forem realmente “Requisições” a serem enviadas, basta um programinha meia boca utilizando Threads…
Caso vc precise de comunicação entre processos, de forma assíncrona, utilize JMS mesmo.
Existem containers bons para isso. O JBossMQ existe(ia) justamente para trabalhar com JMS.
E, caso não exista necessidade de manter contextos transacionais, não use os MDBs de EJB.
[quote=cristian_clever]Não entendi direito se vc quer fazer ou receber as requisições.
Enfim, se vc pretente processar requisições de forma assincrona, além das tecnologias que vc mencionou, vc pode adicionar a lista Servlets ou ainda WebServices, dependendo do escopo e do número de requisiçoes que vc for receber, seria até mais simples do que partir para o Ejb, pois a primeira grande pergunta é quem esta efetuando a chamada? Qual o seu tipo (Tecnologia) de cliente?
Agora se forem realmente “Requisições” a serem enviadas, basta um programinha meia boca utilizando Threads…
[]s[/quote]
Na verdade é resposta, vai ser assim:
Tenho um webservice que será consumido por diversos clientes e até de outra linguagem, quando o cliente for consumir o webservice ele vai passar uma flag dizendo se quer a resposta sincrona ou assincrona (a questão é que o cliente não vai ter q implementar uma chamada assincrona, eu vou ter fazer uma resposta assincrona se ele desejar), e partir dessa informação eu executo normal sendo sincrono, ou então eu começo a fazer um processamento assincrono enviando uma resposta imediata pro cliente e liberá-lo, e continuar o processamento dos métodos em segundo plano…
Tenho receio de fazer Thread e ter que gerenciar tudo, pois serão um boa quantidade de requisições…
EJB (Sessions) como fru-fru … a não ser que vc precise de algo mais powerfull como gerenciamento de sessões, destribuição (o que acredito que não) como disse o clone.
[quote=boone][quote=JavaTux]
Tenho um webservice que será consumido por diversos clientes e até de outra linguagem, quando o cliente for consumir o webservice ele vai passar uma flag dizendo se quer a resposta sincrona ou assincrona (a questão é que o cliente não vai ter q implementar uma chamada assincrona, eu vou ter fazer uma resposta assincrona se ele desejar), e partir dessa informação eu executo normal sendo sincrono, ou então eu começo a fazer um processamento assincrono enviando uma resposta imediata pro cliente e liberá-lo, e continuar o processamento dos métodos em segundo plano…
[/quote]
Ah tá…então após liberá-lo, vc continua seu processamento e é vc que vai chamar uma URL dele passando o resultado…pô, ficou legal assim… :idea:
Realmente assíncrono ![/quote]
Invés do claro deboche poderia ajudar na solução. Mas tudo bem.
O que eu preciso é fazer:
Receber uma chamada
“Liberar” o cliente daquela requisição que ele fez enviando neste momento o “numero” daquela requisição
Iniciar uma thread pra processar essa requisição em segundo plano, gravar informações no banco etc etc.
Não vou avisar o cliente que terminou… Depois vai ter uma segunda chamada que o cliente pode fazer enviando o “numero” que recebeu
e verificar se já foi processado ou não.
Talvez o termo assíncrono foi mal empregado, o que preciso é liberar o cliente e depois ele vai ter uma opção pra verificar se processou, se deu erro etc etc etc…
Bem, antes de mais nada, o cliente exige que seja assim.
Diante deste cenário puder contribuir com informações relavantes.
Você entendeu errado ! Eu não deboxei, eu apresentei uma solução melhor do que a que você acaba de propor.
Na sua proposta, o cliente vai ter que ficar consultando constantemente seu sistema passando o número da requisição para tentar ver se já tem resposta. Isto não é bom nem para o cliente e nem para você. Tráfego e processamento desnecessário de ambos os lados.
Pela minha proposta, para um modelo desconexionista como o que pediu, eu vou além e proponho que seu sistema após receber o pedido do cliente, libere-o, e ele se responsabilize por chamar uma URL do cliente passando a resposta. Esta chamada por exemplo, pode ocorrer logo em seguida, ou daqui 5, 10 minutos, 1 hora, não importa…sempre vai funcionar.
Veja quanta diferença! Ao invés de ter um monte de processamento usando sua proposta, simpliquei e agora tenho apenas 1 chamada do servidor para o cliente, fornecendo a resposta.
Isto é benéfico para o seu servidor pois ele fica mais leve para atender outras requisições e é bom para o cliente também.
Muitas integradoras trabalham assim (Ex: Gateways de SMS) e acho que sua inexperiência no assunto te fez acreditar que eu estava debochando.
[quote=boone]Você entendeu errado ! Eu não deboxei, eu apresentei uma solução melhor do que a que você acaba de propor.
Na sua proposta, o cliente vai ter que ficar consultando constantemente seu sistema passando o número da requisição para tentar ver se já tem resposta. Isto não é bom nem para o cliente e nem para você. Tráfego e processamento desnecessário de ambos os lados.
Pela minha proposta, para um modelo desconexionista como o que pediu, eu vou além e proponho que seu sistema após receber o pedido do cliente, libere-o, e ele se responsabilize por chamar uma URL do cliente passando a resposta. Esta chamada por exemplo, pode ocorrer logo em seguida, ou daqui 5, 10 minutos, 1 hora, não importa…sempre vai funcionar.
Veja quanta diferença! Ao invés de ter um monte de processamento usando sua proposta, simpliquei e agora tenho apenas 1 chamada do servidor para o cliente, fornecendo a resposta.
Isto é benéfico para o seu servidor pois ele fica mais leve para atender outras requisições e é bom para o cliente também.
Muitas integradoras trabalham assim (Ex: Gateways de SMS) e acho que sua inexperiência no assunto te fez acreditar que eu estava debochando.
[/quote]
Realmente muito esclarecedor e de grande ajuda, desculpe minha interpretação errada, nesse último trecho da última linha você disse tudo.
