Olá pessoal!

Frequentemente sou questionado com relação a quando a utilização de um ESB (Enterprise Service Bus ou Barramento de Serviços Corporativo) é interessante em um dado cenário de integração ou não. Espero que este post ajude a esclarecer a esta dúvida, bem como a elucidar as principais funcionalidades que se pode tirar proveito quando se emprega uma ferramenta robusta como esta. Vamos lá!

Em geral, um Enterprise Service Bus está relacionado a estratégias de arquiteturas orientadas a serviço (SOA), com o objetivo de proporcionar a disponibilização de serviços em um local único e centralizado, alavancando reuso, diminuindo acoplamento entre consumidores e provedores de serviços, o que por sua vez reduz significativamente a dependência entre ambos, de forma que manutenções – que, diga-se de passagem, são inevitáveis – possam ser feitas de forma mais tranquila. Todos estes fatores apoiam na redução de custos, seja pela manutenção facilitada (ou com baixo impacto), seja pelo reuso proporcionado.

Uma arquitetura onde há integração entre aplicações através de serviços, que não conta com o emprego de um barramento de serviços, corre o risco de se tornar o que é conhecido como arquitetura espaguete (veja diagrama representando tal arquitetura à esquerda), onde consumidores de serviços dependem diretamente de provedores de serviços. O nome arquitetura espaguete vem da quantidade de “fios” (dependências) que as múltiplas conexões entre consumidores e provedores vêm a gerar. Neste tipo de arquitetura, uma alteração em um serviço pode afetar diversos consumidores de uma só vez, o que pode envolver não só custos com a adaptação de tais consumidores, como também toda uma coordenação quando da publicação da nova versão do serviço, para que seus dependentes não parem de funcionar.

Um barramento de serviços proporciona desacoplamento entre consumidores e provedores de serviços, já que os consumidores não conhecem diretamente quem está provendo o serviço. Alterações em tais provedores de serviços podem impactar diretamente o ESB, mas em geral são transparentes para os consumidores de serviços. Veja no diagrama à direita uma representação da mesma arquitetura apresentada anteriormente, com o emprego de um ESB.

Além deste fator de extrema importância, o livro Service Design Patterns de Robert Daigneau destaca três principais funções de um barramento de serviços: Roteamento de Mensagens, Tradução de Mensagens e Tradução de Protocolo. Vejam a seguir maiores detalhes sobre cada uma destas funções.

Roteamento de Mensagens

Como vimos anteriormente, ESBs são capazes de encaminhar requisições para serviços e enviar respostas de volta para clientes, com o objetivo de prover aos clientes uma forma de chamar serviços que minimiza a dependência entre ambos. Neste sentido, um ESB funciona como uma camada de indireção que permite que a inclusão, atualização, substituição e remoção de serviços aconteçam sem necessariamente impactar consumidores de serviços.

Para tal, em um ESB são criados o que é conhecido como Virtual Services (serviços virtuais), que se parecem com os serviços reais (contratos semelhantes ou exatamente iguais), mas que simplesmente provêm um endpoint (porta de entrada) para o recebimento e posterior endereçamento de mensagens. Uma vez que o serviço virtual seja acionado, o ESB pode direcionar a mensagem para o serviço apropriado, de acordo com regras definidas. A decisão pelo serviço a ser acionado pode ser tomada com base no conteúdo do pacote SOAP (como por exemplo a tag SOAPAction), ou de acordo com cabeçalhos que seguem a especificação WS-Addressing. Padrões de URI (abordagens REST, por exemplo), ou conteúdos da mensagem em si também podem ser considerados para este fim.

Tradução de Mensagens

Um ESB também pode ser usado para traduzir ou transformar mensagens enviadas por consumidores de serviços para um padrão específico esperado pelos provedores de serviço. São diversas as situações em que se pode desejar fazer tal tradução. Vejamos algumas.

A utilização do padrão Canonical Data Model frequentemente requer a tradução de mensagens entre consumidores e provedores de serviços. Em resumo, tal padrão tem como objetivo minimizar dependências entre aplicações que usam modelos de dados distintos para descrever o mesmo conjunto de entidades (cliente, fornecedor, produto, etc.). Para tal, o padrão prega que deve ser estabelecida uma forma única de descrever cada uma das entidades da companhia, e que tal forma seja utilizada quando aplicações distintas precisem conversar sobre as mesmas entidades. Neste contexto, um ESB pode ser utilizado para transformar mensagens recebidas no formato do modelo canônico estabelecido, para o padrão específico que a aplicação destino espera receber. Confira o cenário descrito no diagrama de sequencia a seguir.

Outro cenário é o caso de composição de serviços. Suponha que para realizar uma determinada tarefa seja necessário acionar dois serviços distintos. Com o objetivo de não impor a cada uma das aplicações consumidoras a responsabilidade de acionar os dois serviços na ordem correta, um ESB pode prover, através de um serviço virtual, uma interface única para a realização de tal tarefa. Os dados requeridos por ambos os serviços seriam unidos nesta interface, que uma vez acionada, disparará a transformação do conteúdo da mensagem recebida, separando os campos específicos que cada um dos dois serviços destino espera receber.

Tradução de protocolo

Considere o seguinte cenário fictício. Diversas aplicações em uma organização precisam se integrar com um pacote de mercado, como um ERP, por exemplo. Tal pacote de mercado provê interfaces para integração, porém por não ser dos melhores ERPs, tais interfaces são em um padrão específico apenas, como por exemplo, JMS. No nosso cenário, o padrão JMS não condiz com o padrão corporativo da organização, que prefere utilizar o protocolo HTTP, com mensagens no formato XML/SOAP. Para que todas as aplicações que precisam se integrar com o tal ERP não precisem se adaptar ao seu padrão, podemos utilizar o ESB como um tradutor de protocolo, responsável por intermediar a comunicação entre as aplicações consumidoras e o provedor de serviços, que no nosso caso é o ERP. Para isso, uma vez que as aplicações consumidoras chamem um serviço virtual criado no ESB, utilizando o padrão adotado na companhia (HTTP com XML sobre SOAP), haverá possivelmente a tradução da mensagem para o padrão esperado pelo ERP e certamente a tradução do protocolo, através da utilização de uma API JMS especifica que será responsável por encaminhar a mensagem para o ERP.

Desta forma, além de não acoplar as aplicações da companhia com um padrão que não é tido como corporativo, ou que muitas vezes pode não ser viável para determinadas tecnologias de aplicações consumidoras, numa eventual substituição do tal ERP, as aplicações que se integram com ele não necessariamente seriam impactadas.

Outras funções

Além das principais funções listadas, existem outras funções que ESBs robustos implementam. Vejamos abaixo um breve resumo sobre algumas delas.

Garantia de Entrega. Se um dado serviço está indisponível, o ESB pode persistir a mensagem em um repositório interno e tentar enviá-la novamente, usando o padrão Idempotent Retry Pattern, já descrito aqui em posts anteriores.

Funções genéricas como autenticação, autorização e logging, tirando dos provedores de serviços tais responsabilidades, além de garantir que determinadas politicas sejam aplicadas de forma consistente na companhia.

Comunicação com ferramentas de monitoramento de negócios (BAM, por exemplo). Uma vez que dados que servem como base para formação de KPIs (Key Process Indicators ou Indicadores Chave de Processos) passem pelo ESB, o mesmo pode direcioná-los para ferramentas que permitem agregar tais informações, de forma a disponibilizá-las em tempo real para visualização.

E assim ficamos por aqui! Até a próxima.