Atenção: esse artigo tem um vídeo complementar. Clique e assista!
Uma “introdução moderna” à JMS (inclusive MDB), escrita principalmente para o leitor que ainda não se aventurou com a API de mensageria da plataforma Java EE. Mostramos como programar a JMS com a versão mais recente do Java EE, o que deve tornar o artigo interessante também como atualização para quem já o fez em versões anteriores da plataforma.
Para que serve:
A JMS (Java Message Service) permite a comunicação assíncrona entre aplicações, utilizando dois modelos básicos de conectividade:
1) Filas ponto-a-ponto (queues), onde mensagens submetidas por uma aplicação “produtora” são entregues a uma única aplicação “consumidora”. Pode haver vários consumidores conectados à mesma fila, neste caso somente um deles receberá cada mensagem;
2) Canais publish/subscribe (topics), onde cada mensagem pode ser recebida simultaneamente por diversas aplicações consumidoras.
Em que situação o tema é útil:
Para o leitor que está dando seus primeiros passos com mensageria assíncrona / JMS, ou interessado em novidades da plataforma Java EE 6 (por exemplo, Contexts and Dependency Injection). Para quem ainda não se interessou por mensageria JMS, procuramos apresentar uma motivação. Finalmente, abordamos também as últimas atualizações sobre o status das tecnologias da Sun após a aquisição pela Oracle.
Em comparação com middlewares síncronos (como EJB), a JMS proporciona baixo acoplamento entre produtores e consumidores, pois estes não precisam estar diretamente conectados, nem precisam estar executando ao mesmo tempo – mensagens podem ser armazenadas nas filas/topics por algum tempo (indefinido ou limitado) enquanto não são lidas por alguém. A comunicação assíncrona tem vantagens bem conhecidas; facilita criar aplicações com características como:
• Alta concorrência: a comunicação síncrona A®B implica que a aplicação A não precisa ficar parada enquanto B recebe uma mensagem e executa algum processamento; portanto, há maior potencial de paralelismo, especialmente no lado do produtor;
• Tolerância a falhas: se a aplicação B ficar temporariamente indisponível ou talvez sobrecarregada, isso não impede A de funcionar, nem mesmo deixa A com alguns recursos importantes (como um thread, conexão com database etc.) bloqueados inutilmente enquanto aguarda B – o que tende a reduzir a carga e o risco de falhas também no servidor de A;
• Escalabilidade e balanceamento: transações complexas que envolvem vários sistemas são naturalmente divididas em fatias pequenas e independentes, permitindo à infraestrutura (containers Java EE, JMS, monitor de transações, software de clustering) conseguir melhor paralelismo e ocupação eficiente de recursos.
Existem ainda outras características interessantes, como facilidade de monitoração (é fácil capturar e analisar as mensagens trocadas entre as aplicações), e interoperabilidade com web services (mensagens XML podem ser encapsuladas em mensagens JMS). Na comparação com os web services, a mensageria JMS tem maior desempenho (permite trafegar dados binários entre outras vantagens) e permite implementar transações distribuídas (operações de envio e recepção de mensagens podem participar de uma transação XA, sendo passíveis de rollback).
Este artigo tem uma abordagem totalmente prática; para mais detalhes sobre a API e mensageria, bem como uma abordagem alternativa de programação, veja o artigo online de Fábio Augusto Falavinha na Edição 76: “JMS na prática com Spring e ActiveMQ”.
Neste artigo, vamos explorar a programação da JMS, com uma abordagem prática, atualizada, e focada nos fundamentos – mas utilizando a versão mais recente da plataforma Java EE. Recomendo ao leitor acompanhar o tutorial com o NetBeans 6.9 e Glassfish 3.0.1, mas todo o código poderá ser utilizado em qualquer IDE e container com suporte à plataforma Java EE 6.
Configurando as filas
O Glassfish contém um servidor JMS embutido, o que facilita nosso trabalho: uma vez instalado o NetBeans com suporte a Java EE e Glassfish, está tudo configurado. Só precisamos criar os recursos de JMS que serão usados pela aplicação.
Comece entrando no console de administração do Glassfish, que por default fica em localhost:4848. Vá primeiro em Recursos > Recursos JMS > Fábricas de Conexões > Novo; entre com Nome do Grupo = “jms/CF”, Tipo de Recurso = javax.jms.QueueConnectionFactory; confirme com OK. Agora você já tem uma QueueConnectionFactory, que é o objeto primário de interação com a JMS – como indica o nome, permite fabricar conexões com filas.
Em seguida, acione Recursos > Recursos JMS > Recursos de Destino > Novo; entre com Nome JNDI = “jms/Quotes”; Physical Destination Name = “Quotes”; Tipo de recurso = javax.jms.Queue. Você tem agora uma Queue, a fila que será usada para o tráfego de mensagens. Veja o quadro “Filas e Recursos JMS” para mais detalhes.
O primeiro contato com a JMS às vezes causa alguma confusão entre “filas do servidor” e “filas físicas”. Na nossa configuração do Glassfish, ao criarmos uma fila, temos que preencher dois campos distintos: um é o nome JNDI da fila (“jms/Quotes”), o outro é um Nome do Destino Físico (“Quotes”). Este último é a verdadeira fila, e (a princípio) não reside no container Java EE e sim num servidor JMS. No caso do Glassfish, o servidor JMS é embutido; mas em outros ambientes pode ser um processo separado.
Devido à integração entre o Glassfish e seu servidor JMS (Open Message Queue –mq.dev.java.net), podemos examinar a fila no console de administração, como mostra a Figura Q1. Cada fila possui alguns parâmetros que controlam seu desempenho e comportamento. Os valores default serão OK para a maioria das aplicações.
Aquele recurso de nome “jms/Quotes” que você criou em Recursos de Destino > Novo não é uma fila, é apenas uma proxy para a fila. Além de fornecer um nome JMS à fila, este recurso pode ter capacidades próprias – no caso, temos uma opção de desabilitar a fila; note que se esta opção for usada ela só afeta aplicações que usem este recurso para chegar à fila física “Quotes”. A fila em si não é desativada.
...
