Artigo Java Magazine 37 - Introdução ao JMS

Introdução ao JMS

Primeiros passos com Java Message Service utilizando o JBoss

Conceitos e motivação para middlewares de mensagens, e quando e como usar o JMS com o servidor de aplicações Java EE livre mais popular do mercado

A API JMS é uma das mais estáveis de todo o Java EE. A versão 1.1 não teve atualizações desde os tempos do Java EE 1.3, o que atesta sua maturidade e funcionalidade. Infelizmente os desenvolvedores que tiveram sua formação em microinformática, longe dos grandes CPDs corporativos e seus mainframes, provavelmente nunca foram expostos a algo similar ao JMS, que fornece um messaging middleware (middleware de troca de mensagens, ou apenas middleware de mensagens) e deixam de usufruir das vantagens e possibilidades oferecidas por essa tecnologia.

O JMS é um componente central na arquitetura de grandes aplicações web, onde há necessidade de atender a requisitos extremos de performance, escalabilidade, manutenibilidade e segurança. Mesmo componentes EJB e Web Services não oferecem os mesmos benefícios do JMS nestes quesitos. E o melhor de tudo, a API é bem simples, fácil de aprender, e as configurações necessárias em um servidor de aplicações Java EE são igualmente simples.

Este artigo apresenta uma introdução ao JMS, com exemplos básicos, e demonstra como rodar os exemplos no JBoss 4 (mas acreditamos que todos os exemplos funcionem sem modificações em qualquer versão desde a 3.0.8).

Alguns desenvolvedores acreditam erroneamente que seja necessário usar EJB para usufruir do JMS, talvez por causa da existência dos Message-Driven Beans, atrelados ao JMS na especificação EJB. Na verdade, o serviço e as API do JMS são totalmente independentes dos EJBs. Pode-se fazer uma analogia com os Entity Beans, que permitem persistência em bancos de dados via JDBC, mas nada impede o desenvolvedor de usar JDBC diretamente, sem passar por EJBs. Reforçando esta independência entre o JMS e EJBs, os exemplos de código neste artigo serão de clientes JMS independentes, e não EJBs.

Porque usar messaging middlewares

Quem já fez uma compra em sites como amazon.com deve ter percebido que, logo após o checkout (confirmação da compra), é enviado um e-mail confirmando os detalhes da compra, a forma de pagamento e o endereço de entrega. Algum tempo depois, que pode variar de alguns minutos a algumas horas, é enviado um segundo e-mail confirmando as mesmas informações.

É fácil entender o motivo do primeiro e-mail: fornecer ao comprador um registro da operação realizada, e também uma oportunidade de contestar qualquer erro, ou informar a possibilidade de fraude (ex.: outra pessoa fez uma compra usando o seu e-mail). Mas o segundo e-mail parece um tanto redundante.

O usuário mais atento, no entanto, irá perceber que o texto no segundo e-mail é um pouco diferente, e verificar que é este e-mail que informa que a compra foi realmente aceita, o pagamento efetuado e a entrega agendada. Antes dele, há a possibilidade de ter havido algum problema com o pagamento (por exemplo, a operadora de cartão de crédito não aprovou o crédito), com a compra (algum dos itens não está disponível em estoque, e terá que ser entregue mais tarde) ou com o envio (um endereço no interior pode demorar mais e custar mais caro para os correios).

Muitos visitantes pensam que sites como Amazon (e outros portais de comércio eletrônico) processam as compras de forma on-line. Mas na verdade eles apenas registram o pedido. Outro sistema, operando na retaguarda da loja virtual, é quem efetivamente processa a ordem de compra. Isto traz para o site vários benefícios:

·Tempo de resposta menor: Como o registro do pedido não tem que aguardar pelo OK da instituição financeira que fornece o crédito, nem pelo OK da empresa que realmente fornece o produto (já ouviu falar de “lojas sem estoque”?), o site pode responder ao comprador de forma bem rápida. E o comprador sai satisfeito com um “OK, sua compra foi efetuada” que na verdade significa apenas “sua compra foi registrada, mais tarde iremos processá-la”. Pense na quantidade de sistemas ou bancos de dados que teriam que ser acessados para confirmar uma ordem de compra, e no tempo de resposta que isto iria gerar sob um grande volume de compras simultâneas.

·Maior volume de transações por dia: É sempre mais eficiente agrupar operações para execução conjunta, em batch, do que executá-las uma a uma sob demanda. O batch permite otimizar operações de rede, de disco e de processamento. Então o mesmo hardware pode sustentar uma carga de trabalho maior se for possível “atrasar” algumas operações para realizá-las depois em conjunto. Por exemplo, em vez de enviar pedidos isolados de validação de crédito para uma operadora de cartão de crédito, são enviados pedidos para validar de uma só vez dezenas de contas diferentes.

·Tolerância a falhas: A loja virtual não controla os sistemas das instituições financeiras, dos produtores de mercadorias, nem dos correios e outras empresas que fazem a entrega (couriers). Se algum deles estiver indisponível, ou momentaneamente saturado, o processamento em batch pode ser re-executado mais tarde, sem que o comprador tome conhecimento disto. Então a loja não deixa de vender por causa de problemas de comunicação ou problemas locais nos sistemas das outras empresas.

·Segurança: Uma vez que o sistema da loja virtual não necessita de acesso direto aos bancos de dados de estoques, agendamento de entrega etc., e sim apenas a um banco de dados onde é registrado o pedido de compra (é aqui que entra o " [...] continue lendo...