O papel do ESB em uma solução SOA
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 post. 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 ?
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 estar se preocupando com certos detalhes. Imagine que os passageiros são os dados e a cada parada do bus é um sistema que está sendo acessado com por um protocolo diferente. O conceito de bus não é novo na aé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 trás mais abstração do que usar JMS por exemplo. Pois o bus esta 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 reutilizarã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 o seus sistemas. Não há como ter SOA somente tendo um ESB. Porem 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 são cada item desses e se você precisa ou não de todos.
Componentes Core de um ESB
Código de negocio dentro do ESB?
De inicio pode parecer uma boa idéia colocar seu sistema dentro do ESB, mas acredite não é uma boa idéia. 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.
Java Business Imtegration?
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 destas e para que servem.
Binding Components
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...
Service Engines
São motores que provem 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 Message Router
Basicamente estamos falando do próprio ESB em si na visão do JBI. Já que a mediação acontece via o 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. Por que ele responde todas essas perguntas e muitas outras, além de que a solução está bem madura e funciona com maven 2, que é outra grande vantagem.
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 negocio ou até mesmo usuário de um sistema.
Agora eu tenho SOA?
Ainda não. Você pode usar todos os recursos que lhe falei neste post acima que ainda não tera 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 usa-lo quando você tem diversos sistemas que precisam conversar de diversas maneiras e que as vezes estão distribuídos através da web. Se você só tem 2 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 publica e no que interface privada, mas isso já é outro post, :)
Até a próxima.
Na prática usar um ESB nos trás mais abstração do que usar JMS por exemplo. Pois o bus esta 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 reutilizarã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 o seus sistemas. Não há como ter SOA somente tendo um ESB. Porem 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 são 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ê 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.
Código de negocio dentro do ESB?
De inicio pode parecer uma boa idéia colocar seu sistema dentro do ESB, mas acredite não é uma boa idéia. 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.
Java Business Imtegration?
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 destas e para que servem.
Binding Components
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...
Service Engines
São motores que provem 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 Message Router
Basicamente estamos falando do próprio ESB em si na visão do JBI. Já que a mediação acontece via o 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. Por que ele responde todas essas perguntas e muitas outras, além de que a solução está bem madura e funciona com maven 2, 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 negocio ou até mesmo usuário de um sistema.
Agora eu tenho SOA?
Ainda não. Você pode usar todos os recursos que lhe falei neste post acima que ainda não tera 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 usa-lo quando você tem diversos sistemas que precisam conversar de diversas maneiras e que as vezes estão distribuídos através da web. Se você só tem 2 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 publica e no que interface privada, mas isso já é outro post, :)
Até a próxima.
