Conheça o fascinante conceito de Enterprise Service Bus

Certa vez escrevi um artigo sobre SOA onde descrevi o tipo de cenário perfeito para usar seu conceito.

Usarei um cenário muito parecido para falar sobre ESB (Enterprise Service Bus) a partir de agora. O que nos faz pensar na co-relação existente entre os dois conceitos de SOA e ESB.

Muitos confundem os dois achando que são a mesma coisa, mas não se engane, não é a mesma coisa. O que posso afirmar, já no início, é que ESB é responsável por boa parte das funções de SOA mas não todas.

Vamos ao cenário:
Você trabalha em uma empresa que fornece uma API de pagamento online. Sua empresa disponibiliza a API gratuitamente e milhares de pessoas, diariamente, implementam esta API em suas aplicações online. Como consequência, sua empresa passa a ter inúmeros acessos para:

  • Gerenciar cadastro ( CRUD) ;
  • Cadastrar uma compra feita através de sua API;
  • Registrar Pagamento, entre outras operações.

Mas, partindo do princípio que sua API está sendo utilizada por tecnologias distintas (heterogêneas), como fazer com que seu sistema entenda o que as aplicações externas estão querendo ao consultar seus serviços?

É aí que entra o conceito dos ESB’s.  O Service Bus fornece :

  • Integração orientada a serviços,
  • Gerenciamento de serviços e
  • Corretagem de mensagens tradicionais escaláveis e confiáveis em ambientes heterogêneos.

Ele combina o intercâmbio inteligente de mensagens com roteamento e transformação
de mensagens, além de monitoramento e administração de serviços.

Como ESB se trata de um conceito, existem algumas ferramentas no mercado que aplicaram este conceito em algumas ferramentas transformando-as em poderosas consoles de trabalho e como exemplo temos:

  • Oracle Service Bus ou OSB ( presente na Suite Oracle SOA);
  • Talend ESB;
  • IBM WebSphere Enterprise Service Bus;
  • entre outras.

E quais são esses conceitos/atividades ou responsabilidades do ESB ?

1 – Suporte a web services
O ESB tem a capacidade de invocar web services baseados em WSDL e SOAP, bem como outros serviços como Restfull utilizando o protocolo http.

Geralmente, criamos um WSDL para o serviço que se quer expor no ESB. Os clientes, ao invés de se conectarem diretamente ao WSDL do serviço, eles se conectam a um WSDL ( Proxy) exposto no barramento. Assim, você consegue ter uma conexão que permite tratar lógica de roteamento e transformação dentro do barramento.

2 – Adaptadores
São utilizados para conectar aplicações que não suportam a interface SOAP ou XML, tais como aplicações empacotadas, banco de dados, ferramentas ERP, interfaces via arquivo.
Adaptadores podem ser utilizados tanto no caso da aplicação não fornecer integração via XML ou SOAP, como também nos casos em que se deseja um maior ganho de desempenho evitando o custo em tempo de execução de traduzir para/de XML, se o sistema suporta diretamente serialização de objetos.

3 – Invocação de Serviços
Como uma característica padrão, ESB suporta chamadas síncronas e assíncronas de serviços, e algumas vezes callback. Um serviço pode ser mapeado em outro serviço.

A forma que serviços se comunicam é chamada de padrões de troca de mensagens (ou MEP – Message Exchange Pattern). Um MEP define a sequência de mensagens em uma chamada de serviço ou operação do serviço, especificando a ordem, a direção e a cardinalidade das mensagens.

Existem diferentes tipos de MEP:

  • One-way: A operação recebe uma mensagem, mas não irá retornar uma resposta.
  • Request-response: A operação recebe uma mensagem e irá retornar uma resposta.
  • Solicit-response: A operação envia uma requisição e irá esperar uma resposta.
  • Notification: A operação envia uma mensagem, mas não irá esperar uma resposta.

4 – Medição e Independência de protocolo
Muitos barramentos permitem que diferentes protocolos de comunicação sejam utilizados durante o caminho de uma mensagem.

5 – Roteamento
Barramentos disponibilizam diferentes formas de realizar roteamento de mensagens, por exemplo, a partir do conteúdo da mensagem (usando XPath para navegar na mensagem), roteamento baseado em um serviço de regras e roteamento baseado em políticas.
Alguns barramentos permitem o controle de fila de mensagens a fim de que uma mensagem, quando enviada, seja persistida e não seja perdida. Este é o princípio dos mediadores orientados a mensagens
(ou MOM – Message Oriented Middleware), tais como MQ e JMS.

