Escutando Modificações de um Servidor de Aplicações

7 respostas
Guerr

Estou precisando que uma aplicação Swing “escute” modificações ocorridas em um servidor de aplicações, mais ou menos como um observer remoto. Por enquanto estou criando no cliente uma thread que vai acessar um bean de tempos em tempos verificando se houve modificação.

Confesso que fiquei meio incomodado com isto… Qual seria a melhor opção para o servidor de aplicações avisar o cliente que houve uma modificação sem que eu precise ter um servidor no cliente.

Já agradeço qualquer contribuição!!!

7 Respostas

Luca

Olá

Eu sou fã de trocas de mensagens HTTP para não entrar com possíveis conflitos com o Departamentos de redes. E com HTTP, o único meio é o cliente de tempos em tempos enviar um GET ou POST (uma sonda) perguntando:

  • Há alguma modificação?

Mas se usa JMS, você pode registrar os clientes em um tópico e o servidor publicará as modificações quando ocorrerem.

[]s
Luca

Guerr

Valeu pela resposta!!!

Como a aplicação já é um cliente do servidor de aplicações mesmo, atualmente esta pergunta de tempos em tempos está sendo feita via acesso a EJB mesmo.

A idéia do JMS é bem interessante, porém acho que poderia gerar um número de mensagens muito grande. Precisaria testar mesmo para ver como vai ficar a performance. Como estou encapsulando este mecanismo, depois vou fazer a implementação para JMS e ver qual vai ficar mais eficiente.

Alguma outra idéia?

Chulao

Uma outra opção seria a utilização de Callbacks via EJB.

Agora não sei se essa abordagem ajuda a resolver ou a complicar o seu problema, eu precisei dessa abordagem uma vez e funcionou.

Mas em todo caso segue maiores informações:

http://www.ryerson.ca/~dgrimsha/courses/cps841/RMICallbacks.html
http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html
http://www.dca.fee.unicamp.br/cursos/PooJava/objdist/javarmi.html
http://www.cs.mcgill.ca/~cs577/project/rmiIntro/rmiintro.html

T+

Guerr

Valeu Luca!! A idéia do JMS funcionou 100%!!!

Esta idéia do Callback também é bem legal!!! Vou ver se crio também esta implementação! Obrigado pelos links!

Guerr

Valeu também Chulao! A abordagem do Callback RMI também funcionou muito bem!!!

Estou agora com 3 implementações funcionando na mão:

  • Uma thread que chama um método de um EJB para buscar as mudanças periodicamente.
  • A notificação dos clientes via JMS
  • A notificação dos clientes via Callback RMI

Este é o tipo de coisa que costuma dar problema em ambiente de produção devido a carga e problemas inexperados como queda de rede e etc… Vou experimentar cada um deles e caso tenha algum problema, eu coloco aqui para ficar registrado!

Grato a todos pelas contribuições!!!

mister_m

Guerr@:

Este é o tipo de coisa que costuma dar problema em ambiente de produção devido a carga e problemas inexperados como queda de rede e etc…

Uma implementacao decente de JMS configurada direitinho com topicos durable e ack eh quase 100% a prova de falha. Existe o delay, como em qualquer solucao, mas eh certeza que o client vai receber a notificacao, mais cedo ou mais tarde.

Guerr

Cara, nós temos uma aplicação que roda em uma WAN (que é extremamente instável) e utiliza o SonicMQ. A quantidade de erros e instabilidades que tivemos que tratar foi absurda e a carga excessiva de mensagens causava leak de memória no servidor. Hoje funciona tudo redondinho, mas demorou um tempinho…

Acredito que a implementação com JMS neste caso é a mais adequada, principalmente porque a aplicação vai rodar dentro de uma LAN bem mais instável. Porém neste caso eu prefiro ser mais tipo São Tomé e fazer o teste em ambiente de produção para ver se vai dar problema…

Criado 4 de dezembro de 2006
Ultima resposta 6 de dez. de 2006
Respostas 7
Participantes 4