Splitter Pattern no JBoss ESB

Uma das coisas mais fascinantes do JBoss ESB é o poder da sua estensibilidade. É possível fazer qualquer coisa com ela relacionada a roteamento e transformação de mensagens. Várias coisas já existem nele OOB, mas quando existem casos onde o produto não suporta a feature nativamente, é simples criar sua própria implementação usando a API de pipelines personalizados.

Dito isso, a seguinte situação me motivou a escrever este post. Um cliente me procurou nas ultimas semanas me questionando sobre as estratégias de roteamento do JBoss ESB para implementação do padrão EAI Splitter. O questionamento foi o seguinte: Baseado no padrão, a estratégia é pegar uma mensagem, separá-la em mensagens diferentes e cada mensagem criada, ser roteada para um canal de mensagens diferente.

Tendo esta estratégia em mente, o cliente procurou no JBoss ESB implementações OOB que fizessem isso, e pra sua surpresa (e minha também) nada foi encontrado. As actions StaticRouter e StaticWiretap teoricamente fazem isso, mas o que elas fazem é mandar a mesma mensagem recebida, para diferentes canais de mensagens. Ou seja, o "split" que eles fazem é apenas de canais, ele joga a mensagem do canal de entrada para diferentes canais de saída, mas não faz o split da mensagem em si.

Entendida sua dúvida, e concordando que as implementações OOB do JBoss ESB divergem um pouco do que o padrão sugere, resolvemos que criaríamos uma implementação personalizada do Splitter, um pouco mais alinhada com o padrão estabelecido no EAI Patterns. Fiz esta implementação, e resolvi postar no JIRA do JBoss ESB para que isso vire uma feature da próxima versão. Segue o endereço deste JIRA:

https://jira.jboss.org/jira/browse/JBESB-2805

Se vocês quiserem, votem na feature e agitem o grupo de usuários do JBoss ESB para que a feature seja aprovada. Abaixo, segue a implementação deste padrão. No JIRA, coloquei também um projeto que fiz para testar a implementação.


Na listagem abaixo, segue um exemplo de configuração desta action dentro do JBoss ESB. Repare que para cada roteamento da mensagem recebida, é feito um processo de transformação da mensagem, e a mensagem resultante é roteada para o canal de mensagem, e não, a mensagem original recebida.


Boas Integrações ;-)

Drools 5: Criando / Usando Packages Programaticamente

Os dos recursos mais interessantes do Drools 5 é a capacidade de criar pacotes e executá-los dinâmicamente. Isso é legal porque muitas das vezes, gostariamos que o processo de authoring de regras seja feito automaticamente a medida que algum evento de negócio autorize a criação de uma regra. Neste post, irei compartilhar com vocês uma experiência que tive num cliente nos ultimos dias, onde este cenário foi requisitado.

O JBoss BRMS trabalha com o conceito de repostório de regras. Pense neste repositório como um grande banco de dados que cataloga e armazena as regras para que estas possam ser carregadas em memória e estejam aptar a executar lógicas complexas a medida que fatos são inseridos na agenda de execução. O processo normal para alimentar estas regras no repositório, é quando programadores criam arquivos DRL ou XML com as regras de negócio e fazem o deploy destas no JBoss BRMS, ou, como é o caso mais típico, quando pessoas de negócio entram no BRMS, criam ou alteram as regras, e atualizam o repositório.

Seja qual for o caso, o que é feito é um processo de compilação e geração de um pacote, contendo as regras, definições de fatos, DSL's e demais artefatos do JBoss BRMS. A este pacote chamamos de lista de base de conhecimento, ou, usando o jargão Java, coleção de bases de conhecimento.

Agora imagine que você precisa do seguinte cenário: As regras, são criadas a partir de templates previamente definidos, e quando uma aplicação dispara um evento de negócio qualquer (Ex: autorizar o despacho de um produto) uma nova regra é criada (com base no template) e deve ser compilada a armazenada num pacote existente. Ou seja, o que gostaríamos é que as regras pudessem ser armazenadas no pacote sem que um intermédio humano fosse feito. Isso é perfeitamente possível de se fazer no Drools 5, a listagem abaixo mostra um método genérico sobre como atualizar um pacote existente, ou, se ele não existir, criar um novo pacote.


