Mensageria com JMS e ActiveMQ

Imagine que você tem um sistema de e-commerce (loja virtual), e esta loja já está funcionando e vendendo. Um exemplo dessas lojas são Magazine Luize, Americanas, Submarino, etc. Quando um cliente finaliza seu pedido de compra, finaliza seu carrinho, o sistema de e-commerce deve se integrar com outro sistema, o sistema da Sefaz para gerar a Nota Fiscal eletrônica, o sistema da NFe não faz parte do nosso sistema, da nossa arquitetura, é um outro sistema completamente independente mas necessário e importante para o nosso negócio de e-commerce para a emissão das NFe’s.

Meu sistema de e-commerce precisa ao finalizar o pedido de vendas enviar informações para outro sistema (NFe) para ser gerado e enviado as Notas fiscais eletrônicas que faz parte do nosso processo de vendas.

Então esse outro sistema, que não temos gerencia nenhuma, é um sistema essencial para o nosso negocio pois somos obrigados a enviar os dados para a emissão das NF’s, mas vamos supor que estamos num período atípico de vendas, como um Black Friday e o sistema da NFe fica lento e até chega a ficar fora do ar por algumas horas, ainda assim mesmo sem termos gerenciamento sobre o sistema terceiro, temos que guardar todos os dados das vendas geradas no período em que o sistema de NFe esteve fora do ar, e enviar posteriormente esses dados para serem processados e gerado as NFs quando o sistema terceiro retornar a funcionar.

Resumindo, meu sistema de e-commerce é totalmente dependente de outro sistema (no caso NFe) que está fora do nosso domínio arquitetural e de gerenciamento, e esse sistema terceiro pode falhar, pode estar fora do ar, e mesmo assim não podemos perder nossas vendas em nosso sistema de loja virtual por conta de uma falha de um sistema terceiro, ou seja, sempre quero que meu sistema funcione e faça as vendas independente de estar funcionando ou não o sistema de NFe.

Então seguindo a idéia de nunca perder vendas, mesmo que os sistema possa ou não emitir as NFe naquele momento exato da venda, teremos que deixar estratégicamente nosso sistema desacoplado do sistema de NFe. E que como podemos fazer isso?

Nós colocamos um bloco arquitetural no meio do nosso sistema e do sistema de NFe, uma espécie de servidor e chamamos esse bloco de middleware (que está no meio das duas ou mais aplicações). Dessa forma a loja deixa de se comunicar diretamente ao sistema de NFe, e se comunica agora com o middleware, e o middleware agora de alguma forma se comunica com o sistema da NFe.

O objetivo do middleware é desacoplar o sistema de e-commerce e o sistema de NFe, minha loja não quer saber se o sistema de NFe está funcionando ou não, passo essa responsabilidade para o middleware a qual temos o gerenciamento sobre ele estar online, garantindo o funcionamento do mesmo e garantindo a integração com nosso sistema de e-commerce.

Então nosso sistema de e-commerce vai funcionar processando os pedidos, empacotando esses dados de alguma forma, e entregar esse pedidos para o middleware em forma de mensagem, o nosso middleware vai guardar essa mensagem e em algum momento posterior vai entregar essa mensagem para o sistema de NFe.

Essa ideia de mensagem é o MOM (Middleware Orientado a Mensagem), e aqui podemos perceber duas coisas, é arquiteturalmente desacoplado a comunicação entre a loja virtual e o sistema de NFe, a loja virtual não precisa mais saber da existência do sistema de NFe, embora a existência do mesmo seja importante pro nosso negócio quem deve conhece-lo agora é o nosso middleware, e agora temos uma comunicação via mensagem na qual o middleware faz esse meio de campo para nós, entregando em algum momento depois essa mensagem para o sistema de NFe, ou seja uma comunicação assíncrona, não necessariamente no mesmo instante que foi processado o pedido de vendas.

Arquitetura desacoplada e comunicação assíncrona são características do MOM.

Como desvantagem poderíamos dizer que temos que manter mais um componente arquitetural em nossa estrutura.

Existem alguns exemplos de servidores middleware do MOM, são eles por exemplo: ActiveMQ, HornetQ, WebSphere MQ, Amazon SQS, Iron.io, JBoss Messaging, dentre outros.

Sobre Mensageria – alguns conceitos a mais

Mensageria é um dos quatro estilos de padrões de integração, os estilos são: Mensageria, RPC, File Transfer e Shared Database.

O livro mais conhecido sobre o tema é Enterprise Integration Patterns (EIP), de Gregor Hohpe e Bobby Woolf, lançado em 2003 que fala sobre os Padrões de Integração Corporativos. Fazendo um paralelo, esses padrões do EIP trazem soluções para o universo de integração entre sistemas, assim como os Padrões de Projetos trazem soluções para problemas no universo de Orientação a Objetos.

 

Instalação do ActiveMQ

Nesse artigo vamos da foco ao ActiveMQ e a sua instalação.

Acessamos o site: http://activemq.apache.org/

Na sessão Download, podemos baixar a versão mais atual ou em Getting past release podemos baixar uma versão mais antiga para ambiente windows ou linux.

Iremos baixar no nosso exemplo a versão 5.12.0 para windows, e extrair o arquivo para a pasta C:\jms\apache-activemq-5.12.0 você pode nomear a sua pasta como quiser, contanto que não tenham espaços no caminho do seu diretório para evitar problemas futuros, por isso evite também colocar em “Program Files” ou outros diretórios do windows que tenham espaços.

Para ambiente windows é necessário executar o script InstallService.bat na pasta bin/win32 ou bin/win64 dependendo da sua arquitetura.

Pelo prompt de comando do windows ou pelo terminal do seu linux navegamos no diretório até a pasta bin e executamos o comando para startar o servidor.

Windows: activemq.bat start
Linus: sh activemq start
Acessar em: http://localhost:8161/

Clica na opção Manage ActiveMQ broker, para acessar a área administrativa.

Ou acesse diretamente: http://localhost:8161/admin

User Padrão: admin
Senha Padrão: admin

Dados para Maven POM: