Como implementar a troca de mensagens com JMS

O artigo aborda conceitos sobre a API Java Message Service (JMS) e apresenta um exemplo prático de construção de um produtor e um consumidor de mensagens JMS, utilizando o provedor Apache ActiveMQ.

Do que se trata o artigo:

O artigo aborda conceitos sobre a API Java Message Service (JMS) e apresenta um exemplo prático de construção de um produtor e um consumidor de mensagens JMS, utilizando o provedor Apache ActiveMQ.

Em que situação o tema é útil:

O sistema de mensagens Java, ou JMS, é útil para o desenvolvimento de aplicações que necessitem realizar algum tipo de troca de dados como integração entre sistemas, aplicações de confirmação de serviços, entre outras, o que passa a ser muito simples com o uso desta API.

Resumo DevMan:

A Java Message Service, especificação JSR-914, tem como objetivo o processo de troca de mensagens entre sistemas. Ela define dois padrões para o armazenamento de mensagens, Queue (filas) e Topic (tópicos). A troca de mensagens pode ser usada em projetos de integração entre aplicações, sistemas de sincronização de banco de dados, como também para um sistema de Chat. Os sistemas JMS trabalham em conjunto com JMS Providers, um tipo de servidor que realiza o armazenamento das mensagens enviadas a filas ou tópicos. O envio será realizado por uma aplicação cliente conhecida como produtor, e o consumo se dará pela aplicação cliente chamada de consumidor.

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.

"

JMS Common

Queue Domain

Topic Domain

ConnectionFactory

QueueConnectionFactory

TopicConnectionFactory

Connection

QueueConnection

TopicConnection

Destination

Queue

[...] continue lendo...

Artigos relacionados