Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy Java Magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Troca de Mensagens com JMS - Revista easy Java Magazine 20
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.
Easy Java Magazine 20
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy Java Magazine 20
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Easy Java Magazine 20
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.
"
Este é um post disponível para assinantes MVP
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.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Easy Java Magazine
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Marcio Ballem De Souza
Marcio Ballem de Souza é bacharel em Sistemas de Informação pelo Centro Universitário Franciscano em Santa Maria/RS. Tem experiência com desenvolvimento Delphi e Java em projetos para gestão pública e acadêmica. Possui certificação em Java, OCJP 6.
O que você achou deste post?
3 COMENTÁRIOS
Andre Batista De Andrade.
Meus Parabens Marcio Ballem,
O Assunto e de suma importância para queM trabalha com integração entre sistema, bem fiz um teste aqui seguindo os passos tudo blz mais não sei se no post faltou a questão do log4j-xxxxx.jar pois quando executei deu um problema e no caso add o arquivo jar mencionado e executou normal.
No mais isso mesmo, mas o poste está muito bem documentado e de forma simples.
O Assunto e de suma importância para queM trabalha com integração entre sistema, bem fiz um teste aqui seguindo os passos tudo blz mais não sei se no post faltou a questão do log4j-xxxxx.jar pois quando executei deu um problema e no caso add o arquivo jar mencionado e executou normal.
No mais isso mesmo, mas o poste está muito bem documentado e de forma simples.
[há +1 mês] -
Responder
[autor]
Marcio Ballem De Souza
Olá André, legal saber que você gostou do artigo.
Sobre o jar do log4j o maven deveria ter adicionado ele como dependência do org.slf4j.
Mas menos mal que você conseguiu resolver.
Obrigado novamente.
Sobre o jar do log4j o maven deveria ter adicionado ele como dependência do org.slf4j.
Mas menos mal que você conseguiu resolver.
Obrigado novamente.
[há +1 mês] -
Responder
Thales Ramalho De Souza
Olá,
Há algum problema com o video??? Não estou ouvindo nada.
Há algum problema com o video??? Não estou ouvindo nada.
[há 3 dias] -
Responder
Cursos relacionados
Publicidade