6 – Transformação
Dados representados em XML podem ser transformados utilizando XSLT e consultados utilizando XQuery e XPath. Estas tecnologias permitem preparar o dado para ser trafegado entre sistemas/serviços.
Se um modelo canônico está sendo utilizado, esta é uma característica importante de existir no ESB.

7 – Orquestração
Muitos ESB realizam orquestração através de um serviço de proxy, o qual coordena a execução de múltiplos serviços. Alguns barramentos delegam a orquestração para motores BPEL.

8 – Segurança
O barramento de serviços provê funcionalidades para garantir o uso de políticas de segurança em conjunto com pontos de garantia de políticas, SSL e SAML8 (Security Assertion Markup Language).

9 – Gerência de serviços
Serviços executando no ESB podem ser monitorados, auditados, mantidos e reconfigurados. No último caso, mudanças no processo podem ser feitas sem necessidade de reescrever serviços ou aplicações subjacentes, dependendo das modificações necessárias e dos serviços existentes.

Todos os pontos citados acima são de grande importância, mas gostaria de reforçar dois deles que são : Processo de Transformação e Orquestração.

Quanto ao processo de Transformação (para mim um dos pontos cruciais e de grande atenção), é o processo em que você capta dados de uma origem ( as vezes um Serviço que quer se comunicar com seu web service) e converte-o para o formato que sua estrutura entenda, “alimentando o campo correto” de sua estrutura.

Por exemplo, veja na imagem abaixo a transformação entre dois WSDLs distintos e observe que 3 atributos da Origem foram “CONCATENADOS” para gerar uma única informação.

Isto significa, que todas as vezes que existir uma comunicação entre esses serviços esta regra será aplicada.

Uma forma de evitar ou reduzir a necessidade de fazermos muitas transformações em nossos projetos é utilizar Modelagem Canônica.  Com uso de Modelagem Canônica podemos ter, por exemplo, um XSD ( um schema utilizado no serviço) compartilhado entre Consumidor e o Provedor de serviços para que a comunicação aconteça de forma eficaz.

Assim, o barramento traduz a mensagem para o formato esperado uma única vez e temos a vantagem de termos um XSD padrão que pode ser fornecido pra vários consumidores e não termos que ficar reinventando a roda.

Além desses fatores, tem um outro ponto que devemos ter atenção na transformação que é quando você faz a ligação entre os atributos. Você estará pegando dados de um WSDL e jogando no outro. Por isso a importância de conhecer bem a regra de negócio, para que problemas como esses sejam evitados.

Quanto ao processo de Orquestração, acredito que a definição depende muito da regra de negócio, assim como da metodologia de trabalho do Arquiteto do projeto.

Por exemplo, em alguns projetos que trabalho costumo deixar todo o CRUD no BPEL e a orquestração no OSB já que por ele posso ter recursos como :

  • Roteamento de Mensagens,
  • Enriquecimento,
  • Tratamento de erros,
  • Os Split Joins ( que são ferramentas fantásticas para processamento paralelo de mensagens),
  • entre outras coisas.

Então, em alguns casos já tenho por padrão trabalhar desta forma.

No entanto, existem projetos que precisam ser desenvolvidos de uma forma diferente, por exemplo quando precisamos colcoar a orquestração no BPEL, onde faz-se necessário manter um fluxo de atvidades imprimindo passo a passo como uma determinada regra de negócio funciona.

Atualmente eu trabalho diretamente com os produtos da Oracle, sendo assim, é a ferramenta que eu indico para quem gostaria de projetar Barramentos de Seriços para seus projetos.

No caso da Oracle nós temos o Oracle Service Bus ou OSB que está na versão 12C presente na Oracle SOA Suite. O OSB possui todas as características descritas acima e muito mais.

A partir de agora, desenvolveremos artigos que trarão exemplos de melhores práticas e como utilizar o OSB em seus projetos.

Por hora, fico por aqui.

Dúvidas, entre em contato.

Forte abraço.

Eduardo Santana.
bufallos@bufallos.com.br

 

Leave a Reply

Your email address will not be published. Required fields are marked *