Integrando MRG Messaging e o JBoss ESB

Suponha que você tenha um componente EJB (um Stateless Session Bean) que forneça alguma funcionalidade de negócio que deva ser acessada por diversos canais de transporte. Conforme visto em outros artigos deste blog, usando um ESB você pode habilitar este componente EJB para escutar diversos tipos de canais que o mesmo suporte. No caso particular do JBoss ESB, você pode habilitar tal componente EJB criando um serviço interno que o encapsule (Usando por exemplo o adaptador EJBProcessor) e expô-lo usando qualquer um dos vários provedores que o mesmo suporte, tais como JMS, File, FTP, Socket, HTTP, SOAP, Hibernate, etc.

Uma estratégia interessante que pode potencializar a habilitação de um componente EJB (ou qualquer outro tipo de componente do legado) é fazer com que o JBoss ESB escute um Broker AMQP. Fazendo isso, qualquer aplicação que enviar uma mensagem para o Broker terá sua mensagem processada pelo JBoss ESB que pode, através dos seus mais diversos adaptadores, entregar a mensagem a um canal particular. A principal vantagem desta estratégia, em oposição a de que o próprio Broker entregue as mensagens, é que o ESB pode "preparar" a mensagem antes dela ser entregue. Como parte das funções de um ESB é a de fornecer mecanismos de transformação, você pode receber a mensagem pelo ESB, adaptá-la apropriadamente para ai sim, entregá-la ao canal de destino.

Neste artigo, irei mostrar como isso pode ser feito usando como Broker AMQP o MRG Messaging, e como ESB o JBoss ESB. O exemplo será baseado num cenário de negócio não muito diferente dos vividos no dia a dia de diversas empresas do ramo de telecomunicações.

Um cenário do mundo de telecomunicações

Uma dada empresa provedora de serviços de internet, tv e telefonia possui uma plataforma baseada em JEE que cuida de todo o processo de aprovisionamento de clientes. Em particular, a mesma disponibiliza um componente EJB do stipo SLSB que recebe um pedido de ativação de um ponto e configura-o junto as plataformas de engenharia da empresa.

Uma dada aplicação feita em Python precisa solicitar a ativação de um ponto do cliente diretamente neste componente EJB, mas devido as diferenças e restrições tecnológicas, isso tornou-se um problema emergente. Para contornar o problema, a empresa resolveu utilizar as facilidades que a plataforma MRG Messaging oferece quanto aos aplicações Python sobre conectividade. O programa Python foi modificado então para enviar uma requisição de ativação no formato XML para o Broker AMQP:

Repare que o programa, cria uma requisição baseada em XML que contêm o código do assinante (o campo 'customerKey'), se o cliente deseja ponto de internet (o campo 'internet'), se o cliente deseja ponto de TV (o campo 'tv') e se o cliente deseja ponto de telefone (o campo 'phone'). As informações sobre internet, tv e telefone são "flags" booleanas no estilo C++, onde "0" indica falso, e "1" indica verdadeiro. A idéia é que esta requisição seja transformada em uma requisição RMI/IIOP para o seguinte componente EJB:

Este componente EJB, possui um método chamado "executarAtivacao" que aceita um único argumento: Uma instância da classe com.redhat.mrg.demo.types.PedidoAtivacao. Segue abaixo o descritivo desta classe para conferência e implementação:

Veremos então como fazer com que a mensagem XML recebida pelo Broker AMQP seja processada pelo JBoss ESB de forma que ela seja transformada em uma chamada ao componente EJB implantando num servidor de aplicações J2EE sob o nome JNDI AprovisionadorBean/remote.

Configurando o JBoss ESB para escutar mensagens do MRG Messaging

O JBoss ESB integra de forma transparente com diversas soluções de mensageria, entre elas o ActiveMQ, JBoss Messaging, Websphere MQ e OracleAQ. Integrar com o MRG Messaging não poderia ser diferente. Basicamente, você deve configurar um provedor do tipo JMS que estabelece uma conexão com o MRG Messaging através de algum dos modelos de mensagens suportados (FanOut, Direct, Topic). Definido o provedor, você pode declarar um ou mais buses (canais de transporte) que apontam para filas internas do Broker AMQP. Segue abaixo um módulo ESB criado para o cenário proposto:

