Integração de aplicações usando JBoss ESB

A disciplina de integração de aplicações está presente na engenharia de software a tempos. Através dela, empresas podem conectar aplicativos criando eco-sistemas baseados em legados, aumentando o poder e a dinamicidade das organizações. Quando falamos de integração de aplicações, geralmente nos deparamos com vários conceitos de integração muitos deles desconexos. Isso se dá porque a disciplina de integração de aplicações possue várias formas de implementação, e cada uma delas está atrelada a um determinado contexto ou necessidade diferente. Podemos ter uma idéia do quão complexo e diverso é a integração de aplicações através do catálogo de EAI conhecido como EAI Patterns.

Muito se fala hoje sobre EAI, principalmente com o advento do SOA no mercado. A arquitetura orientada a serviços possue como disciplina o EAI, e justamente por isso, vemos cada vez mais pessoas e empresas afirmando que SOA é o reflexo de esforços do uso de EAI em seus departamentos, mais ainda, vemos pessoas falando que SOA é o reflexo do uso de barramentos de serviços (ESB's) ou mesmo que para se ter SOA, é necessário usar barramentos de serviços.

O grande fato é que integração de aplicações nada têm a ver com SOA, têm haver sobre como a empresa organiza suas informações e fluxo de informações por meio de seus sistemas. Integrar é o reflexo de reuso, e reuso é reflexo de catalizar investimentos passados na criação de novas soluções. Quando esta prática, em conjunto com meios de otimização de processos de negócio e governança é usada, temos os primeiros sinais de uma abordagem SOA. Mas na prática, SOA não precisa de ESB para ser realizado, nem mesmo de EAI.

Quando uma abordagem SOA é concebida numa organização, algumas disciplinas essenciais devem ser aplicadas, antes mesmo do EAI. Grande parte destas disciplinas giram em torno de BDD e BPM, e uma boa parte delas voltadas a gestão de fluxos comerciais. A algum tempo, estou criando um processo de adoção para SOA, e em breve irei disponibilizar uma amostra deste processo (será um produto comercial), e algumas das disciplinas essenciais para uma adoção SOA serão melhor entendidas.

No momento oportuno e previamente vislumbrado, pode ser necessário o uso de infra-estruturas de barramentos de serviços, a fim de realizar algum tipo de integração de aplicações com foco em serviços (e não dados e objetos). Neste momento, deve-se usar boas implementações de barramentos de serviços, de forma a realizar mais rapidamente e com menos transformações na TI (na prática, menos re-engenharia) a sinergia entre aplicações departamentais. Ainda mais, pode-se tornar evidente a interação das aplicações e serviços (e por que não, pessoas) com entidades fora do escopo da fronteira da organização. Neste momento, aspectos de governança de TI devem ser cuidadosamente revisados e talvez restruturados, para melhor atender as modificações decorrentes do EAI.

Para transformações de EAI em organizações, várias abordagens podem ser usadas, bem como várias implementações de ESB hoje existem no mercado. Neste post, iremos estudar como usar o ESB da JBoss chamado JBoss ESB, e dar os primeiros passos na sua configuração e uso. Na prática, este post dará inicio a uma séria de outros posts relacionados a configuração e uso do JBoss ESB, bem como os posts já publicados sobre jBPM.

Conhecendo o JBoss ESB

A JBoss, está cada vez mais investindo recursos na criação de soluções e produtos voltados a abordagens SOA, e parte deste investimento foi a incoporação do ESB da Rosseta dentro da familia JEMS. A solução JBoss ESB é o reflexo da incorporação de uma solução de ESB criada em cima do JBoss, usada a mais de três anos no canadá numa rede de corretagem dentro da familia de produtos JBoss. Esta solução, usa os serviços principais do servidor de aplicação JBoss, e estende alguns serviços para implementar vários conceitos relacionados a ESB formando o produto JBoss ESB.

Com a incorporação do produto dentro da familia JBoss, a empresa não parou um minuto na melhoria da solução e hoje temos várias facilidades encontradas dentro do JBoss ESB, várias delas, voltadas ao uso de outras soluções da JBoss dentro dele, como jBPM, JBoss Rules, Smocks e integração com JBoss Portal. Um detalhe interessante sobre a solução, é que ela já nasceu de um grande caso de sucesso, e portanto já têm uma justificativa comercial para seu uso. Este ponto, apesar de simplório, deve ser considertado em sua adoção, pois muitos produtos de ESB no mercado, são soluções bacanas mas nunca usadas em produção. O JBoss ESB, ao contrário de outras soluções comerciais, está sendo usado a mais de três anos pela segunda maior empresa de seguros e corretagem do Canadá, e o caso de sucesso por ser livremente apresentado pela equipe comercial da JBoss.

Enterprise Service Bus ... Na prática ?

Antes de abordarmos o JBoss ESB num exemplo, temos que concordar com alguns conceitos. Um problema sério que vejo na área de TI, é que conceito depende de onde ele é lido. Vejo várias pessoas tendo visões diferentes e erradas quanto a ESB's, principalmente quando se fala de SOA. Um grande erro, conforme já foi dito, é falar que para se ter SOA, deve ser ter o uso de ESB's. Além disso, vejo várias pessoas confundindo outros conceitos de SOA, como BPM e BPEL, e BPM e BDD. Deve-se tomar cuidado com os conceitos dados, mesmo porque a maioria foram recomendações ou induções de fabricantes de software. Vamos agora entender o que é ESB de forma totalmente neutra, para ai sim, estudar como o JBoss ESB funciona.

Um ESB representa a infra-estrutura necessária para a criação de um eco-sistema baseado em serviços. Entenda serviço como qualquer componente de software que oferece uma solução empresarial, e que pode ou deve ser executado em conjunto com vários outros serviços. Para criar esta sinergia, todo ESB deve manter um barramento, que representa o caminho de execução onde os serviços serão executados, e portanto, poderão sobrer monitoramento, roteamento e transformações. Sendo bastante suscinto e breve, podemos afirmar que todo ESB é qualquer infra baseada em serviços que aborda as questões de monitoração, transformação e roteamento de tais serviços em tempo de execução. Podemos inclusive, falar que a justificativa real para o uso de um ESB, é o interesse particular em um dos três aspectos citados ou mesmo todos eles.

Acima deste conceito, temos também que um ESB é um padrão, é não um produto. Esta sem duvida é a mais polêmica das afirmações, justamente porque fabricantes de software tendem a vender soluções entituladas produtos ESB por ai a fora. Todo ESB na prática é abstrato, e é 'instanciado' para prover determinada demanda de integração de serviços num cenário organizacional. Logo, podemos ter em mente que uma solução de ESB (vamos pegar o Sonic ESB por exemplo) deve prover a capacidade de instanciar um ESB várias vezes. Analogamente falando, podemos dizer que toda classe Java, pode sofrer várias instanciações (criar vários objetos a partir dela), assim deve ser visto o ESB, como o resultado da instanciação do conceito ESB para um caso particular.

De posse desta visão, de que todo ESB é na verdade um padrão e não um simples produto, temos que ver o ESB como sendo um padrão base para outros padrões. Toda solução de ESB deve prover a flexão do conceito de ESB para vários cenários de negócio, envolvendo várias abordagens de EAI tradicionais. Por exemplo, o caso mais simples de instanciação de um ESB é quando temos serviços produzidos e consumidos dentro de uma fronteira organizacional ou departamental. Neste quesito, temos que todas as aplicações negociam um padrão de troca de mensagens comum, e transformações de mensagens não são necessários. Esta abordagem, geralmente chama-se Direct ESB Connection, e sua abordagem pode ser vista na figura abaixo.

Uma outra abordagem também muito conhecida é o ESB Gateway. Nesta variação de ESB, temos o uso do ESB por serviços e aplicações fora do contexto da organização, notadamente, fora da intranet ou DMZ da mesma. Quando temos este modelo, devemos ter em mente que a forma como as mensagens são tratadas difere, e torna-se necessário o uso de componentes de adaptação das mensagens para garantir que as mensagens enviadas e recebidas por serviços intrusos, seja formalmente transformadas em mensagens conhecidas pelos serviços internos. Neste caso, o ESB Gateway é a variação do conceito de ESB pra denotar o componente que faz esta adequação das mensagens, bem como prover um ponto na solução onde verificações de segurança e autorizações podem ser concentradas. A figura abaixo mostra como este mecanismo de ESB baseado em gateway é estruturado.

Através destas flexões do conceito de ESB, podemos ver e constatar que um ESB na prática não deve ser visto como um produto, pois nenhum produto irá mapear todas as variações possíveis para adequar as necessidades das empresas. Se o ESB por visto como um padrão, podemos conceber soluções que podem implementar este padrão e transforma-lo adequadamente para prover uma infra-estrutura de integração de serviços. Ainda mais, se pensarmos no ESB como um conceito, podemos claramente cria-lo a contento para mitigar nossas necessidades não necessariamente aderindo a alguma solução comercial (geralmente muito cara). Claro que soluções que irão viabilizar o negócio digital das empresas devem ser bastante confiáveis, e sob esta justificativa, é que soluções de terceiros devem ser procuradas. Como possibilidade, iremos estudar agora o JBoss ESB, que provê uma infra-estrutura que dá suporte ao conceito de ESB e pode ser facilmente configurado para variar de acordo com a necessidade de integração.

Configurando o JBoss ESB

Vamos agora dar inicio ao estudo do JBoss ESB. Este exemplo, usará a versão 4.0 GA, que segundo a data do post é a ultima versão disponivel nos servidores da JBoss Community. É importante que você esteja familiarizado com certos aspectos de JEE e configuração do JBoss, pois não entrarei em detalhes sobre, por se tratar de um post avançado. Caso encontre dificuldades na confecção do exemplo, talvez seja a hora de revisar alguns conceitos chaves como JEE, JBoss, e outros.

Depois de baixar o JBoss ESB, você deve instala-lo dentro de alguma distribuição do JBoss Application Server. O JBoss ESB não têm uma infra formalmente definida, pois ele segue a risca o fato de ser apenas um conceito de ESB. Por isso, ele usa os serviços principais do servidor de aplicação JBoss. Através da API de JMX, o JBoss ESB pode ser concebido como sendo dois serviços (Service-Archives) que são instalados na pasta deploy do JBoss. Um script Ant que acompanha o JBoss ESB pode lhe ajudar nesta tarefa.

Criando os componentes da Aplicação

Partindo da premissa que toda aplicação integrada, compreende um produtor e um consumidor, iremos criar o exemplo segundo esta premissa. O produtor, será o componente ESB que proverá os serviços de execução do exemplo, e o consumidor será a aplicação que através do ESB, irá acessar o serviço produzido. Iremos começar pelo consumidor. Crie um projeto Java, e crie uma classe Java chamada 'ClienteJMS' dentro deste projeto. A classe, será responsável por enviar uma mensagem através de JMS para uma fila gerenciada do ESB, a fim de produzir a interação com o serviço. A listagem abaixo resume como deve ser o cliente JMS.

Para fazer este cliente funcionar, você precisará de alguns arquivos JAR no seu classpath. Estes arquivos, em sua maioria, são necessários para a interação com a API do J2EE, sendo portanto, uma abordagem simplista de clientes de ESB. O unico arquivo necessário para a execução do cliente é o jbossall-client.jar, que pode ser facilmente encontrado na pasta lib/ext do seu JBoss ESB. Além disso, é conveniente lembrar que o uso de JMS implica no uso de JNDI (abstraído na listagem pelo componente ServiceLocator) e portanto, as configurações de JNDI devem ser feitas no arquivo jndi.properties.

Em seguida, deveremos criar as filas de mensagens dentro do JBoss que comportarão as mensagens trocadas entre o consumidor e o produtor do serviço. Para isso, crie um arquivo XML de configuração na pasta deploy do seu JBoss chamado 'filas-service.xml', contendo as declarações abaixo.

Na listagem, criamos duas filas de mensagens. Uma para comportar as mensagens oriundas de clientes externos a organização (potencialmente, em não conformidade com os padrões de mensagens do JBoss ESB) e outra fila para comportar as mensagens destinadas aos serviços mantidos no registro do JBoss ESB. Logo, caso tivéssemos criado um serviço que usaria o serviço de dentro do ESB, poderíamos enviar a mensagem para a fila 'directConnectionQueue' sem a necessidade da adaptação do ESB.

A partir do momento que temos nosas filas de integração configuradas, precisamos atualizar o registro de serviços do JBoss ESB, para criar a configuração necessária para o serviço do exemplo. Quando o JBoss ESB é instalado no JBoss, é criado um arquivo jbossesb.xml no diretório de configuração do JBoss. Edite este arquivo conforme a listagem abaixo.

Durante o carregamento do JBoss, o mecanismo de ESB irá ler este arquivo de configuração, e atualizar o sistema de registro e repositório do JBoss ESB (que originalmente usa o sistema do HSQLDB para manter as referências) com os serviços declarados. Uma vez que estes serviços se tornam serviços disponiveis para o registro, qualquer forma de acesso ao serviço será possível, seja por SOAP, JMS ou mesmo usando a API do JBoss ESB. Um ponto importante do JBoss ESB é que ele acompanha uma implementação pré-configurada do jUDDI.

Através do jUDDI, pode-se manter um sistema de registro de serviços na forma de páginas amarelas (jargão usado pelo UDDI) em que entidades externas podem consultar na sua organização quais serviços estão sendo disponibilizados e quais podem ser usados. O endereço WSDL oferecido pelo jUDDI é virtual, e mapeia uma fila JMS do tipo Gateway do ESB. Com isso, pode-se interceptar o momento que entidades externas usam os serviços disponibilizados e realizar qualquer tipo de operação como roteamento, transformação ou bloqueio. Para usar o jUDDI, basta instalar o aplicativo da pasta install/jUDDI-Registry do seu JBoss ESB, bem como alterar o arquivo de configuração do JBoss ESB (encontrado na pasta de configuração do JBoss) na seção 'registry'.

Finalmente, criando o provedor do Serviço

Para finalizarmos o exemplo, e finalmente testa-lo, temos que criar o provedor do serviço. Para isso, iremos criar uma classe de interceptação que será coreografado pelo ESB. Serviços são na verdade componentes virtuais que acessam componentes legados, geralmente de outras aplicações. Para demonstrar como esta interceptação é feita, iremos criar um novo projeto. Crie um projeto Java comum, e crie uma classe no projeto chamada 'ExemploInterceptador' a listagem abaixo mostra como esta classe deverá ser implementada.

Nesta classe, criamos um método chamado 'exbirMensagem' que será executado pelo mecanismo de tempo de execução do ESB para a ilustração do exemplo. Nas classes de interceptação, podemos criar vários métodos para realizar a confecção das mensagens recebidas. Para tal, a mensagem, originada através de uma mensagem recebida pelo ESB é passada como argumento para os métodos como o objeto Message. Neste objeto, podemos inspecionar os detalhes da mensagem como seu conteúdo, cabeçalho e descobrir informações sobre para onde a mensagem se destina, ou mesmo alterar a forma como a mensagem mantêm seu conteúdo (roteamento e transformação de mensagens, respectivamente).

Mesmo sendo possível realizar operações nas mensagens de dentro dos interceptadores. não é recomendável esta prática. Lembre-se, componentes interceptadores são usados para realizar o acesso a camada de componentes empresariais e não para conter lógicas de transformação ou roteamento. Se esta for uma necessidade, o JBoss ESB oferece componentes pré-implementados para transformações e roteamento baseado em conteúdo, bastando registra-los no sistema do ESB. Além da separação de responsabilidades, é possível trabalhar transformações e roteamentos de forma totalmente agnósticas ao serviço.

Além do método que imprime a mensagem recebida, criamos também uma variável membro do tipo ConfigTree, bem como um construtor que recebe um objeto deste tipo. Isso é necessário porque em tempo de execução o JBoss ESB instrumenta a classe para realizar algumas operações, e o objeto ConfigTree mantêm algumas configurações e referências para esta instrumentação. Neste caso, é necessário que toda classe de interceptação esteja preparada para injeção de dependência por construtor. Uma dica interessante é por este atributo em uma classe abstrata (AbstractESBInterceptor talvez) e fazer com que todas as classes de interceptação estendam esta classe.

As classes de interceptação possuem um papel importante na pilha do ESB, pois elas são o ponto de contato com o mundo externo, em especial, a camada de componentes da organização. A figura abaixo mostra um exemplo de topologia onde os processos de negócios são realizados por serviços, estes são realizados pelos componentes (ai entram os interceptadores) e os componentes pelas aplicações legadas.

Após criar a classe do componente de interceptação, crie um arquivo JAR do projeto, contendo apenas a classe de interceptação, e copie o JAR criado para a pasta /server/profile/deploy/jbossesb.sar. Quando o JBoss iniciar, o serviço do JBoss ESB irá fazer um scanning de todos os arquivos JAR do seu diretório, e carregar as classes e recursos encontrados no classloader do serviço do JBoss ESB. Com isso, o mecanismo de ESB do JBoss poderá executar a classe de interceptação quando o serviço declarado por chamado.

Feito isso, inicie seu servidor JBoss, e após ter carregado adequadamente, execute a aplicação cliente que criamos. O resultado disso é a mensagem no console do JBoss:

'---> Mensagem do Cliente JMS'

A exibição desta mensagem significa a correta execução do serviço, por meio do gateway ESB criado. Neste caso, a mensagem enviada pelo cliente JMS será enviada para a fila do JBoss chamada 'gatewayQueue'. Esta fila, ao receber a mensagem irá adaptar a mensagem recebida e localizar o serviço a que ela se destina. A localização do serviço se dará fazendo busca no sistema de registro, e quanto encontrado, irá enviar a mensagem (agora, adaptada pelo Gateway) para a fila 'directConnectionQueue'. Nesta fila, haverá o encaminhamento para o serviço real, e a mensagem será então passada como parâmetro para a classe de interceptação.

Considerações finais

Neste post vimos um pouco do poder que o JBoss ESB apresenta quanto a integração de serviços e barramentos. Vimos um exemplo simples mas eficaz sobre como projetar integração de serviços usando filas e clientes JMS. Além disso, vimos o conceito de ESB bem como o que ele representa para o SOA. Em posts futuros, irei mostrar como fazer clientes SOAP para o ESB, bem como registrar serviços externos (de outras fronteiras) dentro do JBoss ESB, de posse que ele cuide dos detalhes de roteamento e execução. Fiz alguns testes usando web services no JBoss ESB, e posso garantir que o mesmo está 'preparado' para ambientes cujo objetivo é SOA (lembrando que para ter SOA não precisa de ESB). A facilidade pelo qual os web services são registrados, bem como eles podem ser transformados é muito grande, graças ao mecanismo de UDDI oferecido pelo jUDDI.

Espero que tenham gostado do post, e possam ter entendido como funciona o JBoss ESB. Fiquem atentos aos próximos posts, este é apenas o começo. Até lá!