Note que, depois que é feito o processo de compilação das regras, a idéia é criar uma coleção de objetos do tipo KnowledgePackage e serializar esta coleção. Quando você serializa esta coleção num arquivo, você pode apenas dar a estensão .pkg que tanto o JBoss BRMS quanto a API do Drools irão poder carregar e executar este pacote, como se ele fosse originalmente feito dentro do JBoss BRMS.

Para utilizar este pacote, você pode usar a mesma API do Drools, e fazendo o processo de carregar o pacote do arquivo, restaurando a coleção de KnowledgePackage's. Feito isso, basta que você crie uma base de conhecimento (KnowledgeBase) e adicionar os pacotes de conhecimento nesta base de conhecimento. Fazendo isso, você cria uma base de regras em memória, e quando você têm isso, você pode criar sessões de execução do tipo Stateless ou Stateful para executar regras dados os fatos existentes, e manter agendas de execução para o motor de RETE / OO. A listagem abaixo mostra como executar fatos dado o pacote serializado.


Bons Códigos!

JBoss ESB: Pesquisando Serviços usando UDDI

Frequentemente, ouço a seguinte pergunta: Ricardo, o JBoss ESB (SOA Platform) é um ESB muito legal, mas e como fica a questão de UDDI nele? Como UDDI é uma infra-estrutura básica de qualquer ESB, é até natural que esse tipo de pergunta seja feita, uma vez que, no JBoss ESB, existe o uso do mesmo através da implementação do jUDDI, porém, não existe nada visual que comprove sua existência.

Neste post, irei explicar um pouco da arquitetura de UDDI, e como, no JBoss ESB, isso funciona. Mas antes de mergulharmos nos detalhes sobre como utilizar UDDI no JBoss ESB, é importante saber como ele funciona e como o JBoss ESB se posiciona quanto a isso.

ESB + UDDI ou ESB = UDDI?

O padrão UDDI estabelece formas padronizadas de registrar e procurar serviços, isso já sabemos. Do ponto de vista de um ESB, que é um grande gerador e consumidor de serviços, nada mais justo que este faça uso do padrão UDDI dentro dele. Dito isso, todo ESB deve possuir uma estratégia baseada em UDDI, mas deixando livre a escolha da implementação de UDDI que se quer utilizar. Isso significa que os serviços que são disponibilizados por um ESB devem ser registrados num sistema de registros baseado em UDDI, e a implementação de UDDI deve ser de escolha do usuário final.

Na prática, é muito mais vantajoso que um ESB utilize qualquer solução que seja compatível com o padrão UDDI, do que obrigar os usuários a utilizar uma. Por quê? Porque é interessante separar os interesses. Um ESB têm grandes responsabilidades no que tange a EAI, mensageria e conexão de aplicaçães, e um UDDI possui outras preocupações diferentes. São mundos que não competem que possuem soluções bem interessantes no mercado para ambas.

No JBoss ESB, assim como tudo no mundo JBoss, os elementos são fracamente acomplados e facilmente substituidos, é premissa básica em JBoss a liberdade de escolha. Por isso, o JBoss ESB possui originalmente uma implementação de UDDI baseada no jUDDI da Apache, mas deixa totalmente livre que o usuário do produto utilize outras soluções. Temos hoje diversos tipos de integrações com implementações de terceiros como é o caso da SOA Software, jUDDI da Apache, JAXR e outras soluções de terceiros.

Dito isso, o JBoss ESB usa como estratégia de UDDI o jUDDI da Apache, possibilitando portanto que os serviços registrados pelos usuários possam ser descobertos via UDDI. Mas, a implementação pode ser alterada sem que o funcionamento padrão do JBoss ESB seja afetado.

