As principais funções de um ESB (Enterprise Service Bus)

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á!

Arquitetura Espaguete

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 Arquitetura Orientada a Serviços com a Utilização de um ESBespaguete (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.

Diagrama de sequencia demonstrando exemplo de fluxo de tradução de mensagens

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.

3 ideias sobre “As principais funções de um ESB (Enterprise Service Bus)

  1. Danilo Régis

    Boa Nelson! Muito bom o post!

    Eu costumo sugerir um ESB para as empresas que me questionam sobre justamente por saber que terei menos problemas como client uma vez que o ESB costuma ter um padrão mais compatível que muitos webservices, como Protheus ou Totvs por exemplo.

    Mas tenho uma dúvida, você sabe me dizer se o SAP XI/PI seria um ESB? Pois se for sai totalmente da proposta de ter uma padrão acessível… Em alguns lugares já vi que ele está mais para um “hub-and-spoke middleware”.

    Abraços!

  2. Nelson Bassetto Autor do post

    Fala Régis!

    Obrigado!

    É isso ai. ESBs em geral trazem um conjunto de adapters que se conectam a diversas tecnologias / protocolos. Adapters adicionais podem ainda ser adquiridos, se necessário.

    No caso do SAP PI, confesso que nunca o estudei em detalhes. Conheço bem o Oracle SOA Suite, que contém o Oracle Service Bus. Aonde estou trabalhando agora também temos o webMethods, da Software AG.

    Porém, em uma pesquisa rápida, tive o mesmo entendimento que o seu. Veja só a descrição abaixo:

    SAP calls PI an integration broker because it mediates between entities with varying requirements in terms of connectivity, format, and protocols. According to SAP, PI reduces the TCO by providing a common repository for interfaces. The central component of SAP PI is the SAP Integration Server, which facilitates interaction between diverse operating systems and applications across internal and external networked computer systems.

    Como o investimento em um ESB é alto e o ROI vem a médio/longo prazo, é sempre interessante consultar uma entidade confiável como o Gartner e/ou o Forrester antes de optar por um produto desses. Veja no link abaixo a classificação de 2011, segundo o Gartner, sobre as empresas com visão mais completa e habilidade de execução, no que diz respeito a Enterprise Service Bus.

    Gartner Magic Quadrant – Enterprise Service Bus – as of 2011

  3. Leandro Silva

    Nelson, muito bom o post!

    Respondendo os comentários acima…

    Sou consultor de SAP XI/PI e tive a oportunidade de trabalhar com o Oracle SOA Suite por mais de um ano em um projeto em São Paulo. A SAP investiu muito no SAP Netweaver Process Integration (PI) antigo SAP Exchange Infrastructure (XI), hoje a versão SAP PI 7.3 (desde a versão 7.1) já “fala” SOA.

    A versão SAP NetWeaver 7.3 contém…

    Service Regitry: Based on the UDDI v3 standard for publishing and discovering services, Services Registry offers interoperable third-party tools…
    – BAM (Business Activity Monitoring)
    – BRM (Business Rules Management)
    – BPMN (Representation of an integration scenario)

    A respeito do Gartner a SAP esta bem posicionada…

    Percebi que no Brasil o pessoal SAP é muito fechado! Muito difícil encontrar integrações utilizando o SAP PI como um barramento corporativo, na verdade participei de um projeto global que estavam utilizando o modelo canônico! Bem interessante quando bem utilizado.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*