Concrete Logo
Hamburger button

Amazon SQS x JBoss HornetQ

  • Blog
  • 4 de Setembro de 2012
Share

Uma das grandes questões envolvidas a respeito de uma aplicação em nuvem é:

    Como criar uma aplicação capaz de enviar mensagens assíncronas para outros componentes da nuvem e garantir a recepção correta dessas mensagens.

 
Certamente, uma das soluções mais adequadas para isso é o uso de mensageria, especialmente quando se trata de desenvolvimento Java, posto que a solução padrão para esse tipo de problema é o uso de JMS.

Este blog já teve vários posts sobre mensageria. Veja blog da Concrete – categoria mensageria e abordou mensageria com Java em API Java JMS – parte 1. Dizem que um dia sairá a parte 2…

No entanto, no caso do Amazon AWS, existe uma solução especial para isso, o Amazon Simple Queue Service, ou simplesmente Amazon SQS. Está pronta para endereçar os problemas mais comuns e com a alta disponibilidade característica de uma solução em nuvem.

Para quem programa em Java (e também para quem programa em outras linguagens), certamente uma das soluções mais atraentes para isso é o JBoss HornetQ. Trata-se de um Message-Oriented Middleware que quebrou vários recordes em termos de performance. Isto por sí só o torna muito atraente em termos de software mantido em datacenters próprios.

O que veremos a seguir é um comparativo dessas duas tecnologias, em ambientes de nuvem.

 

Amazon SQS

O SQS é o sistema de mensageria mantido nos próprios datacenters Amazon AWS.

Isso faz com que ele compartilhe características do Amazon EC2, como a alta disponibilidade, possibilidade de se criar uma VPC, alta segurança, etc. Toda a administração do SQS é feita através do próprio console Amazon e como o próprio nome diz, é realmente muito simples de gerenciar e utilizar.

Exemplo de EC2 e SQS trabalhando junto

 
A comunicação com o SQS pode ser feita inteiramente através de requests REST-like.

Possui também uma API em Java disponibilizada através do Amazon SDK com vários exemplos sobre como usar o serviço. Essa interface pode ser interpretada por um WSDL (sim, você leu corretamente), para que um client “ao gosto do freguês” possa ser criado – o que possibilita, por exemplo, o consumo através de ferramentas como BPEL.

O sistema de segurança também é bastante interessante, podendo limitar as mensagens para um determinado cliente por tempo. Isto pode ser uma boa pedida em caso de software SaaS.

No entanto, o SQS mostrou que pode ser muito diferente de uma API nativa Java a começar pelo fato de que não é JMS-compliant. Essa diferença contrasta com ambientes integrados via Spring que facilitam o recebimento de mensagens:

    Uma configuração no JmsContainer faz com que as mensagens sejam recebidas automaticamente.

Isto é um empecilho no caso do SQS que exige solicitar explicitamente que as mensagens sejam entregues.

Além disso, o SQS não conta com os modos de recepção provisionados pelo JMS como reconhecimento (acknowledge) automático de recepção, manual ou lazy (lazily acknowledge). É necessário que o cliente apague a mensagem recebida através de uma requisição, o que pode se tornar complicado num ambiente transacional.

Ainda não existe uma definição formal de “fila” ou “tópico” no SQS: caso o cliente queira algo como um tópico, deve programar explicitamente um controlador de tópicos, o que pode ser bastante trabalhoso.

A recepção de mensagens não conta com os filtros de recepção comuns em JMS. Essas mensagens só podem ser trafegadas em modo texto e são limitadas a 64KB (caso o cliente precise trafegar algo como uma imagem, por exemplo – codificada em Base64 – a Amazon sugere que a mesma seja salva no S3 e que ao invés de trafegar a imagem, trafegue apenas a referência a ela).

Por isso, é altamente recomendado que as mensagens trafegUem como XML, JSON ou outro formato de fácil interpretação por parte da linguagem que se escolher utilizar – o que, no entanto, aumenta o overhead de interpretação.

Esse é o console para gerenciamento do SQS e visualização das mensagens. Simples e limitado assim.

SQS

 

JBoss HornetQ

O HornetQ é o sistema de mensageria “default” da pilha do JBoss. Como já mencionado anteriormente, ele é conhecido por ter quebrado vários recordes de performance e é JMS-compliant. Isto traz uma série de benefícios:

    – suporta integração com transações distribuídas (XA),
    – oferece seletores de mensagens,
    – é facilmente integrável com frameworks como Spring (além de ser incluído nativamente no JBoss AS 7),
    – trafega mensagens nos formatos oferecidos pela especificação, ou seja, bytes, mapas, objeto Java, uma stream ou texto simples. Sem contar que pode persistir essas mensagens por tempo indefinido.

Como adicionais, ele também oferece uma interface REST (não conta com WSDL ou WADL), possibilitando que clientes não-Java utilizem o mesmo normalmente.

hornetq-api

As principais diferenças entre o HornetQ e o SQS baseiam-se no fato de que o primeiro não é feito nativamente para rodar em ambiente de nuvem, enquanto o segundo é. Isto traz a questão de que a administração de um cluster HornetQ precisa ser feita via JMX ou quando utilizando JBoss AS 7, pela interface gráfica ou pela CLI do Application Server em questão.

Além disso, um cluster HornetQ pode ser complicado de se colocar em nuvem, pois os nós do cluster trabalham em modo de descoberta e operação através de multicast. Por todas essas questões, pode custar particularmente caro manter um cluster desse tipo (em contrapartida ao SQS).

Console administrativo do JBoss AS 7 / HornetQ

JBoss

 

Tabela comparativa

/ HornetQ SQS
Interface REST Sim Sim, com WSDL
Cluster Sim Nativo
JMS-compliant Sim Não
Administração Via JMX ou CLI/interface gráfica JBoss AS 7 Via console Amazon
Custo Tende a ser caro Tende a ser barato
Segurança Através de mecanismos nativos e JAAS Através de políticas definidas no console administrativo
Tipos de mensagem suportados bytes, mapas, objeto Java, stream ou texto simples Texto (limitado a 64KB)
Persistência da mensagem Por tempo indefinido Até 14 dias
Exemplos de uso Sim, junto do download do HornetQ Sim, no plugin para Eclipse

 

Conclusão

O Amazon SQS é uma alternativa muito convidativa para envio e recebimento de mensagens simples, porém com grande necessidade de escalabilidade horizontal. Já é conhecido de todos que a infraestrutura do Amazon AWS é sem dúvidas uma das melhores que existe trazendo grande confiabilidade para esse mecanismo.

No entanto, caso seja necessário um cluster com mais detalhamento na recepção de mensagens, é recomendado utilizar um sistema JMS. Neste caso o HornetQ é, sem dúvidas, um dos melhores existentes na atualidade.