O que é um barramento de serviço corporativo (ESB)?

Um ESB realiza transformações de modelos de dados, gerencia conectividade, faz o roteamento de mensagens, converte protocolos de comunicação e, potencialmente, gerencia a composição de várias requisições. O ESB pode disponibilizar essas integrações e transformações como uma interface de serviço reutilizável por novas aplicações.

O padrão ESB é normalmente implementado usando um tempo de execução e conjunto de ferramentas de integração especialmente projetados (ou seja, produto ESB) que garantem a produtividade máxima possível.

Um ESB é um componente essencial da SOA, ou arquitetura orientada a serviços, uma arquitetura de software que surgiu no final dos anos 90. A SOA define uma maneira de tornar os componentes de software reutilizáveis por meio de interfaces de serviço. Geralmente, esses serviços utilizam interfaces padrão (por exemplo, serviços web), permitindo sua rápida incorporação em novas aplicações, sem a necessidade de duplicar a funcionalidade realizada pelo serviço nas novas aplicações.

Cada serviço em uma SOA contém o código e os dados necessários para executar uma função de negócios completa e independente (por exemplo, verificar o crédito de um cliente, calcular o pagamento mensal de um empréstimo ou processar um pedido de hipoteca). As interfaces de serviço fornecem um acoplamento solto, o que significa que elas podem ser chamadas com pouco ou nenhum conhecimento de como o serviço é implementado abaixo, reduzindo as dependências entre as aplicações. As aplicações por trás da interface de serviço podem ser escritos em Java, Microsoft .Net, Cobol ou qualquer outra linguagem de programação, fornecidas como aplicações empresariais empacotadas por um fornecedor (por exemplo, SAP), aplicações SaaS (por exemplo, Salesforce CRM) ou obtidas como aplicações de código aberto.

As interfaces de serviço são frequentemente definidas usando WSDL (linguagem de definição de serviços da web), que é uma estrutura de marcação padrão baseada em XML (linguagem de marcação extensível). Os serviços são expostos utilizando protocolos de rede padrão, como SOAP (protocolo de acesso de objeto simples)/HTTP ou JSON/HTTP, para enviar solicitações para ler ou alterar dados. A governança de serviços controla o ciclo de vida do desenvolvimento e, no estágio apropriado, os serviços são publicados em um registro que permite aos desenvolvedores encontrá-los e reutilizá-los com rapidez para montar novas aplicações ou processos de negócios.

Os serviços podem ser criados do zero, mas geralmente são criados expondo funções de sistemas de registro legados. As empresas podem optar por fornecer uma interface de serviço baseada em padrões na frente dos sistemas legados, usar o ESB para se conectar diretamente ao sistema legado por meio de um adaptador ou conector, ou o aplicativo pode fornecer sua própria API. Em qualquer caso, o barramento de serviço empresarial protege o novo aplicativo da interface legada. Um ESB realiza a transformação e o roteamento necessários para se conectar ao serviço do sistema legado.

É possível implementar um SOA sem uma arquitetura ESB, mas isso seria equivalente a apenas ter um monte de serviços. Cada proprietário de aplicativo precisaria se conectar diretamente a qualquer serviço necessário e realizar as transformações de dados necessárias para atender a cada uma das interfaces de serviço. Isso dá muito trabalho (mesmo que as interfaces sejam reutilizáveis) e cria desafios significativos de manutenção no futuro, pois cada conexão é ponto a ponto.

Em teoria, um ESB centralizado oferece o potencial de padronizar e simplificar drasticamente a comunicação, as mensagens e a integração entre serviços em toda a empresa. Os custos de hardware e software podem ser compartilhados, provisionando os servidores conforme necessário para o uso combinado, oferecendo uma solução centralizada escalável. Uma única equipe de especialistas pode ser encarregada (e, se necessário, treinada) de desenvolver e manter as integrações.

Os aplicações de software simplesmente se conectam (“conversam”) ao ESB e deixam que o ESB transforme os protocolos, roteie as mensagens e se transforme nos formatos de dados conforme necessário, fornecendo a interoperabilidade para que as transações sejam executadas. A abordagem de arquitetura de barramento de serviços corporativo atende a cenários para integração de aplicações, integração de dados e automação de processos de negócios no estilo de orquestração de serviços. Isso permite que os desenvolvedores gastem bem menos tempo integrando e muito mais tempo se concentrando em fornecer e melhorar suas aplicações. E a capacidade de reutilizar essas integrações de um projeto para o próximo oferecia o potencial de ganhos de produtividade e economia ainda maiores no futuro.

Mas embora os ESBs tenham sido implementados com sucesso em muitas organizações, em muitas outras organizações, o ESB passou a ser visto como o gargalo. Fazer alterações ou melhorias em uma integração pode desestabilizar outras pessoas que usaram essa mesma integração. As atualizações do middleware ESB geralmente afetavam as integrações existentes, portanto, havia testes significativos necessários para executar qualquer atualização. Como a ESB foi gerenciada centralmente, as equipes de aplicativos logo se encontraram esperando na fila por suas integrações. Com o aumento do volume de integrações, a implementação de alta disponibilidade e recuperação após desastres para os servidores ESB se tornou mais cara. E como um projeto entre empresas, o ESB se mostrou difícil de financiar, tornando esses desafios técnicos muito mais difíceis de resolver.

Em última análise, os desafios de manter, atualizar e dimensionar um ESB centralizado se mostraram tão avassaladores e caros que o ESB frequentemente atrasava os próprios ganhos de produtividade que ele e a SOA pretendiam proporcionar, frustrando as equipes de negócios que antecipavam um ritmo maior de inovação.

Para uma análise mais aprofundada da ascensão e queda do ESB, leia “O destino do ESB”.

A arquitetura de microsserviços permite que os componentes internos de uma única aplicação sejam divididos em pequenas partes que podem ser alteradas, escaladas e administradas de forma independente. Os microsserviços surgiram e ganharam força com o aumento da virtualização, da computação em nuvem, das práticas de desenvolvimento ágil e do DevOps. Nesses contextos, os microsserviços oferecem o seguinte:

• Maior agilidade e produtividade do desenvolvedor, permitindo que os desenvolvedores incorporem novas tecnologias em uma parte da aplicação sem afetar o restante dela.
• Escalabilidade mais simples e econômica permitindo que qualquer componente seja dimensionado independentemente de outros, para obter a resposta mais rápida possível às demandas de carga de trabalho e ao uso mais eficiente dos recursos de computação.
• Maior resiliência, pois a falha de um componente não afeta os outros, e cada microsserviço pode atender aos seus próprios requisitos de disponibilidade sem impor um requisito de "maior disponibilidade comum" aos outros componentes.

A mesma granularidade que os microsserviços trazem para o design de aplicações pode ser aplicada à integração, com benefícios semelhantes. Esta é a ideia por trás da integração ágil, que divide o ESB em componentes de integração descentralizados e refinados, sem interdependências, que equipes de aplicações individuais podem possuir e gerenciar por conta própria.