Como implementar a troca de mensagens com JMS

Java Message Service, ou simplesmente JMS, é uma API Java EE lançada em 1998 pela Sun Microsystems. Aproximadamente 15 anos depois, a API JMS quase não sofreu atualizações em seu projeto inicial, o que é justificado por sua estabilidade e maturidade.

Mas que tipo de serviço é oferecido por esta API? O objetivo principal do JMS é realizar a comunicação entre sistemas através de mensagens. Estas mensagens são produzidas por um JMS Producer, enviadas e armazenadas em um JMS Provider e consumidas por um JMS Consumer. Tais mensagens podem ser armazenadas em um sistema de filas (Queue) ou em um sistema de assinaturas chamado de tópico (Topic), dependendo da necessidade de cada projeto. Outra característica presente no envio de mensagens é a possibilidade delas serem enviadas de maneira síncrona (produtor e consumidor ativos ao mesmo tempo) ou assíncrona (produtor ativo e consumidor desativado). Como as mensagens são armazenadas em um provider, a configuração de seu envio pode ser feita de tal forma que elas fiquem armazenadas no provedor mesmo que o consumidor não esteja sendo executado naquele momento. As mensagens ficariam então armazenadas até que o consumidor fosse ativado e as consumisse. Talvez a principal vantagem deste serviço seja a garantia de que a mensagem será entregue.

Um serviço JMS pode ser usado, por exemplo, como um sistema de chat (bate-papo), como um sistema de confirmação entre serviços ou como um sistema de integração, muito usado para sincronização entre bancos de dados. Pode ser aplicado também para executar tarefas assíncronas em ambientes de cluster, evitando qualquer tipo de duplicação de tarefas que possam vir a ocorrer em consequência das diferentes máquinas virtuais. Alguns sistemas de comércio eletrônico, por sua vez, utilizam mensagens JMS para tratar as operações de compra de um produto pelo consumidor, a análise de crédito deste consumidor junto à operadora de cartão de crédito e também a confirmação de disponibilidade de entrega pela empresa de frete. Os sites destas lojas virtuais apenas apresentam os produtos e recebem os pedidos de compra, enquanto mensagens são geradas com os dados das compras e enviadas para uma ou mais aplicações que processam tais informações de forma externa ao sistema do site. Isso garante ao site um tempo de resposta menor aos acessos, maior segurança e maior volume de transações diárias.

Com base nisso, este artigo abordará os principais conceitos da API JMS, e como exemplo prático, teremos o desenvolvimento de uma aplicação produtora e uma aplicação consumidora de mensagens que se comunicarão com o provider Apache ActiveMQ.

JMS Provider

O JMS Provider é uma aplicação servidora que fornece, além do armazenamento de mensagens, o controle e a administração dos serviços disponibilizados pela tecnologia JMS. O mercado de aplicações JMS é bastante concorrido, tendo inúmeros provedores disponíveis, sendo eles comerciais ou open source. Eles podem ser encontrados de duas formas, no modo chamado standalone como também embutidos em um Java Application Server (Java AS).

Como exemplo de providers standalone temos o Apache ActiveMQ, Joram, HornetQ, OpenJMS, entre outros. Já no modo Java AS temos, por exemplo, no JBoss o HornetQ, no JOnAS o Joram e no Apache Geronimo o ActiveMQ. Servidores como GlassFish, WebSphere e WebLogic também fornecem serviço JMS, o que não acontece com containers web como o Apache Tomcat e o Jetty.

Mesmo quando se usa um Java AS como armazenamento JMS, não existe a necessidade das aplicações, tanto produtoras como consumidoras, estarem armazenadas no Java AS. A comunicação entre aplicação e provedor é realizada por meio de um protocolo de comunicação, de um endereço IP e uma porta de serviço. Essa comunicação não padroniza um único tipo de protocolo de comunicação, como também, não padroniza a porta de serviço. Por conta disso, haverá diferença entre provedores distintos, já que cada um deles define a sua própria configuração de acesso.

Clientes JMS

Existem dois tipos de clientes JMS, a aplicação produtora e a aplicação consumidora. Os clientes consumidores podem consumir mensagens de forma assíncrona ou síncrona, de acordo com a especificação ou necessidade do sistema.

As aplicações de envio e consumo de mensagens podem ser implementadas, por exemplo, com código Java puro, através da especificação EJB ou com auxílio de um framework que disponibilize algum recurso JMS como o Spring. A implementação de um cliente é baseada em três grupos de interfaces que fazem parte da API JMS, como podemos verificar na Tabela 1.

Tabela 1. Os três tipos de interfaces JMS.

As interfaces da coluna JMS Common possibilitam o envio e o consumo de mensagens tanto do tipo filas como tópicos. Já o grupo Queue Domain é específico para a implementação de filas, enquanto o Topic Domain se limita à implementação de tópicos.

As mensagens JMS

Uma mensagem, mesmo que contenha como conteúdo a simples frase “Hello World!”, possui ainda várias informações geradas pela própria API, ou mesmo outros dados informados pelo usuário. Isto ocorre porque toda mensagem JMS é dividida em três partes (ver ...