O que é ESB (enterprise service bus)?

Um ESB é um componente essencial da SOA, ou arquitetura orientada a serviços, uma arquitetura de software que surgiu no final dos anos.

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 novos aplicativos, sem a necessidade de duplicar a funcionalidade realizada pelo serviço nos novos aplicativos.

Cada serviço em uma Arquitetura Orientada a Serviços (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 os aplicativos.

Os aplicativos por trás da interface de serviço podem ser escritos em Java, Microsoft .Net, Cobol ou qualquer outra linguagem de programação, fornecidos como aplicativos empresariais empacotados por um fornecedor (por exemplo, SAP), aplicativos SaaS (por exemplo, Salesforce CRM) ou obtidos como aplicativos de código aberto. 

As interfaces de serviço são frequentemente definidas usando a Linguagem de Definição de Serviço da Web (WSDL), 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 rapidamente para montar novos aplicativos 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, a 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 aplicativos 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 arquitetônica de barramento de serviço corporativo oferece suporte a cenários para integração de aplicativos, 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 significativamente menos tempo integrando e muito mais tempo se concentrando em fornecer e melhorar seus aplicativos. E a capacidade de reutilizar essas integrações de um projeto para o próximo oferece o potencial para ganhos de produtividade ainda maiores e economia a jusante.

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 um mergulho mais profundo na ascensão e queda do ESB, leia "O destino do ESB".

A arquitetura de microsserviços permite que os componentes internos de um único aplicativo sejam divididos em pequenas partes que podem ser alteradas, dimensionadas 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 do aplicativo sem afetar o restante do aplicativo. 
  
  
• 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 aplicativos 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 aplicativos individuais podem possuir e gerenciar a si mesmas.