sexta-feira, 12 de março de 2010

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 aprovisiona
mento 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.ty
pes.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 e
m 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 ;-)

0 comentários: