CHAT - JMS

com Cassio Camilo

Guapo > Bom pessoal, já está na hora de iniciar o chat
Guapo > o Cassio já está aqui conosco
Guapo > alguém quer fazer alguma pergunta?
CassioCamilo > Bom, gostaria de dizer que é um prazer estar aqui com vocês, batendo um papo sobre a API JMS.
FranklinSamir > Cassio, pode citar em que tipo de aplicações vc usa JMS no dia dia?
CassioCamilo > Franklin, ja tive experiências, mas nada comercial. O uso ainda é pouco difundido.
CassioCamilo > Mas está crescendo.
FranklinSamir > é por isto q perguntei.
CassioCamilo > Recentemente tivemos o lançamento de um livro sobre o assunto (que foi divulgado na MundoJava) e acho q agora as coisas começam a caminhar.
Guapo > eu sei de vários sistemas usando JMS em instituições financeiras
FranklinSamir > Vi poucas aplicações reais. Eu diria até q JMS é das tecnologias mais conehcidas e menos usadas.
Guapo > os bancos usam bastante porque muitos já usam há algum tempo frameworks de mensagens
FranklinSamir > Guapo, a única aplicação q conheço usando JMS para valer é de um banco... o Sicredi
Guapo > trabalhei no HSBC e lá tínhamos vários sistemas que usavam JMS
FranklinSamir > Parte deste sistema do HSBC é desenvolvido aqui do meu lado mas nunca tive contato.
CassioCamilo > Mas existem sim, grandes sistemas. O diferencial é que ela é muito usada para EAI. E isso só vemos em grandes coorporações...
guest190532 > Parabens pela reportagem, está bem completa e acessível.
Guapo > o que acho interessante na API é que trabalhar com Mensagens permite arquiteturas bastante robustas
Guapo > e bastante elegantes
Guapo > desacopladas
CassioCamilo > Isso é verdade! O processo assincrono facilita muito as coisas!
Guapo > Vejam o próprio exemplo que o Cassio deu no artigo
Guapo > se fosse feito com outra tecnologia as coisas seriam muito mais complicadas, certo Cassio?
CassioCamilo > Exatamente. Para se ter uma idéia. O Provider já me fornece uma série de serviços...
CassioCamilo > que facilitam a vida do desenvolvedor.
CassioCamilo > A questão da entrega das mensagem, armazenamento, rollback. Tudo transparente.
Guapo > O artigo traz um exemplo de apuração de eleições em Urnas
CassioCamilo > Isso. Os diversos usuário(eleitores) mandam o seu voto para uma determinada urma. Ao final da eleição, um aplicativo acessa a Queue e busca os votos.
RodrigoUrubatan > boa arquitetura :D e não fica pesando um servidor durante a votação com o que só precisa processar depois :D
CassioCamilo > Apesar da grande vantagem da API JMS, existe uma corrente que é contra. Não por negar o seu potencial..
CassioCamilo > Mas por acharem que a forma de programação.
CassioCamilo > é muito estruturada para o modelo Pub/Sub.
RodrigoUrubatan > mas o problema da API pode ser facilmente mascarado utilizando alguma API de mais alto nivel para fazer a interface com JMS
tanquetav > Tenho uma duvida quanto as tais Poison Messages ...
tanquetav > Uma vez implementei via JMS um sistema para despachar email, caso meu servidor de email estivesse com problema
tanquetav > nao perderia a mensagem nem travaria o cliente.
tanquetav > Porem quando dava erro no servidor ficava dando loop, a mensagem nao tinha um tempo de espera
tanquetav > Ai descobri que o tempo de espera nao eh algo padronizado. Achei isso extremamaente chato
CassioCamilo > É verdade. Você pode setar o timelife da mensagem, mas problemas podem ocorrer ainda! Com relação as medidas tomadas pelo Provider, a coisa é mais complicada.
CassioCamilo > A especificação não estabelece um tempo padrão (como vc disse) o q faz com q cada Vendor tenha um solução diferente.
tanquetav > Acho que deveria ter mais coisa em relacao a configuracoes das filas dentro do padrao, acho uma outra grande falha da SUN
tanquetav > como esses timeout, numero de tentativa
CassioCamilo > é... por um lado isso seria extremamente útil. Mas não podemos esquecer que a idéia da SUN é de criar uma especificação apenas. E deixar que a coisa corra livre!
CassioCamilo > Isso tem seu lado bom, mas com vemos, tem o ruim também!
CassioCamilo > Sobre a sua aplicação... quais foram as dificuldades de implementação?
tanquetav > Olha, foi bem tranquilo, ate pela simplicidade da funcionalidade
tanquetav > A unica coisa chata realmente foi que nao resolveu meu problema
cvillela > lembrando, claro, que o JCP eh uma entidade aberta, e que se vc precisa _mesmo_ de alguma coisa inclusa na spec, eh soh fazer barulho
CassioCamilo > Bem lembrado cvillela!
tanquetav > cvillela: para ser incluso daqui uns 5 anos, provavelmente. Muito burocratico o JCP
cvillela > tanquetav: bom, nao vamos entrar nesse merito ;)
tanquetav > ok
cvillela > Com que implementacoes de JMS voces tem brincado?
tanquetav > eu testei o jbossmq e o da weblogic
CassioCamilo > Bom, inicialmente usei a RI da própria SUN(iQM se não me engano!) para aprender. Depois passei para o JBossQM.
CassioCamilo > Como trabalho com o JBoss no dia a dia, já fui direto nele!
cvillela > nenhum relato do ActiveMQ? :)
Guapo > ActiveMQ?
cvillela > guapo: activemq.codehaus.org
cvillela > posso estar completamente enganado, mas acho que vai ser a implementacao de JMS do Geronimo
Guapo > vi o site, interessante!
RodrigoUrubatan > é o que ta escrito no site do geronimo, que vão usar o activemq mesmo
CassioCamilo > A grande vantagem das especificações é o fato de não ficarmos preso apenas a um AS. Usamos Geronimo, depois JBoss, e por ai vamos!
cvillela > (ainda bem, pq se ficassemos presos no JBoss, eu voltava pro C++...)
Guapo > acho interessante também a possibilidade de integração com sistemas legados
Guapo > aliás, alguém já integrou via JMS co MQSeries ou similar?
cvillela > guapo: eu ja... foi meu primeiro projeto em Java, alias :)
cvillela > o MQSeries eh... digamos... temperamental, mas extremamente robusto, depois que ta funcionando
CassioCamilo > cvillela, vc notou alguma mudança de comportamento por parte da aplicação, após a integração?
cvillela > mudanca de comportamento? hmm, nao, pra falar a verdade ela ficou mais calma :D
cvillela > ta, brincadeira de lado, eu nao entendi a pergunta
CassioCamilo > :) ! Boa. Assim, se você teve problemas de overhead na comunicação dos sistemas? ou ficou tudo bem homogênio.
cvillela > ah, o overhead nao foi suficiente pra causar nenhum problema, mas que ele existe, existe... afinal JMS tem todo aquele bafafa de garantia de entrega (e o MQSeries, mais ainda) que o SPL-SPC nao tem
Guapo > Na opinião de vcs, quais seriam exemplos de aplicações para usar JMS?
cvillela > qualquer aplicacao tem um pouquinho de assincronia
CassioCamilo > Acho q em primeiro lugar, aplicações de integração. Depois aquelas com necessidade de desacoplamento e de fácil substituição das interfaces.
tanquetav > Acho que uso de JMS em aplicacoes envolvendo interacao com o usuario eh um pouco complicado
tanquetav > o usuario adora ver a resposta NA HORA
cvillela > tanquetav: nem tanto... voce pode usar JMS como um jeito mais "EE" de fazer Futures
RodrigoUrubatan > o usuário adora ver respostas na hora, é verdade
cvillela > explicando um pouco melhor... queries sao sempre síncronas, mas as atualizacoes podem ser assincronas, e a aplicacao só "espera" por ela quando alguma query esta envolvida
cvillela > (claro, eh muito mais facil falar do que fazer, mas o Eclipse, por exemplo, usa isso pra todo lado na versao 3)
tanquetav > acharia excelente usar JMS para relatorios pesados
tanquetav > Ate para evitar uma penca de relatorios pesados simultaneamente no servidor
CassioCamilo > é possível tirar proveito do "assincronismo" para QUASE tudo. Acho também q para determinadas aplicações, os usuário, não querem esperar pelo processamento de determinada operação. Querem apenas a resposta. Essa pode vir na hora, ou alguns minutos depois.
CassioCamilo > O leque para se usar é muito grande! Acho q o proveito ficara ainda maior quando mais atribuições forem feitas ao Provider. Como é o caso do Container EJB.
cvillela > hmm, alias, nao sei se ja levantaram essa questao
cvillela > mas voces nao acham JMS uma api "pesada"?
tanquetav > Eu nao acho nao
Guapo > A API? acho que não, mas o provider...
Guapo > você acha villela?
CassioCamilo > Hmm, não vejo muito assim não... Até pq a API é bem enxuta.
cvillela > pesado no sentido de "dificil de testar"
tanquetav > Acho que independente da API, a propria natureza assíncrona do negócio é um empecilho
tanquetav > fazer um unit test deve ser praticamente inviavel
Guapo > hhmmm, entendi
tanquetav > confiar num sleep e esperar a resposta de um MDB por exemplo, é sem noção
CassioCamilo > Talvez o processo de homologação das aplicações se torne complicado, mas o teste não. Depois de armado o terreno, acho que fica tranquilo.
cvillela > unit test ate que nao é difícil
cvillela > mas integration test é bem mais chato
CassioCamilo > Os testes de integração seriam um pouco complicado mesmo.
CassioCamilo > Mas isso tende a melhorar! Vale lembrar que a API já está a um tempo no mercado e só agora vem ganhando admiradores, ou despertando o interesse para concorrentes e melhorias!
Guapo > OK pessoal, estamos chegando ao fim do horário do chat
Guapo > Gostaria de agradecer a participação de todos
CassioCamilo > Gostaria somente de dizer obrigado a todos. Qualquer dúvida estaremos por perto!
Guapo > Obrigado Cassio
CassioCamilo > Foi um prazer.