Usar um ESB virou moda nos últimos meses. Não digo que a tecnologia
não seja adequada, mas usar um ESB não significa necessariamente ter
SOA. Se você esta interessado em saber o que SOA é ou não é, você pode ler este texto.
Meu objetivo aqui é passar a minha visão sobre ESB e de como e quando
ele pode ser usado em uma solução SOA e em soluções que não são SOA.

Bus?

Isso
mesmo. Se formos pela tradução literal significa serviço de ônibus
corporativo. A idéia é bem simples: o bus leva e traz dados para você. Logo, você não precisa se preocupar com certos detalhes. Imagine
que os passageiros são os dados e a cada parada do bus é um sistema que
está sendo acessado por um protocolo diferente. O conceito de bus
não é novo na área. Se olharmos para placas-mãe já tínhamos esse
conceito lá, ele foi apenas adaptado para integração de sistemas.

Na prática, usar um ESB nos traz mais abstração do que usar JMS
por exemplo. Pois o bus está em um nível superior, provendo bem mais
abstrações e facilidades. Usar um ESB lhe traz uma série de facilidades
de integração de sistemas, é disso que venho falar.

Implementando com um ESB == SOA ?

De
forma alguma. ESB é focado em integração de sistemas, especificamente
falando de protocolos, plataformas e formas de acesso como http, ftp,
sockets, etc… Enquanto SOA é sobre contratos e reutilização de
sistemas. Perceba que a integração é uma parte importante, mas SOA é
muito mais do que isso.

Mesmo que você use um ESB isso não faz
com que você tenha SOA. Para ter isso vai depender da forma como você
modela e concebe os seus sistemas. Não há como ter SOA somente tendo um
ESB. Porém, o ESB é um componente importante em uma solução SOA, toda a
integração de sistemas acontece via ele.

Como você já deve ter
percebido um ESB é sobre comunicação. Claro que junto a isso vamos
precisar de mais coisas como transformação, roteamento, orquestração,
etc… Vamos ver na prática o que é cada item desses e se você
precisa ou não de todos.

Componentes Core de um ESB

• Invocação: Responsável por por prover suporte a protocolos de transporte de maneira síncrona e assíncrona.
• Roteamento:
  Responsável por mandar as informações para um lugar ou para outro, você
  pode fazer isso de maneira estática ou dinâmica. Pode usar roteamento
  baseado em regras com o Drools, por exemplo.
• Mediação (Transformação): Responsável por prover a transformação de protocolos, por exemplo entrar em um http e sair em um SFTP.
• Mensagens:
  Responsável por prover o tratamento, processamento e reforço de
  mensagens. Por exemplo, se você leu um xml o ESB tem que ser capaz de
  adicionar ou remover informações desse XML antes de chegar no destino.
• Orquestração/Coreografia:
  Estão relacionados a processos complexos e BPMN/BPEL. Se você não usa
  BPEL, não irá precisar destes dois, muitas pessoas acham que são
  obrigadas a usar esses dois em um ESB e em muitos casos não existe tal
  necessidade.

Certamente você precisa de segurança, até porque
SOA sem segurança não existe! Você pode pensar em outras coisas como
monitoramento (BAM) e processamento de eventos complexos (CEP) mais aí já
estamos falando de algo que está fora do ESB, ou seja, não são suas
responsabilidades.

Código de negócio dentro do ESB?

De
início pode parecer uma boa idéia colocar seu sistema dentro do ESB,
mas acredite, não é. Você deve fazer seus sistema longe do
ESB e fazer com que o ESB vá até seu sistema e converse com ele. Desenvolver o sistema dentro do ESB só gera mais acoplamento e
complexidade.

JavaBusinessImtegration?

Essa é a JSR 208/312
para implementação de SOA em Java. A especificação é bem simples, tem
poucos conceitos como: SE, BC, NMR. Vamos dar uma pausa na sopa de
letrinhas e vamos ver o que significa cada sigla e para que
servem.

BindingComponents

São
responsáveis pela comunicação com protocolos remotos e também devem
normalizar/desnormalizar mensagens. Você usa um BC especifico para cada
protocolo que você conversa como http, ftp, rmi, JMS, XMPP, etc…

ServiceEngines

São
motores que proveem serviços de vários tipos para o NMR. Alguns exemplos
de SE são rules engines, BPEL engines, XSLT engines, scripting engines,
EJB continers. Você pode usar o serviço do camel da apache para roteamento por exemplo.

Normalized MessageRouter

Basicamente
estamos falando do próprio ESB, na visão do JBI. Já que a mediação
acontece via ESB, o NMR dá transparência de localização aos serviços
também.

Uma excelente solução de ESB

Hoje a melhor solução em termos de ESB para mim é o ServiceMix,
da apache. Por que ele usa o Spring? Não. Por que ele implementa JBI? Não. Por que ele é todo plugavel e você pode remover o que não quer? Não. Porque ele responde a todas essas e a muitas outras perguntas, além
de que a solução está bem madura e funciona com maven 2, o que é outra
grande vantagem.

Visão geral do ServiceMix

A
forma como o ServiceMix separa a lógica de comunicação da lógica de
processamento é muito boa, e tudo isso através da JBI. O legal é que
você pode distribui-lo de forma embarcada com todo o suporte do Spring Framework ou de forma stand alone, até mesmo com outro ESB.

Você pode usar o Drools com o ServiceMix, essa integração já está pronta, assim você pode expor as regras de roteamento para um analista de negócio ou até mesmo usuário de um sistema.

Agora eu tenho SOA?

Ainda
não. Você pode usar todos os recursos de que lhe falei neste artigo e ainda não terá SOA, mas isso não quer dizer que você não tenha uma
boa solução. Essa solução é muito válida em cenários de integração de
sistemas.

Ok, sempre usarei um ESB agora!

Nopes!
Um ESB pode não ser a melhor solução para o seu problema. Você deve
usá-lo quando tem diversos sistemas que precisam conversar de
diversas maneiras e que às vezes estão distribuídos através da web. Se
você só tem dois sistemas Java que estão na sua empresa, considere a
possibilidade de usar algo mais simples como o JMS por exemplo.

Falando
de SOA, o contrato dos sistemas não será definido pelo ESB, o ESB será
apenas a forma de você usar os contratos nas fronteiras, mas não é
pensando nele que você deve definir esse contrato. Para definir bem os
contratos você terá que pensar no que é interface pública e no que
é interface privada, mas isso já é outro artigo!

Até a próxima.