Repare que foi declarado um bus chamado "mrgChannel" que é vinculado ao serviço "AtivacaoProxyService" através do listener "mrgListener", conforme você pode ver na lista de listeners do serviço. Este serviço realiza duas transformações baseadas em Smooks (msgTrans1 e msgTrans2) que transformam a mensagem XML recebida (enviada pelo programa Python) na instância da classe com.redhat.mrg.demo.types.PedidoAtivacao que deverá ser passada como parâmetro ao EJB de aprovisionamento. O trabalho de invocar o componente EJB é feito pelo adaptador EJBProcessor, que realiza uma conexão JNDI com o servidor de aplicações e realiza um lookup do componente remoto para execução.

A primeira transformação muda o XML recebido para um documento XML que define tipos mais próximos ao Java, mudando por exemplo os flags de utilização para instâncias válidas de um java.lang.Boolean. A listagem abaixo mostra como esta transformação deve ser feita:

Foi utilizado para esta transformação um cartulho do tipo XSL que aplica um template XSLT no documento XML da mensagem. O restante da transformação fica por conta do script XSLT fornecido no cartucho. A segunda transformação é mais simples, ela apenas lê o documento XML resultante da primeira transformação e converte-o em um objeto Java:

Uma vez que a mensagem esteja no formato Java, isto é, como uma instância da classe com.redhat.mrg.demo.types.PedidoAtivacao, o adaptador EJBProcessor realiza uma invocação RMI/IIOP para o componente EJB hospedado num servidor de aplicações. Abaixo segue o screenshot da minha máquina, que mostra o exemplo sendo executado e a saída do console do servidor de aplicações:

Boas Integrações ;-)

Enterprise Messaging usando Red Hat MRG

O Red Hat MRG é uma plataforma integrada que combina alta performance, computação distribuída e mensageria inteligente baseada em padrões de mercado. Em termos práticos, MRG sigifica: Messaging, Real-Time e Grid. O MRG teve seu anúncio em dezembro de 2007, e seu lançamento oficial em 19 de junho de 2008, durante a conferência do Summit 2008. Atualmente ele se encontra na versão 1.2 e possui diversas melhorías da versão original, muitas delas voltadas a questões de segurança e certificação com plataformas de hardware e software. Neste artigo, irei mostrar como o Red Hat MRG funciona, em especial, a parte referente a mensageria baseada em AMQP. Mas antes disso, deixe-me apresentar, mesmo que suscintamente, a plataforma MRG como um todo.

Red Hat MRG

O MRG é uma proposta corporativa para trazer três caraterísticas essenciais do mundo enterprise para dentro de um sistema operacional que dispensa apresentações: Red Hat Enterprise Linux. A idéia básica é fazer com que o próprio sistema operacional RHEL tenha features relacionadas a mensageria, processamento em tempo real e processamento de CPU distribuído. Com isso, clientes de diversos segmentos como telecomunicações, finanças e governo podem realizar um único investimento muito mais estratégico, tendo uma subscrição que elimina a necessidade de licenças em produtos diferentes como por exemplo, o IBM Websphere MQ (MQSeries).

Conforme dito anteriormente, o MRG é composto de três componentes. São eles:

• Messaging: Solução de mensageria baseada no padrão AMQP e capaz de executar milhões de mensagens por segundo. A principal caracteristica do Messaging é a capacidade de receber e entregar mensagens de diferentes aplicações e linguagens, sem precisar sacrificar recursos corporativos de soluções de mensageria como garantia de entrega, transações, segurança do canal e das mensagens bem como alta performance.
• Real-Time: O real-time é o elemento responsável por dar presivibilidade no processamento de aplicações em cima do kernel do RHEL. Através de um kernel otimizado, é possível dar menor latência no processamento de cargas pesadas e ainda sim, dar um comportamento previsível do ciclo total do processamento. Do ponto de vista de aplicações Java, o real-time também possibilita um melhor aproveitamento dos CPUs quanto a execução de coletas de lixo, evitando por exemplo grandes pausas de coleta (Full GC) e deteriorização da performance com a realocação de objetos entre as gerações.
• Grid: Computação em grade não é um assunto novo, mas representa um tipo de solução que com o advento da virtualização e da computação nas nuvens possibilita crescimentos de poder de processamento em altos níveis. A principal caracteristica do Grid é possibilitar que um processamento pesado seja distribuído e coordenado entre vários nós sem que a separação físíca de CPUs seja um vilão quando performance e presibilidade sejam cruciais. Nesta apresentação, você pode perceber por exemplo, como uma renderização pode ser processada de forma mais rápida utilizando vários recursos virtuais baseados no Amazon EC2.