Como alterar a implementação de UDDI do JBoss ESB?

Para utilizar uma nova implementação de UDDI dentro do JBoss ESB, basta que você altere no arquivo jbossesb-properties.xml (dentro do SAR do JBoss ESB) a seção "registry" mostrado na listagem abaixo:


Como visualizar meus serviços registrados?

Pra visualizar seus serviços no JBoss ESB, você irá precisar de uma ferramenta que consiga consultar um registro de serviços via o padrão UDDI. Existem várias ferramentas que fazem isso no mercado, algumas pagas e outras open-source. Iremos, para efeitos didáticos, usar o UDDIBrowser. Mas você pode usar uma solução de qualquer fabricante para pesquisar o sistema de registros dos JBoss ESB.

Se vocẽ percebe a diferença entre ter um sistema de registros e um software que explora sistemas de registros, você começa a perceber o poder que têm em mãos. Grande parte das soluções de UDDI são muito mais vistas por serem visualmente agradáveis quando o assunto é explorar registros, mas, o que realmente importa, é a solução de sistema de registros em si. E justamente por não importar qual é a solução que você usa para explorar serviços, você, no JBoss ESB pode usar qualquer solução.

Configurando o UDDIBrowser para explorar o JBoss ESB

A primeira coisa a se fazer é baixar o UDDIBrowser. Você pode baixá-lo gratuitamente aqui. Depois de baixa-lo, execute-o através do programa ub.bat que se encontra em sua pasta "bin". A figura abaixo mostra sua interface principal depois de iniciado:

Para que o UDDIBrowser possa explorar serviços num sistema de registro, você precisa registrar nele o endereço do seu sistema de registro. Para isso, vá até o menu Edit->UDDI Registries. Será mostrado uma lista padrão de sistemas de registros que você pode acessar (sistemas públicos). Clique no botão "Add" para adicionar um novo sistema de registros. Na janela apresentada, entre com o endereço do seu JBoss ESB como mostrado na figura abaixo:

Clique no botão OK. Depois disso, a nova entrada é disponibilizada na lista. Selecione a opção "JBoss ESB 4.6" e clique no botão "Connect". Pronto, agora o próximo passo é realizar algumas pesquisas para testes. Faça uma pesquisa básica, procurando por todos os serviços registrados: Vá no menu View->Basic Find. Marque a opção "business" e clique no botão "Search". O resultado deverá ser como mostrado na figura abaixo:

Pronto. Agora você pode realizar pesquisas no sistema de registros do JBoss ESB e explorar os serviços que estão sendo consumidos. Para melhor adequação ao seu ambiente, lembre-se que tanto a solução de registro quanto o aplicativo de procura podem ser facilmente substituídos, deixando sua solução / projeto mais flexível.

Boas Integrações!

XSLT no JBoss ESB: Removendo NameSpaces de um XML

Estive num cliente estes últimos dias, e precisei fazer a remoção de todos os namespaces de um documento XML para que uma determinada engine de transformação pudesse fazer seu trabalho. O XML era recebido pelo JBoss ESB através do JBR Provider, (SOAP, HTTP, UDP, Socket) e uma dada ação do pipeline precisava receber este XML sem qualquer namespace. Neste caso, apliquei uma transformação do XML usando XSLT, fazendo com que o documento XML fosse "emitido" sem qualquer referência a um namespace. Vou compartilhar com vocês como isso pode ser feito no JBoss ESB.

1) Usando Smooks, crie um programa XSLT que processe o documento XML

2) Registre a transformação no pipeline do serviço que receberá o XML

3) Faça os testes: Envie o seguinte documento XML para o JBoss ESB:

4) Este deverá ser o resultado depois que o XML for processado via XSLT:

Ponto de atenção: Nenhum código Java teve que ser escrito. E outra coisa legal é que o template XSLT usado pode ser aplicado em qualquer documento XML, tornando-o genérico. Legal heim?

Boas Transformações!