Para saber mais sobre o Red Hat MRG, você pode consultar on-line no site da Red Hat. Existem diversos documentos, papers e ativos sobre o MRG disponíveis. Vamos agora dar foco em ênfase a parte relacionada a mensageria do MRG.

MRG Messaging

A um certo tempo atrás, escrevi este artigo que fala sobre o protocolo AMQP. Na época, mencionei a plataforma Red Hat Messaging que seria a implementação do AMQP pela Red Hat. Atualmente, esta implementação faz parte do produto Red Hat MRG, apesar de poder ser adquirido separadamente através de subscrições exclusivas.

O AMQP possibilita que diferentes linguagens de programação possam trocar mensagens utilizando um broker que implementa as especificações ditadas pela iniciativa AMQP. Neste caso, podemos ter portanto diferentes implementações deste broker por diversos fornecedores, sem que a interoperabilidade seja sacrificada. Como analogia, pense por exemplo nas especificações do JEE, e nas diferentes implementações de servidores de aplicação, como JBoss, WebLogic e Websphere. Cada uma das soluções pertente a um fornecedor particular, mas todos eles possuem uma stack básica que é padrão (ditada por um consórcio) e que permite que as aplicações possam ser escritas de uma forma padronizada e uniforme.

Assim funciona implementações do AMQP. Você pode usar brokers de diferentes fabricantes que todos eles irão poder trocar mensagens entre si. Algumas das implementações existentes de brokers AMQP são o iMatix OpenAMQP, Red Hat MRG, Apache Qpid e RabbitMQ. Todos eles, possibilita que mensagens sejam enviadas e entregues através da mesma pilha de software, que possui implementações para linguagens diversas como Python, C++, Ruby, CSharp e claro, Java.

Porém, cada implementação possui suas especificidades, e a do Red Hat MRG com certeza é os altos níveis de desempenho e performance, bem como a previsibilidade de processamento das mensagens, graças a integração nativa com o Grid e o Real-time. As principais características do Red Hat MRG são:

• Modelos de mensageria baseados em P2P, Publish/Subscribe e Async
• Mensageria com alta disponibilidade
• Transações locais e distribuídas
• Multiplos clientes: Java, CSharp, C++, Python, Ruby, linguagens de Scripts
• Ferramentas de gerenciamento e consoles de monitoramento
• Federação de Brokers, ideal para nodos geograficamente distribuídos
• Atenticação baseada em SASL
• 4 padrões de roteamento de mensagens, incluindo XQuery
• Acesso direto a AIO para durabilidade de mensagens e Journaling
• Broker C++ otimizado para o RHEL integrado com Grid e Real-time
• E muito, mas muito mais coisas ...

Instalando o Red Hat MRG Messaging

Instalar o Messaging não pode ser mais simples quando você usa RHEL. Abra um console e entre com suas credenciais de super usuário (root). Feito isso, execute o seguinte comando:

yum groupinstall "MRG Messaging"

Este grupo de pacotes instala vários componentes do Messaging como o Broker, os stubs necessários para que clientes possam conectar no Broker e as stacks das linguagens de programação. Para quem não usa o RHEL e usa um Red Hat alternativo (Fedora, CentOS), o repositório que define este grupo não estará disponível. Neste link, você pode consultar os pacotes necessários e instalá-los individualmente.

Depois que os pacotes forem instalados, você pode verificar se tudo está correto iniciando o Broker. Para isso, abra um terminal e execute o seguinte comando:

/usr/sbin/qpidd -t

Este comando inicia o broker na porta 5672 e exibe uma série de mensagens no console (resultado do parâmetro -t de "trace") referentes as cargas e carregamentos feitos. Verifica se a mensagem "notice Broker running" aparece. Se aparecer, significa que o broker está pronto para receber e processar mensagens. Para interromper a execução do broker, basta teclar "Ctrl + C" no console. Caso a porta 5672 já esteja sendo usada por outro processo, é possível configurar o broker em outra porta. Para rodar o broker na porta 8888 por exemplo, execute o seguinte comando:

/usr/sbin/qpidd -t -p 8888

Alguns exemplos usando Red Hat MRG Messaging

Vamos agora verificar como podemos fazer uso do MRG Messaging. Para isso, irei mostrar várias aplicações escritas em linguagens diferentes que trocam mensagens através do Broker. Para este primeiro teste, execute o broker na porta padrão. Vamos criar um programa em Python que conecta no broker e espera por mensagens numa fila. Crie um programa em Python como mostrado abaixo:

Este programa realiza uma conexão com o broker, e define uma fila chamada "message_queue". Na sequência, é criado uma ligação entre esta fila e o nome "routing_key" para que conexões baseados no protocolo "direct" possa ser efetuado.

Abra um console, e execute este programa com o seguinte comando:

python ConsumidorUsandoPython.py

Para executar este programa, você precisará ter o interpretador do python instalado, bem como os stubs do AMQP. Agora vamos criar um produtor de mensagens em Python. Crie o seguinte programa:

Este programa Python faz um processo de conexão semelhante ao consumidor, mas a sua ação é de enviar uma mensagem para a chave "routing_key". Assim que esta mensagem chegar no broker, ele irá roteá-la para a fila mapeada a esta chave. Execute este outro programa usando o seguinte comando:

python ProdutorUsandoPython.py

Assim que a mensagem for enviada ao broker, o consumidor será notificado da sua entrega e irá exibir no console o resultado da mensagem enviada. O screenshot abaixo da minha máquina mostra este cenário:

Agora vamos deixar as coisas um pouco mais interessantes. Vamos criar um produtor usando Java. Para isso, escreva o seguinte programa Java usando a API do JMS:

Repare que o programa Java carrega algumas propriedades de conexão de um arquivo de propriedades. Antes de executar este programa, crie o seguinte arquivo:

Execute este programa Java. Você deverá ver a seguinte saída dentro do consumidor Python:

Para finalizar estes testes com o broker, vamos fazer algo um pouco fora da caixa: Consumir as mensagens do broker usando C# .NET. Vou deixar aqui o código fonte do programa CSharp que fiz, e vou apenas mostrar a execução do produtor Python e o consumidor .NET para maior clareza. Mas repare no código fonte disponibilizado o quão simples é criar uma aplicação cliente para AMQP.

Como funciona o modelo de troca de mensagens?

No AMQP, existem vários modelos de troca de mensagens. O modelo mais usado e conhecido sem dúvida é o de FanOut. No FanOut, cada fila é vinculada a um nome para o Broker, e um consumidor deve enviar suas mensagens para este nome. O nome, representa o vínculo da fila no Broker, e fornece portanto um acesso direto entre a fila e o consumidor da mesma.

Uma abordagem parecida com a FanOut é a Direct. Através do modelo de Direct, você enviada mensagens para um nome virtual que possui uma chave associada. Tanto o nome quanto a chave são vínculados a fila interna do broker, e o mesmo só autoriza a entrega da mensagem na fila (ou seu consumo) se o programa cliente enviar a chave correta.

Outro modelo também muito utilizado é o de tópicos. A idéia de tópicos também é baseada em chaves vínculadas a fila do broker, porém, várias chaves podem definir "assuntos" que diferentes filas e diferentes consumidores podem estar interessados:

Federação de Brokers: Integrando empresas usando AMQP

Um dos recursos mais interessantes do MRG Messaging é a capacidade de federação. Em linhas gerais, você pode "ligar" dois ou mais brokers fazendo com que produtores e consumidores de diferentes localizações possam trocar mensagens utilizando um dos modelos mostrados anteriormente.

Através deste recurso, você pode ter por exemplo um broker AMQP (MRG Messaging ou outro) rodando em Nova York escutando eventos de trading e bolsa de valores, e ter um broker MRG Messaging rodando em São Paulo, exibindo as mensagens de Nova York para os diversos consumidores (Java, Python, C++) quase em tempo real.

OK, este MRG Messaging parece interessante, mas e a performance disso?

Números explicam melhor que palavras, logo, nada melhor para falar de performance do que mostrar benchmarks baseados em cenários de hardware e software. Segue abaixo alguns números que mostram a capacidade de processamento do MRG Messaging num dado cenário montado pela equipe do MRG Messaging:

É realmente viciante trabalhar com o MRG Messaging, e espero que esta brilhante solução esteja sendo usada nos servidores de várias empresas do Brasil pois as possibilidades são infinitas. Se você achou este produto interessante e acha que ele pode ser bem utilizado na sua empresa, entre em contato comigo no e-mail ricardo.ferreira (at) redhat.com para falarmos mais afundo e com maior nível de detalhes. Terei grande prazer em ajudá-los ;-)